The “Six Thinking Hats”, described by Edward de Bono in his book of the same name, is a great tool for creative problem solving. Using this methodology, you adopt different perspectives by “putting on different hats”, to more holistically understand the problem domain and solution space, by utilizing a plurality of perspectives. Can this approach be used to generate valuable insights and trigger worthwhile changes within the software application delivery process? You bet!

Shelf with six hats marked with a different color

The software application delivery process: Areas for improvement

One of the highest leverage improvement areas for software organizations 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’s worth the time and energy of doing serious analytical work, creative problem solving, and continuous improvement adoption.

Introducing: The Six Thinking Hats for the software delivery process

Group of people discussing around a big map

The White Hat perspective - Data

The White Hat perspective focuses on the data. What data do you already have from your processes - and what else can you 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 don’t 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. You may wonder how this fits into our processes, but it’s important for a strong team.

Example questions include:

  • Would people enjoy doing these tasks?
  • What is our gut feeling about the removal of these manual approval steps?
  • Is there anger or resentment between teams?
  • Do we have a gut feeling on where the biggest 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 negative outcomes. Example questions include:

  • What happens if people don’t follow this process?
  • Could we miss major security vulnerabilities during this step?
  • What are the ways in which the build could 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 positives; potential added benefits of the process.

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 our 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, in order to learn from it?
  • Could we completely change the charter of this team?
  • Could we gain more traction by making a huge 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. This is about strict checks and balances.

Example questions include:

  • How could we ensure this compliance check is run for every build?
  • 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?

In this article from Praxis Framework, they 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

It can be useful to think of these roles as advocates of the different approaches of each hat. You 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.

Open your mind

Coupled with diverse teams and by playing devil’s advocate, using The Six Thinking Hats approach can facilitate rich collaboration and rich 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.