Author: Alexey Krivitsky
There has been recently a very heated debate on the ScrumMaster Community on Facebook. It all started with a provocative question from Ben Linders on who should be solving impediments. My answer was "teams as much as they can, except when the issues are out of their power - then managers". And then the flame started.
A SAD STORY
The discussion on Facebook collided with my good friend (and a great ScrumMaster) sharing with me quite a sad story of his. Some weeks ago he was fired along with his other 15 colleagues, also ScrumMasters.
The company decided to keep just a few. Interestingly the company never decided to stop using Scrum. It was just "optimized to remove overhead". That happened the day a new CEO came in and claimed that "ScrumMasters add no value" (a literal quote I was told).
Think of this once more: in a Scrum company, ScrumMaster became an overhead role.
What have we all done wrong in the industry that it is going sideways that badly?
It starts with (mis-)understanding the dynamics of team maturity and the role of removing impediments. So let's see.
TEAM MATURITY AND SCRUMMASTERY
We all know the Tuckman's model of group relationship development with its four (actually there are five) stages:
Before a team can get any closer to a high-performance stage, they need to go through fire and ice of conflicts into building norms and working agreements.
In reality, of course, such development is never linear and any team passes through multiple cycles of storming-norming. Still the simplicity of the model helps understand the ground idea - people need to stay together for a while before they can learn how to work as a great team.
Based on Tuckman's dynamics, here is my understanding of development of a Scrum team:
The term "ScrumMom" (coined by Angel Medinilla) is probably the best description what is usually happening during the first stage. The team is relying on its ScrumMaster (the Mom) to do Scrum. And that's understood! We all learned to walk, run, bike, ride - and we all needed teachers and supporters on the way.
Until one moment when we crashed into a bush and realized it was our sole responsibility (and no one else's) to control the way we walk, run, ride.. or develop software products.
One can say the goal of a ScrumMaster is to make sure team doesn't jump off a cliff before they know how to fly.
Instead s/he is there to make sure a team can steadily learn how to ride on a relatively safe but bushy playground. And with a helmet on.
But not for too long, though!
So what is with removing impediments?
The ScrumGuide lists "Removing impediments to the Development Team’s progress" as one of the key ScrumMaster's services toward the teams.
Yes... And no.
So what is going to happen if a ScrumMaster keeps solving all impediments for a team? The team will simply never grow (and will always need a ScrumMom). That is opposite of what a ScrumMaster shall be striving for. Hence it's wrong.
When someone is hungry, giving him a fish solves the immediate problem (removes an impediment) and is also a generous thing to do. But on the other hand - giving him a fishing rod and teaching how to use it - is also a good strategy. It likely takes more time and effort though,but guarantees that similar problems can now be handled by the individual.
So which impediments shall a ScrumMaster be removing? And how?
Here is my thinking sheet:
- A team has an impediment. In theory shall be able to solve themselves.
=> Teach/coach how and pair if needed.
- A team has a similar impediment again.
=> Stay away and wait for the team to step in and fix it.
- A team has an impediment that they shall be capable of solving. But they are not fixing it.
=> Make the issue is highly visible. Stay away and wait for the team to step in and fix it.
=> Teach how to visualize similar issues so that they are never omitted.
- A team has a highly visible impediment that they shall be capable of solving. But they are not.
=> Understand what is blocking the team to take the responsibility.
=> If it can be fixed with teaching/coaching the responsibility process - do it.
=> See if other teams have the same issue and if attitude is also similar.
- Despite the effort the impediment is still there. Teaching/coaching the team didn't help.
=> Likely it has a systemic root cause to be worked out by the management.
=> Make the issue is highly visible to management.
I see a ScrumMaster as not the ultimate impediment remover. Instead his goal is to grow capacity of the team and the entire organization to be able to solve all kinds of impediments. Here is how we can really add value.
Otherwise we just become Scrum administrators - an overhead role. Why overhead - well, because teams in other organizations are doing all that by themselves.
And then one day a CEO comes in...
But it doesn't have to be that dramatic as in my friend's sad story. In fact, you want your engagement with a team to be time-boxed.
TIME-BOX YOUR SCRUMMASTERS
If I know my mission with a certain team is limited, my attitude towards coaching and removing impediments will be much more different than if I know I'm "attached" to the team full-time and forever.
Does your company attach ScrumMasters to teams?
Or are you a partial ScrumMaster and a team member (e.g. test engineer)?
If yes, then that's likely going to be a never-ending debate - if you're really adding value or just fulfilling an overhead role.
ScrumMasters need to have a good vision on where to guide teams and have an agreed time-box (like a release of a product) to prove these ideas right or wrong.
This changes the dynamic of ScrumMastery completely:
Because If I know I'm there just for a certain agreed time - and my goal is to help a certain team grow and reach the next maturity level (whichever that is), I'm likely to be pushing back impediment solving onto the team and working also with management to create a better system for teams to perform.
That would make the team independent (also from me) and a company a better place. And when the time comes for me to leave and help other teams, this team I've been working with will know how to carry on fishing.
So don't attach your ScrumMasters to teams. Instead, help them build bold visions of team and organization growth and support them in making this leap within a given time-frame.
P.S. I'm working on a thinking tool to help ScrumMasters / Agile coach build and share their big visions. Check out the focusedagilecoaching.com.