Software delivery and the six thinking hats

Edward de Bono described a remarkable tool for creative problem-solving in his “Six Thinking Hats.” Using this methodology, a team member adopts a plurality of different perspectives by “putting on different hats” to holistically understand the problem domain and solution space. Can this approach generate valuable insights and trigger worthwhile changes within the software application delivery process? You bet!

The software application delivery process: Areas for improvement

One of software organizations’ highest leverage improvement areas is the application delivery process. The impact spans time-to-market, security, quality, development costs, and feature velocity. Poor application delivery rapidly diminishes market share and financial health for software-centric organizations, but excellent application delivery can accelerate the organization’s strategic efforts, improve margins, and expand market share.

With so much on the line, it is worth the time and energy to carry out serious analytical work, creative problem-solving, and continuous improvement adoption. A case study by Delcol, et al. (n.d., p. 2) outlined the principal reasons for selecting the Six Thinking Hats approach in their software development project:

• harnesses focused thinking within a flexible process (appealing to most engineers),
• discounts the belief that creativity is the domain of only selected people,
• generates consensus, and
• depersonalizes criticism.

The team described in the case study proposed a conservative estimate of 40% perceived improvement in group functioning as a result of one project. An ROI calculation indicated that the client reaped an additional net $26.48 for every dollar spent on the Six Thinking Hats skills innovation program, based on team members’ estimates of improved efficiency.

Many previous projects analyzed by the case study team discovered that most design review conflicts centered on the following (p. 2), and were subsequently remedied by the novel approach:

• Presentation of incomplete or erroneous information.
• Poor handling of questions (adversarial tone, poor topic focus, interruptions, and tangents).
• Generalizing and/or exaggerating issues.
• Inability of the review process to generate consensus, identify new ideas, or find acceptable solutions.

Introducing: The six thinking hats for the software delivery process

The white hat perspective - data

The White Hat perspective focuses on the data. What data does the team already possess from the processes of the enterprise - and what else can the team collect?

Example questions include:

• Where do we already have (and where do we need) time studies for application delivery activities?
• What parts of our application delivery process are “black boxes” that we do not understand?
• Are we collecting the right metrics to drive continuous improvement efforts?
• Are time-to-market and DevSecOps adoption correlated among application teams?
• What percentage of the average release duration is attributable to manual quality assurance testing?

The red hat perspective - emotion

The Red Hat perspective focuses on emotions and intuition. The team may wonder how this fits the processes of the enterprise, but it is essential for a strong team.

Example questions include:

• Would people enjoy doing these tasks?
• What is our gut feeling about removing these manual approval steps?
• Is there anger or resentment between teams?
• Do we have a gut feeling about where the most significant problems are?
• Would it make our engineers happier if we removed this work altogether?

The black hat perspective - risk

The Black Hat perspective focuses on risks and adverse outcomes. Example questions include:

• What happens if people don’t follow this process?
• Could we miss significant security vulnerabilities during this step?
• Which ways could the build fail?
• Is this a non-value-added activity? (Check our definition of value-adding activities here)
• What if conversions fall way below the projection?

The yellow hat perspective - benefits

The Yellow Hat perspective focuses on the process’ positive, value-added benefits.

Example questions include:

• Could this activity also be a source of direct customer feedback?
• What would this look like if everything goes exactly according to plan?
• Could new tooling boost performance in this area?
• Where can we best leverage talented new hires?
• How can we scale our successes and best practices to other teams?

The green hat perspective - creativity

The Green Hat perspective focuses on creativity and wild new ideas. Go way out there with this one.

Example questions include:

• What if we deliberately let this process fail to learn from it?
• Could we completely change the charter of this team?
• Could we gain more traction by making a considerable pivot here?
• What if we switched to an entirely different model for revenue generation?
• What if we had a separate team chartered with new product developments to disrupt and cannibalize this revenue stream?

The blue hat perspective - control

The Blue Hat perspective focuses on process control—strict checks and balances.

Example questions include:

• How could we ensure every build runs a compliance check?
• How do we control the server resource consumption?
• Can we minimize the number of paths to production?
• How do we enforce this policy?
• Can we standardize on a single enterprise DevOps toolchain?

A different hat for different roles?

One method (Palmer, 2015) would be to assign different hats to different project roles:

• White Hat: Project Owner
• Red Hat: Project Manager
• Black Hat: Assurance
• Yellow Hat: Users
• Blue Hat: Project Management Office

These roles can be thought of as advocates of the different approaches of each hat. The team may like to take the lead from this perspective or even utilize these people within the team to head up the brainstorming efforts of each approach.

Next steps: Open the minds of the stakeholders

“We may have a perfectly adequate way of doing something, but that does not mean there cannot be a better way. So we set out to find an alternative way. This is the basis of any improvement that is not fault correction or problem solving.”

― Edward De Bono, Six Thinking Hats

Coupled with diverse teams and playing devil’s advocate, the Six Thinking Hats approach could facilitate rich collaboration and problem-solving. When applied to the software delivery process, this collaboration and problem solving can generate surprising and substantial insights and value for the organization. Try out an inexpensive course, Problem Solving for Continuous Improvement, that will touch upon the application of the Six Thinking Hats approach to problem-solving