DeBono’s 6-Hats
This is a bit of a tangent and not something brought up directly in my ORSC classes, but I think DeBono’s 6 Thinking Hats is a wonderful example of meta-skills in action. That is, it defines six different (personas, perspectives, points-of-view, lenses) to view something with. In particular, they can help with technical team based collaboration and decision-making?
Depth to our decisions
First, it gives us a breadth of perspectives to examine our options. For example, the White Hat is the data, facts, and figures hat. If we were making a decision on the database architecture to support our performance needs, it would be incredibly important for someone on the team to adopt the White Hat and mine the team (and customers, stakeholders, analysts) for performance specific targets that are required for the architecture. In this case, hand-waving and conjecture isn’t helpful. We’d need hard numbers and targets; something the White Hat perspective would foster and drive towards specifics.
Breadth or perspective to our decisions
As we’re reviewing and discussing something as a team, quite often we focus on a single or small set of the hats. For example, the Green & Yellow Hats often begin the discussion of new ideas or approaches for a specific design or architectural element, with green driving the creative ideation part and yellow the logic and positive part of the approach. If these two are the only hats that drive a decision, then the team missed four other perspectives in making their choice.
Not that it’s a bad choice, but it was narrowly conceived and narrowly considered. If someone on the team played the part of Devil’s Advocate, then they put on the Black Hat to consider some of the negative possibilities that could result from the decision. They criticized major and even minor points. Trying to get everyone to consider this perspective and then respond with alterations or alternatives to the original design.
I like to think of each hat as testing the steel of an approach—tempering it and making it stronger. So the more hats you use in your facilitation (divergent discussion, convergent discussion and decision-making) the broader your view is towards the problem and the broader your solutions.
Team-based influence
Quite often it’s difficult for some team members to raise issues in public. This is particularly evident in teams with strong personalities. Often if a strong team member brings up an idea, say a Green Hat idea, many on the team will feel intimidated to play Devil’s Advocate or bring up any criticism because of the others’ position in the team, their authority, or their strength of personality.
The hats can actually dilute the personal nature of the commentary in these situations in that you’re not attacking the individual or their idea. You are simply putting on a hat and trying to fulfill its purpose. It abstracts individuals from personal engagement and quite often it strengthens their ability to bring out alternative positions that they would normally not be willing to do.
So, in practice you see team member’s engaging the hats in this way. For example, if someone wants to bring up a criticism they’d say –
“as a Black Hat, I think the design lacks fault tolerance in the back-end because of the limitations of the message-broker we’ve chosen…”
which challenges the idea and clearly not the individual.
The Hats Themselves
The hats often lend themselves to a ‘flow’ of discussion. I’ve laid that flow out below in the order in which I present the hats themselves. Not that you have to precisely follow-it, but it does have a sense of symmetry to it as you’ll see after going through it.
While I do recommend that you try and engage all of the hats, clearly there are no Six Thinking Hat police that will come into your meeting, declare a violation, and haul you away. So trust your team and use your best judgment in determining which hats are appropriate for a specific decision.
White Hat – Objectives; Facts; Requirements
Quite often laying out the facts will help drive team-decisions. In software this often takes the form of requirements, use cases, or user stories. White Hat discussion usually occurs in the beginning and rarely needs to be initiated. However, a part of the hat is going back to the facts and refining them. In the case of functional requirements, perhaps looking for trade-offs and phasing to meet the customers key goals.
Green Hat – Creative; Ideas
This is truly the brainstorming hat. In agile teams, this is the predominant hat, as the team works to be inclusive, respectful and to get all viable ideas on the table. It’s the essence of planning & value poker as well where you get the teams’ opinions out in the open to drive discussion. This is also the creative hat, where different ideas aggregate into others that are more creative solutions—the more the merrier.
Yellow Hat – Positive; Benefits
To use a common use case term, this is the “Happy Path” case for the requirement or the design that reflects the easiest implementation or has the greatest potential on the surface. It’s a great hat to explore early to gain momentum in your divergent thinking as many options will often surface for more analysis. The other side of this hat is exploring the benefit or potential of the idea—it’s business case or ROI.
Black Hat – Negative; Criticism
As I mentioned earlier in the post, the Black Hat or Devil’s Advocate perspective can be incredibly useful in honing your designs and solutions. It usually refines the Yellow Hat perspective in the edge cases, creating a more robust, error & fault tolerant solution. It’s also one of the most familiar of the hats for the team to leverage.
Red Hat – Emotional; Reactions
Quite often in software it’s not the logical flow that attracts customers or gets them excited. Usually it’s something emotional or unexpected. The Red Hat is the one that reminds you to do customer focus groups and to do research within your U/X team so that you’re focuses on those ‘delighters’ that excite and gain an emotional reaction from your customers. It also exemplifies your “gut feelings” when making decisions.
Blue Hat – Rational; Conclusions
This is the decision process hat—so the facilitator often wears this hat by default. It also focuses on documentation, maintaining roles and responsibilities, an driving the teams towards conclusions. In the case of roles, holding the team responsible for the role of who is responsible for architectural decisions, perhaps an architect or team leader, vs. who can weigh-in with some alternatives.