<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><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><br></div><div>Some top issues may be resolved quickly, in a single iteration, or by a single person. Some issues may be at the top of the pile for a long time because no one on the team can figure out a solution. And the most interesting case, some issues that start out with few votes become more and more important until they become a high priority. </div>
<div><br></div><div>This approach accomplishes several things: first of all, it makes sure that the highest-priority issues are addressed by the whole team immediately. Beyond that though, over time it ensures that important issues of long standing do not become the status quo. </div>
<div><br></div><div>An example from my own experience: on one team at Thoughtworks, the QA people had a problem managing test data. In early iterations, this was a low priority, as it did not affect the whole team, and other issues took priority in voting. As the project went on though, the lack of test data affected more and more people on the team. The shepherd for the test-data issues changed over the iterations, even the senior "Architect" on the project had no solution for the iterations where he was the spokesperson for the test-data issue; the issue became more and more important to everyone, and no one had a solution. Eventually the test data problem was solved by someone who joined the team-- the issue had bubbled to the top of the list over many sprints, and the new person was able to solve the problem given the deep exploration by the whole team. </div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 4:52 PM, Tomasz Finc <span dir="ltr"><<a href="mailto:tfinc@wikimedia.org" target="_blank">tfinc@wikimedia.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Dec 9, 2013 at 3:47 PM, Steven Walling <<a href="mailto:swalling@wikimedia.org">swalling@wikimedia.org</a>> wrote:<br>
> My first question is when should I schedule our retrospectives? For context,<br>
> Growth is in the tail end of our fifth sprint, and sprint planning/kickoff<br>
> meetings happen on Wednesdays for us.<br>
<br>
</div>Apps do them every two iterations.<br>
<br>
Whenever we try anything new we like at least two iterations (4 weeks)<br>
to be able to really assess any change and know wether it was<br>
consistent or a fluke.<br>
<br>
It's worked incredibly well for us to validate changes and assess progress.<br>
<br>
If they start to become thin then i'll likely make them quarterly<br>
and/or if they become too packed then we'll go to weeklies.<br>
<br>
--tomasz<br>
<br>
_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
</blockquote></div><br></div>