[teampractices] Retrospectives

[Chris McMahon]

I'll suggest you do a retrospective for every sprint.  These retrospectives
should have three aspects:

What went well:  celebrate your successes, you deserve it.
What did not go well: make a list of issues encountered during the last
sprint
What to improve:  this is where it gets interesting...

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.

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.

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.

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.









On Mon, Dec 9, 2013 at 4:52 PM, Tomasz Finc <tfinc at wikimedia.org> wrote:

> On Mon, Dec 9, 2013 at 3:47 PM, Steven Walling <swalling at wikimedia.org>
> wrote:
> > 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.
>
> Apps do them every two iterations.
>
> Whenever we try anything new we like at least two iterations (4 weeks)
> to be able to really assess any change and know wether it was
> consistent or a fluke.
>
> It's worked incredibly well for us to validate changes and assess progress.
>
> If they start to become thin then i'll likely make them quarterly
> and/or if they become too packed then we'll go to weeklies.
>
> --tomasz
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20131209/7b507329/attachment.html>