Instead of judging our way forward, we need to design our way forward. We need to be thinking 'what can be', not just about 'what is' - Edward de Bono
® Six Thinking Hats is a registered trademark of Edward de Bono
This is Part 1 of a 3-part series.
After several years of working long hours as a programmer I went into teaching - it was my interest in learning and problem solving that motivated me. As developers and development teams we engage in learning throughout our careers but primarily in terms of "technical skills" rather than "meta skills". These meta skills focus on areas such as how we learn and how we engage others to help us achieve goals. I've worked with many people that I would class as excellent developers. These people can solve coding problems quickly and elegantly but I've noticed that they often do so with blinkers on. As teams engage in agile approaches to projects it is important that they engage more closely in understanding the environment in which they are working.
Whilst studying and then working as a teacher, the skills around thinking and the area of metacognition became a primary interest to me. One well-known strategy for guiding thinking is Edward de Bono's "Six Thinking Hats" - first published in 1985. The six hats provide an enduring method for framing how teams can examine problems and seek effective solutions:
- White hat : The white hat focuses on facts.
- Red hat : The red hat focuses on feelings
- Black hat : The black hat focuses on caution
- Be careful with the term "black hat" as it is often aligned with negativity
- Yellow hat : The yellow hat focuses on optimism
- Green hat : The green hat focuses on being creative
- Blue hat : The blue hat focuses on the thinking process.
- "This is just new age mumbo jumbo"
- Some people really like to argue and anything that sounds like they won't be able to push their idea threatens them. The key risk with these people is that they believe the loudest argument is the strongest argument. Encourage these people to engage but be definite in adhering to the process - calling out when they're trying to dominate.
- "This will take too long"
- Some people feel that it's quicker to "work out the answer and go for it". Unfortunately this is often a form of "shallow" problem solving - they haven't really worked out a good answer and, usually, they've focussed on the technical aspect and not the whole issue. I've found that the first answer, once put under scrutiny, starts to fall apart quickly and, if the team had started development, a large amount of time is wasted in code.
- Don't make people wear a hat as it can reduce the session into a side show.
- Don't allocate each person a specific hat for the session as the group should be working with the same hat at any one time.
- Stay "on hat" by parking comments that fall under a different hat. Note the point on a whiteboard and direct the group back to the current hat.
- Monitor the highly assertive group members. Not everyone likes to proactively put ideas forward but, assuming you have a good team, encouraging the whole team can lead to solutions that the loud mouths never thought of.
One example is when reviewing a workflow: the White hat is really useful as you just want to know what the steps are and who carries them out - later on you could arrange a session that uses other hats to focus on issues such as problems with the workflow (Black hat) or improvements to the workflow (Green hat).
In the next article I'll look at how you can use the hats in a pairing arrangement to help you to direct your questioning during analysis work.
- Six Thinking Hats by Edward de Bono