What is Agile Facilitation?

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.

What I’m learning about coaching from learning to surf

I’m always eager to learn new things, as I find it a useful way to maintain a ‘beginner mind’ approach to life. Usually my focus is in the agile and/or creative area, but earlier this year I had an opportunity to go for a surf lesson at a discounted rate, and on a whim I booked the lesson. Unsurprisingly, while I managed to stand up on the (large, beginners) surf board, I didn’t really feel a passion for it.

But after a while it dawned on me there was another reason for learning something completely out of my comfort zone: agile methods are by definition about continuous improvement, and therefore about continuous learning. By slowing down and paying close attention to my own learning experience, I could try to apply what I notice to agile coaching.

I’ve now had four lessons, three in a dedicated “group”, and to date all with different coaches. This is what I have so far:

  1. Fear of failing manifests as doubts and naysaying – what we know as ‘resistance’. This has been present at every lesson (“maybe I can skip this one, I’m tired & have a lot of work to do” etc.) and I wonder if it ever truly goes away. But ignoring that voice is immensely satisfying – I’m beginning to think ‘ignoring’ is the key to overcoming resistance, rather than motivation or rationalization.
  2. For the most part my coaches don’t tell me what to do, aside from basic info before we get into the water. They just help me get going and let me at it, knowing each person will find their own way.
  3. There’s a lot more to learning a new skill than just the main objective – it’s familiarising yourself with a whole new environment (language, orientation, techniques, constraints).
  4. My coaches don’t judge when I fail, or tell me what I did wrong. Sometimes they offer other information – ‘try this’, ‘what you should know about the water (environment) is that’ – but as a beginner there is so much sensory overload that it’s hard enough to make sense of what you are doing without someone telling you what you’re doing wrong.
  5. Once I’ve made a mistake often enough to realise it’s a pattern, I know what to ask. Then I can focus on learning how to do it right. So I’m really committed to that improvement, and I do so at my own pace. Yes, some of my questions are dumb, and sometimes I do feel dumb. But I still own gaining that piece of knowledge.
  6. When I do follow a suggestion rather than work it out myself, I’m never quite sure what I was doing before. But then I usually go backwards again, and find out the hard way anyway.
  7. A small word of praise goes a long way – both from peers and from the coach.
  8. It’s important to get out of early comfort zones quickly – as a beginner, you’re likely to be working within unrealistic ‘safety-harness’ boundaries that allow you to conquer the basics. Once you’ve done that, the safety net quickly becomes a limitation, and staying in that zone keeps you struggling with the wrong things. So you need to be able to stabilise, then move swiftly to more challenging ground.
  9. Different coaches know different things – it’s great to be exposed to a variety of perspectives.
  10. The community of experts are a lot more forgiving of an outsider once you’ve given it a shot, and come back again for more.
  11. No matter what your skill level, a good dose of humility and a recognition of others’ achievements is what engenders friendship and encouragement – and these are what create a sense of “team” out of a group of individuals.
  12. Learning something new redefines how you see yourself and your skill sets. A new skill might extend your current grouping to include the new one (i.e. ‘more sport skills’), or open up whole new avenues (‘now I’ve done this, perhaps I could also do that’). I think both of these are things to celebrate with team members as they happen.

I’m hoping that over time these and other observations will help me to be more attuned to the agile teams I work with, and to address similar issues as they arise with a deeper insight into what’s going on.

So why is this on a facilitation blog? Because a lot of agile facilitation happens outside of the time-boxed and clearly defined meetings: as a Scrum Master skill, coaching is both helping people adapt to agile methods and aiding the process of team transformation. To do so with as little “telling” and as much understanding as possible is one of the definitive aims of facilitation.

Appreciative Inquiry: Facilitation Lessons from an On-the-Spot Retrospective

I’ve been reading recently about teams who only focus on positive retrospectives – never asking “what did we do wrong”, and focusing instead on “what can we do better” – with great results. While the idea makes sense to me, I wasn’t sure how I could introduce the concept to my team.

But today the team decided to bring the retrospective forward by half a day, to this afternoon instead of tomorrow morning.* And being a “last responsible moment” kind of planner, as well as a “Don’t prepare, just show up” kind of improvisor when the situation dictates, I headed off to the shops to grab snacks & ponder which format would be best for the team. They’re doing pretty well, and the sprint review was a success, but nothing in particular sprang to mind on the walk.

Armed with my prompt-list of retrospective activities and a vaguely related transcription of activity formats, I headed to the room & got going, praying that inspiration would strike. It didn’t – or at least, it didn’t seem to.

Fortunately I follow a pretty standard format which the team knows well, so we got started with the sprint metaphor followed by review of the sprint artifacts. By which time I was sure inspiration would strike. Still no. Except for the nagging idea to ‘put it to the team’.

So when we got to the “Gather Data” section of the retrospective, I turned to my list of standard activities, and read them to the team, saying “this is the list I usually work from, let’s see what makes sense for us today”.

“Try appreciative inquiry

Instead of looking at where to improve, look at what’s working well and how you can build on that. Use short, pair interviews to explore questions such as, “When were you at your best on our last sprint?” “Who else was involved?” and “What conditions were present?” After the interviews, put the pairs together in groups of four or six (two pairs or three pairs together) to find common themes.

From Esther Derby’s blog 7 Ways to Revitalize Your Sprint

I explained each one as I went along, and watched the team weigh up each option. Top of the list was Esther Derby’s Appreciative Enquiry (see right) – a technique I hadn’t used with this team before.

Another format that seemed valid to me was “We’re Good At / Worry About / Wonder About” since there are changes afoot, but one of the members pointed out we’d done that about three sprints ago – I love that they respect variety! – and asked about Appreciative Enquiry. This team is pretty logic-focused and also contains quite a skeptic, so I was surprised when they all agreed – essentially to work in pairs, ask each other nice questions, and feed back on their pair’s behalf.

