Common Scrum Anti-Patterns That Could Be Holding Your Team Back

I have witnessed a variety of anti-patterns in my time as a Scrum Master, and the ones I describe here are by far the most common. They’re all examples of Scrum teams and the organisations they work for trying to do the right thing but inadvertently deviating from Scrum and limiting its effectiveness. 

“The anti-pattern is a commonly-used process, structure or pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.” - Design Patterns: Elements of Reusable Object-Oriented Software (1994)

Committing To The Sprint Backlog 

Scrum teams might set a Sprint Goal which requires the completion of every Sprint Backlog  item or they might believe that their commitment is to the Sprint Backlog itself. This renders the team inflexible and they may struggle to adapt if additional work emerges during the Sprint. They are missing the point of the Sprint Goal: it should be a single achievable outcome that guides the team on which work items they should focus on to deliver the most value.

Creating Mini-Waterfalls By Sticking To Specialities

Mini-waterfalls occur within Sprints when developers stick rigidly to their specialities and work in a linear non-collaborative way. This often manifests as sequential development and testing phases for each backlog item. Those tasked with testing come off badly in this arrangement as they wait for a handoff from development, which can put them under pressure later in the Sprint and jeopardise the Sprint Goal.

Starting Work Without Pulling It IntoThe Sprint Backlog

Team members often feel conflicted at the end of the Sprint. They want to start the next highest value item in the backlog, but it doesn’t fit into the remainder of the Sprint. They can’t split it down any further to make it fit, there’s nothing smaller of equivalent value they want to work on, and they don’t want to introduce an item that would make the Sprint look unfinished. 

What to do? They may decide to make a head-start on a backlog item without pulling it into the Sprint Backlog, which compromises visibility. It’s more important to uphold transparency than keep up appearances to make reports look better. 

Prioritising Sprint Work Over A Scrum event

Towards the end of a Sprint, some team members may begin to drop out of Daily Standups, Sprint Reviews or the Sprint Retrospective in a bid to complete their Sprint work and meet the Sprint Goal. While they have good intentions to finish the work, Scrum only works when teams inspect and adapt; if they miss opportunities to do so they introduce risks. 

Revising Estimates On Work In Progress 

Story point estimates help teams reach a quicker consensus on estimates. They also feed into velocity which helps to forecast the Sprint. Unfortunately, velocity also gets mistaken for a performance metric which leads teams to unduly concern themselves with the accuracy of their estimates, perhaps discussing and revising them multiple times during the Sprint and letting it distract them from Sprint work. There is little value in discussing story points between Sprint Planning and the retrospective – they’ve done their job once the Sprint is planned, but they can be inspected in the retrospective enabling the team to learn from them.

Cancelling The Sprint Review When Work Isn’t Ready To Demo

The Sprint Review often gets confused with a demo, which is unnecessary when the team doesn't have anything ready to present. While it’s nice to see working software at the end of the Sprint, there is still plenty for the team to discuss with stakeholders in the review, such as the challenges that were faced, learnings, feedback on the current increment and the product backlog. 

Cancelling Or Postponing Events When Some Team Members Can’t Attend

The whole Scrum team should be present for the Scrum events but holidays, appointments and sick days often make that difficult. However, the event should still go ahead with the remaining members, even if it’s shorter and requires a follow-up when absent team members return. Delaying or skipping these vital opportunities to inspect and adapt can have negative consequences as risks may go unaddressed. 

Letting Standardisation Trump Self-Organisation 

Scrum teams should self-organise and have the freedom to adapt their ways of working as often as needed. In organisations with multiple teams, there may be some degree of standardisation introduced by the tools they use or the stakeholders they work with.  

It’s common for multiple teams to use the same backlog management software and share a workflow that is configured on an organisation level. This forces all teams to agree on the same steps and statuses and restricts each team’s ability to self-organise. Management may favour a standardised approach as it helps them understand how the teams are working and makes it easier to create reports from their metrics. 

Allowing Hierarchy Within The Scrum Team 

There shouldn’t be hierarchies within a Scrum team, but many organisations struggle to grasp this concept and continue to promote more experienced team members to senior or lead roles. Experienced developers come to expect these opportunities to progress to a higher level. When lead developers have line management responsibility for others on their Scrum team, it can be a recipe for artificial harmony, hidden concerns and a reluctance to admit to mistakes or weaknesses. This lack of openness could be damaging to the Scrum Team and prevent them from building trust.

Working Overtime Regularly

Teams may work overtime when a deadline is approaching and believe they’re demonstrating agility. However, it's important to point out that agility does not promote adaptability at the expense of sustainability. Scrum teams should aim to work at a steady pace to increase predictability and help them forecast further work more accurately. When overtime becomes a habit it inflates velocity beyond what the team can typically achieve, and can subsequently set false expectations on future delivery dates. Teams can’t keep up this faster pace indefinitely and will eventually burn out, having a negative impact on future Sprints. 

Drafting In Extra Help 

There’s an old English saying: “Many hands make light work.” This is not the case when it comes to complex work. The saying “Too many cooks spoil the broth” is probably more fitting as more developers can slow a team down, especially in the short term as new members need to be brought up to speed. Larger teams also tend to be less efficient and flexible than smaller ones. When extra people are introduced on a temporary basis it can be particularly wasteful, as the team spends time training them only to see them leave and take that knowledge with them. 

Accepting Dependencies That Prevent Cross-Functionality

Sometimes organisations are structured in ways which prevent Scrum teams from becoming cross-functional. Perhaps there are separate backend and frontend teams, or maybe the team relies on separate UX or operations teams (the latter may manage deployments, etc.). In these cases, the team doesn’t have all the skills required to deliver working software and the dependencies that exist give them less control over their work.

Starting With A Sprint 0

The beauty of Scrum is that it needs very little preparation – teams can start doing proper Sprints from their inception. There’s no need for a practice or preparation Sprint. I’ve seen Sprint 0 used to spend the length of a Sprint preparing, sometimes without committing to a concrete outcome or holding regular Scrum events. The first Sprint should have a valuable outcome just like any other, and that outcome may be a prototype, a proven/disproven hypothesis or the acquisition of knowledge on something specific. It’s better for a team to start as they mean to go on and execute their first Sprint properly. 

Summary 

There are many other anti-patterns born out of misunderstandings about Scrum/Agile or intentional deviations which are believed to be harmless. The above anti-patterns are fairly general but there are many more that specifically relate to the interactions of Scrum Masters and Product Owners with their Scrum teams, that are worthy of their own articles. 

Scrum is a light framework, especially in its current incarnation (The Scrum Guide has become less prescriptive over the years, to give teams more flexibility) and all the elements serve a vital purpose in reducing risks or increasing efficiency. There are negative consequences of omitting any part of the framework, no matter how insignificant they may seem.