Scrum Anti Patterns [Identify and Avoid them2024 ]
What Are Scrum Anti-Patterns?
Scrum is a project management methodology filled with scary-sounding terms: Scrum anti-patterns are a prime example. However, don’t be alarmed. Scrum anti-patterns are just bad behaviors that can hinder processes, events, individuals and teams. As you can imagine, it’s important to squash anti-patterns if you want your team to live and breathe Agile.
In the following sections, we will examine Scrum anti-patterns that can be a detriment to daily scrums, sprint planning meetings and sprint retrospectives. We’ll also cover negative behaviors that can affect multiple Scrum roles. If you’d like to learn more about Scrum events and Scrum roles, check out our what is Scrum and Scrum history guides. Now, let’s learn about Scrum anti-patterns.
Scrum anti-patterns can inject themselves into any Scrum process and role.
Sprint Planning Meeting Anti-Patterns
Sprint planning meetings are vital. Without them, the product owner can’t set goals for the next sprint or assign work from the backlog. Similarly, the development team won’t know what’s expected of them, nor will they be able to create user stories. Below, we’ll cover the sprint anti-patterns that should be avoided at all costs during this Scrum event.
Unplanned Work
Stakeholders know that a firm product owner (PO) will push back on extra work if they think it’s unnecessary. Unfortunately, this can lead to stakeholders bypassing the product owner and going straight to a developer. This needs to be nipped in the bud immediately, as unplanned work can lead to scope creep. Developers, make sure all extra work is reported to your PO.
No Objective
Scrum teams (product owner, Scrum master and development team) must set a goal for the upcoming sprint. Without a clearly defined objective, the team will not know what they’re working toward and will instead just mindlessly work on random features from the sprint backlog.
Poor Workload Planning
The product owner and development team must work together to set realistic workloads during the planning meeting. If too much or too little work is assigned by the product owner, or if the development team bites off more than it can chew, deadlines can be missed. The best pieces of Scrum software make it easy to assign and track tasks from the backlog.
Most modern project management suites, like Jira (pictured),
allow product owners to manage large sprint backlogs without fuss.
Developer Absence
Unless the organization uses a scaled Scrum method where reps from multiple development teams attend Scrum of Scrums events, every development team member must take part in the planning meeting; otherwise, the team will not be on the same page. Clear your schedules and make the effort to attend. Work will be much easier if you do.
Daily Scrum Anti-Patterns
The great thing about daily Scrum meetings is that they only last 15 minutes. However, without proper planning, daily Scrums can quickly go south. Below, we’ve listed a few of the main anti-patterns to look out for during daily Scrum meetings.
Poor Time Management
Given that daily Scrums only last 15 minutes, it’s vital that Scrum teams know that the clock is ticking. Make sure team members know they have a limited amount of time (usually 60-90 seconds) to say what they need to say. Failure to impose strict schedules can lead to daily Scrums that take longer than necessary.
Monologues
Most people like to talk; Scrum team members are no different. It’s important to ensure individuals know they have limited time to speak during the event. If team members think they have an open mic, you’ll get monologues instead of status reports.
Ask team members to stay on point, otherwise you’ll learn everything from how tasks are going, to what team members had for dinner and how their doctor’s visit went.
Whether you hold daily Scrums in person or via virtual meeting tools like Slack,
be consistent with meeting times and agendas.
Interruptions
Nothing can break the flow of a meeting or someone’s train of thought like interruptions. Make it clear that while a team member is talking, everyone is to remain quiet and not blurt out questions.
Raising a hand to answer a question or waiting until the speaker has finished is far more polite. It would be wise to ask everyone to silence their phones during the meeting, too.
Lack of Consistency
A lack of consistency regarding what time daily Scrums occur, whether they’re in-person or via virtual tools like Slack (here’s our Slack review), can interfere with daily Scrums. Ensure meetings are held in the same place, that everyone knows the agenda, and that all involved know what’s expected of them before the event starts.
Scrum Retrospective Anti-Patterns
Scrum retrospectives, which should be held at the end of every sprint, can quickly become a no-go zone if Scrum Masters allow negative behaviors to emerge. A poorly planned or disrespected retrospective meeting can hurt your team’s productivity and make team members lose trust in leadership. Below are the most common retrospective anti-patterns.
No Meeting Minutes
Many items related to the previous sprint are discussed in retros, and often, Scrum teams decide upon new best practices. However, all new ideas could be lost if notes aren’t taken during the event. Don’t hold a meeting where nobody is noting what’s discussed. Pick a person to be a note keeper and then use notes to continually improve the team and processes.
can help Scrum Masters facilitate retrospective meetings.
Au Revoir, Product Owner
Many believe that only the development team and the Scrum Master should be privy to sprint retrospective meetings. This couldn’t be further from the truth. Scrum teams win together and lose together. As such, make sure your product owner is present during retrospective events.
Time Wasting
If the retrospective meeting is considered a waste of time, morale could drop. Make the retrospectives worthwhile. Celebrate wins, accept defeats, create new best practices, ensure the Scrum team decides what team-building exercises to do and give the meeting a fun theme. Be sure to hold the meeting in a comfortable location, too.
Finger Pointing
If Scrum Masters aren’t careful, sprint retrospectives can become bashing sessions where individuals do nothing but point fingers at other team members. Don’t let this anti-pattern creep into your meeting. Remind everyone that the team must be a cohesive unit. Teams win and lose together, and individuals do not take the fall for any issues.
Scrum Master Anti-Patterns
Being a Scrum Master is not an easy job. Scrum Masters have to look for anti-patterns in other areas, manage conflict and hold many meetings. Unfortunately, their responsibilities do not make them immune to destructive behaviors. We’ll look at a few of the most common anti-patterns of Scrum Masters below.
There are plenty of Scrum certifications for anyone who wants to further their Agile career.
Substandard Support
Everyone needs support; when it’s received, trust grows and work gets done. One of the worst Scrum Master anti-patterns is not giving support. If there are tasks on the Agile board that haven’t moved in a few days and a leader doesn’t reach out to offer help, there’s a problem. Don’t let your team sit on problems. Support everyone and keep the process moving.
No Retros
If a Scrum Master doesn’t hold retrospective meetings, it means two things: They believe the team and processes are problem-free, and the Scrum Master doesn’t want to celebrate wins. Both are cause for concern. Retros are vital because celebrating successes builds morale, and solving problems can help the team learn and grow.
Avoiding Conflict
Conflict is never easy to deal with, but it comes with the territory when you’re a manager. Unfortunately, not all Scrum Masters know how to handle disagreements between team members or how to confront issues.
However, continued avoidance of rumblings will negatively impact the team, deadlines and possibly the quality of the deliverable. It’s vital that leaders have tough talks when needed.
Scrum Master Flow Disruption
Flow (workflow) disruption occurs when a Scrum Master ignores stakeholders adding unplanned work, which can change the project scope. Disruption also occurs when line managers (a team lead) adds or removes team members without authorization and alters team member tasks. Scrum Masters must watch for these issues and stop flow disruption at all costs.
When product owners deny change requests, stakeholders may sneakily approach the development team to add unplanned work, which can cause flow disruption.
Development Team Anti-Patterns
Development teams have a lot on their plate and must complete their work within the allotted time. As you can imagine, working under such stress can cause bad habits to form. Below are the unfavorable development team behaviors that product owners and Scrum Masters should look out for.
No Time For Bugs (Technical Debt)
Ideally, development teams should set aside 20% of their time each sprint to resolve issues and work on bugs. Development teams that fail to allocate this time and only focus on implementing new features may cause a backup that could delay the delivery of the next iteration. Product owners need to ensure that bugs and issues aren’t being pushed aside.
Work-In-Progress (WiP) Limits
Work-in-progress (WiP) limits determine the maximum number of tasks that a development team can work on at any given time. Failure to work within the WiP limits can cause development teams to become overworked, which can cause delays. Delays in throughput can be measured by looking at cycle times (periods between a task starting and being finished).
Granular Planning
One poor behavior that can emerge in development teams is over-planning, or being too granular. The Scrum process is flexible and welcomes changes throughout the process, so if a development team plans for every task during a sprint planning meeting, it could result in wasted time when changes occur. Teams should only plan for a quarter of the tasks upfront.
Roughly 20% of a development team’s time each sprint
should be set aside to work on issues and bugs.
Cherry Picking
Dev teams should always pick backlog items with the highest priority. However, it can be tempting for individuals to cherry-pick tasks that look more appealing or offer instant gratification.
Cherry-picking can lead to many problems, including reduced cross-functionality, decreased team morale and trust issues. Product owners must ensure that top-priority issues are resolved first.
Product Owner Anti-Patterns
The key task of the product owner (PO) is to communicate the overall goal of a sprint with the development team and manage product backlog items. Should a PO succumb to any of the Scrum anti-patterns listed below, the whole sprint could derail and the team could suffer.
Canceling Sprints Without Dialogue
The product owner can cancel a sprint if it looks like it will fail. However, the PO should always consult the Scrum team before making such a big call. Team members might devise solutions to problems that can save the sprint. Canceling a sprint without discussion shows a lack of faith in the team, goes against Scrum values and hurts collaboration efforts.
Refusing to Cancel Sprints
When a sprint looks like it will fail and no solutions appear, or if it’s no longer necessary due to changing demands, the product owner must cancel the sprint. Forcing a team to continue to work on a defunct iteration will only waste time and tie up valuable resources that could be used elsewhere.
Product owners must leave communication channels open
so that the team can decide if a sprint should be canceled.
Product Owner MIA
An absent product owner who’s not around to guide the development team can cause delays, frustrations and damaged morale. A PO that’s not around will also force the team to make decisions that may harm the outcome of the current iteration. If you’re a product owner, make sure you’re available for your team so that you can offer feedback and guidance at all times.
Sprint Stuffing
Sprint stuffing occurs when the development team finishes a sprint early. Instead of letting the development team celebrate and focus on bug fixes, training or other issues, the product owner forces the team to take on more work from the backlog. At the end of the day, meeting the sprint goal is all that’s required, and the product owner should not introduce more backlog work.
Scrum Team Anti-Patterns
No Scrum Master wants to say their Scrum team failed or that they missed deadlines. To avoid Scrum team issues, everyone must ensure that the below-listed bad behaviors don’t creep into the team. If team leaders nip the anti-patterns listed below in the bud, they’ll be the first to hear that the Scrum team welcomed the interventions. Let’s look at the most common problems.
Lack of Trust
It’s hard for any team to work if there’s a lack of trust between its members. If team members start acting unprofessionally or blaming each other for mistakes, delays will ensue, trust will be broken and communication will begin to fail. It’s imperative that these behaviors are caught quickly, or internal conflict could destroy a project, which could lead to client dissatisfaction.
It’s vital that every member of the Scrum team is on the same page every step of the way.
Broken Communication
Broken communication goes hand-in-hand with a lack of trust. One of the building blocks of Agile project management methodologies is an open dialogue between teams. If team members don’t trust each other, communication in events like sprint planning meetings, retrospectives and other Scrum events will dry up, which will lead to a serious team collaboration issue.
Overcommitment Syndrome
During sprint planning meetings, the Scrum team decides on the duration of the upcoming sprint and what work will be completed. However, it’s easy for teams to overcommit to workloads that aren’t possible to complete in the allotted time. Should this occur, individuals can become stressed, work quality can decrease and team morale can be harmed.
Hardening Sprints
A hardening sprint occurs when too many tasks during the sprint don’t meet the team’s definition of done (a predetermined level of quality) or aren’t completed at all. In other words, the team has to clean up its work by holding a dedicated hardening sprint. If hardening sprints occur often, it could be a sign that the team does not have a grasp of core Agile principles.
Stakeholder Anti-Patterns
Stakeholder anti-patterns can emerge when they want to exert dominance, don’t have faith in the team or don’t get along with the product owner. While stakeholder input is essential, it’s important that stakeholders aren’t allowed to cross the line. Be on the lookout for the following damaging stakeholder anti-patterns.
Pitching Developers
Stakeholders often go around product owners to get extra work added to a sprint by approaching the development team directly. However, what may seem like a small task to stakeholders could, in fact, be a massive job that can throw a spanner in the works. As previously mentioned, unplanned work can increase the risk of scope creep, so ensure all extra work is accounted for.
Product owners and development team members need to make sure
that stakeholders aren’t over-utilizing bug expedition lanes.
All Bugs All The Time
Many Scrum teams have an expedited lane for bugs marked on their sprint board so that they can be squashed quickly. Stakeholders know this, and in an effort to speed up work on their ideas, stakeholders could start calling every one of their tasks a bug, which could disrupt the flow of work.
Micro Managing
It’s not uncommon to have stakeholders who are technically-inclined. This is all well and good until the stakeholder(s) try to adopt a hands-on role so that they can change the direction the team is heading. This shows a huge lack of faith in the Scrum team, and micro-managing actions on the part of the stakeholder could confuse and demoralize the team. If you see this, alert your product owner.