<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 5:24 PM, Chris McMahon <span dir="ltr"><<a href="mailto:cmcmahon@wikimedia.org" target="_blank">cmcmahon@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"><div><br></div>I'll suggest you do a retrospective for every sprint.  These retrospectives should have three aspects: <div>
<br></div><div>What went well:  celebrate your successes, you deserve it. </div>
<div>What did not go well: make a list of issues encountered during the last sprint</div><div>What to improve:  this is where it gets interesting... </div></div></blockquote><div><br></div><div>Mobile web has followed this format since we organized as an agile team, and personally I find it to be really useful. It's super lightweight and just enough structure.</div>
<div><br></div><div>I've been curious about trying out other approaches, as in some ways the formula has started to feel a little dry and, well, formulaic, but we haven't tried anything else out.</div><div> </div>
<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"><div><br></div><div>Take the list of things that did not go well and prepare to vote on them.  Everyone on the team gets some number of votes, 3 or 5 or whatever.  Everyone on the team can distribute their votes for improvement among the list of issues to be improved.  After voting, the top few issues (3 might be a good number) get assigned to some person, by volunteering, by the Scrum Master, by some mechanism. That person may not be the one to fix the issue, but that person is the one that shepherds the fixing and moves the fixing of the issue along. </div>
</div></blockquote><div><br></div><div>This is a really important point and I think this can make a real difference between a valuable retrospective and a total snoozefest. On the mobile web team, we chat super briefly about the things that didn't work - just enough so that everyone has some idea of the pain point. Then we speak more in-depth about the things the majority of folks feel are important. If we didn't do it this way and instead just spoke through all the negative things, we likely wouldn't get through all of it, and we'd likely spend a bunch of time on things that aren't as important for the team to address as a whole.</div>
<div><br></div></div>There's a great book out on the subject of retrospectives, and it's worth a read:</div><div class="gmail_extra"><a href="http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649">http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649</a><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>