6 Thinking Hats Retrospective

Use:

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”.

Length of time:

Approximately 60 minutes but can easily be tailored to need.

Short Description:

The team discuss the previous period since the last retrospective whilst collectively wearing one of De Bono’s ”hats” at any time. The hats relate to particular ways of thinking and force the group to collectively think and discuus 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). 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 that 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 are 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”).

Source: Rob Bowley also described here