I’m pretty sure that if I’d planned this activity without their input, it would have bombed. But because they’d chosen it, everyone got stuck into the exercise. There was a brief moment as they wondered what they’d got themselves in to, with a bit of ‘do we have to answer all of the questions’ but since the questions are simple and follow each other well, it wasn’t much of an objection. And what was really interesting was how consistent the answers to the questions were – with variety indicative of personality rather than differences of opinion. This really emphasised how well they work as a unit.

To take the leap of making all this ‘fluffy stuff’ actionable, I had the team answer the question “How can we apply this knowledge to future sprints?” in round-robin format. From this we generated some very concrete goals and actions – concrete enough for the team to feel comfortable committing to two – a change in work patterns (limit WIP) and a specific action to change their environment setup to reduce external dependencies.

So my facilitation lessons from Just Showing Up today were:

1. It’s okay to just show up – when everyone knows how to make an informed decision
2. Fluffy stuff can go down well with an outcomes-focused team – as long as we work towards clear and concrete goals
But most importantly:
3. As always, the best way to make sure everyone’s engaged in the process is to include them in the decision making.

I think the team needs to have a relatively good understanding of the retrospective process for this to work (“Ha” in the Shu-Ha-Ri scale), but it’s magic to see.

* We usually have the retro straight after review, but the post-holiday period for work and school had meant some parent-focused rescheduling.

Activities for Retrospectives – Collected Links & Lists

Once we move beyond the normal “What Worked Well / What Didn’t / What Can We Improve” retrospectives, there’s a whole world of interesting activities to engage and focus participants – and it’s growing fast :D

These sites provide a good starting point:

Retrospective Wiki: Retrospective Plans
This section of the wiki includes quite a few complete retrospective plans such as 6 Thinking Hats; Everyday Retrospective; ‘Start / Stop / Continue / More of / Less of’ Wheel. Even if you don’t use the plans in their entirety, they give a good idea of how to structure a retrospective, from activities to timing. I like this whole site – it’s worth looking through.

Extract from Agile Retrospectives – Making Good Teams Great
This PDF extract of Esther Derby and Diana Larson’s classic, kindly provided by the publishers The Pragmatic Bookshelf, includes the following games: Timeline, Triple Nickels, Team Radar, Force Field Analysis, Fishbone.

Partnerships and Possibilities
Diana Larsen and Sharon Buckmaster’s blog, containing a variety of agile writings. Filter on Retrospectives for quite a long list of activities – either blogged or linked to other blogs. I particularly like Circles and Soup, as well as the Appreciative Retrospective – I’ve used both ;-)

Thorsten O. Kalnin invents really interesting creative retrospectives. Try Agile Speed Dating, Agile Olympics (Golf, Tennis and Bowling have been added so far), or the irresistible StrategicPlay® simulations using Lego.

Gamestorming Games Wiki
This site is has a variety of facilitation games, and is more of a general facilitation resource, but I’ve used some activities in retrospectives to great effect. It’s a particularly useful site if you’re looking for ‘out of the box’ ideas.
I strongly recommend purchasing the Gamestorming book – it’s a fabulous resource to have on hand to flip through when you’re looking for inspiration.

Other links:

This conversation on the LinkedIn Certified ScrumMasters Group: Creative ways of conducting retrospectives has some interesting ideas from contributors.

Why I Care About Retrospectives

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

All About Retrospectives – Collected Links & Lists

The sites below contain a wealth of information about what agile retrospectives are, how to conduct them, and how they fit into the broader agile picture.

If you’re new to retrospectives, take your time browsing sites that look interesting to you, from basic to advanced. If you’ve been doing this for a while you’re likely to be familiar with a few of the sites; I hope you find some new gems or interesting combinations that spark new ideas for you… would love to hear if you do!

Refactoring your Development Process with Retrospectives
A thorough introduction by Rachel Davies on why retrospectives are important for teams. The article covers learning from experience, the structure of a retrospective, and how to do them well.

Insights You Can Use
Esther Derby’s blog, which is aptly named :-) Filter on Retrospectives for insights specific to retrospectives, how they work, why they fail, and ways to make them stick. For reading and re-reading.

Resources on Retrospectives
Comprehensive links list covering the basics of conducting good retrospectives – what to do and what not to do – as well as interesting variations and experience-based discussions.

Agile Advice – Recommended Materials
A great set of links to all things agile, with retrospective and facilitation concerns featuring under headings like Team Building, Corporate Culture and Self Organizing Teams. Worth trawling.

Agile/Scrum Retrospectives – Tips and Tricks
InfoQ’s useful set of collected tips and techniques for conducting retrospectives – and like many agile blogs, the content continues in the comments section ;-)

The Retrospect Prime Directive

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

This quote is what we know as the Retrospective Prime Directive. It comes from Norman L. Kerth’s “Project Retrospectives: A Handbook for Team Reviews” – one of the earliest books specifically on the subject of Retrospectives, written in 2001.*

I hold the Prime Directive to be true in every situation, even when the product is below standard, or it seems that team members are not contributing their best. I find it useful to remember that it’s the best given the resources available and the situation at hand. Retrospectives are the tool we have for surfacing underlying issues that stop us from producing the best of all possible work – from technical to budgetary to interpersonal.

By holding this principle to be true in all situations we get away from blaming and move quickly to searching for the source of problems. It’s also is a significant factor in building trust, and it’s only in a truly trustful environment (safe space) that team members are able to get to the real issues affecting project success – or indeed, feel comfortable sharing their ‘secrets of success’ to enable everyone else to achieve great results.

* Norm Kerth is often referred to as the Father of Retrospectives – his site is at www.retrospectives.com