- 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
Scrum Master Anti-Patterns by Scrum Events
The Sprint Planning
The anti-patterns in this section focus on the Sprint Planning.
7. No Slack Time
Observation: The Developers regularly bow to the hard-pushing Product Owner: “Last Sprint, you delivered twenty-five story points, and now you are choosing only seventeen?” Consequently, they accept more issues into the Sprint Backlog than they can stomach without the Scrum Master’s intervention.
See Chapter 3, anti-pattern 8, for a detailed description.
8. Unrefined Work Items
Observation: The Scrum Master does not address accepting “unrefined” Product Backlog issues into the Sprint Backlog during Sprint Planning. (This observation refers to regular work, not emergencies or last-minute changes of high importance.)
Background: The Scrum Master’s choice increases the risk that the Developers will probably not accomplish the Sprint Goal, rendering a core Scrum principle useless: reliably providing valuable, potentially shippable Increments every single Sprint.
What reasons may a Scrum Master have to ignore the issue? Some things come to mind:
Overreliance on team autonomy: The Scrum Master may think it is the Developers’ sole responsibility to identify the Product Backlog items for the Sprint Backlog without interference.
Complacency with current practices: The Scrum Master might be complacent with the current practices, especially if the team has delivered despite the absence of refined Product Backlog items. However, this practice goes against the Agile Manifesto’s principle of continuous attention to technical excellence and good design.
Perceived lack of time: The Scrum Master may believe there isn’t enough time for thorough refinement, not objecting to the Developers’ pushing ahead with unrefined Product Backlog items.
Lack of experience: A Scrum Master new to the role may not fully understand the implications of accepting unrefined Product Backlog items into the Sprint Backlog, underestimating the associated risk.
Avoidance of conflict: The Scrum Master might avoid conflict within the team or with stakeholders by not insisting on refinement. They may perceive that challenging the Developers’ decision may lead to disagreements.
Remedy: The inherent risk that repeating an exception turns it into the new normal is obvious. So, how can we counter this anti-pattern of not addressing the increased risk of accepting unrefined Product Backlog items into the Sprint?
Some suggestions are as follows:
Promote the benefits of refinement: The Scrum Team can work together to emphasize the value of Product Backlog refinement. Highlighting its role in reducing uncertainties, managing risks, and enabling more accurate estimations may help the Scrum Master understand its importance.
Establish refinement practices: As a Scrum Team, schedule regular Product Backlog refinement sessions to ensure this activity becomes a part of the team’s routine. The Scrum Master can facilitate these sessions until the team can handle them autonomously.
Foster transparency: Continually reinforce the Scrum value of transparency. Show how it’s essential for every team member to understand what the team will work on and the potential risks associated with unrefined Product Backlog items.
Promote shared understanding: Ensure that everyone on the Scrum Team has a shared understanding of each Product Backlog item before it’s pulled into a Sprint. The Scrum Team can support the creation of a shared understanding by having discussions, asking questions, and seeking clarifications during Sprint Planning and Product Backlog refinement sessions.
Feedback and inspection: Encourage regular inspection of the process and feedback. If the team experiences negative consequences from working on unrefined Product Backlog items, use this opportunity to discuss the issue and brainstorm solutions.
Encourage stakeholder education: If external pressure is an issue, consider sessions where the Scrum Team educates stakeholders about the principles of Scrum and the importance of Product Backlog refinement. Make it clear that pushing unrefined items into the Sprint can hurt the quality of the product, the predictability of the team’s work, and can hinder accomplishing the Sprint Goal in general.
Consider a Definition of Ready: Finally, the team could agree on a Definition of Ready, specifying the conditions a Product Backlog item must meet before Developers can select it during Sprint Planning. (However, beware of turning such a practice into a dogmatically applied approval gate.) Learn more about the Definition of Ready in Chapter 15, anti-pattern 3.
9. No Improvements
Observation: While the Scrum Team agrees on improvement items during Retrospectives, they never consider them during Sprint Planning.
See Chapter 6, anti-pattern 16, for a detailed description of this anti-pattern.
The Sprint
The following anti-patterns focus on the mishandling of the Sprint itself.
10. Flow Disruption
Observation: The Scrum Master is unable to prevent stakeholders from disrupting the workflow of the Scrum Team during the Sprint.
Background: There are many manifestations of how stakeholders can interrupt the Scrum Team’s flow during a Sprint, impeding the team’s productivity and endangering accomplishment of the Sprint Goal. Some classic examples follow:
Misusing Scrum events: Stakeholders or managers turn the Daily Scrum into a reporting session.
Disrupting Developers: Stakeholders constantly address Developers directly during the Sprint, ignoring that interruptions harm the Scrum Team’s effectiveness.
Team membership disruption: Line managers take team members off the Scrum Team, assigning them to other tasks, or add members to the Scrum Team without prior consultation of the team members.
The last example is particularly challenging, as creating a Scrum Team is expensive due to the inevitable drop in productivity during the norming and storming phases of the team-building phase. Hence, changing their composition is a critical decision that shall include the team members. Scrum Teams are not talent pools in disguise at the disposal of line managers.
Remedy: Scrum Masters should not restrict stakeholders’ access to team members, but they should educate stakeholders on how to best communicate with the Scrum Team to foster an effective relationship. Some suggestions on how to proceed are as follows:
Set boundaries: Establish clear guidelines about when and how stakeholders can interact with the Scrum Team, aligning with the Scrum Guide’s assertion of minimizing disruptions.3
Educate stakeholders: Educate stakeholders on the impact of disruptions on the Scrum Team’s productivity and how they jeopardize the Sprint Goal.
Assert team autonomy: Uphold the principle that Scrum Teams manage their composition and workflow, underscoring their right to self-organize. (Advocating for this principle proves challenging in many organizations.)
Preserve Scrum events: Protect the integrity of Scrum events, emphasizing their importance in supporting team coordination and communication, not for reporting purposes.
Strengthen Product Owners: Emphasize the Product Owner’s role as the first line of communication between stakeholders and the Scrum Team to maintain focus.
11. Defining Technical Solutions
Observation: An engineer turned Scrum Master is now “suggesting” how the Developers implement issues. Alternatively, the Product Owner or an outsider, such as a technical lead, is pursuing the same approach.
Background: Why might a Scrum Master overstep the boundaries of their role and get involved in implementation questions when the Scrum Guide clearly states that any decision on how to turn a Product Backlog item into a done Increment is solely the decision of the Developers? Some reasons may include:
Old habits: The Scrum Master, an engineer in the past, may naturally gravitate toward providing solutions based on their technical experience. They may inadvertently revert to their old role out of habit or believe they are genuinely helping the Developers.
Underestimation of team skills: The Scrum Master may underestimate the Developers’ capabilities, believing that the team needs their guidance in technical matters. This perception could stem from a lack of trust or unfamiliarity with the team’s skills and competencies.
Pressures and self-preservation: If management or stakeholders pressure the Scrum Master to deliver specific results, they might feel compelled to interfere in the Developers’ work. They could think their role is on the line if the team doesn’t meet these expectations.
Control issues: The Scrum Master, because of personal insecurities or a perceived lack of progress, may feel the need to control the process. They may believe they can speed up the process by directing the work rather than allowing the Developers to self-manage.
Inadequate transition: Transitioning from a technical role to a Scrum Master is a significant shift. It requires a change in mindset from being a doer to becoming an enabler. If this transition is not adequately supported or understood, the Scrum Master might fall back into the comfort zone of their previous role.
Fear of obsolescence: The Scrum Master may worry that by not involving themselves in the technical decisions, they will become disconnected from the actual work, which could make them feel less valuable or even obsolete.
Remedy: So, what can we do about this Scrum Master anti-pattern? How can we convince the Scrum Master to let go of their former self as a Developer and doer and embrace the role of an enabler? Consider the following:
Open dialogue: Have a frank conversation, perhaps during a Retrospective, about the Scrum Master’s role. Highlight the principles of the Agile Manifesto and the Scrum Guide, emphasizing that the Scrum Master’s role is to facilitate, not dictate, the implementation. Discuss the benefits of self-organizing teams and how they improve team productivity and creativity.
Training and education: Encourage the Scrum Master to attend further training or workshops to better understand the nuances of their role. It’s beneficial to learn from the experiences of other Scrum Masters who have transitioned from technical positions.
Peer feedback: Encourage the Developers to provide feedback whenever they feel the Scrum Master is overstepping their boundaries. They should give this feedback constructively, emphasizing how such behavior affects the team’s productivity and autonomy.
Role modeling: Share examples of successful Scrum Masters who have effectively transitioned from a technical role, showing the Scrum Master that stepping back from implementation does not diminish their value, reputation, or standing.
Mentoring or coaching: A more experienced Scrum Master or agile coach can guide the transitioning Scrum Master, providing them with strategies to combat the urge to delve into technical details.
Self-reflection: Encourage the Scrum Master to practice self-reflection. It might be helpful for them to question why they need to involve themselves in the implementation and how they can work toward overcoming this inclination.
The Daily Scrum
12. Not Supporting Struggling Developers
Observation: A Developer experiences difficulties accomplishing an issue over several consecutive days, and nobody on the Scrum Team offers help. Moreover, the Scrum Master fails to facilitate the necessary discussion.
Background: There may be many reasons for a Developer’s struggle. Here are just a few:
Task complexity: The task may be more complex or challenging than initially anticipated, for example, due to technical debt.
Lack of experience or skills: The Developer might not have the necessary skills or experience to complete the task.
Health or personal issues: Personal or health issues may impact the Developer’s performance.
Fear of criticism or failure: The Developer might be reluctant to admit difficulties due to fear of judgment or criticism.
Lack of team collaboration: The Developer workload has reached such an unproductive level that they no longer can support each other.
The worrying issue is less the struggle than the lack of support by the teammates and, more important, the Scrum Master.
Remedy: There are many ways to address the preceding issues, from improving craftsmanship to employing an effective Definition of Done to regular skill-sharing sessions to creating a safe space where no one is judged but is supported.
However, regarding the failure of the Scrum Master to detect the necessity to support a team member, I suggest using a simple visualization technique from Kanban: the “work item age.” It is about tracking and displaying the time a Product Backlog item has spent in a specific state, such as “in development.” This time is often represented visually on the Kanban board, for example, by adding a marker for each day the item did not move. Once an item accumulates a predefined number of markers, the team offers support.4
It is helpful to agree on this practice as a part of the team working agreement to create a shared understanding among all team members that they need to support each other.
13. Not Preventing Stakeholders from Attendance
Observation: Although the Developers decided to limit attendance to the Daily Scrum to the Scrum Team members, stakeholders show up uninvited, and the Scrum Master fails to address the issue.
Background: It is the Developers’ prerogative to decide how to run the Daily Scrum. If they choose to keep stakeholders away from it, this decision needs to be respected by everyone else.
Following are possible reasons that Scrum Masters fail to address the inappropriate behavior of the stakeholders attending the Daily Scrum uninvited:
Inadequate support from the organization: Without enough backing from the organization, the Scrum Master might find it challenging to address the issue, particularly in organizations that consider their role to be team-focused.
Conflict avoidance: They may want to avoid conflicts or uncomfortable stakeholder conversations.
Lack of confidence: The Scrum Master may hesitate to confront stakeholders higher up in the organization. (Ask yourself: Would you show Elon Musk the door?)
Ineffective communication skills: The Scrum Master may lack the communication skills necessary to deal with high-level stakeholders.
Stakeholder pressure: There could be high pressure from stakeholders on the team to perform better, making it difficult for the Scrum Master to intervene.
Fear of repercussions: The Scrum Master might fear negative repercussions, like job loss or other political consequences within the organization.
Remedy: There are several ways a Scrum Master can educate stakeholders who show up uninvited to the Daily Scrum and explain that they need to stop this behavior unless the Developers invite them:
Set clear boundaries: Communicate the rules and expectations for the Daily Scrum, emphasizing that it is an event for and by the Developers and the need to respect their autonomy.
Provide education: Teach stakeholders about the purpose and structure of the Daily Scrum, explaining why their presence could disrupt the event.
Stakeholder meetings: If necessary, arrange separate meetings for stakeholders to voice their concerns and queries, ensuring they feel heard without interrupting the Daily Scrum.
Use visual aids: Use signs or visual cues indicating that the Daily Scrum is in session and interruptions are not welcome unless invited. (An “On Air” sign works for Scrum Teams, too.)
Encourage self-management: Foster the Developer’s self-esteem, enabling them to address the issue directly with the stakeholders.
Involve management: If necessary, involve higher management to support Scrum’s rules and the Scrum Master’s efforts.
The Retrospective
The final set of Scrum Master anti-patterns addresses the Sprint Retrospective.
14. Groundhog Day
Observation: The Sprint Retrospective never changes in composition, venue, or length.
Background: In this case, the Scrum Team tends to revisit the same issues repeatedly—it’s Groundhog Day without the happy ending. It has become a boring exercise, a ritualized formality—what was good during the last Sprint, what was bad, let’s have some action items—that proves of little and, in time, diminishing value to the Scrum Team.
Remedy: Try to vary the format of the Retrospective; for example:
Go meta and have a Retrospective on your Retrospective.
Have a themed Retrospective.5
Change the venue or the time.
Disguise the Retrospective as a team breakfast.
There are so many things a Scrum Master can do to make Retrospectives great again and reduce the absence rate. Be creative with every single Retrospective and aim not to repeat a single format or theme. Liberating Structures and many other websites dedicated to organizing Retrospectives make this an affordable and worthwhile investment.
15. Let’s Have the Retro Next Sprint
Observation: The Scrum Team postpones the Retrospective to the next Sprint.
See Chapter 9, anti-pattern 4, for a detailed description.
16. #NoRetro
Observation: There is no Retrospective, as the team believes there is nothing to improve, and the Scrum Master accepts this notion.
See Chapter 9, anti-pattern 1, for a detailed description.
17. #NoDocumentation
Observation: No one is taking minutes for later use.
See Chapter 9, anti-pattern 10, for a detailed description.
18. The Blame Game
Observation: The Retrospective is an endless cycle of blame and finger-pointing.
See Chapter 9, anti-pattern 14, for a detailed description.
19. No Psychological Safety
Observation: One or two team members dominate the Retrospective.
Background: This communication behavior is often a sign of a compromised environment that is no longer psychologically safe.
Retrospectives support a Scrum Team’s path to excellence only when everyone can address issues and provide their feedback free from third-party influence. If some team members dominate the conversation and perhaps even bully or intimidate other teammates, the Retrospective will fail to provide such a safe place. This failure will result in participants dropping out of the Retrospective, rendering the results less valuable.
Remedy: It is the primary responsibility of the Scrum Master, in their role as a chief facilitator,6 to ensure that everyone is heard and has an opportunity to voice their thoughts.
By the way, equally distributed speaking time is, according to Google, also a sign of a high-performing team. Learn more: What Google Learned from Its Quest to Build the Perfect Team.7
If a Scrum Master needs to restore psychological safety, several angles may prove successful:
Set clear expectations for Retrospectives by pointing to Scrum Values, emphasizing the importance of respectful communication, active listening, and equal participation. Encourage the team to hold each other accountable to these rules.
Seek to speak with the dominant individuals privately, addressing their behavior and its impact on the team. Help them understand the importance of psychological safety, and request their support in creating a more inclusive environment.
During Retrospectives, watch the dynamics and intervene when necessary to maintain a balanced and inclusive discussion. Redirect the conversation if it becomes unproductive or if specific individuals start to dominate or bully others.
Utilize structured discussion formats, such as round robin or Conversation Café, where each team member takes turns sharing their thoughts. These practices can help ensure that everyone has an opportunity to speak and that the conversation remains balanced.
Actively involve introverted or less vocal team members by asking for their opinions, prompting them to share their thoughts, and acknowledging their contributions. Offer support and reassurance when necessary. However, please note that not all of your less vocal teammates may feel comfortable with this approach.
Offer different ways for team members to share their thoughts and feedback, such as written input or anonymous submissions and surveys. Anonymity encourages everyone to share their perspectives, even if they are uncomfortable speaking up during the Retrospective.
Inspect the effectiveness of Retrospectives and adapt as needed. Gather feedback from the team on how the Retrospectives work, and implement changes to improve psychological safety.
(See also the Remedy section of anti-pattern 14, The Blame Game, in Chapter 9.)
20. Excluding Stakeholders All the Time
Observation: The Scrum Team categorically rejects having Retrospectives with their stakeholders.
See Chapter 9, anti-pattern 5, for a detailed description.