Meta

The ScrumMum – an agile adoption anti-pattern

Whichever way you look at it, if you’ve ever heard yourself talking to your team and uttering the words “I’m not your mother”, it’s probably not a good thing.

Even if you’re actually a Mum and have the healthy intention of creating independent and highly-functioning people – ready and equiped to face the world on their own two feet – having to tell someone who isn’t your progeny that you’re not their Mother means:

1. There is a clear case of mistaken identity
and
2. The aforementioned person(s) clearly aren’t in a place of independence or higher functioning yet.

If you’re their ScrumMaster and you’re saying these words, then you may have just fallen into the trap of becoming your team’s ‘ScrumMum’.

This can be an easy trap to fall into, particularly if you’re in the early days of an Agile adoption. This is in part due to the notion of Servant Leadership and maybe err-ing on the side of servitude over leadership.

It can also be exacerbated by the fact that few companies initially accept that the ScrumMaster role is a full-time position. They often create hybrid roles (or slashies as the movie Zoolander called them) despite protests from Agile/Scrum Coaches about ‘conflicts of interest’. In many cases, an early Agile adopter’s preference is for ‘resource utilisation’ over human objectivity.

However the conflict of interest causes considerable issues. It’s really hard to be objective when under direct pressure to deliver. So, when faced with this situation, plus the desire for successful adoption of a better way of working, most ScrumMasters will take on any trivial task to free them of this conflict. They can then maintain the justification for their existence – ‘I’m not directly productive, but look how all the support I give enables the team’.

This can lead to an over reliance on the ScrumMaster, with the team effectively seeing them as the team administrator. Before long the team stops doing even the most basic of things: from updating the board or calculating their velocity, to writing up actions from retrospective. Instead the ScrumMum ‘facilitates’ for them.

Unfortunately, the ScrumMum, while trying to do the right thing, makes it hard for the team to move up the ladder to the next level of an Agile adoption. Mainly because it separates the team from working directly with the Scrum theories and practices which help them improve.

This is Scrum by rote, instead of the standup being the Team’s standup, it becomes the ScrumMum’s standup – with the ScrumMum orchestrating and asking the 3 questions. The team just go through the motions in an almost mechanical way. This can lead to the standup becoming a status update with a distinct lack of co-ordination, the very thing the standup was intended to avoid.

The same follows with the other Scrum ceremonies. The team often going through the motions with little or no understanding of why they are doing something. Their sole interest becomes exiting the gathering as soon as possible so they can get back to their work and be ‘productive’.

As the team disengages with the system they operate in, the opportunity to create profound change and a more effective way of working is lost.

It can take a great deal of effort to turn this around. Undoing the dependence on the ScrumMum often involves some form of ‘reset’ to transfer ownership and responsibility from the ScrumMum to the team.

This often involves helping the team realise that the ceremonies and practices of Scrum are their ceremonies and practices. It’s necessary to first transfer ownership, then help the team understand the nature and value they derive from protocols.

For example, the team’s velocity is their velocity. It’s a diagnostic tool to help the team understand how well their engine is running. It’s certainly not a measuring stick to compare them with other teams. And it probably shouldn’t be use as a predictive tool for ‘planning’ delivery dates.

Instead, when their velocity dips, it allows them to reflect in order to understand why the dip occurred and what they can do to prevent that particular dip occurring again.

When their velocity increases, the team have the opportunity to analyse why it increased and decide if and how they can take advantage of it.

So, with the example of velocity, the ScrumMaster’s role is to help the team understand the principles. Why velocity is calculated, what about it’s nature will help the team understand more about their environment and how it will help them unlock and move to the next level.

It’s my humble opinion the Scrum framework presents a set of training wheels just like those on your first bike. A ScrumMaster’s key role is to support the team in understanding the mechanics of riding the bike, demonstrate why the use of the training wheels are initially necessary and then challenge the team to remove said wheels as soon as they can.

This can be done by:

Demonstrating the mechanics, show them how it works.

Transferring ownership to the team, let them try, let them fail.

Gradually decrease the support until they’re able to go it alone.

Once the team is on this path, they’re fast on the road to becoming self-sufficient. Your aim as a ScrumMaster (just like any good parent) is not to justify your own existence. You’re not there to create a group of dependents, but to know that your team can go out into the world and forge its own way.