I started a while back a wiki ( https://www.mediawiki.org/wiki/Analytics/ScrumRetrospective) explaining the 5 why's method if you want to dig deeper into a problem. The wiki contains some useful references and examples. D
On Mon, Dec 9, 2013 at 7:36 PM, Arthur Richards <[email protected]>wrote: > > On Mon, Dec 9, 2013 at 4:47 PM, Steven Walling <[email protected]>wrote: > >> Hey all, >> >> So one of the pieces of feedback out of our Quarterly Review last week >> for the Growth team is that we should probably start doing retrospectives >> to improve our process. >> >> I understand the theory behind retrospectives as a product owner, but >> since we don't have a scrum master, I wanted to ask Arthur, Tomasz, Katie >> and others about them. >> >> My first question is *when *should I schedule our retrospectives? For >> context, Growth is in the tail end of our fifth sprint, and sprint >> planning/kickoff meetings happen on Wednesdays for us. >> > > Whenever your team needs them. > > The retrospective is one potential response to agile principle #12 ( > http://agilemanifesto.org/principles.html): > At regular intervals, the team reflects on how to become more effective, > then tunes and adjusts its behavior accordingly. > > In Scrum, retrospectives traditionally happen at the end of every > iteration, prior to kicking off the next iteration. The mobile web team > used to adhere strictly to this, but after a while the team decided to make > them less frequent, as the sprintly retrospectives were starting to feel > less useful. We switched to another extreme - doing them quarterly. This > started to feel too infrequent, and now we are doing them every two > iterations. > > Personally, I find having the retrospective at the end of the cycle to > feel really good - it's a natural break point. It allows us to focus on the > work at hand during the course of a cycle (or two), and bring up the things > that aren't working in a structured way that minimizes context switching > during the middle of a cycle. At least that's the theory; we have a > tendency to bring up issues as they happen and sometimes get bogged down in > discussion over email, etc mid-sprint, but tend to hold off on more serious > discussion/decision making until the retrospective. Anyway, I think ideal > timing probably depends on what the rest of your development cycle/workflow > is like and what the team needs. I think the important thing is that you do > them with enough frequency to catch issues early, and have a structured > time/space to acknowledge the things that are going really well. > > -- > Arthur Richards > Software Engineer, Mobile > [[User:Awjrichards]] > IRC: awjr > +1-415-839-6885 x6687 > > _______________________________________________ > teampractices mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/teampractices > >
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
