If you work as a Scrum Master or Agile Coach, you have probably run into teams where Scrum just doesn’t take off. The various Scrum Events feel like a chore, motivation is low and people complain about Scrum.
I’ve certainly had my share of teams like this. While I’ve also been fortunate for the many excellent Scrum Teams that I’ve worked with (both employed and as a freelancer), for some teams it felt like I was “flogging a dead horse”.
It took me a while — longer than it should have — to discover that this often happens when the Scrum Framework is not a good fit for the work that a group of people does. And then it quickly becomes a burden.
When Scrum fits
The Scrum Framework is a good fit for some problems, but not for others. Especially when you’re new to Scrum and excited about the possibilities, its easy to treat it as a cure for all ails.
The Scrum Framework is purposefully designed to help teams deal with complex problems. These are challenges where no clear-cut solution exists, and where experimentation and discovery are necessary to figure out what might work. There is also a temporal element where people have to work together for weeks, months, or even years to solve the problem or set of connected problems. This could be the development of a product, a research project, a long-running marketing campaign, or something else that takes more than a few weeks and can’t be done by one person alone.
Organizations, teams, consultants, and coaches sometimes try to force Scrum onto problems it isn’t designed for. And the resulting tension is often experienced by the teams, making their “resistance” very understandable.
“Organizations, teams, consultants, and coaches sometimes try to force Scrum onto problems it isn’t designed for.”
How do you know when Scrum doesn’t fit?
I’d love to give a clear-cut guideline for when to use Scrum and when not to. But such a simple answer doesn’t exist. It depends greatly on the team, the organization, and the kind of work they do.
What I can give you are some signs to look for. Over time, I’ve applied Scrum to software engineering, product development, marketing efforts, scientific research, and organizational redesign. Even to my own marriage with Lisanne Lentink. By applying Scrum in a wide variety of domains, and making many mistakes along the way, I’ve learned to look for the following “potential bad fit indicators”:
- Teams work mostly on small improvements, bug-fixes, support issues, and configuration tasks that are collected by the Product Owner.
- Teams struggle to formulate Sprint Goals because the work on the Product Backlog is mostly unrelated. Even when you try, it is difficult to find connections, other than that they need to be done at some point in time.
- Teams work on multiple products or projects at the same time, and this makes sense in their context. For example, teams are configuring ERP-software for different clients at the same time. Or teams work for different customers because smaller teams and shorter Sprints don’t make sense.
- The Sprint Reviews are mostly a repeat of everything that the team has been working on. But there is no clear, single Increment that can be inspected because the work isn’t related.
- There are no stakeholders at the Sprint Review because you would end up with a bunch of completely unrelated stakeholders, and a shared review doesn’t make sense. Or you still do the Sprint Reviews, invite this bunch of stakeholders, and it feels very weird as they wait for “their item” to be inspected.
- Sprint Planning feels forced, as the work that needs to happen in a Sprint is highly unpredictable. A good example of this are teams that provide support for existing platforms and are highly dependant on what comes in on a given day.
- Although people are grouped into “teams”, everyone generally works on their own items. Although collaboration is nice, it isn’t necessary to get work done.
- People are part of the Scrum Team for one or two days a week. They work for other teams or projects on the remaining days.
- The timebox of the Sprint feels artificial, as the only thing coming out of the Sprint is a bunch of unrelated items.
The keyword is “Coherence”
The Scrum Framework makes sense when each Sprint can feasibly result in a coherent batch of completed work — the Increment — that can then be inspected by the team and its stakeholders. For some kinds of work, this Increment will be more tangible than others. For example, a Scrum Team that is developing a software product can present a new version that includes the work done this Sprint. An engineering team can share a new prototype that is improved based on what was learned from the previous version. The Increment may be less tangible for Scrum Teams that perform other kinds of complex work. For example, a scientific research team may use a Sprint to test one or two hypotheses and share the results in the Sprint Review. A team that uses Scrum to guide an organizational redesign process may use their Sprints to focus on a particular area of redesign (like formulating job descriptions) and share their results with relevant stakeholders at the end.
The keyword is coherence. The Scrum Framework makes sense when there is coherence in the work of a group of people or when they would benefit from more coherence. The latter part is important because even though that coherence may not be there now, that doesn’t mean it won’t be there when you try and start removing impediments.
“The Scrum Framework makes sense when there is coherence in the work of a group of people or when they would benefit from more coherence.”
Bad fit? You may need to try harder
Just as Scrum is often applied to problems that aren’t suited for it, it is often ignored for problems that are perfectly suited for it. The fact that the Scrum Framework doesn’t fit now, doesn’t mean that it shouldn’t.
“Just as Scrum is often applied to problems that aren’t suited for it, it is often ignored for problems that are perfectly suited for it.”
So perhaps you are currently working on three projects at the same time, and this seems unavoidable. Or you are part of multiple teams, and there’s little you can do about that. Or the items on the Product Backlog have no coherence, and that’s that. Although this may lead you to conclude that the Scrum Framework is not suited for you, this may be too quick.
Because there is an important trade-off between the fit and the benefits of something like the Scrum Framework. For example:
- Working on multiple projects or products at the same time inherently increases Work-in-Progress and reduces the flow of work through your team.
- Being a member of multiple teams inherently makes it hard to commit to any of the teams and to create focus. Again, Work-in-Progress will increase and flow will decrease.
- The benefits of teamwork — like being able to help each other, increased morale, and higher motivation — are very limited when everyone is working on their own items.
- When you don’t have Sprints, you lose the focus that a time-box like this gives to a team to solve a particular sub-problem of the larger problem.
- When you don’t release new Increments and don’t validate your assumptions with your stakeholders, you won’t be able to reduce the risk of getting it wrong. Even when it is hard to do this validation, can you take the (financial, PR, customer relations) hit when you’re wrong?
What’s the alternative?
When the Scrum Framework is not a good fit, what is? Honestly, this is usually the question that I ask teams. Considering the work that they do, what would be a good way to organize the work that also allows them to work empirically?
- Teams that have to work on different projects or for different customers at the same time may still benefit from elements of the Scrum Framework. Although Sprint Goals and a single Increment may not make sense considering the lack of coherence in work, they can still use the Product Backlog as a “Team Backlog” and use the Scrum Events to synchronize their work where needed. It isn’t Scrum, but it still allows them to work empirically.
- For teams that can’t feasibly forecast the work for even a single Sprint, or when the time-box of a Sprint doesn’t make sense otherwise, Kanban is often more suited. On a side note; I would recommend using Kanban with Scrum whenever you can anyways.
- Often, I’ve started without mentioning Scrum and focused on empiricism instead. So we started by creating transparency around the work in progress (the Sprint Backlog), upcoming work (the Product Backlog) and picked some moments to at least coordinate our work within the team and with stakeholders and to learn from that (e.g. the Scrum Events). For some teams, this eventually grew into Scrum. For others, it became a process of their own that was still built on empiricism (transparency, inspection, and adaptation).
My preference is to try Scrum when there is sufficient coherence between the work that people in a team do. When that coherence isn’t there, the question for the team then becomes if it would be beneficial to have more of it. If the answer to that is a clear “No”, then don’t use Scrum. If the answer is “Maybe”, then try Scrum together and see what happens. You can use Liberating Structures like What, So What, Now What, Conversation Cafe, or UX Fishbowl to answer this question together.
It’s never perfect, and that’s fine
The title of this post may suggest that Scrum either fits or it doesn’t. But it isn’t black and white. The first reason is that Scrum is a framework, not a prescriptive methodology. Scrum only tells you what to do at a minimum, but not how to do it. The “How” is so deeply contextual, that there is no single answer that works for every team. So to a large degree, it's up to teams to make Scrum fit their work and vice versa.
The second reason is that it shouldn’t be a goal to achieve a “100% fit”. The goal of Scrum is to help teams deliver more value to their stakeholders sooner through an empirical approach. It isn’t about Scrum, but about what it makes possible. If teams can make this possible through other means, or by adopting only parts of Scrum, then good for them!
Finally, even the best Scrum Teams I’ve worked with didn’t have a perfect fit. Sometimes we skipped a Sprint Retrospective. Or we postponed a Daily Scrum to fix a critical bug. Or we did a Sprint without a Sprint Goal because we just couldn’t find a clear pattern in the work that was important. And that is fine.
Closing words
In this post, I explored what happens when Scrum doesn’t fit the work. Based on my own experience, I offered some of the signs that I look for to determine if there is a “bad fit”. If that fit isn’t there now, it doesn’t automatically mean that Scrum is a bad idea though. It is up to teams to determine if the benefits of Scrum outweigh the fit and if there are ways to improve to fit.
I’m curious to hear your thoughts and personal experiences on this. How did you discover that Scrum wasn’t a good fit? What has helped you?
Check our other writing on Medium. If you like our free content, meetups, podcasts and tools, please consider supporting us. Click here for ways to do so.