Scrum Anti-Patterns: Red Flags in Agile Practices

What are Scrum anti-patterns?

An anti-pattern is the opposite of a best practice; though it may look like one. Anti-patterns are processes or behaviors within the context of a sprint or Scrum team that may seem positive but actually lead to negative results.

An anti-pattern is not a mistake or an error or a lack of experience on the part of a single team member – usually, they are embedded, standard practice within the team or organization; misinterpretations of Scrum principles of transparency, inspection, and adaptation. As such, they can be difficult to spot or address; especially in teams and organizations new to Scrum. And yet, if you’re going to get the full benefit from working with Scrum, you need to identify and resolve any Scrum anti-patterns that may be present.

List of Scrum anti-patterns

Different Scrum roles, activities, and elements – the process, the sprints, the standard meetings, the team, and individual roles – carry the risk of different anti-patterns.

Sprint planning anti-patterns

Planning meetings are critical to running an efficient and productive sprint; however, the following can undermine the plan:

• Using the product backlog to ‘store’ ideas – Using the sprint backlog to keep track of ideas and potential features means the backlog is unwieldy and less easy to use.
• Unrefined product backlog – Backlog refinement is a process of, “…adding detail, estimates, and order to items in the product backlog.” (Source: Scrum.org) Unrefined backlog items result in the team working on items that aren’t ready or fully understood. However…
• Over-prepared backlog – Backlog refinement is carried out when necessary, according to priority; keeping every backlog item prepped and ready to go is a potential waste of team effort as not all items will be allocated to a sprint.
• Too much stakeholder control – The team, Scrum master, and product owner are responsible for setting the sprint goals and sprint plan; stakeholder input is important but they shouldn’t make decisions for the team.

Sprints anti-patterns

According to Scrum.org, a sprint is, “where ideas are turned into value.” A sprint is a short period (usually between one and four weeks) in which the Scrum team works on clearly identified goals to deliver a tangible result. However, Scrum anti-patterns can undermine the value that is produced.

• Extending the deadline – Having to extend the duration of the sprint to meet sprint goals is not a good sign; it probably means the sprint planning was flawed or failed to take a critical factor into account.
• Adding new tasks mid-sprint – This might sound like an opportunity (especially if the sprint is progressing quicker than expected) but it is better to finish early, review, and plan better next time.
• Relying too much on the definition of ready – The definition of ready tells the team when an item from the product backlog can be addressed in a sprint; however, too-rigid criteria can result in some items never being ‘ready’.
• Failure to cancel – If a sprint goal becomes outdated or impossible to achieve due to a change in circumstances or priorities, the sprint should be canceled (usually by the product owner).

Daily Scrums anti-patterns

The daily Scrum meetings are critical to monitoring sprint progress and ensuring the whole Scrum team is on the same page. Every 24 hours, the daily Scrum meeting ensures the team is on track; with course correction where necessary. However, the goal of this short meeting is not to review everything but to maintain transparency within the team and its work.

• The overcrowded daily Scrum – When the size of the Scrum team is too large, the daily Scrum becomes unmanageable, taking up too much valuable time.
• Daily problem-solving – The purpose of the daily Scrum is not to tackle the barriers and pitfalls the team might be encountering.
• Skipping meetings – When everything in the sprint is going ‘fine’ it’s tempting to save time and skip the daily Scrum. First, transparency is lost; second, things may not actually be ‘fine’; third, once you start skipping meetings, it can become a habit.

Sprint review anti-patterns

After each sprint, the Scrum team holds a sprint review, with the aim of comparing the sprint’s results (the product increment) with the goal the team was focused on achieving.

• Fudging the definition of done – The definition of done is basically the acceptance criteria for each product backlog item. With deadlines and other pressures, it can be tempting to equate ‘almost-done’ with ‘done’.
• Review ‘echo chamber‘ – Ideally, the sprint review is open to stakeholders or sponsors; without this kind of input, the Scrum team risks becoming insular and losing the big-picture perspective.

Sprint retrospective anti-patterns

The sprint retrospective is another kind of review; taking place after each sprint, the retrospective’s focus is on the Scrum process itself. The emergence of anti-patterns (aka failures of the process) during a retrospective meeting dedicated to process improvements is especially ironic.

