<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 4:47 PM, Steven Walling <span dir="ltr"><<a href="mailto:swalling@wikimedia.org" target="_blank">swalling@wikimedia.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hey all,<div><br></div><div>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.</div>
<div>

<br></div><div>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.</div><div><br></div><div>My first question is <i>when </i>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. </div>
</div></blockquote><div><br></div><div>Whenever your team needs them.</div><div><br></div><div>The retrospective is one potential response to agile principle #12 (<a href="http://agilemanifesto.org/principles.html">http://agilemanifesto.org/principles.html</a>):</div>
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.</div><div class="gmail_quote"><div><br></div><div>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.</div>
</div><div class="gmail_extra"><br></div>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.<br clear="all">
<div><br></div>-- <br>Arthur Richards<div>Software Engineer, Mobile</div><div>[[User:Awjrichards]]</div><div>IRC: awjr</div><div>+1-415-839-6885 x6687</div>
</div></div>