Snowstorm Sprint Retrospective Archive

Snowstorm Sprint 2 Retrospective

Date: Tue Aug 31, 2010

Team Feedback

OZ

What went well?

• Not alot. 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?

• Work out better ways of organizing contributions from open source contributors. Not satisfied we're there yet.
• Concerned about what happens as the rate of pull requests goes up, if we scale.

TOFU

What went well?

• OOO for most of the last sprint
• Trying to find grounding in the new process.
• 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?

• Would like a list of relevant URLs.
• What is the process for finding reviews open.

AIMEE

What went well?

• Can't think of things other than what Tofu said

What could we do better?

• Get settled into new process. We should improve
• The convert process could use some clean up

MEROV

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?

• Improve the review process
• Wasting cycles waiting to get reviews complete
• What about when code is done
• Too many tools, Jira to spreadsheet, PE reveiws - single unified way to access backlog.
• Making sure we get things from the community faster

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?

• 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

What went well?

• Good team focus, lots of on the fly problem solving

What could we do better?

• Improve communication - I need a pull!
• 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!

RESIDENT FEEDBACK

Cummere Mayo

3 things i have noticed.

1. allot of bugfixes that need done in order to acopmplish 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.
2. allot of non LL devs find the new process confusing and not well documented yet (suggest workign with documenttation on that)
3. 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 bieng brought up and forwarding them to someone from triage to make sure they get on the agenda isntead of relying soley on the filter system?

ACTION PLAN - IMPROVEMENT

SPRINT BACKLOG

• Update time remaining every day
• 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, leae 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 absense 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 stroies, 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 suggseted 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.