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 coaches point was that it was not my sons job to pick up the bat, he had more important things to do.
I recently made a connection in my coaching role for Scrum Masters. Many Scrum Masters today don't really understand Scrum very well and see their job as mainly an administrative job. They've become the "Jira Lackey" for the team, which means that much of their time and effort is spent on updating items in Jira, sharing Jira on their screen for meetings and making sure it is kept up to date. I just want to scream at them, "Hey Mersino, you are not their Jira Lackey!".
How We Got Here
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 making sure that their plans match reality.
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! Most project managers lack the skills needed to be effective as Scrum Masters and as a result, they don't do it well. Sure they 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 Maser should be much more than a task master. 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 phyical 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 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 adminstrators 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.
By Anthony Mersino | Tuesday, May 31, 2016