Difference between revisions of "Snowstorm Sprint Retrospective Archive"

From Second Life Wiki
Jump to navigation Jump to search
(Created page with '=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 muc...')
 
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
=Snowstorm Sprint 2 Retrospective=
{{Project Snowstorm Nav}}
Date: Tue Aug 31, 2010
__TOC__
<br clear="all"/>


==Team Feedback==
=Snowstorm Sprint 7 Retrospective =
Date: Mon Nov 15, 2010


===OZ===
== Team Feedback ==
What went well?


  * Not alot. Things were chaotic and difficult.
=== Merov ===
  * 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.
Good:
  * Concerned about what happens as the rate of pull requests goes up, if we scale.
* Time track work better though we still need to do a better job
* 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.
* 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


  * OOO for most of the last sprint
===Oz ===
  * Trying to find grounding in the new process.
Good:
  * Like the legacy repo conversion process, like the documentation
* group communication worked extremely well
  * The branch that did drop out of that was a relatively smooth integration.
* made lots of progress communicating with community
  * Particularly good when Tofu as the merge monkey is not the same person as the person who wrote the code.
* handled several integration & beta release minor crises and not have it disrupt everything we’re doing
What could we do better?


  * Would like a list of relevant URLs.
Needs Improvement:
  * What is the process for finding reviews open.
* trouble focusing on coding tasks
===AIMEE===
* time is too fragmented
What went well?
* need a way to take quick & easy patches - use RB & has proposal for fast path


  * Can't think of things other than what Tofu said
===Esbee===
What could we do better?


  * Get settled into new process. We should improve
Esbee had nothing good to say.
  * The convert process could use some clean up
===MEROV===
What went well?


  * Couple of things went well!
Needs Improvement:
  * Scrum worked well. Lots of focus.  
* Need to stagger design and development across sprints. (IE. Prim alignment, Keyboard Shortcuts, etc.)
  * Issue with LLKDU, working with Chopper Got more done than we thought we would
* 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 could we do better?
We can determine this during sprint planning by marking tickets for which we want to create a project viewer.


  * Improve the review process
===Anya===
  * 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
* beginning of sprint - not enough work - end of sprint - not enough time
  * 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.
===Resident Feedback===
  * 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
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.
What could we do better?
* this issue is not lost and will be included in the next sprint. 


  * Improve communication - I need a pull!
  * Update the sprint backlog _Daily_
  * No extra issues added to sprint backlog after sprint planning meeting


EXTRA
==Improvement & action plan:==
Sprint backlog versus Product Backlog - never just say backlog!


===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


==RESIDENT FEEDBACK==
===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


===Cummere Mayo===
===Project viewer for larger changes===
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.
* named branch in a forked repo? Fork?
  2. allot of non LL devs find the new process confusing and not well documented yet (suggest workign with documenttation on that)
* project viewer before merging back into viewer-dev
  3. those that purely testers like me havent seen how we can be involved yet
** code review
reinterates 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?
** product owner review


=ACTION PLAN - IMPROVEMENT=
= Past Retrospectives =
 
[[Snowstorm_Sprint_Retrospective_Sprint_2 | Sprint 2]]
==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 cue, 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.

Latest revision as of 16:15, 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=1106932"