Difference between revisions of "Snowstorm Sprint Retrospective Archive"

From Second Life Wiki
Jump to navigation Jump to search
m (Spelling, typos)
Line 1: Line 1:
=Snowstorm Sprint 2 Retrospective=
=Snowstorm Sprint 7 Retrospective =
Date: Tue Aug 31, 2010
Date: Mon Nov 15, 2010


==Team Feedback==
== Team Feedback ==


===OZ===
=== Merov ===
What went well?
* Not a lot. Things were chaotic and difficult.
* Can't think of much good to say except that we got through it. And we got a lot done.
* We did get some contributions from OS. 


What could we do better?
Good:
* Work out better ways of organizing contributions from open source contributors. Not satisfied we're there yet.
* Time track work better though we still need to do a better job
* Concerned about what happens as the rate of pull requests goes up, if we scale.
* Got traction on "big" items, not just bug fixes


===TOFU===
Needs Improvement:
What went well?
* We're doing a good job with small things but not that good with bigger ones. My own experience shows that 2 weeks is to short to design/socialize/review/code/iterate on anything.
* OOO for most of the last sprint
* Time and work load not used consistently, so the burn rate and dashboard cannot be trusted. Please update the work spent and remaining time!
* Trying to find grounding in the new process.  
* We still need a way to pick patches from community faster
* Like the legacy repo conversion process, like the documentation
* The branch that did drop out of that was a relatively smooth integration.
* Particularly good when Tofu as the merge monkey is not the same person as the person who wrote the code.


What could we do better?
===Oz ===
* Would like a list of relevant URLs.
Good:
* What is the process for finding reviews open.
* group communication worked extremely well
* made lots of progress communicating with community
* handled several integration & beta release minor crises and not have it disrupt everything we’re doing


===AIMEE===
Needs Improvement:
What went well?
* trouble focusing on coding tasks
* Can't think of things other than what Tofu said
* time is too fragmented
* need a way to take quick & easy patches - use RB & has proposal for fast path


What could we do better?
===Esbee===
* Get settled into new process. We should improve
* The convert process could use some clean up


===MEROV===
Esbee had nothing good to say.
What went well?
* Couple of things went well!
* Scrum worked well. Lots of focus.
* Issue with LLKDU, working with Chopper Got more done than we thought we would


What could we do better?
Needs Improvement:
* Improve the review process
* Need to stagger design and development across sprints. (IE. Prim alignment, Keyboard Shortcuts, etc.)
* Wasting cycles waiting to get reviews complete
* On a case by case basis, I think we need to consider creating project branches for stories we pick up so we don't have non-functional code sitting in viewer-development.
* What about when code is done
We can determine this during sprint planning by marking tickets for which we want to create a project viewer.
* Too many tools, Jira to spreadsheet, PE reveiws - single unified way to access backlog.  
* Making sure we get things from the community faster


===ANYA===
===Anya===
What went well?
* Working off the backlog
* Got EXTs in backlog
* Short durations are great
* Appreciated having a Scrum Sprint Backlog


What could we do better?
* beginning of sprint - not enough work - end of sprint - not enough time
* The process is still awkward for us.
* Suggestions sent via email.
* Consider making the review board publicly available on Linden servers (free and could be installed)
* Maybe figure out a way to use our QA resource before a pull
* There's not enough detail in the task description, lots of TBDs, not a lot of opportunities to figure those out.
* Feels like process is too heavy for short fixes, how do we work faster (burst of code fixes in one commit)


===ESBEE===
===Resident Feedback===
What went well?
* Good team focus, lots of on the fly problem solving


