|
The Edward De Bono “Six Thinking Hats” methodology is a framework that allows the user to compartmentalise their thinking about a particular topic and structure it so that time is spent in a more constructive manner. It works best in the group context, but can be applied on a personal basis. Edward de Bono is considered by many to be one of the leading minds in the world of creative thinking, has written over 60 books on the subject and is the inventor of the term ‘lateral thinking’ (http://en.wikipedia.org/wiki/Edward_de_Bono ).
So given that as testers we are often challenged to think laterally about our tests, the question I am asking is, ‘what can De Bono teach us about testing?’
Before I go into the Six thinking Hats, (and I know that already the testers amongst you are picking holes with that term, so bear with me), I want to describe what is a fairly typical experience for me in meetings, be they with testers, developers or management. The meeting goes something like this….
There is an issue under discussion, Bill explains the issue and says it needs to get sorted. Gill says that we need to understand the history leading up to this point. Peter interrupts to say, forget that, we haven’t time to go over old ground and he suggests that we do X, Y and Z. Bill agrees, but Andrew states that there is this and that problem with that approach. Before anyone realises it, two hours of discussion have gone by, some tempers have become frayed and a course of action has been decided on, but not with everyone’s backing. To make matters worse, one member of the team feels that they have been personally attacked and is left feeling very upset. Although the meeting had an agenda, and all the items have been covered, somehow we still have not done all we had hoped.
If that sounds all to familiar, then maybe a different approach would help, and this is where the ‘Six Thinking Hats’ can help. Most of our meetings are based on an adversarial method of thinking, “I am right and have to justify my position” v’s “He is wrong and I have to disprove his position”. The discussion has point and counter point, support and attack, and follows a trail led by statement and response. If we were to draw the conversation it might look like this.
‘Six Hat’ thinking seeks to bring a structure to the group thinking, and concentrates on types of thinking, rather than types of thinker. The whole group is led to think in the same way at the same time. So for example rather than one guy being known as the ‘negative’ one in the group, the whole group is encouraged to see the problems, but together, and then, the whole group moves on to see the positive actions etc. If we were to draw a ‘Six Hats’ discussion, it might look like this;
Let me explain briefly about the hats, and how it works.
The idea of different coloured ‘thinking caps’ is simply a method to help us identify different thinking modes (don’t get hung up on the terms). The six different hats are;
 Blue Hat – Managing the Thinking
This hat is the ‘control’ hat. It sets the focus of the meeting, and summaries and concludes the meeting and ensures that the thinking modes are observed.
 White Hat – Information
This hat is about information, facts, not speculation. It seeks to discover; What do we know? What information do we need? Where can we get the information we need?
 Red Hat, Feelings, Intuition, Instinct
This hat gives the opportunity for people to express how they feel about a subject without long explanations, justifications or questioning.
 Green Hat, New Ideas, Possibilities
This hat gives the opportunity for people to think creatively, come up with new ideas, the more the merrier, ideas are produced here and assessed later. The key to green hat thinking is to encourage an unfettered flow of ideas
 Black Hat, Risk, Difficulties, Problems
This hat represents sceptical thinking, (we testers will love this hat). In this thinking mode we point out the issues with an idea, where it won’t work and any potential problems.
 Yellow Hat, Benefits, Feasibility
This hat represents optimistic thinking, (and guess what, we testers will have to think this way as well!) It looks both long and short term and concentrates on reasons to follow a particular course of action.
A meeting may use all, or, some of these thinking modes, and may use them more than once. It is about coming up with the right mix to get the best results for the given agenda.
Ok, so now you have had a crash course in six hat thinking (and I recommend if you ever get the chance to read up on this, or attend a training session, you grab it with both hands), lets imagine how it might work in one particular testing related scenario.
Your next release is due to go live in two weeks if it is to meet its schedule. You have two weeks worth of test scripts to run, but today you have just been told by the development manager that he needs another week before he can give you the code. You call a meeting of the test team, along with the development manager, project manager and some business stake holders. You decide to use the “Six Thinking Hats” methodology. The meeting might go something like this.
You set the agenda, and explain that rather than have open discussion the group is going to try a more structured approach. The agenda means that together you will first spend some time gathering the facts, then look at the risks and difficulties involved. Once that is done, you then intend to brainstorm some ideas about how we can approach the issues. You will then decide what sounds like the best way forward before looking at the pro and cons for the idea. At the end of the meeting you will sum up and assign actions.
You then ask for the development manager to explain the position, giving details of where they are at in development, and ask him to stick strictly to fact. He explains that they still have issues with one module, but think they will have that sorted in three days. You ask if three days is his estimation, or is it a fact, does he know for sure that it will be fixed and if so how. At this point someone from the business starts to have a moan about past delays. You cut them off, explaining that this section is only about fact, and that they will get a chance later on to express how they feel. You go back to the development manager, who explains that this is his best estimate, based on his experience. Again you explain that we only want the facts in this session. Someone else asks the manager how much time has been spent on the module so far, and to list the issues with the functionality as it stands. Someone else asks if this is the only issue stopping the code being delivered. Someone else asks if this module can be removed for the release.
You now have the basic facts.
You go round the table, asking people to say in no more than twenty seconds what they feel about the issue. You get a variety of responses such as;
“Its not as bad as I thought it might be.” “ I am surprised we got this far before this was raised”, “I am sure we can fix this given a few more days”
You explain that you now want everyone to think of how we might approach this issue, you explain that all ideas are valid, the wackier the better. That there will be an opportunity later to think about the feasibility of the idea, but for this session it is just a case of throwing out as many ideas as possible.
The meeting rises to the challenge, though you have to cut off a couple of people who wanted to respond and discuss some of the suggestions. But they soon got the idea. Suggestions were made such as;
‘Delay the release’, ‘Work double shifts’, “Reduce the testing”, “Remove the functionality”, “Release with the issue and give the customer a work round”, “Prioritise the testing” “Release to test now, and test what you can, them release again and test the fix” “Give the application to UTest and let the world and his wife have a go” “Give up on the project and pay the customer his money back”
A whole load of ideas were produced, and to narrow them down a quick, what do you think session was held. Each idea was read out, and each member of the group rated it as , Yes = 2, No = 0 or Maybe =1. Again, no discussion of the idea was allowed at this point.
One of the business members wanted to discuss the merits of each idea before the group got to rate them. You explained that if you gave two minutes to each of the 45 ideas generated it would take 1 and a half hours, and asked if he still wanted to discuss each. He agreed that this way might be a good idea after all.
The two ideas with the top score were chosen as the basis of the next discussion.
You ask the group to list all the draw backs associated with each of these two ideas in turn. The have to give the draw back, and the reason behind their thinking. This takes about twenty minutes, with the testers, (surprise surprise) contributing the most. At the end of the discussion you have a good list of problems with these two ideas. Interestingly, a couple of problems thrown out by the testers were withdrawn when they had to explain their thinking. On reflection it turned out these were not real issues at all.
You then ask the group to move on to listing all the benefits associated with each idea in turn. Again a good number of benefits were listed, with all members taking part, including even the most sceptical of participants. Again you are surprised by the results. Where as in the past, negative comments out weighed positive comments, it seems that this time the group has found it easier to come up with reasons why the ideas are good than why they are bad.
You draw the meeting to a close by reviewing the two lists (positives and negatives) and assigning actions to team members, You now have two very definite courses of action to mitigate against this potential set back. On a whim you ask people to state how they feel now.
You get an enthusiastic response for the group with comments like,
“ I cant believe we got so much done in such a short time”, “I feel I understand the problem and for the first time have been part of the decision about what we should do to correct it” “ I feel we have got the right way forward”
Although I have concentrated on the late into test issue above, I am looking forward to applying the same discipline to the next time I write test UAT cases with a group of business users new to testing.
I hope this has at least given uou something to think about, and as I said at the beginning of the article, I would be very keen to hear your thoughts and experiences on using the “Six Thinking Hats” for testing.
Tony Simms is the principal consultant at Roque Consulting (www.roque.co.uk) and can be contacted via email; tony.simms@roque.co.uk
|
