rob bowley

I’ve done this one a couple of times now and had postive feedback both times. It’s a good alternative to the shuffling-cards-around-style retrospectives as it mostly involves talking (albeit in a controlled manner).

You can read about De Bono’s 6 Thinking Hats on Wikipedia where it is described as: “a thinking tool for group discussion and individual thinking. Combined with the idea of parallel thinking which is associated with it, it provides a means for groups to think together more effectively, and a means to plan thinking processes in a detailed and cohesive way”.

Use

The description above sums it up and as I said it’s a good alternative format to more familiar plans

Length of time

Approximately one hour but can be tailored to your needs

Short Description

The team discuss the previous iteration whilst all wearing one of De Bono’s “hats”. They then do the same but wearing another hat until all the hats have been worn. The hats relate to particular ways of thinking and force the group to collectively think and discuss in a particular way. The facilitator documents any output on a whiteboard. The ouput from the last hat (Red) is converted into actions.

Materials

A large whiteboard and 6 coloured cards (one for each hat) and a room with space to arrange chairs in a circle (no table).

Process

Preparation

Arrange chairs in a circle so all the participants are facing each other. Put the colored cards along the top of the whiteboard in order of hat wearing (see below). Be familiar with all the “hats”.

Introduction

Once everyone is seated introduce the exercise by giving a brief summary of De Bono’s Six Thinking Hats process. Then explain that the group will all put on the same hat and discuss the iteration (what went well, want didn’t go so well, what can we do to improve things) for 10 minutes and after that they will put on the next hat in the series and so on until the all the hats have been worn.

Very Important: If at anytime anyone starts talking in a manner not appropriate for the current hat interrupt the discussion and say something like: “That’s great Black Hat thinking, but we’re not wearing that hat right now. Remember, we’re wearing our Green Hats which are about alternatives and learning so please try to discuss the subject in this manner”.

Tip: The facilitator should try to stay out of the circle and try to avoud the participants talking directly to them. This is tricky as people have a habit of watching what you’re writing on the board. Try to block the board so they’re not distracted.

Order of hats

According to Wikipedia the order of hats most suited to process improvement is  Blue, White, White (Other peoples views), Yellow, Black, Green, Red, Blue but for this exercise we will use:

Blue, White, Yellow, Black, Green, Red

Blue Hat (5 minutes)

Use the blue hat to discuss the objectives for the session and write the output on the whiteboard.

White Hat (10 minutes)

Participants raise  and discuss anything from the last iteration which can be said to be a fact or information. Hunches and feelings and any discussion of reasons or other non information based output should be left for the appropriate hat.

Yellow Hat (10 minutes)

Participants can only talk about the good things that happened in the last iteration.

Black Hat (10 minutes)

Participants can only talk about the bad things that happened, any negative criticism they have or worst case scenarios they can think of.

Green Hat (10 minutes)

The discussion moves on to any ideas people have about solving problems or things that may add more value to the business or help in any way. Outside of the box helicopter view blue sky thinking is encouraged.

Red Hat (5 Minutes)

Give the participants a short period of time in which they can come up to the board and write down 2 emotive staments each. These could be the issues that have stood out for them the most or an idea for solving a problem. These statements should be instinctive which is why you will give them very little time to do this.

Conclusion and Actions

Spend a little time as a group having a look at the Red Hat output. Are there any themes? Do any of them have relationships to each other. Do any particularly stand out? From this get the group to decide on a couple of actions to take away. As always ensure the actions are very easy to execute (so nothing like “write more unit tests” or “refactor the database” and more like “try to write test first this iteration” and “arrange a meeting with the DBA to discuss a strategy for refactoring the database”).

After a successful run of Retrospective Surgery at SPA2009 we got some really good output so thank you to all who attended. As a result I’ve updated the Agile Retrospective Resource Wiki with new tools, ailments and cures and a cool new plan I bumped into the other day. It’s beginning to come together really nicely

I’m a big fan of retrospectives having found them incredibly useful in ensuring teams can focus on continously improving their process. However they are difficult to get right and I know many teams struggle to get much out of them and often give up altogether. I think this is a big mistake.

Firstly, if you haven’t read it, I’d highly recommend Agile Retrospectives: Making Good Teams Great by Darby, Larsen & Schwaber. A great introduction to retrospectives with a lot of plans and ideas to help you out (although I have to say I find many of them too long for my liking).

However, beyond that book there really isn’t much else available so I’ve started a wiki to collect retrospective resources. Without further ado I’m delighted to announce:

The Agile Retrospective Resource Wiki or http://retrospectivewiki.org

A plea for contributors

Everything else you need to know is on the wiki, but I would like to take this opportunity make a plea for contributors. The content is currently a bit limited as I’m the only contributor so far so if you’ve got any cool retrospective plans, tips, tricks or anything else please add them.

Along with Matt Wynne I’ll be running the Retrospective Surgery session mentioned on the wiki at SPA2009 next week so I expect we’ll be getting some juicy new content imminently.

This is a retrospective I ran last week which I thought I’d share as it seemed to work quite well.

Before the retrospective I provided participants with a simple Word document template and asked them to identify their top 5 issues (one per template) and for each issue suggest as many solutions as possible. The template is to ensure participants can be as anonymous as possible.

Before getting into the top 5’s I did a quick energy seismograph (found here):

1. Draw a line with each day of the iteration marked
2. Ask the team to add significant events to the time line.
3. Once these have been exhausted ask each team member to draw a line on the chart, above the line being positive and below the line being negative to show how they felt throughout the iteration

In this instance it showed that generally the team was very happy. However at one point everybody’s line dipped into the negative which coincided with some release failures near the end of the iteration. Whilst this only confirmed what everyone was already saying I found it a really useful exercise as it’s quick, confirms the biggest issue/s and is very good at rooting out any others which may have been forgotten/overlooked.

On to the top 5’s.

1. Collect all the print-outs, spread them on the table and ask the team to group relevant issues.



2. Ask for a title for each group, create a column for each one on a whiteboard (or flip chart sheets stuck to the wall) and place the associated print outs on the floor below.
3. Get participants to form pairs (preferably with someone they don’t normally work too closely with) and give them three minutes with each column to come up with as many actions as they can and to write them in the column. Pairs are able to refer to the print outs and previous pairs’ actions for inspiration.
4. After three minutes pairs move on to another column until all are exhausted.
5. Go through all the actions so all participants are aware of them all.
6. Give each participant three votes and ask them to choose their favourite actions (can use votes however they wish e.g. 3 on one action).
7. Identify the most popular actions and ask for volunteers to own them. Make it clear it will be their responsibility to ensure they get completed before the next retrospective (tip: don’t choose too many actions and definitely no more than one action per participant).

As with all retrospcetive output I find the best way to ensure they get actioned is to stick them up on the wall somewhere everyone can see.