Reading:
The Six Thinking Hats: A Catalyst For Fast And Effective Software Reviews
Share:

The Six Thinking Hats: A Catalyst For Fast And Effective Software Reviews

What if there was an option to use static reviews but with minimal impact on time and cost?

The usefulness of software reviews in development projects of varying scales has been documented and evaluated for years. The general feeling is that it's desirable but not essential for the overall quality of the project, due to the effect it has on relevant resources, time, and cost. 

What if there was an option to use static reviews but with minimal impact on time and cost? The objective of this article is to offer the reader a method to do just that. It uses the concept of lateral thinking and applies it to the software review process. The first part of the article will focus on the lateral thinking concept ‘six thinking hats’ formulated by Edward De Bono (1985), followed by an introduction to software development reviews. It will then move on to the benefits of combining the two.

What Are The Six Thinking Hats? 

Over the past few years, the ‘six thinking hats’ concept has been successfully applied in many organisations, from software development companies to schools, due to its simplicity and effectiveness. It was derived from the ways in which the human brain thinks and conceptualises: the hats, according to De Bono, are, as follows: facts and information, feelings and emotion, critical judgement, positivity, new ideas, and the big picture. 

We can use colours to denote each ‘hat’:

  • White - Facts and information
  • Red - Feelings and emotion
  • Black - Critical judgement
  • Yellow - Positivity
  • Green - New ideas
  • Blue - Big picture

Thinking of the hats as colours helps to address the stumbling blocks inherent in language and to dispose of preconceptions. The hats allow for more focused and deeper thinking with regard to the subject under discussion. 

In product development meetings, people are often wearing different thinking hats, but they are not aware of it. One person is thinking about statistics and metrics, while somebody else is having an adverse reaction to the subject. Still others may be thinking of ways to improve the process. But there is a way to facilitate thinking in parallel even if everyone in the room is using a different thinking hat! 

‘Six thinking hats’ review meetings are chaired by a moderator who directs participants’ thinking to any of the six colours. The hat selected by the group dictates the desired output. For example, if the subject is the QA monthly report, the moderator could ask each participant to adopt the white hat. This means that the output desired consists purely of facts and information (nothing else). It remains focused on this area until enough information is gathered, and then the group will switch to another hat such as red, which will lead to general feelings and emotions regarding the report. Awareness and conscious application of the different thinking processes entailed by the hats can yield a lot of useful information in minimal time. 

Using The Hats In Software Reviews

Depending on the scale and context of your project,  you may choose from among several review types: management, informal, walkthrough, technical, and inspections. In this article we’ll discuss inspections and technical reviews. 

Inspections

During an inspection, the review group identifies and describes defects in a work product in relation to specifications, standards and other quality attributes. The review group also considers the processes used to create the work product and the inspection process. Roles involved in this process are: trained inspection leader, inspectors from a variety of disciplines, and the creators of the product under review (such as software developers, technical writers, business analysts, or QA test plan writers). 

In an inspection, the moderator adopts a blue hat or big-picture stance and will plan the needed thinking strategies accordingly.  All of the other colours are important to the inspection as well: white hat (facts and information), black hat (critical judgement), yellow hat (positivity), green hat (new ideas), and red (feelings and emotion). 

The moderator should schedule individual, timed sessions for each of the colours, with the goal of eliciting thinking and discussion in the following areas. Discussion during each timed session should focus only on the colour for that session.

  • White: facts and information the group has that can lend clarity to the critique
  • Black: what could go wrong?
  • Yellow: potential benefits of the product or process
  • Green: new ideas
  • Red: emotions about any aspect of the product or about the previous sessions

At the end, the moderator summarises the sessions and the group decides on next steps.

Technical Reviews

A technical review is an evaluation of a work product to establish its suitability for intended use. Work products that may be reviewed can include requirements specifications, functional specifications, design documents, test conditions, and user guides. The review participants include a trained moderator, the author(s) or creator of the artifacts under review, reviewers with technical expertise, and other business stakeholders. 

In a technical review, the focus is on the suitability of the product or process to its intended use. The hats for which sessions should be scheduled include the white hat (facts and information), black hat (critical judgement), and yellow hat (positivity). Other than that, the review session proceeds much as described in the Inspections section above.

In both types of review, the role of the moderator is critical. The moderator is tasked with perceiving all information discussed from the blue hat big-picture perspective and to direct thinking and discussion accordingly. It may be that, due to the nature of the review type, sessions for one or more or the hats are not needed. 

The implementation of these reviews in software development projects can increase cost effectiveness. Defects identified early in the software development lifecycle are cheaper to address than those found during the test execution period. 

Final Thoughts

The benefits of integrating the ‘six thinking hats’ framework into software reviews have been touched on above. Six-hats sessions have a predictable, clear structure, guiding those in the meeting to think about and review the product from the same angle at the same time, which may decrease the time required to carry out the review. However, as with any process, it is only as good as the people who create and abide by it. It may be that certain participants find it too confusing or too simplistic for it to be effective. Strong leaders and moderators are essential to the approach’s  success, because any deviation from the thinking hat in use during a given session hinders the whole process.

I believe that there is a place for the six thinking hats in software reviews. The methodology is cheap to implement and simple to use. It should benefit any type of meeting since it helps individuals and groups to think more strategically and effectively. And it should reduce the time required for reviews. If you reduce review time and show positive results, your organisation will be more receptive to implementing six hats reviews as a standard practice.

For Further Information

Neil Wheelhouse's profile
Neil Wheelhouse

Test Manager

Neil's testing career started in 2006 and includes experience in the following sectors: education, supply chain (RFID), e-commerce, gambling industry, cash management, digital banking, health and wellbeing, and telecommunications. He started as a junior tester and from there took the path toward leadership as lead tester, senior tester, team lead, culminating in his current role as test manager.



Comments
🎙️ TestBashX Brighton Speakers Announced!
Discussion: How To Get More Involved with the MoT Community
Tales From Developer Tester Collaboration – Maaret Pyhäjärvi & Llewellyn Falco
Don't be a Superhero - Ali Hill
Organizing Your Very Own Testing Meetup
Quality doesn’t belong with the tester! – Maaret Pyhäjärvi
What does TDD mean for me, the Tester?
Testing Ask Me Anything - CI/CD and Delivery Pipelines
99 Second Talks - Test.bash(); Manchester 2019
With a combination of SAST, SCA, and QA, we help developers identify vulnerabilities in applications and remediate them rapidly. Get your free trial today!
Explore MoT
TestBash Brighton 2024
Thu, 12 Sep 2024, 9:00 AM
We’re shaking things up and bringing TestBash back to Brighton on September 12th and 13th, 2024.
30 Days Of Agile Testing
Learn all about how testing fits into an Agile context with our 30 Days of Agile Testing!