How to improve your retrospective

Marc Löffler did a session about "How to improve your retrospective" past weekend at agile coach camp 2013. Result was a list of possibilites what you can do to improve your retrospective and maybe sometimes vary the usual format as described in "Agile Retrospectives".

Since the results speak for themselves, I will just post the photos of the results here:

The Definition of done workshop

Recently one team I take care of as a Scrum Master needed a Definition of Done. Since I couldn't find anything on the internet about a corresponding workshop or a good method to create a definition, I created a workshop based on the "Challenge Cards" method from the book "Gamestorming" (page 158). Here's how you do it:

Time needed:
About 30 - 60 minutes

Preparation:
Prepare green and red colored post its and a blank flip chart (or similar).

How to play:
Divide the team into two groups. One group is the problem group, they get the red post its. The other group is the DoD group, they get the green post its. Now give both groups 10 minutes time.

Ask the problem group to think of common problems the team encounters regarding development, which could be fixed by a definition of done. Examples would be "a lot of bugs", "released version doesn't work" or "duplicate data appears". Important: Point out that it's not about problems the team can't be made responsible for (kernel panic on a server for instance), but that it's about problems that occur due to errors made during development.

Ask the DoD group to come up with possible items for a definition of done. This can be anything they can think of.

After the 10 minutes, ask the problem group to post their first problem on the left side of the flip chart. Now ask the DoD group to post one or more items that can solve this one problem on the right side of the flip chart. Let them draw an arrow going from the DoD item(s) to the problem post it. Notice that there can be more than one DoD items solving a problem and that one DoD item can solve multiple problems. It is ok and desirable to draw arrows from already posted DoD items to a new problem.
Continue until all the problems have been posted.

Now there are 3 possible outcomes:

You still have DoD items left.
Ask the DoD group to post them on the flip chart. After that, ask the whole team if they can think of more items they would like to include on the definition of done.

You still have problems that don't have a possible solution.
Ask the whole team if they can think of anything solving it. After that, ask the whole team if they can think of more items they would like to include on the definition of done.

Every problem has at least one possible solution.
Ask the whole team if they can think of more items they would like to include on the definition of done.

As a last step go over all the DoD items that have been posted on the flipchart during the workshop and ask the team if this item makes sense on a definition of done and if they agree, if this item lands on the definition of done.


Example:
Our result looked like this

Different estimation methods compared

A while ago, I conducted a workshop about agile estimation. In this workshop, I showed the participants three (of many) different ways of estimation: Planning Poker, Magic Estimation and the Team Estimation Game.


Planning Poker [Interaction level: high]
Probably the classic estimation method. The product owner reads a user story, the team estimates using the planning poker cards. If there are any differences in the estimation, the team starts a short discussion about everyones different opinion of the story at hand. If after about 3 estimation rounds there is still no consensus, the story is obviously not clear enough and everyone tries to gather new information until the next estimation session. Planning Poker usually uses story points, although I've already seen cards with animals on it (quite a nice idea actually). The estimation session ends when either all the stories are estimated or when time is up.
At the workshop I let the participants estimate what it takes to clean a kitchen. During estimation the team realized, that story #1 and #4 are too large and split them up to 2 and 3 stories.

Magic Estimation [Interaction level: low - medium]
Probably the second classic estimation method. Prepare a flipchart (or similar) where you draw an arrow going up (symbolizing the increased complexity) and write your references beside the arrow, be it user stories, T-Shirt size or whatever you feel most comfortable with. The product owner reads a user story, writes it on a post-it and puts the post-it on the flipchart. This procedure is repeated for about 5 stories. The team then gets 2 minutes to stand in front of the flipchart and silently move the post-its to where it thinks they belong. If during the 2 minutes you realize, that a story is wandering around a lot, you might want to talk about some details after the 2 minutes. This whole procedure is repeated until there are no stories left or the time is up. 
At the workshop the result looked like this:

Team Estimation Game [Interaction level: low]
An estimation method I found a while ago here (page is in german) and have used at the workshop myself for the first time. This method is quite similar to magic estimation. As with magic estimation you need a flipchart prepared. The product owner brings all the stories on index cards to the estimation and lays them, heads down, on a table. Someone from the team (whoever wants to go first), takes the first story card, reads it out aloud and then puts it on the flipchart where ever he/she thinks it belongs. Now the second one in the team pulling a card can either put it besides, above or below the first story read. From the third story on, every team member has 3 possibilities for his move:

• Read the next story card and put it on the flipchart
• Reassign a story already on the flipchart, also explaining why he does that
• Skip

When reassigning a story, you might also mark the story with a dot. The more dots a story gets, the more opinions about it differ and you should discuss it in detail. Like with the two other estimation methods, the team estimation game ends when there are no more stories left or when time is up.

At the workshop the result of the team estimation game looked similar to magic estimation:

Conclusion:
In my time as a developer I only used planning poker (apart from any workshops or similar I attended). After having conducted this workshop, I still prefer planning poker over magic estimation and team estimation, since the interaction with planning poker is way higher than with the other two (which is also the conclusion of the workshop participants). That doesn't render magic estimation and team estimation totally useless, there are still valid use cases for them. They are actually quite useful when you need a lot stories estimated in a short time, e.g. at the beginning of a project. Other than that my favorite remains planning poker.

Who's doing what?

When using Scrum Sprintboards or Kanban Boards you usually also want to show who's currently doing what.
We started with pinboards, pins and index cards. In order to visualize who was doing what we printed out a photo of every team member and pinned the photo to the current index card that was in the "Work in progress" (Wip) column.


A while ago we changed this system: We bought a large whiteboard and started using magnets instead of pins. This gave us the chance to print magnets for each team member thus you simply have to put a magnet on the Wip index card to visualize that you're working on it:

As you can see, we didn't use actual photos but gave every team member the opportunity to choose a picture of their liking. I chose Dr. Zoidberg. If you choose to do so aswell, don't forget to include a legend on your whiteboard so that everyone can see which magnet belongs to whom.

Every team member has 10 magnets, which makes it really easy to still know who completed what since the last standup, as we keep the magnets on the index card until the next standup.

You can order the magnets here.