Nowadays, I spend 100% of my time in agile teams either engaged in direct coaching, teaching, or participating directly within the team. One of the core tenets of agile teams is self-direction. This is a state that is much easier to say than it is to achieve. One of the more critical activities that fosters self-direction is effective facilitation and the role of facilitator.

Leveraging Scrum then, this ‘art’ largely falls within the realm of the Scrum Master. A large part of that role is directed towards focusing the teams’ energy on effective discussion, debate, and decision-making. Trying to create an environment where the team experiences what Jim Surowiecki calls . The key point is that the collective wisdom of a team, group, or crowd is quite often greater and more valuable than any singular domain expert.

These team-based innovative solutions surround architectural & design choices, surfacing and analyzing critical customer requirements, and crafting the simplest yet most powerful feature sets in response to our customers. There are often a myriad of directions or choices a team can make and getting the path right isn’t always easy. Effective facilitation can be one of the differentiators for teams hovering between average and outstanding delivery.

5 Dysfunctions – The Passionate Debate…

As it turns out, technologists seem to debate everything.  Or at least that is my experience from over 30 years of software development. They’ll be just as passionate about naming conventions for a particular nondescript configuration file as they are about designing a high performance databases for a new large-scale CRM application.

I think it might have something to do with personality type or perhaps just a fondness for debate. Regardless, just as we have a tendency to be overly optimistic with respect to estimates, we have a tendency to deaden the horse on nearly all technical topics.

I recently read by Patrick Lencioni and received some excellent training surrounding that material. One of the key points the instructor made focused towards encouraging teams to have Passionate Debate…but about the Things That Truly Matter. It’s the last part that we often forget as technologists.

A good facilitator will try and focus the discussion away from the myriad and towards the things that truly matter. It’s a prioritization game that aligns incredibly nicely with the agile methods. In this 3-part series of posts, I want to explore facilitation. I think its one of the most important skills to bring out the best in agile, self-directed teams.

A Quick List of Facilitation Tools & Techniques

So, if you’re a Product Owner, Scrum Master, or agile team member who wants to improve your facilitation skills, I thought I’d provide a list of some techniques that I’ve found helpful in guiding teams’ towards successful agile execution. While these tools and techniques can be helpful in all contexts, I feel they’re particularly helpful in agile contexts. Enjoy!

Ask why; ask why five times

There is something quite powerful about asking why. Why are we doing this? Why is this complex design the only way to solve this problem? Why are we taking on so much scope in delivering this feature?

In lean circles a common approach is to ask why five times. The tactic is to peel the onion and drill through peripheral points into the core of an issue or requirement. And when you ask why, don’t be afraid to wait for an answer. Allow time for folks to think about the question and respond. Sometimes that silent pause can be most helpful in getting to the essential core of a discussion.

Ask silly questions

One of my favorite approaches to foster expanded discussion is to ask silly or frivolous questions. Sort of putting myself out there as being clueless, so that others will seize the moment to correct me and explain the options, true nature of each, and why we’ve chosen the direction we’re taking.

The other side effect is that teams’ will also re-examine their drivers for a decision and often look for simpler approaches. It sort of shocks their nervous systems into reconsideration. But clearly you need a thick skin and self-confidence to take this approach.

Make controversial statements – see who responds and how

A variation on the silly question approach is to make absolute or other controversial statements. Let me give you an example. In your business domain, designing and testing for high security is an important criteria.

So in a requirement planning session you exaggerate as to how little security testing you’ve seen in the requirements—knowing that there is a reasonable level. You’re looking for team members to respond with the facts. You’re also looking for realization across the team of any security testing ‘gaps’ that might still exist.

Put on a different hat (Development, Sales, Marketing, QA, Architecture, Regulations, PMO, Management)

One of the more powerful actions you can take is changing your point-of-view or perspective. That’s why personas are so powerful when developing User Stories. They help you to clarify the ‘User’ in the “As a _____” clause.

But you don’t need formally defined personas to put on different perspectives. Simply ask the team to consider the requirements, design, or problem from various lenses. I think the facilitative art is in selecting the perspectives based on the problem at-hand and not simply going down a by-rote list.

Devil’s Advocate

I sometimes struggle when someone adopts the Devil’s Advocate position. I’ve seen it miss-used as a stalling or blocking tactic from those who aren’t truly interested in specific directions or decisions. In these cases, it’s an unhealthy plow.

However in the healthy case, it’s a wonderful perspective. It focuses the teams’ energy on the opposite case, causing them to think about decision alternatives and how to defend & strengthen their case. Often it drives slight alternative approaches that might not have otherwise surfaced.

Recognize / thank folks that exhibit and weigh-in with candor

Actively recognizing folks who are weighing-in with valuable feedback is another way of encouraging feedback. First acknowledge those that are engaging and thank them for their contributions. If someone takes a risky position or challenges an incumbent in a courageous manner, I like to point this out as well.

In fact, the more candor I see being driven into the debate, the more I visibly appreciate and recognize it. Now you have to walk carefully here as a facilitator so you’re not perceived as picking favorites.

Exaggerate – small or large

This is one of my personal favorites and I probably overuse it a bit. It’s related to the controversial statement option above. However, in this case, you minimize or maximize the point being made. It serves to get the teams’ attention and focus them on the “shades of gray” related to any discussion.

For example, if I detect that the team is minimizing the testability aspects of a design discussion, I might ask them how they’d propose testing it if they had to do it? What if they didn’t have any ‘testers’ at all? In this case, that exaggeration might pull the teams’ consideration towards the importance of building in efficient, up-front testability.

Ask quiet folks to weigh-In OR ask loud folks to weigh-In last

Team dynamics often seem to include quiet and loud characters in their fabric. Part of the role of a facilitator is to equalize these voices – in an effort to create an environment where all voices (opinions, options, thoughts) are heard.

One technique for loud voices is to privately ask them if they’re aware of how influential they are on the teams’ decisions and to ask them to weigh-in more carefully and after others have had their opportunity. For quiet members, often simply asking them directly will get them to engage.

Or assigning them a position that you think they’ll struggle with—in order to drive them from their comfort zone. Another approach is to setup ground rules that expect everyone to fairly contribute to decision-making.

Facilitative Tools

As a means of wrapping up this post, I thought I’d share some traditional facilitative tools:

• Clearly rank options as a team; then converge on the best option based on team discussion – removing outliers first.
• Discussion, then team voting; re-vote as required. Use a technique where you surface supportability of a decision vs. agreement with the decision.
• Time-boxed discussion; then a pre-declared decision-leader decides if the team can’t come to a decision within the time-box.
• List Pro / Cons and vote as a team – consensus or majority or decision-leader led decision.
• Explore the overall cost of doing it vs. the opportunity cost – not doing it. Keep the discussion focused on value & cost—making it a mathematical decision of sorts.

Quite often it’s useful to write down or specifically quantify your discussions – making lists, ranking items, and generally clarifying the discussion in words at a whiteboard or on a flip chart. This has a tendency to bring the team back towards reality and help them to converge on a direction.

A large part of this is driving towards a decision—often the hardest part of facilitation. So having a variety of decision-making models can help.

Wrapping Up

I hope you found this post useful. I also hope it inspired 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.

In my next post I’ll be sharing another tool for facilitation – Edward De Bono’s Six Thinking Hats model and how it can also help your facilitation. Till then, happy decisions…

Stay agile my friends,

Bob.