• Too positive – The retrospective meeting focuses only on what has gone well; no improvements possible? Really? Conversely…
• Too negative – The meeting only covers points for improvement, failing to identify or celebrate the positives. The key is balance.
• Lack of confidentiality – Known as “someone sings” by Scrum.org, this anti-pattern involves a retrospective attendee disclosing information discussed during the meeting to external parties. For the sake of in-team trust and openness, the contents of a retrospective meeting should stay within the team.
• No action taken – Positive and constructive discussion takes place, actions for improvement are identified and agreed upon. Then, nothing happens post-meeting as the team focuses on the next sprint and its goals. This becomes a lack of accountability which undermines future retrospective meetings.

Not all anti-patterns relate to stages in the Scrum/sprint process; each Scrum role brings the risk of less-than-best practice.

Scrum master anti-patterns

The main role of the Scrum master is to use their Scrum expertise to coach, train, optimize, and facilitate the work of the Scrum team.

• The Scrum police – The Scrum master’s role is to ensure the team follows the Scrum Guide. However, taken too rigidly and the Scrum master becomes a kind of enforcer, focused on the process rather than the results.
• Acts as a manager – The Scrum master is not a team leader or project manager; such roles are rarely ‘agile’. However, given the responsibility for the team’s effectiveness, the Scrum master can fall into the management trap instead of acting more as a servant-leader to the team.

Development team anti-patterns

Take away the Scrum master and product owner and the remaining development team consists of the developers, engineers, designers, QA specialists, and so on.

• The ‘hero’ – One team member (perhaps due to having more knowledge or experience) feels obliged to do ‘too much’, to be the team’s superhero. The result? Burnout and/or tasks uncompleted which have a knock-on effect on team effectiveness.
• Ignoring technical debt – Scrum.org recommends that around 20% of resources in a sprint are allocated to fixing bugs and refactoring. Ignoring this in order to achieve ‘more’ is counter-productive in the long term.
• Over-engineering – Tempting as crossing all the ‘T’s and dotting all the ‘I’s can be, it tends to result in scope creep during the sprint and unnecessary complexity in the product increment (and ultimately, the final product).

Product owner anti-patterns

According to the Scrum Guide, the product owner is, “accountable for maximizing the value of the product resulting from the work of the Scrum Team.” Arguably, the product owner’s most important role is responsibility for the product backlog which, as we’ve seen above, has a few potential anti-patterns of its own.

• The uninvolved product owner – Sometimes the product owner doesn’t feel like part of the Scrum team (especially when they are the client representative bringing the non-technical business perspective).
• Failing to take decisions – The product owner is (within the Scrum team) responsible for decisions on the product, release date, budget, backlog items… However, some product owners prefer to defer the decision-making to stakeholders or the C-suite.

Dealing with Scrum anti-patterns

How can you avoid anti-patterns developing in your Scrum team? Scrum is a complex tool, capable of producing excellent, high-value results but, when used too rigidly or laxly, likely to fall short of what it could achieve.

Some basic working principles that help avoid the embedding of Scrum anti-patterns would be:

• Create a psychologically safe working environment – When everyone feels comfortable and confident sharing their experience or viewpoints when contributing to group discussions, you are more likely to identify any anti-patterns.
• Encourage transparent and open communication – Ensure there are opportunities to comment on how Scrum is working or being used. Sprint retrospectives are the obvious starting point.
• Establish a culture of learning – Regardless of experience and knowledge, we can all learn more. The broader the awareness of Scrum (and anti-patterns) across the team, the more likely you are to unearth poor practices.

When you do identify Scrum anti-patterns, treat them as an opportunity for improvement. Despite the list of specific anti-patterns categories in this article (and the broader dive into the topic by Scrum.org) they are not generic but highly specific in their details. A team’s anti-patterns are unique to that team and the work it is doing. Therefore the solution is likely to be unique too, and best arrived at by the team itself (with the above working principles in place, of course!)

Don’t ignore Scrum anti-patterns

All Scrum anti-patterns are – by definition – examples of Scrum misuse. They are commonly found among Scrum teams because Scrum is a tool that requires training and experience to use effectively. Anti-patterns can arise at any stage of the Scrum process, and in the carrying out of any role. Experts and newbies alike are at risk of falling into one of these ‘bad habits’. The best solution (and protection) is a greater awareness – team-wide – of the Scrum framework; and how it can be inadvertently misused.