Learn more about Velocity Partners offshore software development company 

In my last post on facilitation, I shared some general principles for facilitating technical outcomes in software teams. Much of the focus was on creating just the right atmosphere so that team members shared their opinions and made thoughtful, team-based decisions.

In this post, I want to share Edward De Bono’s Six Thinking Hat model and how it can help you in facilitating much richer discussions surrounding your technical decision-making. But first I want to share another facilitative model with you. It’s more of a dynamic that occurs within individuals and teams who are trying to create new products, solve new problems, add features, or in general compete in their respective markets with creative solutions that drive customer value. 

Divergent vs. Convergent Thinking

                  

  Divergent – many  answers                       Convergent – one answer

One way to think about any team-based discussion that needs to lead towards a decision is that it occurs in two-phases. There’s a first phase that is focused on divergent thinking. In divergent thinking you want to get ideas on the table. So consider this team level process as equivalent to brainstorming.

In brainstorming you want to get ideas and options on the table. You don’t want to judge, prioritize, or analyze them. You simply want to generate as many as possible. If your divergent time-frame is too limited, then team members will feel as if they haven’t had a fair sharing or vetting of their ideas.

So as a facilitator, letting a team ramble on or throw around crazy ideas is a perfectly sound thing to do. In fact, if you don’t do it, it will lead to less buy-in and less permanent decisions. Quite often, you’ll want to leave half of your meeting time-box for divergent conversation—fostering engagement across the entire team.

Then mid-way, you need to turn the discussions around and focus more on convergent thinking. That is, you want the team to start winnowing down ideas and converging on a single decision or at least a very small sub-set of options to decide upon later.

If you recall, I presented some decision-making tools in my last post. For example, as part of closing down or converging on an option, you could do some of the following:

• Vote on the options on the table; define loose, strong or unanimous majority before voting
• Prioritize the options, keeping the top 2-3 in play for a second round of discussion
• List Pro/Con for each option – leading towards prioritization & elimination
• SWOT (Strength, Weakness, Opportunities, Threats) analysis for the top 2-3 options, then discuss and converge on a selection
• Select a decision-leader to lead the convergence discussion; if resulting discussion exceeds your time-box, decision-leader decides

Usually the above are led by the facilitator—in the front of the room, active at a whiteboard or flip chart, collecting data from the team and converging towards a decision.

It’s this oscillation between divergent and convergent thinking that is the hallmark of good facilitation when making important or ground-breaking decisions. Striking the balance between over/under discussion and fostering a whole team view is crucial. I usually allocate set times for divergent, interim, convergent, and decision-making close as part of this exercise—even allowing these themes to cross over multiple meetings.

Now that I’ve set the stage for this process, let’s move back to the thinking hats…

Back to the Thinking Hats

So what does this notion by De Bono have to do with team facilitation? In particular, technical team based 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.

Wrapping Up

I hope you found this post and its predecessor useful. I also hope they inspire you to work on your facilitation skills—particularly if you’re part of an agile team. Why? Because many teams spin-and-spin around discussions and desperately need quality facilitation. I hope you can broaden your role to help fill this need.

I’ve found that Edward De Bono’s Six Thinking Hats model can truly help your facilitation within your teams by fostering depth & breadth to your decision-making. For now I sincerely hope your decisions improve in their quality!

In our next and final installment on facilitation, is anything really final, we’ll explore the Fist of Five tool. It’s one of the tools I use most often.

Stay agile my friends,

Bob.