Many Scrum Masters act as if their job is to keep all the tasks up to date in the online agile tool. They act like mother hens, constantly chirping about team members not moving their tasks to done. Or, they are the only one with admin rights to make changes in Jira, TFS or whatever.
These are warning signs that the Scrum Master really doesn’t understand their role. By focusing on the tool being used, they miss out on removing impediments and supporting the team to self organize. Let’s look at how this occurred, but first, a little backstory.
[Read why I don’t like agile tools in The 9 Pitfalls of Using Agile Tools]
A Baseball Story
A few years back my son was playing as the catcher for his high school baseball team. There had just been a close play at first base, and my son was picking up the bat for the opposing team and returning it to their dugout.
It seemed like a nice thing to do, so I was surprised and won’t soon forget when his coach yelled out “Hey Mersino, you’re not their bat boy”. The point the coach was making was that it was not my son’s job to pick up the bat, he had more important things to do and focus on.
I recently made a connection in my agile coaching role for Scrum Masters. Many Scrum Masters today don’t really understand the Scrum Framework very well and see their job as mainly team administrator.
They’ve become the “Jira Lackey” for the team, which means that much of their time and effort is spent on updating items in the online agile tool, sharing Jira on their screen for meetings, creating nifty dashboards and running reports. I just want to scream at them, “Hey Scrum Masters, you are not the Jira Lackey!”.
How Scrum Masters Became the Jira Lackey
Traditionally, it was the project manager who tracked the tasks for team members and made sure everyone was working on the right things.
Project managers are drawn to their MS Project plans like moths to a flame and they can spend inordinate amounts of time trying to make their Microsoft project schedule match reality. Which is nearly impossible.
The Scrum Master is definitely not the project manager for the team. Many organizations put their project managers into the role of Scrum Master; stop it! [See Project Managers Make Lousy Scrum Masters]
Most project managers lack the skills needed to be effective as Scrum Masters. They fall back on what has worked for them in the past, and as a result, they make terrible Scrum Masters. They tend to focus on task management or administrative work like keeping the Jira Board up to date. Or they take notes during the daily standup, email them out to everyone and dutifully post them in SharePoint. Sigh.
Sure those former project managers are great at keeping an eye on the tasks in Jira (or TFS, VersionOne or some other tool) because that is what they always have done. And that is part of the problem – they don’t see being a Scrum Master as anything different than what they have always done.
Scrum Masters Should Be Much More
The Scrum Master should be much more than a taskmaster. They are a servant leader, bulldozer, and cheerleader. The Scrum Master encourages the team to become a high performing team.
The Scrum Guide summarizes the Scrum Master role as follows:
“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”
“The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
The Scrum Guide goes on to describe in detail how the Scrum Master serves the team, the Product Owner, and the Organization. The problem is, most Scrum Masters haven’t read the Scrum Guide, and they don’t really understand Scrum well enough to teach it to others and to enforce the theory, practices, and rules.
Yes, But Doesn’t the Scrum Master Serve the Team?
The Scrum Master is indeed a servant leader for the team. Does that mean that they should update the task board in Jira? No. Servant leadership is about serving the highest needs of the team.
The test of servant leadership is whether the team members are thriving and growing. For a new team, it may be helpful for the Scrum Master to update Jira at first.
But as the team matures, it is important for the Scrum Master to teach the team how to do this (and most other team activities) for themselves. It’s like packing a lunch for your son or daughter each morning.
It may be great and important when they are 8, but completely inappropriate when they are 18. And even more inappropriate at 28.
Having the Scrum Master update the Jira board or other team tracking tools can also have another undesired effect – the team doesn’t take ownership.
Teams should own their outcomes and whatever tools they need to make that happen. In fact, they don’t even need to use Jira. The tools are for the team.
If they are all in the same room and they want to use a physical task board, then the that is what they should use. But the point is this – whatever tools the team needs to get the job done, these should be owned and updated by the team. When they are owned or driven by the Scrum Master, the team no longer has to own them.
So What Should The Scrum Master Do?
The Scrum Master should be mastering Scrum, and coaching the Team, Product Owner and organization to use it effectively. They should be helping the team to self-organize and remove impediments.
Craig Larman is an expert on Scrum and Agile and he takes what it says in the Scrum Guide pretty seriously. In his view, the Scrum Master should be fixing the organization.
He sees Scrum Masters as powerful, impactful, and strategic. They are change agents and leaders. They shouldn’t be worried about tasks in Jira or asking if everyone can see their screen at the start of the standup. That is an administrative job that the team can do for themselves.
Most of us would agree that it is important to have a product backlog that is prioritized based on value. We want the teams working on the highest priority items because frankly there is ALWAYS more work for the team to get done than what they have the capacity to do. So we have to make choices and we strive to maximize the value that the team delivers.
We seem to forget the importance of prioritizing based on value when it comes to the contribution that the Scrum Master is making. Many Scrum Masters are focusing on the mundane and the trivial, and not focusing on the activities that will have the most impact across the enterprise.
Sure the Jira board is up to date, but has the organization implemented automated test tools to provide more throughput and shorter cycle time?
Is the team performance being undermined by continuous firefighting and shifting priorities that the Scrum Master is not heading off through the use of Systems Thinking and Root Cause analysis?
What should YOU do?
Take a moment to evaluate the Scrum Masters in your organization (and yourself if you are a Scrum Master). If you look at the work of a Scrum Master in a typical week, what is the impact of their efforts on the overall organization? Are they working on organizational impediments and changes?
Look also at the people who are performing this important role. Are they simply re-branded project managers? Or are they underpowered administrators who are focusing on the trivial and mundane?
Also, think about why it is that you have what you have? Is it a lack of understanding of Scrum? Or is it actually a way for the organization to preserve the status quo and resist change?
I hope this has provided you some food for thought. I welcome your comments and questions.