Scrum-but and Agile anti-patterns
There are many stories about Scrum-but, agile anti-patterns, and common agile misconceptions. If you’re wondering about the term, it comes from the idea “we’re doing Scrum, but we” [do something that is completely the opposite of what it says to do in Scrum]. Often this is because a firm doesn’t want to make changes when adopting Scrum. Problem is, those changes are usually needed to make Scrum work! Otherwise your product development might fail entirely.
While I don’t want to be the “Scrum Police” and enforce rules by the book, you do still need to watch out for these anti-patterns. Especially the ones that really derail your agile methodology journey.
The main agile anti-patterns are:
- big up-front design / big releases
- big user stories / technical user stories
- lots of signoffs and handovers
- disempowered teams
- absent Product Owner
- no WIP limit
- lots of side projects.
This article will explain all these agile anti-patterns in more detail now.
Big up-front design
Big up-front design doesn’t go well with agile
“We do scrum, but we do a big up-front design”. This one is very common, especially in organisations doing “Scrum-fall“, i.e. Waterfall but with a bunch of iterations in the Build phase. Now there is actually nothing wrong with some initial architecture, especially if done mainly in the form of exploratory coding, spikes, etc. You don’t want to lock down all your designs initially though. Break things into chunks, and design and build each chunk in order, instead of designing all the chunks first. Designs often need to change, so do them as you go.
Big releases
Are you releasing once a sprint or more? Or once a quarter?
“We do Scrum, but we release every six months”. Another common occurrence in large organisations trying to do agile practices, but doing agile development mistakes. There’s not much point doing one-week iterations if you release twice a year.
You’re supposed to have a potentially shippable product at the end of a sprint, but an emphasis on the “potential”. If you’re not doing frequent releases, you can’t do Build Measure Learn (as per Minimum Viable Product thinking), you can’t do DevOps, and you’ll be slow to respond to feedback.
Big user stories
Are you slicing your stories small enough to fit into a sprint?
“We do Scrum, but we have big user stories that cover all the use cases”. This is an easy one to avoid. User stories should be very small, ideally able to be completed in a few days, or even less
User Story Slicing can help you get stories nice and small. You can read about the SPIDR approach to story slicing here.
I once did a “carpaccio” exercise in some Agile training where we had to build software in sprints of three minutes. True story.
Technical user stories
Another common problem: teams writing technical user stories. Usually that start like “As an API, I want to…” or “as a database, I want to something.”
There’s nothing wrong with doing technical work, or even writing technical tasks. Those are fine. The problem is, they are not user stories! I wrote a whole article about this topic if you are interested.
Lots of signoffs
“We do scrum, but we have to make sure everything is signed off, so it doesn’t keep changing”. The whole concept of “sign off” is stupid, and a lingering stench of Waterfall mindsets.
Signoffs break flow and slow down development and learning. They also disempower teams and maintain existing hierarchies. A Scrum team has all the people, skills and authorities to completely develop product increments. Otherwise they are not a Scrum team!
If they need to go ask permission from some external group to get something considered “Done”, they are not empowered. And not at all a Scrum team.
The solution is simple: get the person or people who do the “signoff” and put them in the Scrum team. If they can’t or won’t do this, then you need to start telling people that Scrum is not going to work here.
Lots of handovers
“We do scrum, but we have separate teams that are specialists in their field, and they hand over work to each other”. We’re supposed to have cross-functional teams; I wrote about this topic in more detail here. Handovers in agile project management are a form of waste, introduce risks, and should be removed whenever and wherever possible.
Handoffs are usually either a sign of external “signoffs” (see above), or a sign of an “Undone work” team (a concept from Large Scale Scrum). So the team is creating product increments that kind of Done, but not really. They might need to get approved, or audited, or certified, or penetration tested, or whatever.
And the work that those external teams does then gets the Increments from “almost done” to “done”.
But again, a Scrum team by definition has everything it needs to get something to Done. So get those people, skills, tools or processes inside the team. And the handoffs disappear.
Disempowered teams
This is a sad and very common mistake in the world of agile team dynamics. Teams are supposedly set up for success as part of some agile transformation, but the team has no power at all.
The Product Owner is just a Business Analyst with a fancy title, the development team work at the whim of some Tech Lead or Team Leader, and the Scrum Master is kicked around by a project manager.
Scrum only works when teams are empowered. When they build and own their backlog, can define and prioritize their own work, and can choose when to release a product increment.
If all of that is chosen by people outside the team, you don’t have a Scrum team, you have a project team. Which is ok, but don’t go expecting amazing results.
Absent Product Owner
This is similar to the last anti-pattern, but a little different. Instead of a disempowered product owner, you have one who is never really there. They are too busy dashing between meetings with bigwig stakeholders to worry about their cute little Scrum team.
This leaves the team trying to pick up the pieces and figure out what to do. The Product Owner usually delegates some things to “proxy” business analysts. But it is usually clear that they cannot make any meaningful decisions about the product.
No WIP limit
This sounds like it has to do with Kanban or Lean. And it kind of does. But it is a common mistake made by agile and Scrum teams too.
WIP limits can help reduce chaos and improve flow
The team has way too much work happening at once, which results in nothing getting done. Developers are jumping from fire to fire, continually context switching, and have no time to build in quality or pay down technical debt.
A team with no WIP limit will struggle with long cycle times and poor responsiveness. It is usually caused by disempowered teams (see above), which have work pushed on them, rather than pull work onto themselves.
Multiple projects / “side hustles”
The team is meant to be working mainly on one product and backlog, but is actually split across multiple projects or workstreams. Some team members are working on “side hustles” or random projects that they are 17% or so allocated to.
This is a typical symptom of unfocused organizations and sloppy management. It is also way more likely to happen with disempowered teams.
One of the core values of Scrum is focus. For a reason! Teams can only achieve meaningful results if they can focus on one big problem at a time. So let them! Cut out the “I just need you 20% on this and 40% on that and 15% on those things” stuff. Form a team, give them a problem to solve, and leave them alone.
Death by micro-management
The team are continually being micro-managed. Project / program managers, tech leads and architects are continually wandering in and assigning tasks and problems to people. Snoopy stakeholders and middle managers pop their heads into the Daily Scrum / Daily Standup to demand updates and harass people for timelines and explanations.
This is just awful and can rarely be fixed, sadly. It’s probably best to cut and run at this point.
Sprint Backlog changes
Another worrying sign is a Sprint Backlog that keeps getting changed, especially by the Product Owner. The Sprint Backlog is chosen by the Developers and is supposed to be pretty static. They are supposed to update it as they work on and close off items, but not have random things thrown in it after the sprint starts.
This is usually a sign of over-active and over-involved stakeholders, or a zealous and dominating product owner. Or it could just be an organization that can’t make up its mind. And keeps chopping and changing its direction. None of these are good.
Should we worry about Scrum-but and agile anti-patterns?
I’m not saying that every team has to follow the Scrum book to the letter. I don’t think it is helpful to be a “scrum nazi”, especially with teams new to Agile. Bashing people over the head with the Scrum guide every half hour is not a good idea. But I do think teams moving from waterfall to Agile should adopt it properly first, then try and experiment with it once they’ve got the hang of it. Doing something different to the canon is good if you’ve thought of a cool experiment or are looking to implement continuous improvement; doing it because you can’t get away from your old bad habits is not so good.
Agile anti-patterns: Frequently asked questions
What are the three agile patterns?
The three main patterns of agile software development are self-organizing teams, continuous integration / continuous delivery, and incremental and iterative development.
What are the anti-patterns of agile and Scrum?
Many of the classic agile and Scrum anti-patterns are described above. Big design, big releases, disempowered teams, absent product owners, and too much WIP (work in progress) are classic examples.
What is an anti-patterns for a Scrum of Scrums?
Scrum of Scrums is a different concept in Scaled Agile frameworks such as SAFe (Scaled Agile Framework). That would be a topic for another article. But a common anti-pattern of Scrum of Scrums is a long event with people giving status updates, instead of discussing real problems and ideas on how to fix them.
This video gives you a good overview of some Scrum anti-patterns.
