Menu
Writing software requirements (specifications) is a tricky business. On a project, there is a key role for that job: Business Analyst. They interact with the Business side and the Technical side. They are the bridge between two quite separate worlds. They are under tremendous pressure because they need to explain to one world what the other one wants. This requires, in the first place, understanding what the Business really wants. And sometimes, answering that basic question is difficult. There are several possible reasons for that. We could mention: difficulty to translate the business into computing routines; the difficulty to express without ambiguity a process that requires some level of human judgement, the business persons capable of telling what is needed are rarely available, there is no clear requirements process in place, the requirements capture format is fuzzy and not properly used, etc. But in this article we will study only the simplest one of them: The business may very well be simply unsure about what it wants. At the start of a project, it is quite common to make a long list of needed features. In this list, there are items that are obviously truly needed, and some are actually far less obvious.
I remember working on projects where some requirements were considered as mandatory, essential. One could not live without them. And when I was asking the simple question: who needs them? I could not get any answer. So, I then ask: who captured them? Still no answer. Nonetheless, someone, one day, believed it was a very nice feature indeed.
In some other cases, time is essential. The project must be released at a specific date. Features need some cleaning as it is becoming obvious that all won’t be implemented in time.
Sometimes, it is simply at the beginning of the project, while working at the Vision stage that it is needed to clean the core features from the fantasy features, the features that will make money and the features that will cost money.
Deciding what goes in and what goes out is often subject to long debates. Everyone who has worked on a project and has been involved at the requirements stage has participated to meetings to make decisions. The format of this meeting can be greatly improved by using the technique known as: 6 Thinking Hats.
6 Thinking Hats is a framework invented by Edward DeBono who also famously invented the Lateral Thinking concept. DeBono is defending vigorously the idea that thinking constructively and creatively is a skill that can be acquired. One is not necessarily born a thinker and everyone can become one. DeBono has written many books that I recommend. The one related to the technique covered today is: 6 Thinking Hats, by Edward DeBono, ISBN-13: 978-0141033051.
6 Thinking hats is a framework for focussing one’s thoughts on a specific part of the problem. These parts are identified by a hat with a colour. Everyone will wear five hats one after the other while the person leading the group session will also wear the 6th hat. The principle is simple; the meeting leader is choosing a hat, i.e. a specific way at looking at the problem. While one specific hat is chosen it is only allowed to look at the problem with this hat, i.e. this point of view. Any other way is forbidden. By doing so, you are not disturbing the others and you force your brain to concentrate on one aspect only, increasing its efficiency. The duration of a specific hat is chosen by the group leader.
The 6 hats are the following:
When wearing the white hat, participants must look for facts and facts only. A fact is considered as such when it is verifiable. “Sales of product XWZ have increased 10% last year” is a valid fact. “Market demand for our product should be huge” is not a fact. “ACME Research studies show that the demand for XYZ widgets next year should reach 15 millions World wide” is a fact. One may challenge the findings but this finding by ACME research is a fact.
With the yellow hat, one looks at the bright side of the problem. Participants are looking at positive things to say on the problem. “The production of our new widget has been very well received by the production team. They feel valued by this product.” “Putting this new widget on the market will show how confident our company is in the future.” One must be positive, optimistic and truly try to find sunshine in the problem submitted.
This one is the most natural one for most of us. It is about critical thinking. It is what most people in occident have learned to do on every problem submitted to them. One looks at the dark ugly side of the problem. “The production of our new widget was a nightmare in terms of logistic.” “Putting this new widget on the market will show how slow we are to react to the market trends.” It is generally very easy to fill this part of the session with plenty of thoughts. Being negative is one of the things we do best. It is actually a shame but nonetheless a fact (does it go in the white hat as a “verifiable fact”?… I let you think about it.)
The red hat is about giving your feelings without justifications. Participants just give their guts feeling. It is essential to remember that nobody has to explain these feelings. Justification would be a barrier to freedom and we would not hear all what we have to hear.
“It’s a great product, I strongly believe in it.” “I do not trust the guy in charge of this new product. I would not go for it.” “Something tells me this product will cannibalize our market. No go.” We do not always know why we think one way or another, but being able to share these feelings is important. As soon as you ask for justification, people will be much more reluctant to share their thoughts.
This hat is the Creative hat. Under this colour, participants are asked to be creative, go on parallel routes. As creativity is not necessarily an easy path, the session leader might use creativity techniques to help the participants. Such techniques are beyond the scope of this article. Some results might be: “This new widget would be very attractive if associated with a mobile device feature.” “The guy in charge of the product at our partner’s is too shy. I would rather work with Mr Johns at ACME. But Mr John deals with surf boards. Maybe our new widget could bring that extra feature to surf boarding…” Techniques such as word association may be used. In the end, the purpose if to free people’s minds, have them think out of the box. One never knows what will be the result of this hat.
Last but not least, the Blue hat is the meta-thinking hat. It is a hat that the session leader will wear permanently. This hat is about thinking about the session itself. “What is the best next move to bring great thinking? What next hat should it be? Who did not speak? Why didn’t they speak yet?” Etc. This person must perfectly understand the 6 Thinking Hats format.
6 Thinking hats is a generic tool. As such it can be applied to a wide range of situations. With software requirements, it presents a long list of advantages. For a start it allows, or even force, people to contribute to a problem. The buy-in of team members is far stronger when one has had the opportunity to share one’s views. It also presents a structured framework that guides people through the problem. Unlike an informal meeting, very little time is wasted. And when someone becomes creative on the question, it is inside the context of the green hat and therefore not considered anymore as crazy thinking. People are required to get a bit crazy for a moment. The framework also forces people to be positive, even about a problem they dislike very much. It becomes an exercise of the brain and in time even a reflex.
When it comes to deciding what features remain in scope and what features get out of scope, the thinking process is greatly improved in speed and in quality. The experience shows that very few items cannot be judged in the first meeting. The main reason why an item may remain a problem is when the most knowledgeable person on the topic cannot participate. So, you need to make sure that the persons attending the thinking session are in a position to contribute under the different hats. Maybe everyone does not have facts to provide, but at least one person should. If you know that no-one will have anything to say on the white hat, one person should be tasked doing some research on the subject to present the findings. Without any fact for instance, the thinking process is greatly weakened, unless it is because very little is known about the topic. But then, this in itself becomes a fact!
When the setup of the project implies the use of remote team such as in offshore or nearshore development, the 6 Thinking Hats framework comes very handy. The reason is that various cultures will have various ways to contribute to the solution of a problem. Going to people and say to them “Feel free to tell me what you think” can be pointless if not counter productive. But by using a framework to help people focus on the same part of the problem at the same time, you remove some barriers that could prevent people to contribute. The consensus effect of this technique is also doing marvels. As communication is one of the most delicate element of a project involving offshore development, any technique that strengthen the quality of communication is welcome and should be added to the Project Manager’s toolset. 6 Thinking Hats is one of these techniques!
Liemur is using 6 Hats Thinking internally and with customers. The structure it brings to the debates is extremely efficient and fruitful. On Software Requirements, it allows peace of mind for the features that have been binned and allows replacing some of them by more interesting and useful ones. In all cases, this format brings the following advantages:
If you are in a rush and cannot afford the luxury of the 6 Thinking Hats, you may want to have a look at another lighter framework: PMI (Plus-Minus-Interesting).
Of course, it is essential to note that 6 Thinking Hats is not a technique dedicated to software requirements. It can and should be applied to any problem or important decision you have to make. It can be applied in group but also at the individual level.
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
If you like this article, what about tweeting it or recommending it?