With the wave of Agile ways of working quite a few new roles have been introduced to organisations: with basic Agile we’ve added Product Owner, Agile Coach, Scrum Master. Then the famous Spotify model added some extra roles to the mix like Chapter Lead and Tribe Lead. It’s easy to get lost in the role jargon if Agile is not your daily bread and butter or you’ve been a bit further away from software development.
I want to focus on the Agile Team Facilitator role that you might have heard of and perhaps wondered about how it’s different from an Agile Coach or Scrum Master.
Let’s start by breaking down the name into the 3 elements. “Agile” is pretty clear, it’s about the particular mindset, a set of attitudes and practices. The word “Team” clearly puts a spotlight on what the role focuses on. The last element is “Facilitator”, meaning actively helping people to work better, building a common understanding and making things easier.
You might say ‘oh it sounds very like a Scrum Master role’. Well, yes and no. While some activities might be the same, there are a few key differences. The Agile Team Facilitator role is framework agnostic, meaning that this person is not tied to the constructs of Scrum as a magic wand to improve whatever the team is doing regardless of context.
The Power of Words
Speaking of magic wands…if I had one, I would get rid of the name “Scrum Master” and turn all Scrum Masters into Agile Team Facilitators. Here are my top 4 reasons why:
- Calling yourself a master will not win the hearts and minds of the team members you’re working with. Mastery does not come from a 2 day course and a certificate.
-Not all teams need Scrum, but all teams benefit from good facilitation.
- In an environment with low Agile knowledge or experience calling yourself a Scrum Master might put you in a losing position from day 1, because people have very little knowledge of what you actually do and outside Agile, it’s a fairly strange terminology.
- It’s a term with a fairly heavy gender bias, even if not intended. We should be looking for language that supports equality seamlessly, not requiring explanation or additional mental effort to accept it.
It might sound like it's only a word game, but words have power. Believe me, I’ve been a Scrum Master for a few years. I’ve heard all the jokes already (the ones not behind my back anyway) - they certainly didn’t make me feel very ‘masterful’.
The Four Approaches of an Agile Team Facilitator
Through my work with many teams over the years I have learned that my way of interacting with each and every one of them has been different. All of these experiences have crystallised into patterns that I call approaches of an Agile Team Facilitator. This model is useful for defining the type of involvement you have with a team, based on the state they’re in. If I had known this some years ago it would have made my work with teams way more effective.
One of the key skills for an Agile Team Facilitator is the ability to read the team’s context and the environment. Whenever I start working with a new team I look at two main signals. First goes the team's capability to continuously improve and self-organise. I observe the existing ways of working, quality of discussions, relationships and their ability to improve. I look at how teams tackle challenges, make decisions and enable different people to express their voice.
Secondly, I look at the level of engagement that people bring and their willingness to learn. To test that out, I introduce some ideas to the team during or offer new ways of doing things, and then check to see how they respond. Is the team curious and willing to try new things, or do you get an awkward silence and people don’t really care about trying something new to improve? Are team members present in meetings or distracted, looking at their second screen and not paying their full attention?
Understanding these signals help me to choose an initial approach and see how the team responds. Here are the four approaches based on my initial read of the signals described above:
The ultimate goal for an Agile Team Facilitator is to help teams improve their self-organisation and show a path for continuous improvement. There is no timeframe for how long it should take to transition through different quadrants because every environment is unique with its own context and constraints. These different states are not a transition from bad to good. It’s a pathway of progression respecting the current state of any team.
These states are not fixed. You will have teams that are stuck in a particular state forever and can’t breakthrough towards the higher levels of self-organisation or engagement. Teams will also flow between these states over a period of time due to the impact of things like new people joining, changes in structure or product etc. Once a team has achieved a state of self-management and high performance they will obviously not remain there forever. Like any team they will go through highs and lows; sometimes they will find themselves in a rut, get bored or lose momentum. This is a natural part of work life and team performance and it is the Agile Team Facilitator's job to inject new stimuli and initiate corrections.
Very few organisations can afford to have a team facilitator for every team, so the best you can do is show up, help teams grow and move on to the teams that need your support more. Next time I will talk about specific practices for each quadrant and most common challenges.
What signals are you looking for when working with teams?