- Introduction
- The Scrum Master According to the Scrum Guide
- Scrum Master Anti-Patterns by Scrum Events
- Food for Thought
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Scrum Master According to the Scrum Guide
Before we start dissecting probable reasons for and manifestations of Scrum Master anti-patterns, let us revisit how the Scrum Guide defines the role of the Scrum Master:1
Scrum Masters are accountable for establishing Scrum, aiding all in understanding its theory and practice.
They are responsible for the Scrum Team’s effectiveness, enabling practice improvements within the Scrum framework.
Scrum Masters act as servant leaders for the Scrum Team and the larger organization.
They serve the Scrum Team by coaching self-management and cross-functionality, focusing on high-value Increments, removing impediments, and ensuring effective Scrum events.
They aid the Product Owner through effective Product Goal definition and Product Backlog management and by promoting understanding of clear backlog items, enabling empirical planning, and facilitating stakeholder collaboration.
Serving the organization, Scrum Masters lead Scrum adoption, plan and advise on implementations, promote understanding of empirical approaches, and remove barriers between stakeholders and Scrum Teams.
The keystone of the Scrum Master role is leadership. (Too bad that it is officially no longer called “servant leadership”; I found that description to be better suited.) Unfortunately, in many cases of Scrum Master anti-patterns, it is precisely this idea that an individual does not meet.2
Possible Reasons Why Scrum Masters Leave the Path
Following are some often-observed reasons for Scrum Masters not behaving as intended:
Ignorance or laziness: Some Scrum Masters assume that one approach to Scrum fits every team. They learned Scrum in a specific context and apply that same approach in every organization in which they are active, no matter the circumstances. Why go through the hassle of teaching, coaching, and mentoring if you can shoehorn the “right way” directly into any Scrum Team?
Lack of patience: Patience is a critical resource that a successful Scrum Master needs to exhibit in abundance. But, of course, there is no fun in readdressing the same issue several times, rephrasing it probably, if the solution is obvious—from the Scrum Master’s perspective. So, why not tell the team how to do it “right” all the time and save all that effort? Too bad that Scrum cannot be pushed but needs to be pulled—that’s the essence of self-management. (You may observe a similar behavior resulting from boredom.)
Dogmatism: Some Scrum Masters believe in applying the Scrum Guide literally, which unavoidably causes friction because Scrum is a framework, not a methodology; see Figure 1.2. Nevertheless, teaching Scrum that way feels good: team members come and ask for help; now, the Scrum Master has a purpose:
When Scrum Team members follow the rules, the Scrum Master has influence or authority.
Being among the chosen few who interpret the Scrum Guide “correctly” secures status and respect among teammates and the broader organization.
The Scrum Master may easily attribute the Scrum Team’s progress or success to the Scrum Master’s teaching; now, they also have proof regarding their mastery of Scrum.
Finally, their mastery of Scrum is a convincing argument for the organization to keep the dogmatic Scrum Master on the payroll; apparently, the Scrum Teams need an interpreter of the Scrum Guide to reap the framework’s benefits.
Figure 1.2 Scrum is a practical yet imperfect tool to solve complex, adaptive problems but is not an infallible methodology.
Laissez-faire turned into indifference: Pointing the team in a direction where the team members can find a solution for an issue is good leadership. However, letting them run without guidance all the time sooner or later may turn into indifference or an I-do-not-care mentality.
The opportunist: Secretly, the Scrum Master believes that this Scrum thingy is a fad but recognizes that it offers a well-paid position: “I will weather the decline in demand for project managers by getting a Scrum Master certificate. How hard can this be—the manual is merely 13 pages?” However, this conviction will inevitably bring out the opportunist’s true colors over time.
Frustration: The Scrum Master has been working diligently for months, but the team is not responding to the effort. The level of frustration is growing; see Figure 1.3. There are many potential reasons for a failure at this level. Here are just a few:
The agile effort lacks sponsorship from the C-level of the organization.
There is a widespread belief that Agile is just the latest management fad and thus is ignorable.
The team composition may be wrong—perhaps some team members despise Scrum.
There is no psychological safety to address the team’s problems.
The company culture is antagonistic toward transparency and radical candor.
Individual team members harbor personal agendas unaligned with the team’s objective.
Figure 1.3 Scrum Masters are only human, too. Lend them your hand when things make no progress.
Ultimately, the Scrum Masters cannot solve this issue by themselves; its fixing is an effort of the whole Scrum Team.
The tactical Scrum Master: These Scrum Masters drank HR’s Kool-Aid and believe that Scrum Master is a position, not a role. Moreover, there is a career path from junior Scrum Master to VP of Agile Coaching. Consequently, they constrain their work strictly to the Scrum Team level until being promoted.
The rookie: The Scrum Master might merely be inexperienced. Given that we all need to learn new skills regularly, cut them some slack in this case, and reach out to support their learning effort. Scrum is a journey, not a destination, and no one on the team travels alone.
)
)
Anti-Patterns from Acting as an Agile (Line) Manager
Agile Management is an oxymoron: you manage systems but lead people. The primary purpose of any agile practice is to empower those closest to a problem to find a solution and to help the team to self-manage over time. Self-organizing teams need coaches, mentors, and servant leaders; they do not need directive managers. Watch out for the Scrum Master anti-patterns corresponding to this agile manager attitude.
1. Agile Manager
Observation: Your Scrum Master acts like an agile line manager, dismissing Scrum’s idea of self-managing teams of capable individuals who solve customer problems autonomously.
Background: Self-management does not mean the absence of management: Why would a Scrum Master or Scrum Team assume, for example, responsibility for payroll? Would that help with creating value for the customer? No. Being a self-managing team does not mean the absence of management per se, it simply means a different kind of management that is focused on helping people to grow their skills rather than telling people how to do their work.
There are various reasons why a Scrum Master may behave in this way; for example:
Lack of understanding: Misunderstanding the Scrum Guide can lead a Scrum Master to act as a line manager. They may not fully comprehend the principle of self-managing teams due to a lack of training, coaching, and mentoring.
Fear of loss of control: Some Scrum Masters, due to their previous roles as managers, may fear losing control and relevance. They need to learn and embrace the idea that by helping the team to self-manage, their ability to have a positive effect is multiplied, not reduced.
Organizational culture: Scrum Masters may resort to old managerial behaviors if the organization still values and rewards traditional management practices. This behavior may persist, especially if the organization hasn’t fully embraced agile principles, particularly building projects and products around motivated individuals and trusting them to do the job.
Resistance to change: Change can be uncomfortable and difficult. Some “Scrum Masters” may resist the change to a servant leadership role, as stated in the Scrum Guide, from a traditional command-and-control management style due to ingrained habits, comfort, and familiarity.
Lack of trust: A Scrum Master who doesn’t trust the team’s ability to self- manage might act as a line manager. This behavior contradicts the Scrum Guide’s vision of a Scrum Master serving the team and fostering an environment where the team can work at its highest potential.
Overemphasis on delivery: If the organization focuses overly on meeting deadlines and delivery, the Scrum Master may adopt a managerial approach to push the team, contrary to promoting sustainable development.
Insufficient support: Without enough support from upper management and other departments to foster an agile environment, a Scrum Master may revert to line management out of frustration or necessity. This scenario contradicts the Agile Manifesto’s principle of giving the team the needed environment and support.
Remedy: Some steps the organization and the teammates can take to help the Scrum Master overcome the “agile manager” behavior are, for example:
Mentorship and coaching: Pair the Scrum Master with an experienced mentor to help them learn and adopt appropriate behaviors. The mentor can give real-time feedback, helping the Scrum Master to understand when they’re slipping into a line management role.
Continuous learning and training: Promote ongoing education to ensure the Scrum Master understands the principles of the Scrum Guide and the Agile Manifesto. They need to comprehend that the role of the Scrum Master is to serve the team, not manage it. Regular refresher courses and workshops can reinforce these principles.
Encourage dialogue: Team members can initiate a conversation with the Scrum Master about their concerns, being open and respectful. It’s important to refer to the Agile Manifesto and Scrum principles when discussing how the Scrum Master’s behavior affects the team’s self-management.
Feedback: Consider implementing a 360-degree feedback system, allowing team members to provide anonymous feedback to the Scrum Master if team members feel uncomfortable addressing the issue in Retrospectives.
Performance metrics: Align Scrum Master performance metrics with agile principles. Instead of assessing based on output and meeting delivery deadlines, focus on team satisfaction, quality of work, and progress toward self-management and accomplishing the team’s Product Goal.
Patience and persistence: It takes time to unlearn ingrained behaviors and adopt new ones. Be patient with Scrum Masters who are transitioning from a traditional management role. Regularly reinforce the importance and benefits of agile practices while addressing any concerns or resistance they might have.
2. Running Scrum Events by Allowing Someone to Speak
Observation: The Scrum Master hosts all Scrum events down to the level where team members wait for permission to contribute.
Background: When team members seek approval from the Scrum Master before speaking out, the Scrum Master has already left the facilitation role in favor of the supervisor mode. While Scrum Masters support their teams by facilitating events, it does not imply that they always run the show with a domineering attitude. Their job is to help their teammates to accomplish the purpose of the respective Scrum event, not to enforce an orderly procedure from their perspective.
Remedy: There are a few things the teammates can do to encourage their Scrum Master to relinquish an overly controlling role:
Initiate open discussion: Address the issue respectfully within the team, perhaps during a Retrospective. Make the conversation about the process and roles, not the person.
Assert autonomy: Begin contributing without waiting for the Scrum Master’s prompt. Show initiative in discussing and deciding tasks, thus reinforcing the concept of a self-managing team.
Encourage peer facilitation: Suggest a rotation of the facilitator role for Scrum events to promote shared ownership and demonstrate that the Scrum Master doesn’t always have to be in control.
Educate on role: Gently remind the Scrum Master about the core aspects of their role: serving the team and the Product Owner, removing impediments, and not managing tasks or people.
Seek external guidance: If internal efforts aren’t effective, consider contacting an agile coach or experienced Scrum Master from another team for advice or mediation.
Each of these steps aligns with the values of the Agile Manifesto, encouraging individuals and interactions over processes and tools and promoting a more effective, collaborative way of working.
3. The Administrative Assistant
Observation: The Scrum Master pampers the Scrum Team to a level that keeps the team dependent on their services. For example, they might
Organize meetings,
Purchase stickies and Sharpies,
Take notes, write protocols,
Update the Product Backlog on behalf of the team (whether in a tool or not),
Organize budget for tools, education, and team activities,
Preselect applicants for open team positions, and
Channel stakeholder communication—you get the idea.
Background: Sometimes, Scrum Masters believe that being supportive of their teams requires assuming the role of the personal team assistant. That is an unfortunate misinterpretation of their role; they are supposed to help their teammates become self-managing, and everyone knows how to order or “organize” stickies and Sharpies. More critical, however, is when Scrum Masters decide to keep the team in the dark about principles and practices in order to secure their job.
What might be the motivation for such behavior? Some aspects are as follows:
Desire for power and control: The Scrum Master may relish the feeling of indispensability and control they gain by keeping the team reliant on their services, appearing more knowledgeable and indispensable.
Positioning: If they view administrative tasks as “beneath” the team members, they might attempt to create an image of themselves as self-sacrificing leaders by taking on these tasks.
Avoidance of accountability: By focusing on administrative tasks and not their actual responsibilities—such as coaching the team and the wider organization about Scrum—they might be sidestepping more challenging, accountability-laden aspects of their role.
Comfort in familiar tasks: They might find comfort in administrative tasks, especially if they previously held roles that required such tasks, giving them a sense of control and accomplishment.
Lack of confidence: They might lack confidence in the team’s ability to manage these tasks or coach and facilitate effectively, causing them to retain control over seemingly trivial matters.
Remedy: Similar to the Agile Manager anti-pattern, there are a few steps the teammates can take to help the Scrum Master overcome this behavior:
Peer feedback: Offer constructive feedback to the Scrum Master. Encourage teammates to do the same, creating a unified voice that calls attention to the issue.
Proactive participation: Don’t wait for the Scrum Master to assume tasks. Proactively take ownership of tasks such as updating the task board or organizing events, demonstrating your ability to self-manage.
Ask for coaching: Request that the Scrum Master focus more on facilitating, coaching, and mentoring than on taking over administrative tasks. Suggest working sessions to help deepen understanding of Scrum principles and practices.
Education: Share resources such as books, articles, or videos on the role of a Scrum Master, or organize team sessions with Scrum Masters from other teams where they share their success patterns.
Engage management: If the Scrum Master’s behavior persists, you may need to involve senior management or human talent department. Maintaining a productive work environment is crucial, and sometimes it requires outside intervention to resolve such issues.
The aim is not to antagonize the Scrum Master but to help them understand and fulfill their role more effectively. Always approach these steps with respect and an eye toward improving team dynamics and productivity.
4. Tracking Flawed or Useless Metrics
Observation: The Scrum Master tracks metrics that focus on output or individual performance, like the number of story points completed, personal velocity, or estimation accuracy.
Background: Generally speaking, metrics help to clarify the current situation and allow us to gain insight on change over time. Without metrics, assessing any effort or development will be open to gut feeling and bias-based interpretation.
A metric should therefore be a leading indicator for a pattern change, providing an opportunity to analyze the cause in time. The following three general rules for agile metrics have proven to be useful:
Track only those metrics that apply to the team. Ignore those that measure the individual.
Do not measure parameters because they are easy to track. (Various project management tools offer out-of-the-box reports.)
Record context as well. Data without context, for example, the number of available team members or the intensity of incidents during a Sprint, may turn out to be nothing more than noise.
While utilizing predefined reports of the team’s Product Backlog management software is probably a sign of ignorance or laziness, keeping track of individual performance metrics—such as story points per Developer per Sprint and reporting them to that person’s line manager—is a critical warning sign.
Remedy: What action may a Scrum Team take to convince the Scrum Master to switch to measuring meaningful agile team metrics?
There are a few options; for example:
Explain metrics in context: The team can educate the Scrum Master about agile values, principles, and practices and their impact on identifying agile metrics. For example, it’s essential to highlight that individual-focused metrics undermine team collaboration and often lead to poor results.
Propose relevant metrics: The team can propose tracking more relevant and beneficial metrics such as lead time, cycle time, or team health. These metrics focus more on the team’s performance and value delivery than on individual output. It is helpful if the team also explains why these metrics are more meaningful and how they improve the team’s effectiveness and efficiency.
Self-organization: As a self-managing team, members can take control of the metrics themselves. They can start tracking the proposed metrics and demonstrate their value over several Sprints. Seeing the positive results might convince the Scrum Master to change their approach.
External facilitator: If the situation does not improve, the team could suggest having an external agile coach or another experienced Scrum Master facilitate a workshop. The team and Scrum Master can openly discuss the issue and find a solution. The external facilitator may be able to provide a neutral viewpoint and effective advice.
5. Spying for Management
Observation: During the Sprint, the Scrum Master reports to the management whether the Scrum Team will meet the current forecast.
Background: I took this from a job offer I received: “You will coordinate and manage the work of other team members, ensuring that timescales are met and breaches are escalated.”
Besides completely misunderstanding the Scrum Master’s role, there are some other reasons that may motivate a Scrum Master to disregard Scrum values:
Pressure from management: The Scrum Master may be under pressure from management to provide frequent updates and assure progress. This demand could stem from a lack of understanding of Agile and Scrum principles among the leadership, particularly the emphasis on trust and empowerment over monitoring and control.
Lack of trust in team: The Scrum Master may lack trust in the team’s ability to meet their forecast and thus feels the need to keep management informed. The Scrum Master’s lack of trust may even contribute to their ineffectiveness by reducing their motivation.
Insecurity about role: The Scrum Master might feel insecure about their role and value within the organization. By reporting to the management, they may try to demonstrate their importance and control over the team’s work.
Remedy: What action should a Scrum Team take to convince the Scrum Master that this behavior is inappropriate? I would start with the first and second of these suggestions and keep the third in reserve:
Communicate openly: Team members should initiate a general conversation with the Scrum Master about their concerns, explaining how this behavior undermines trust and self-management principles. They should pursue this respectfully and constructively, using specific instances as examples, for instance, during a Retrospective. The Retrospective’s outcomes could also be shared with the broader organization, helping others understand the team’s way of working and their commitment to the Scrum values.
Self-reporting: The team can propose a self-reporting mechanism whereby they take responsibility for reporting their progress. The process may include visual radiators or dashboards that everyone, including management, can access. In addition, the team may consider publishing a newsletter to make stakeholder communication as simple as possible.
Involve a neutral party: If direct communication doesn’t yield results, involving a neutral party like an agile coach or a trusted leader in the organization could be helpful. They can facilitate a discussion and help resolve the issue.
6. Team Harmony over Conflict Resolution
Observation: The Scrum Master sweeps conflict and problems under the rug by not using Sprint Retrospectives to address them openly.
Background: There are several reasons why a Scrum Master reverts to peacekeeping; for example:
Overemphasis on positivity: The Scrum Master may erroneously believe that Retrospectives should focus only on what went well to keep the team’s morale high. However, this view neglects the equally important aspect of addressing what didn’t work and finding ways to improve, a key element of the Agile Manifesto’s emphasis on continuous improvement.
Fear of confrontation: The Scrum Master may be uncomfortable with conflict and avoid addressing it openly. This behavior often arises from a misunderstanding of the nature of conflict, viewing it as harmful rather than an opportunity for improvement and team growth.
Preservation of the status quo: The Scrum Master might be afraid of upsetting the existing emotional balance of the team, even if this equilibrium isn’t producing the best results. This idea may result from a lack of understanding of the continuous improvement principles underpinning Agile and Scrum.
Personal relationships: If the Scrum Master has close personal relationships within the team, they may fear damaging the relationship by bringing up contentious issues, directly violating the Scrum value of openness.
Misunderstanding the role: The Scrum Master may not fully understand their role and responsibility to facilitate effective Retrospectives. They may see their role as a peacekeeper rather than an improvement facilitator.
Lack of skills or training: The Scrum Master may lack the necessary skills to facilitate a Retrospective effectively, such as being able to manage conflicts, drive constructive discussions, and aid the team in deriving actionable insights. This skill gap points to a need for further professional development in these areas.
Fear of repercussions: The Scrum Master may be apprehensive about the potential fallout from exposing issues. This fear could be due to a corporate culture that penalizes mistakes rather than viewing them as learning opportunities, contradicting Agile’s principle of regular reflection for effective adjustment.
Avoidance of accountability: By not discussing issues openly, the Scrum Master may be trying to avoid assigning or taking accountability for problems, which directly conflicts with the Scrum value of commitment to achieving team goals.
Belief in privacy: The Scrum Master may believe that certain issues are private or sensitive and thus not suitable for open discussion in a Retrospective.
Remedy: So, what can we do about this anti-pattern? How can we help the Scrum Master overcome their flawed understanding of Scrum values, openness, conflict, and Retrospectives? A few things come to mind; for example:
Feedback and communication: Encourage the team to openly communicate with the Scrum Master about how their action of ignoring conflicts is affecting the team’s performance and morale. Honest feedback may serve as a wake-up call.
Coach for transparency and openness: Foster an environment where transparency, openness, and constructive feedback are encouraged and appreciated. Show the Scrum Master the value of these practices by modeling them in action.
Promote a learning culture: Cultivate a culture that views mistakes and conflicts as opportunities for learning and growth, not as failures. This approach aligns with the Scrum principle of inspecting and adapting to improve.
Address fear of conflict: If the Scrum Master avoids conflict, address this issue directly. Discuss the benefits of constructive conflict and how it leads to better solutions and stronger team cohesion.
Invite an agile coach or experienced Scrum Master: In persistent cases, it could be beneficial to invite an experienced agile coach or Scrum Master to guide your Scrum Master. They can provide an outside perspective and suggest effective ways to handle conflicts and problems.
At the same time, be also aware that self-management is a privilege earned through delivering valuable outcomes. Suppose the team fails to deliver due to internal strife and proves incapable of overcoming the situation. In that case, there may be a moment when a Scrum Team should take action against an ineffective Scrum Master, Product Owner, or any team member.
If a team can’t improve or fix itself, stakeholders may lose confidence, cancel the project, and potentially dissolve the team, emphasizing the responsibility of management to intervene when necessary.