Over the years, working as a full-time Scrum Master and mentoring many others, I discovered these five traps. And I never saw anyone who has overcome all of them. But it is worth trying because it is the path of all great Scrum Masters.
So, what are the traps?
Trap #1: Starting to Serve
You have just joined the company and the team. Surely, you want the team to see how valuable you are as a Scrum Master. So, you're doing the best you can:
building good relationships with the team members
being seen as their friend
by solving the team's immediate problems will do
But a few wrong moves with good intentions, and you're in the 1st trap – you've become the team's secretary. Of course, the team want you to solve all their problems and have a reliable friend. I saw so many Scrum Masters lost themselves for years in this trap.
Your mission as a Scrum Master is to work on the system, not in the system. How to do that? Some ideas:
avoid getting involved in taking care of repetitive tasks (i.e., meeting bookings)
don't become a decision maker for things that the team couldn't agree on before
try to skip your initial reaction (solving problems) and go deeper with five why's (do root cause analysis alone and with the others)
help the team to see and own the problem and solutions
A great help here is the article of 2009 by Henrik Kniberg on cause-effect diagramming. System's thinking is your true saver here. You want to be the team's friend. But a wise one!
Trap #2: Getting Involved into Work
OK, you've avoided the 1st trap – you didn't jump to immediate problem-solving. Great, but now likely you feel the urge to do something of real value. And you have the skills for that – your primary skills (i.e., being a developer, a tester, or an analyst).
And there are many cases where to apply them:
You can't see the team struggling with understanding a piece of a requirement. So, you're jumping in and applying your BA skills to write a better backlog item…
Or you can't see the build being red all the time. So, you're fixing the test that broke it…
Good? Are you satisfied now? I think you are. Because doing those things make us all feel alright.
But notice: the team should have enough people to do those things already. And if not, that is the problem to get solved. And if you saw those challenges of the team, then it means the team is likely lacking is some thinking tools and practical tools.
Therefore, help the team build their capabilities, not merely apply your work skills when there is a gap:
Are you in love with collaborative backlog refinement sessions? Great! Teach the team how to do it more collaboratively.
Are you good at coding? Awesome. Show how to refactor some complicated legacy code and add some automated tests to it.
But whatever you're doing – never work alone. Your mission is to help grow other people's skills. Have you tried mob programming yet? There is also remote mob programming that requires almost zero extra tools.
Trap #3: Owning the Process
Hey, you didn't let yourself down and didn't become yet another team member doing the work, but you are staying above the water and working on the system. I am proud of you. I wish I were that good when I was a full-time Scrum Master, stuck in the first two traps for years.
But didn't you become now the one who cares about the process and its improvements the most? When everyone else is busy doing work, you are the only one who has the time to re-think the processes, right? Oops.
You've made your team depend on you: your thinking and your actions. This has been sucking out the feeling of process ownership from the team. Maybe not completely. But even if partially – you're in the trap #3. Congrats! This is much better than the first two traps. Yet, it is a trap nevertheless. That means, this limits your impact.
Your mission is not to drive process improvements (on your own), but rather enable the team to take care of it. By creating a culture of continuous improvements. And that means the process must be owned and got experimented with by the team. Not you!
Retrospectives are a great place to find out what to improve and experiment with. But never ever volunteer yourself for the action items. Never improve anything by yourself. Stay silent until someone else volunteers. And if no one does – this is a place to do an intervention with a question of genuine curiosity: “Hey team, isn't that interesting: almost everyone has just voted on that problem. And now, no one is willing to work on it. And please note that I am not judging. But this is intriguing. What are you making of this? What do you see that I don't?”
Let people volunteer for the things they care about. And never make them report back to you the status of those actions. You're not the process improvement boss! Behave like you don't care. This is a powerful technique to foster caring in others.
Trap #4: Working (just) with the teams
You did great. The team owns the process. The culture change has persisted. You are replaceable, but very useful. The team likes you, wants more of your “doing nothing but for good” attitude.
Are you done?
The team is just one part of the system. You shall be coaching not the parts of the system , but their interactions.
What are those? At least these three:
The relationships of the team and the product owner
The relationships of the team and the stakeholders
The relationships of the Product owner and the stakeholders
These relationships are your coaching client. Not the individuals. Think of that.
And the best way to keep that always in mind is to focus on the entire stream of customer's value. Not a single team. Not a single team's backlog. But the whole thing. Typically, it includes many teams, different stakeholders and various parts of the organization.
Your goal was never to coach scrum to a single team or two. But OK, you had to start somewhere. Now it is the time to go unleashed.
Trap #5: Having no Exit Strategy
You can't be improving a system forever.
You will be owned by the system eventually. Accepting its rules and limitations. And at that moment the change agent is done. You are done.
And you'd better have a plan for that. And it better a solid plan. A bold one. A vision of perfection that you helped the organization to uncover. A good way to start would be looking at the tools like this one: www.agilecoachingcanvas.org.
Thanks for reading this! And drop me a message if you have figured the next trap!