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
