Although the Scrum Guide specifies only one accountability for the Scrum Master, more is packed into that single statement than a can of sardines.
Trying to fulfill the accountability of the Scrum Master has been a point of strife in my career and mental health.
A Director of Software Engineering once explained to me the ramifications of listing one-year projects as a single line on a spreadsheet. The gross summation implies that there is just one thing to do and diminishes the amount of effort required to complete this massive project. The longer it takes to complete this single item, the more incompetent the development team starts to look through the eyes of executive leadership that aren’t involved in the details.
I believe a similar gross understatement applies to the Scrum Master’s single accountability.
“The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.”
That’s all, aye?
The Scrum Guide proceeds to decompose this one statement into three categories of contributions. Compared to the other roles (Product Owner and Developers), which have four bullet points, the Scrum Master ends up with twelve. The remainder of this article will explore each of those points. Along the way, I hope to shed some light on the scope of work that occurs with each.
“Coaching the team members in self-management and cross-functionality”
We could get into an endless discussion about the definitions of self-management and cross-functionality. Let’s agree that this statement aims to build a team of leaders. Some of you may balk at this description because your definition of ‘leader’ differs from mine. After reading The 360 Degree Leader by John C. Maxwell, I’ve realized that being a leader is more about your actions and attitude and less about your title.
“A leader is one who knows the way, goes the way, and shows the way.”
- John C. Maxwell
Self-managing teams work collaboratively to plan and execute work without needing to be micro-managed. Cross-functional teams possess all the skills between them to be able to accomplish a task from beginning to end. Developing teams that meet these criteria is not easy, and many people who achieve such feats have best-selling books or movies based on the crusade.
David Marquet in Turn the Ship Around! tells the story of how he took the worst ship in the fleet and turned it into the best in terms of morale, performance, and retention.
The Ron Clark Story is a movie that documents a teacher’s journey to take the worst performing class in a Harlem school and unlock the student’s potential.
For most teams, these new skills will require a paradigm shift. Micro-managers used to doling out tasks must transition to a different leadership style. Developers who have grown accustomed to being told exactly what and how to do things will need to develop planning and collaboration skills.
“Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done”
Focus boils down to helping the team identify what is important and giving them air cover from shifting priorities. Sprint Planning plays a big part in increasing focus. We plan what we will accomplish in the upcoming one to four weeks, and we have a Sprint Goal that sets a vision. Helping teams truly leverage focus in Scrum instead of just going through the motions can be challenging.
To build high-value increments, teams need to develop the skill of decomposing functionality into bite-sized chunks. The faster we can deliver something, the quicker we get feedback. Smaller bites are easier to manage, and we’re more likely to build the right thing or recover from mistakes more quickly.
High-value increments also require knowing each feature’s value, which means that the Product Owner must obtain that from the stakeholders and communicate that to the developers. If that’s not happening, it’s on the Scrum Master to coach the Product Owner and Developers on the importance of these details.
To meet the Definition of Done, the team must have one and use it. That alone can be a challenge for groups new to the agile mindset.
“Causing the removal of impediments to the Scrum Team’s progress”
Not every impediment experienced by the team will be something that the Scrum Master themselves will remove, but they will play a part in causing the removal.
It might be that we coach the team on how to remove the blocker for themselves. In other situations, we may need to raise the impediment to the attention of people in leadership positions that have the power to remove the obstruction.
Escalating and following up on obstacles will take up a significant portion of time based on my past experiences, especially when it comes to cultural impediments that can be slow to change.
“Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.”
Though the Scrum Master isn’t required to run or even participate in all Scrum Events, it falls to them to ensure success.
The first and seemingly easy task is ensuring that someone has scheduled the meetings. If the team is already operating in self-management mode, the Scrum Master may not necessarily own the invites. Still, they’ll need to ensure a schedule is in place, the appropriate people have been invited, and everyone knows where they need to be.
The key to ensuring a productive event is that everyone understands and commits to the event’s purpose. We all must know what we’re trying to achieve and agree that the goal provides value.
In the past, I’ve developed unique scripts to kick off each Sprint Event by restating its purpose. Marketing has popularized the idea of repeating a message seven times. This repetition helps ensure everyone remembers why they’re there and that we’re all pointed in the same direction. Tactics such as reaffirming the purpose of a meeting can help prevent common anti-patters like the Daily Scrum devolving into a status meeting instead of serving as a planning meeting for the team.
Enforcing the timebox helps the team in two ways. It ensures that they have time remaining to focus on delivering value, and it promotes improving the efficiency of events. Mark Summers tells a story about ending a Sprint Review on time, even though the Product Owner didn’t cover all of the material. The Product Owner was upset because, ultimately, the whole affair drew attention to their inefficiencies. On the bright side, though, the Product Owner resolved the inefficiencies before the next meeting.
Ensuring that events are positive and productive is another area where an agile team may require much mentoring. Several experiments may be necessary to stamp out unproductive meeting habits. Individuals may need to upskill in effective communication, or we may need to implement working agreements that target eradicating destructive meeting behaviors.
If teams struggle to have positive interactions during a Sprint Event, solving this particular issue might take several rounds of root cause analysis before we can identify the ultimate solution. Do we have one specific person who is always an Eeyore? Does the whole team not see the value of the event? Are there severe cultural issues that make every day seem like we’re returning to the coal mine? Each of these situations would be addressed differently and aren’t easily solved.
“Helping find techniques for effective Product Goal definition and Product Backlog management”
Like most other tasks in the Scrum Master’s realm, the solution must be unique to the team’s situation. If the Product Backlog has one-hundred items, the refinement processes will be different than for a backlog with ten items.
You may have different options depending on which project management tool the team uses to track Product Backlog Items.
Some teams decide that only the Product Owner can add items to the backlog. In contrast, other agile teams allow anyone to add items but limit what they bring into Sprint Planning by enforcing a definition of ready.
The Scrum Master may need to help the team try several techniques and processes before finding the combination that works for them.
“Helping the Scrum Team understand the need for clear and concise Product Backlog items”
User Stories need to be just long enough to accomplish the necessary communication. Too short, and it’s impossible to reach a shared understanding. Too long, and no one will read it. Most of the teams I’ve worked with are always on one end of the spectrum. Either your Product Backlog Items contain only a title and no other details, or the stories include lengthy essays that may or may not be relevant.
It falls on the Scrum Master to help the team find their sweet spot for appropriate documentation. Some popular user stories and acceptance criteria templates can help, but the process must be customized to work for the team’s personalities.
“Helping establish empirical product planning for a complex environment”
I’ve written other articles about the importance of empiricism in Scrum. The concept seems simple but can be challenging to adopt in practice. Creating a safe space for teams to experiment does not come naturally to all cultures. If you are lucky enough to be able to experiment without fear of failure, you still have to convince your teams to try something new.
“Facilitating stakeholder collaboration as requested or needed.”
Remember, the ultimate goal is to have self-managing cross-functional teams. Although it might primarily be the Product Owners role to work with stakeholders, there will be instances where the team will need to work with people outside the Scrum Team.
The Scrum Master is likely to have more connections to other areas of the company through their work in resolving organizational impediments. These connections may come in handy when the team needs to collaborate with stockholders. The Scrum Master can make introductions and help developers know how to approach a conversation.
“Leading, training, and coaching the organization in its Scrum adoption”
There are entire companies founded solely to provide a solution for this gap, but it technically falls in the purview of the Scrum Master.
Most leading, training, and coaching will be a natural side-effect of fulfilling the other responsibilities we’ve already discussed. There may be times, though, when a more focused training session is required to get groups or individuals up to speed.
If the Scrum Master doesn’t have the capacity to provide training, they may choose to identify a vendor that can offer it on their behalf. The Scrum Master ensures that the need is filled in whatever way it makes sense.
“Planning and advising Scrum implementations within the organization”
As other teams in the organization start to see the benefits that Scrum provides, other groups might also become interested in implementing Scrum. The Scrum Master will play a large part in helping to plan and advise new implementations of Scrum.
Learnings can be shared across teams, and there may be a desire to implement consistent practices and techniques.
“Helping employees and stakeholders understand and enact an empirical approach for complex work”
Empiricism is the key to a successful Scrum implementation. Unfortunately, many teams miss this, and they try to follow Scrum by the book and make an incorrect assumption that anything not covered in the Scrum Guide isn’t allowed.
Helping the team embrace a culture of experimentation is a big hurdle that most Scrum Masters tackle. It’s a continuous battle to infuse empiricism into a group unfamiliar with the concept.
“Removing barriers between stakeholders and Scrum Teams”
The last but certainly not the least task for the Scrum Master is to break down organizational silos. Companies that come from a more traditional background may have segregated people by role.
Talking to a co-worker with a different manager may be a faux pas. The status quo is to escalate all items to the managers, and they’ll speak to the other manager and communicate the resulting outcome to the individual contributors.
In some cases, management has sheltered teams to the extent that they don’t even know who to talk to obtain the information they might need.
To remove these impediments, Scrum Masters must break down silos and normalize people communicating across lines. As you can imagine, that’s not a small ask in some companies.
Like sardines packed into a can, we can pack the responsibilities of a Scrum Master into one accountability.
Although, on the surface, this one accountability might seem as small as a can of sardines, be aware that, like sardines, the Scrum Master’s job is never-ending.