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!
IMPEDIMENTS
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.
Write a comment
Ben Linders (Monday, 21 March 2016 12:29)
Great post Alexey. As we discussed on Facebook, I like team members to be the ones who solve problems, in stead of having a Scrum master (Scrum mom) doing it. There's value in the Scrum master helping the team to find ways, and be an example, but yes, it's about teaching people how to fish in stead of feeding them.
In my opinion very mature team probably don't need a Scrum master role anymore. This is also why I don't believe in full time Scrum masters (I blogged about this in http://www.benlinders.com/2015/no-dedicated-scrum-master/). We have to prevent Scrum masters from becoming overhead, keep the role valuable, up to the point that a team has developed enough capabilities to self organize.
Alexey Krivitsky (Monday, 21 March 2016 12:34)
Thanks, Ben.
I can agree with the fact that there can be a period in a team's lifespan when it has over-grown its ScrumMaster (happened to me several times in my carrier of a full-time ScrumMaster).
So yes, one can say that a very mature team doesn't need a ScrumMaster. More accurately: they don't need that specific ScrumMaster anymore.
It still doesn't mean there is no better coach out there to help this team to keep growing. It is definitely a sign for this ScrumMaster that s/he is better off helping other teams in the company. And most likely this team can be self-managing and sustain the process.
But like any good football team - the better it gets, the better coach it needs.
Florian Eisenberg (Monday, 21 March 2016 14:40)
Alex,
I agree with Ben on some of the aspects. Mostly, I would like to point out, that the Scrum Master is a role that someone is playing, not a position somebody should fill out. Thus, if there are things impeding the team which need "management attention", there'd better be someone who can clear the path for them instead of using up their precious time playing politics in the enterprise. What I've seen with many, many teams is a development team which invests a lot of their time into resolving impediments instead of working on their main responsibility – developing a product customers love. There exists "support troops", if you don't mind the picture, which can do a hell lot better job at clearing the path – they're called managers, team leads and so on. They should, after all, play the role of the Scrum Master. Just as they should work in the development team if that is their best place of contribution.
It's not about the team & its growth. It's about the product and the customers. The teams growth is a means, not an end.
As sad as the friend's story is on a personal level: if the Scrum Masters are not generating value and instead the team leads do –and I've seen that, too – they should be let go. The Scrum Master is there to make the team faster.
Alexey Krivitsky (Monday, 21 March 2016 14:41)
Thanks, Florian.
Can't agree more.
Steve Casey (Friday, 23 September 2016 14:45)
As a counter-point to the characterisation of a scrum-mom, do we really want our developers removing impediments of faulty power supplies in the server farm or an inadequate speakerphone for the standup?
Sure - impediments directly related to their skills, they should fix them, and get used to fixing them, but something else that's a distraction? The SM could have it as a part of their role to ensure that the right people are fixing the problem, properly and timely.
I worry the SM is just worried that they're becoming a glorified administrator. If an impediment is there, it's part of their job to remove it!
Seth (Tuesday, 16 July 2019 14:36)
If you are simply referring to impediments to the team becoming more agile, than I would agree with you. I think "impediments" goes way beyond that however to really include technical impediments. In my experience, the team is more than capable of removing their own impediments (after all, they are bright people). An impediment of a tablespace being full doesn't require a scrum master coaching them to talk with the DBA. The act of a scrum master removing impediments is beneficial to the team in that it keeps them focusing on their key goal of producing working software/meeting their goals versus spending time on other these issues.
Regarding the Scrum Master role, it has to be more than just being an agile coach (that is what Agile Coaches are for not scrum masters). A scrum master must be a "servant leader" to the team. He/she must be willing to pitch in beyond just coaching the team in the ways of agile and provide value to the team in meeting their goals (this includes removing impediments). The reason why many companies and teams don't see the value in scrum masters is that people in the scrum master position are often not providing any value. They focus on just being agile coaches rather than a member of the team fulfilling both leadership role AND a servant role.