What could we do better?
Boroondas Gupte: Where communication went a bit wrong (I'm partly to blame about that myself, I guess) is VWR-23826 . WolfPup asked me to test the STORM-102 branch, where I noticed that.  I've asked Oz what info would be needed from me to fix this before it hits viewer-dev, but I still don't know what I have to provide.
* Improve communication - I need a pull!
* this issue is not lost and will be included in the next sprint. 
* Update the sprint backlog _Daily_
* No extra issues added to sprint backlog after sprint planning meeting


==EXTRA==
* Sprint backlog versus Product Backlog - never just say backlog!


==Improvement & action plan:==


==RESIDENT FEEDBACK==
===3-week sprint===
===Cummere Mayo===
* doing things in the open takes more time
3 things i have noticed.
* Sprint 8 will be a 3-week sprint. At the end we will review and consider whether to keep this going forward.
# a lot of bugfixes that need done in order to accomplish what LL has stated are short or medium turn plans dont seem to be a priority and the residents cant seem to make them more.
* still need to stagger design & socialization work so we have enough at the beginning of a sprint
# a lot of non LL devs find the new process confusing and not well documented yet (suggest working with documentation on that)
# those that purely testers like me havent seen how we can be involved yet


reiterates the idea of reviving or remaking the bsi group for testing. also wonders maybe for helping keep bugs that are needed to be fixed or at least should be fixed for major products, find a couple of expereinced testers to troll through the forums and the jiras to tag items that are being brought up and forwarding them to someone from triage to make sure they get on the agenda instead of relying solely on the filter system?
===Update dashboard daily so we can use results===
* give ourselves credit for what we do, and give ourselves data for better analysis.
* grumpity to follow up personal tracking in jira
* add merge monkey task in jira and assign back & forth during sprint
* beta build task
* best practices sharing.
* oz to propose a proposal for quick updates


===Project viewer for larger changes===


=ACTION PLAN - IMPROVEMENT=
* named branch in a forked repo? Fork?
* project viewer before merging back into viewer-dev
** code review
** product owner review


==SPRINT BACKLOG==
= Past Retrospectives =
* Update time remaining every day
[[Snowstorm_Sprint_Retrospective_Sprint 2 | Sprint 2]]
* We're moving to GH soon, so we'll do away with spreadsheets.
 
==BUG FIXES/MAINTENANCE==
* Get bugs on the backlog
* Flexibility for crashers and things that come up along the way.
* Tofu: Would it help to have a task that rolls over from week to week?
 
==TRIAGE==
* Patch, versus bug, versus new feature request triage. Esbee and Q working out the details.
* There is also the triage of patches that people process that people propose on VWR. We don't look at those. We have lots of low-hanging fruit.
 
==ORGANIZING CONTRIBUTIONS FROM OS CONTRIBUTORS==
* Oz has 4 people signing up for work this sprint
* Oz hopes he hasn't dropped anybody
* Simple and obvious fixes - button mislabeled -
* Hate to be in the position of pushing back on things that are
* Fast track for easy things, leave some space for planning
* Lines of change threshold
* Consider implications of fast track changes - documentation, support, localization
* Pretty sure we have an opportunity to do fast and easy stuff
* Hate to be in the way of doing that.
 
==HOW WE SCALE ONCE THE RATE OF PULL REQUESTS GOES UP?==
* Merge monkey? Would it work to assign people day to day
** Rotating responsibilities for pulls could work. Could be too heavy on one person (works for the release team)
* Pulls are going to get easier as people can sync better
** An hour and a half ot two hour cycle. You don't really want ot check something into viewer-development if you're not sure it's going to build on all platforms.
** Pull, build, then do the push. It's a longer window.
* Before a build gets into the queue, we have an assurance it's been built on all platforms.
* Oz us thinking about how to make that easier for open source developers. In the absence of an automatic way, for people who don't have the resources. Anyone working on something and needs help working on build across all platforms and we'll see if we can advertise getting that done.
 
==QA RESOURCES==
* We have a dedicated QA resource from PE. How can we better use them?
** Andrey is the QA person.
* Testing of bugs, user stories, patches coming in.
* From Anya:
** he will test daily builds from viewer-development
** he will share the spreadsheet with the snowstorm team where he will track results
** and we will figure out a process to review those results as part of our sprint at some point i guess
** additionally tho, we should be able to use Andrey to test _before_ commits
 
===END OF SPRINT DEVELOPMENT VIEWER BUILDS===
* Test the build. Tag it.
* Tagging it is great. And CG suggested a tag to our teamcity set up. The diff since the last instance of the end of sprint tag.
* Build should be finalized the last day of the two week Sprint, Monday.

Revision as of 16:13, 15 November 2010

Snowstorm Sprint 7 Retrospective

Date: Mon Nov 15, 2010

Team Feedback

Merov

Good:

  • Time track work better though we still need to do a better job
  • Got traction on "big" items, not just bug fixes

Needs Improvement:

  • We're doing a good job with small things but not that good with bigger ones. My own experience shows that 2 weeks is to short to design/socialize/review/code/iterate on anything.
  • Time and work load not used consistently, so the burn rate and dashboard cannot be trusted. Please update the work spent and remaining time!
  • We still need a way to pick patches from community faster

Oz

Good:

  • group communication worked extremely well
  • made lots of progress communicating with community
  • handled several integration & beta release minor crises and not have it disrupt everything we’re doing

Needs Improvement:

  • trouble focusing on coding tasks
  • time is too fragmented
  • need a way to take quick & easy patches - use RB & has proposal for fast path

Esbee

Esbee had nothing good to say.

Needs Improvement:

  • Need to stagger design and development across sprints. (IE. Prim alignment, Keyboard Shortcuts, etc.)
  • On a case by case basis, I think we need to consider creating project branches for stories we pick up so we don't have non-functional code sitting in viewer-development.

We can determine this during sprint planning by marking tickets for which we want to create a project viewer.

Anya

  • beginning of sprint - not enough work - end of sprint - not enough time

Resident Feedback

Boroondas Gupte: Where communication went a bit wrong (I'm partly to blame about that myself, I guess) is VWR-23826 . WolfPup asked me to test the STORM-102 branch, where I noticed that. I've asked Oz what info would be needed from me to fix this before it hits viewer-dev, but I still don't know what I have to provide.

  • this issue is not lost and will be included in the next sprint.


Improvement & action plan:

3-week sprint

  • doing things in the open takes more time
  • Sprint 8 will be a 3-week sprint. At the end we will review and consider whether to keep this going forward.
  • still need to stagger design & socialization work so we have enough at the beginning of a sprint

Update dashboard daily so we can use results

  • give ourselves credit for what we do, and give ourselves data for better analysis.
  • grumpity to follow up personal tracking in jira
  • add merge monkey task in jira and assign back & forth during sprint
  • beta build task
  • best practices sharing.
  • oz to propose a proposal for quick updates

Project viewer for larger changes

  • named branch in a forked repo? Fork?
  • project viewer before merging back into viewer-dev
    • code review
    • product owner review

Past Retrospectives

Sprint 2

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Snowstorm_Sprint_Retrospective_Archive&oldid=1106912"