Like a lens, experience refines the understanding of Scrum Master responsibilities, even when you thought you already had a clear picture.
The Scrum Guide lays out the twelve responsibilities of the Scrum Master with clarity. However, even with this seemingly straightforward guide, this role (or accountability as we now call it) remains one of the most misunderstood.
It doesn’t help that a quick Google search for ‘Top 7 Responsibilities of a Scrum Master’ yields numerous top-ranking pages riddled with misinformation.
My clarity of the role emerged through experience. Though the following seven responsibilities may not be explicitly listed in a Scrum Master job description, in my experience, they’re what’s needed to fill the role successfully.
“Coaching the team members in self-management and cross-functionality”
- Scrum Guide
Recognizing the significance of fostering team autonomy is pivotal for thriving as a Scrum Master. Shifting from an executor to an enabler mindset is one of the most challenging paradigm shifts to embrace.
Finding the right balance can be challenging even as you begin to embrace this mindset. It’s not about being merely a cheerleader but instead navigating between enabling and active involvement, ensuring you add value without overstepping.
You’re tackling different problem sets compared to your team. While developers troubleshoot system bugs, you’re strategizing how to eliminate process bottlenecks. While the Product Owner prioritizes backlog items, you explore experiments to enhance team efficiency and knowledge.
The Scrum Master role often faces criticism, with misconceptions ranging from uncertainty about your daily activities to the belief that you’re primarily responsible for scheduling meetings and taking notes. This misunderstanding can lead to a sense of needing to justify your position.
You could take on more tasks, start solving problems independently, and attempt to enforce processes. This course of action is a natural response to try to highlight your achievements. However, this overcorrection strays from the core principles of the Scrum Master’s accountability and will lead you down a dysfunctional path.
While the term ‘servant leader’ may no longer be explicitly stated in the Scrum Guide, its essence persists in every mention of the word ‘serve,’ reflecting the foundational principles of the role.
You don’t solve problems; you bring them to the team to solve. You coach them on their options, drawing from your experience of what has worked and failed in other teams and industry-standard best practices they might consider. Suppose a team member needs to handle a task beyond their current skill set, such as a challenging conversation. In that case, you may support them by accompanying them or driving the discussion once to provide an example. However, consistently doing these tasks for the team hinders their growth, autonomy, self-management, and self-organization.
One of my significant misconceptions about this role was the belief that Scrum Masters are solely responsible for removing impediments for the team, implying that I had to solve all the problems. Despite occasional bouts of confidence bordering on hubris, even I realized the futility of attempting to solve all the team’s problems single-handedly. It took time to understand that my initial interpretation was a misunderstanding of the role rather than a personal failure.
If my team faces an impediment due to a lack of Django skills, and peers expect me as a Scrum Master to ensure their development in this area, we’re screwed. Frankly, I’m not even familiar with Django. I can’t teach it to the team. While I might arrange training, evaluating its suitability is challenging when unaware of the technology.
“Removing impediments to the Development Team’s progress”
- Scrum Guide (2010-2019)
For a very long time, the Scrum Guide listed removing impediments as the responsibility of the Scrum Master. In 2020, this changed, slightly:
“Causing the removal of impediments to the Scrum Team’s progress”
- Scrum Guide
Now, this makes more sense. Do you know who’s in a position to evaluate Django training? The developers themselves. I don’t have to tackle this impediment solo; my role is to facilitate its removal. I can assist the team in selecting training, suggest reaching out to Doug from another team known for his Django skills, propose allocating time for self-training, or help draft a proposal for formal training. I can lend support in these areas, but I don’t believe the framework ever intended Scrum Masters to do this solo.
- Facilitating stakeholder collaboration as requested or needed.
- Removing barriers between stakeholders and Scrum Teams.
- Scrum Guide
When I first stepped into the Scrum Master role, I believed these responsibilities primarily involved dismantling organizational silos and encouraging stakeholder participation in Scrum Events. While these aspects are relevant, I’ve realized that the underlying issue often lies in the development team’s uncertainty about whom to engage with or their hesitation to do so.
In many instances, I simply needed to inquire to determine the key stakeholders we needed to engage with. I would then arrange a meeting involving relevant team members and the identified stakeholders. During these meetings, I’d facilitate introductions, set the context by connecting the team’s work with stakeholder interests, and guide discussions toward addressing pertinent questions and concerns.
After the initial introduction and context-setting, collaboration typically unfolds organically.
Numerous teams feel detached from stakeholders, often restricted from direct interaction with users. These teams commonly believe that the organization has mandated that only the Product Owner has direct contact with end users. However, in reality, enforcement is rare; it’s often only a perceived restriction. In my experience, seeking assistance and explaining one’s objectives generally garners willingness to help or referrals to the appropriate parties.
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
- Scrum Guide
At first glance, the Scrum Guide appears straightforward, but it can be challenging to adhere to in practice. The prevalence of Scrum anti-patterns illustrates common but dysfunctional problem-solving approaches. Agile forums and articles often showcase teams struggling due to poor Scrum implementations.
Contrary to common belief, the Scrum Master isn’t the Scrum police; they more resemble a dietitian, guiding and coaching teams towards healthier practices. It’s an evidence-based approach to coaching aimed at fostering continuous improvement.
Like a dietitian, a Scrum Master doesn’t force-feed broccoli but explains its benefits over Snickers. They won’t snatch the Big Mac from your hand, but they might suggest a turkey burger aligns better with your goals. Like a dietitian, a Scrum Master influences choices through education and experimentation rather than controlling your actions.
I believe this approach mirrors what’s necessary as a Scrum Master. You can’t coerce people into following a process; you must persuade them by highlighting the benefits and helping them recognize the value.
“Those convinced against their will are of the same opinion still.”
- Dale Carnegie
When the team begins utilizing the Definition of Done to consistently deliver high-value, high-quality increments, the progress will persuade them. As they derive value from all Scrum Events without being held hostage for one hour for a fifteen-minute event, their enthusiasm for attending these events will naturally increase.
Great Scrum Masters inspire teams to adopt Scrum by demonstrating its value.
- Planning and advising Scrum implementations within the organization
- Leading, training, and coaching the organization in its Scrum adoption
- Scrum Guide
Upon reading the Scrum Guide, I believed it was my responsibility to orchestrate a top-down transformation across the entire company while simultaneously enhancing my team’s efficiency. That’s a lot of responsibility for just one person.
From my experience, the primary focus of the Scrum Master lies in enhancing their team’s efficiency. However, this often entails educating individuals on the team’s periphery, such as external collaborators or stakeholders. You’ll need to help them understand the appropriate interaction methods with an agile team.
At times, your focus might shift toward optimizing your team’s workflow. If your team receives work from an upstream team, any inefficiencies in their processes can impact your team’s flow. Thus, you may find yourself collaborating with the external team to address these issues and improve processes, thereby resolving downstream challenges that affect your team.
I’m reminded of the story of the cracked pot. In the tale, a water bearer who uses a cracked pot to carry water along a path notices that one side is barren while the other is filled with beautiful flowers. The cracked pot feels inadequate because it leaks water, but the water bearer explains that the pot’s flaw allows water to nourish the flowers on the side of the path.
While this story underscores the notion that everyone possesses distinctive strengths and weaknesses, with imperfections sometimes yielding unexpected benefits, its relevance here is slightly different.
While the pot’s primary purpose was to transport water, its leaks unexpectedly nourished unintended areas along the way. Similarly, as you strive to enhance your team’s efficiency, you may also find yourself fostering the agile mindset through teaching or practical application, thus inadvertently benefiting beyond your primary objective.
- Helping establish empirical product planning for a complex environment
- Helping employees and stakeholders understand and enact an empirical approach for complex work
- Scrum Guide
Inexperienced me once believed that fulfilling these responsibilities would naturally occur by simply adhering to Scrum’s empirical framework. However, I’ve realized that active effort and guidance are essential to address these responsibilities effectively.
In a previous role as a database analyst, I encountered a team member tasked with running a vast array of month-end reports compiled over three decades. The list had grown unwieldy, with outdated processes remaining unquestioned despite technological advancements.
People are naturally averse to change, often defaulting to the status quo with the mindset of “It’s the way we’ve always done it.” It requires significant effort to pause and question whether established practices still hold value. Individuals may continue operating on autopilot without intervention, resistant to reconsidering ingrained routines.
A team member devised a straightforward yet brilliant strategy to assess the relevance of reports. My colleague included a note with the next round of reports: “If you find value in receiving this report, please reply to this email. Otherwise, we plan to remove this task from our monthly process.”
Even this straightforward idea sparked concerns. What if people felt offended by justifying the necessity of the report? What if crucial executives were too busy to respond, leading to significant business impacts if next month’s report was omitted? What if someone missed the email due to vacation and could not confirm their need? Would we face numerous “Do you know who I am?” responses?
”[…] if we follow the example of poker players by making explicit that our decisions are bets, we can make better decisions and anticipate (and take protective measures) when irrationality is likely to keep us from acting in our best interest.”
- Annie Duke
Scrum relies heavily on empiricism, which values experience and makes decisions based on factual evidence. Essentially, it entails adopting a mindset of experimentation to gather evidence and then using that knowledge to inform future decisions.
These experiments aren’t set in stone; we reserve the right to change direction whenever we gather enough information to devise a better plan. Given our short Sprints, the impact is limited to just two weeks, even if an experiment goes awry.
Following the email experiment, we eradicated a staggering 75% of the tasks she managed with a single message.
The perpetual cycle of inspecting and adapting within Scrum fuels innovation. As Scrum Masters, guiding the transition from complacency to embracing experimentation and continuous improvement presents a significant challenge, yet it also holds immense promise.
- Helping find techniques for effective Product Goal definition and Product Backlog management
- Helping the Scrum Team understand the need for clear and concise Product Backlog items
- Scrum Guide
At the outset of my journey as a Scrum Master, I perceived these responsibilities primarily as instructing others on the intricacies of user story templates and acceptance criteria or perhaps ensuring the Product Owner’s readiness and backlog grooming for Sprint Planning.
But that’s a superficial grasp of the broader scope involved. Backlog management entails two key facets. Firstly, it’s about charting our destination (the Product Goal) and plotting the course (Product Backlog Items). Yet, there’s another layer: ensuring the team aligns and shares a common understanding of the destination and the planned journey, ensuring everyone moves forward in unison.
Each team member may engage in collaborative understanding differently. As a Scrum Master, you must assist the team in discovering techniques and communication styles that resonate, fostering alignment among them.
Do we need a roadmap? How detailed should it be? Teams vary in their needs—from detailed notes to concise summaries. Your role as a Scrum Master is to guide them to a sweet spot: enough information to avoid confusion but not so much that they’re mired in backlog refinement.
At its core, the Scrum Master accountability revolves around empowering the team to achieve effectiveness by leveraging the Scrum Framework to its fullest potential.
To enhance your skills as a Scrum Master, adopt an empirical approach. Your initial encounter with the Scrum Guide likely occurred early in your exposure to the framework, offering a limited perspective. Embrace ongoing learning and experience to broaden your understanding and refine your practice, akin to adjusting the focus of a lens for a clearer view.
After conducting experiments and gaining hands-on experience with your team, revisit the Scrum Guide to derive new insights and ideas. This iterative process of learning and experimentation will gradually refine your understanding and bring clarity, akin to achieving a 20/20 vision.
Quick Links
Legal Stuff