One of the more distinctive differences between agile software development and its traditional counterparts is the wide-spread adoption of group facilitation techniques by agile practitioners.
This is largely due to the high degree of collaboration demanded by agile methods: we have to learn effective ways of sharing information and making decisions together – so much so that it’s become one of the Scrum Master’s major responsibilities.
I see facilitation as a foundation support for self-organization, and critical to new management practices: the fundamental understanding that an informed collaborative approach to problem solving involving those closest to the work will consistently yield better results than a plan designed by a single expert.
So what is facilitation?
As a field, facilitation is hard to define. Wikipedia and Google give us a view of the wide range of contexts in which the term facilitation is used, from business to neuroscience.
These give us a good overview, but I worry about definitions that tell us facilitation is ‘making things easier’ (from the root ‘facile’). Because while facilitation is a significant aid to collaboration, as experience tells us, collaboration is not easy. Good facilitation provides ways to address this and make it more comfortable in the long run, but it’s neither a magical panacea for problem resolution nor a superficial fix we can use to avoid conflict.
To clarify my understanding of the field, this is my take on facilitation (I won’t claim it’s the most elegantly worded):
Facilitation is the “art” (an informed blend of techniques and insight) of aiding groups to collaboratively interpret their (project) context and identify the most valuable path forward.
From a continuous improvement perspective, we know that having clear and attainable goals set and agreed on by those doing the work is a fundamental factor in both motivation and team success. Coupled with the short cycles of Scrum, this provides an excellent mechanism for teams to improve incrementally while responding to changing conditions.
But we also know from complexity theory that there are situations when it’s just not possible to see up front what the desired outcome might be, and setting predefined goals or actions can be meaningless, or even damaging if they lead us in the wrong direction. In situations where work emerges as we go along, a facilitator needs to be able to help the team clarify the boundaries in which exploration can take place, and understand how to navigate these waters.
In either circumstance, the facilitator ensures that teams reflect regularly on the process, either to clarify whether the activities undertaken are leading them to the intended outcome; or to ensure that they are conscious of the steps they’re taking, the results generated and the kinds of patterns emerging – and what these indicate about next steps (Cynefin‘s Probe – Sense – Respond model). The detail of what and how to proceed is a product of the facilitation itself, not a predetermined formula.
From this perspective, agile facilitation is about reaching a new level of understanding; surfacing valuable insight that will get the group to their next stage – whether it’s a vision, the next sprint, or a new team dynamic.
Outside of continuous improvement, the Scrum Master facilitation functions include planning well for meetings, using time-boxes effectively, and ensuring good communication flow both within the team and across organizational boundaries. At a process level, it’s ensuring that coming work is appropriately groomed and that everyone is aware of constraints so that the right expectations are set.
Here the facilitator function is making sure that the time utilized and the effort expended are appropriate and valuable, and that there is as little as possible waste in both meetings and normal day-to-day activities.
And this is part of the ‘art’ of facilitation: how do we know what is wasteful and what beneficial? What level of noise is required for us to have sufficiently investigated all areas?
In different contexts, discussing a tangent or exploring an alternate technology could be beneficial, harmful, or irrelevant – but if it’s important enough to come up, we need to ensure that we explore sufficiently for the first two possibilities, and avoid the last. Again, this call must be guided by group input. Facilitation involves making sure everyone involved with a decision has a voice, is clear on both the constraints and possibilities, and is able to proceed in an informed manner.
It’s well noted that the facilitator does not provide answers, and as a rule does not contribute to the content. What they create is the most conducive environment for each individual to contribute their knowledge and clarify their concerns, such that the group is to be able to choose the best route for their situation, as a self-organized team responding to business needs.
And do to this well, we need a wide and deep ‘toolbox’ of techniques, from idea sharing to consensus activities, which allow us to respond in a contextually relevant way to the range of challenges with which software development so regularly furnishes its practitioners.
Pingback: Scrum Master 的外功 – 如何引導活動 « 敏捷進化趣 Agile FunEvo
Well put together. Any take on SM’s facilitation assessment based on Dreyfus model?
Cara Turner said:
Hi Muhammad, thanks for the comment :)
I like the Dreyfus Skills Acquisition model in any field, as an insight & input into designing learning, and particularly its relevance for mentoring relationships & personal development.
I’m not a big fan of performance assessments. I have tried out the adapted assessment model. It was built with good intention, but I’ve seen it used really badly – along with a number of well-meant ‘objective’ assessment tools.
I far prefer retrospective-based conversation & exploration for assessments, and it might make sense to discuss the model in that context, without the ratings. Every person’s journey is so different for so many reasons – I’ve found that customizing the conversation gives far more real value. Although that would seem to take more time, it actually feels like it saves time (although I haven’t specifically tracked the effort.)
Whatever route you take, I hope your assessments go well & provide meaningful insights.
Hi Cara, thanks for ur reply. To me Dreyfus model has too many levels, feels like slicing hair. I am working on facilitation part of wheel of scrum project and i am not sure you can have 5 different levels of facilitator, i can see a Master and novice and maybe proficient. i am not sure about competent and expert. how do u differentiate a master facilitator from an expert one or for that matter competent from proficient. are these methods really used in real life to make assessments?