Don’t let facilitators solve problems

Whether it is right or wrong, it is a matter of fact, most facilitators have been team managers at some point or another. Moreover, as a manager, their primary responsibility was solving problems for those they managed. This is a hard dynamic for many facilitators who might deny they ever solve problems but then eventually fess up.

Most managers care passionately about the teams they work with and can often see a way to resolve the team’s immediate problems. So they think it helpful to step in and suggest a solution for the team to execute, or worse, take the responsibility for fixing the team’s problem themselves.

The drawback is that, although it is tempting for the facilitator to fix the problems and in the short term, the facilitator is actually denying the team the opportunity to develop the skills to solve problems for themselves in the longer term. ‘Hold on, my Scrum master’s job is to remove impediments to the team’ we hear you say. However, this creates a dependency on the facilitator, which might well get stronger rather than weaker over time.

Try to work by the principle that everything facilitators do for a team should reduce the team’s reliance on facilitation a little and make their role a little more redundant (remember that when you make your role redundant you are more likely to get promoted than fired).

There are two recurring failure modes that we see in this situation and as facilitators we must avoid.

First, as facilitators, we must resist jumping in. We might think we are acting in the best interests of the team by coming up with a solution to a problem they have identified, but in reality we deny them the chance to solve the problem for themselves.

When a facilitator describes a solution rather than a need, it is likely that any resulting outcome will be sub-optimal. Of the many reasons for this, not using all the skills and brain power of all the members of the retrospective is wasteful. Also there is a lack of ownership when a team are handed a solution rather than presented with a problem. The upshot is a team who might not appreciate why they are doing what they are doing while also missing out on an opportunity to improve their problem-solving skills.

The second, and arguably worse, failure mode is when the facilitator takes responsibility to fix the problem. In this situation, a team identifies a problem in a retrospective which the facilitator steps in to take away and fix, because they know the systems, organisation, people or solutions of the past. In this case, teams have many of the same problems as before but with the additional disadvantage that team members may not even know how the problem has been solved.

When the facilitator solves the problem, the next time the team face a similar problem, they will not know how to go about starting to rectify the situation. Instead, they will either have to find the facilitator or, even worse, wait until their next retrospective to raise this latest problem.

Key benefits

This idea means playing the long game. Used successfully to remove the reliance on the facilitator, it will provide greater long-term speed and throughput for your team.

By developing the problem-solving techniques that teams naturally have and applying them to solving organisational problems, team members will become more empowered. They will feel more ownership of a solution to a problem if they have designed it. This ownership will translate to a greater success rate.

This empowerment will bring a shift of focus within teams to fixing problems rather than sitting on them waiting for help, or just working round them. This agitation will start to change the dynamic and culture within an organisation as problems become things to solve and not immovable obstacles.

How to make it work

As a facilitator, back off. Even if you see an opportunity to solve a problem in a more efficient way, remember that is a short-term efficiency while the long-term effectiveness of the team depends on the team learning how to fix problems themselves.

Make sure that the team get to the root cause of the problem. Using techniques like the ‘5 Whys’ and Ishikawa’s fishbone model, widely written about in quality control literature, will drive the team to find the root cause of their problems. In this way, solutions that address the root cause become much more obvious than when teams only deal with the superficial problem first identified.

Use open questions in retrospectives to help the team drive their own solutions. Ask focusing questions like ‘What possible courses of action do we have and which can you control or influence?’ This should lead them to think about the range of options available. Write these suggestions down, even if they seem impossible, as the act of displaying them will likely prompt exploration of the underlying assumptions and further derivatives of the original idea.

Finally, no one likes to see people struggle with a problem at length. If you as a facilitator must offer your insight, first, ask permission. Once you have the agreement of the team tell the team explicitly that you are taking off your ‘facilitator hat’ and that you are contributing as a team member. Once you have presented your idea as an option, don your facilitator hat again without trying to influence the team further.

This doesn’t mean letting the team drive off the cliff. You can always challenge an idea, but remember that every time you step in, you reduce team’s independence a bit.