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.

As a Scrum Master, I care about all the Scrum “events” – Sprint Planning, Daily Standups, Sprint Demo / Review and of course, the Retrospective. Do I care more about the retrospective? I’m not sure – but I certainly put a lot of effort into each one.

Partly that’s because I think it’s really important to make the most out of every meeting, and since each sprint is different, I try to make sure that the retro fits the overall needs of the team. And partly it’s because in my experience retrospecting has been a sorely neglected part of project management (in all industries, not just software) so there’s still a lot to learn about it. But since it’s arguably the most valuable tool we have for continuous improvement – to look back, identify strengths, clarify areas for improvement, and set plans in place to do so – I figure it’s worth putting extra energy in.

The retrospective is at the core of the Agile principle “Inspect and Adapt”. (Marc Bless unpacks this principle very nicely).  It’s particularly valuable in complex environments, where there’s a high degree of uncertainty and teams must be able to adapt to changing information and changing needs – which happens to be the realm of most software projects.

As an ex-Project Manager, I’ve been on projects where everyone knew we were veering off-course, with a collective feeling of “why doesn’t anyone do anything about this” hanging in the air – but we were always too late or under too much pressure by that time to do anything other than hold our breath and hope we can avoid disaster.

The ability to pause regularly to assess our overall progress, identify corrective action and implement it, seemed like an impossible luxury – or the final straw, when in extreme cases we had to go cap-in-hand to the client and explain why we couldn’t meet the time / scope / budget commitments. And while necessity may be the mother of invention, in these situations very few team members have much creative energy left.

Of course, when we had delivered a project on time & in budget (it’s a rare but not entirely mythical thing), we were immediately put under pressure to deliver more in the next project, with little opportunity to review what made this project different and be able to harvest that learning.

As I moved into an Agile environment, the focus of my retrospectives naturally shifted from projects to teams, and to me this is where the most value – and greatest challenge – lies.

Developing strong teams is one of the greatest assets a company can invest in. When a team is collaborating openly, sharing collective knowledge and engaging in constructive disagreement, it becomes increasingly easy to identify and eliminate blockages, smoothing the ability to complete work, and move on to the next challenge in a continuously improving – and highly functioning – team.

A lofty goal, and frequently considered the “snake-oil” of agile salesmen, this can only really be achieved when teams become dedicated to owning their improvements in an organization that supports and participates in the changes identified, over a sustained period of time.

At their heart, I see regular retrospectives as a key tool for team transformation, which help teams move from being a fragmented group of individuals reacting to corporate pressure, to trusting, self-organizing, motivated and directed teams, contributing to corporate discussions.

Yes, I have lofty ideals. Fortunately Agile provides me with a lot of practical ways to implement them :D