Difference between revisions of "Snowstorm Sprint Retrospective Archive"

From Second Life Wiki
Jump to navigation Jump to search
m (Spelling, typos)
 
(2 intermediate revisions by the same user 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 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?
=== Merov ===
* 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===
Good:
What went well?
* Time track work better though we still need to do a better job
* OOO for most of the last sprint
* Got traction on "big" items, not just bug fixes
* 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?
Needs Improvement:
* Would like a list of relevant URLs.  
* 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.
* What is the process for finding reviews open.  
* 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


===AIMEE===
===Oz ===
What went well?
Good:
* Can't think of things other than what Tofu said
* 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


What could we do better?
Needs Improvement:
* Get settled into new process. We should improve
* trouble focusing on coding tasks
* The convert process could use some clean up
* time is too fragmented
* need a way to take quick & easy patches - use RB & has proposal for fast path


===MEROV===
===Esbee===
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?
Esbee had nothing good to say.
* 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===
Needs Improvement:
What went well?
* Need to stagger design and development across sprints. (IE. Prim alignment, Keyboard Shortcuts, etc.)
* Working off the backlog
* 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.
* Got EXTs in backlog
We can determine this during sprint planning by marking tickets for which we want to create a project viewer.
* Short durations are great
* Appreciated having a Scrum Sprint Backlog


What could we do better?
===Anya===
* 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===
* beginning of sprint - not enough work - end of sprint - not enough time
What went well?
* Good team focus, lots of on the fly problem solving


What could we do better?
===Resident Feedback===
* Improve communication - I need a pull!
* Update the sprint backlog _Daily_
* No extra issues added to sprint backlog after sprint planning meeting


==EXTRA==
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.
* Sprint backlog versus Product Backlog - never just say backlog!
* this issue is not lost and will be included in the next sprint. 




==RESIDENT FEEDBACK==
==Improvement & action plan:==
===Cummere Mayo===
3 things i have noticed.
# 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.
# 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?
===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


=ACTION PLAN - IMPROVEMENT=
===Project viewer for larger changes===


==SPRINT BACKLOG==
* named branch in a forked repo? Fork?
* Update time remaining every day
* project viewer before merging back into viewer-dev
* We're moving to GH soon, so we'll do away with spreadsheets.
** code review
** product owner review


==BUG FIXES/MAINTENANCE==
= Past Retrospectives =
* Get bugs on the backlog
[[Snowstorm_Sprint_Retrospective_Sprint_2 | Sprint 2]]
* 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.

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"