Two Damaging Myths About Scrum and Kanban

There are two very common, very damaging, and very wrong misconceptions about Scrum compared to Kanban. I’ll bet you’ve heard them. Maybe you’ve even repeated them yourself.

Not long ago, I gave a Scrum vs. Kanban presentation at the Kansas City Developers Conference, and I discovered that nearly three-fourths of the room had heard these false beliefs in conversations about Scrum and Kanban.

I was completely and utterly…not shocked at all. I have heard them many times as I’ve talked with clients about these approaches.

Do you have some misinformation about Scrum and Kanban floating around your organization? Let’s take a look at these misconceptions.

Myth 1: Kanban is better for support, but Scrum is better for feature development

You can’t go very far in your typical “Scrum vs. Kanban” article without running into some form of this misconception, even among people who really ought to know better. The idea here is that Kanban works better for small, well-defined items while Scrum is better for the more ambiguous, experimental, and exploratory items that make up software features.

I believe this myth has sprung up because it is true that Scrum teams often struggle with how to make support items fit into a sprint.

Support items are typically unpredictable. They happen when they happen and not at predetermined intervals. They also tend to be high priority, often overriding existing priorities. You also don’t know what size they’re going to be in advance.

This can be challenging for Scrum teams to handle. How many story points does a production bug get? Can you wait until the next sprint to fix it? If not, how does that impact your sprint goal?

Support items tend to not play well in a framework where you plan in advance what you’ll be working on for the next two weeks.

Since Kanban prioritizes on an item-by-item basis in a continuous flow, it’s easy to make that production bug the very next thing the team works on without affecting the workflow. Kanban also doesn’t rely on sizing for its projections, so it doesn’t really matter if the bug takes one day or 10 to fix.

So in those ways, it may be appropriate to say that Kanban is better than Scrum at accommodating support items.

However, just because Kanban does really well with support items does not mean that it performs worse with things like user stories or features. It handles those items just as well.

Many software teams use Kanban for feature work and do not find Scrum to be better at it. In fact, if a feature development team transitions from one to the other, it’s almost always from Scrum to Kanban and very rarely in the other direction.

Myth 2: Scrum is better for teams that are new to Agile; Kanban is better for experienced teams

This is another fallacy that probably came about due to the observation that most teams move from Scrum to Kanban (if they move at all) but very few go the other direction.

When you see this happen so often, it’s easy to get the impression that beginners need to cut their teeth on Scrum until they mature, and then they’re ready for Kanban.

But the reasons teams move from Scrum to Kanban is not because they are no longer beginners; it’s because Scrum had limitations that they believed Kanban would resolve.

Most beginning agile teams start with Scrum simply because Scrum is the more popular framework and is likely the one that’s best known by an organization’s staff. If an organization is brand new in their agile journey, they’re likely to look for guidance, and that guidance is far more likely to be Scrum simply because Scrum is far more widespread.

I’ve even heard several organizations use the word “agile” instead of the word “Scrum” simply because they don’t realize there’s a distinction. Scrum is just all they know.

But the mere fact that most teams begin with Scrum doesn’t mean that Scrum is better for beginners. Most kids’ first cars are clunkers, but I doubt anyone would argue that a $200 twenty-year-old jalopy that stalls whenever you roll the window down is “better for beginners” than a current year’s model with no mechanical problems.

If there is a seed of truth to this, it’s that Kanban teams do have to come up with a lot of their own policies, whereas Scrum often tells you what to do.

Kanban teams have to decide their own roles, their own meetings (and meeting frequency), their own continuous improvement mechanism, and their own artifacts they use for moving the work forward. Scrum tells you exactly what to do in all of those areas.

So, one could say that newer teams aren’t up to the task of deciding their own policies, but I disagree. I have started many new developer teams with Kanban and they did just fine right out of the gates.

At the same time, I have also run into teams that are very uncomfortable with self-management and autonomy. They feel safer if someone is telling them exactly what to do and how to do it. So, I believe this isn’t so much an issue of beginner and advanced teams so much as it’s about the comfort level a team has with defining their own work processes (or more often, the level of autonomy an organization believes in giving their teams).

Why does It matter?

Simply this—when people are committed to overly simplistic fallacies such as these, it can cut off profitable discussion around what is truly best for a team. Instead, courses of action are practically predetermined based on information that isn’t reality.

The decision a team makes to try Scrum or Kanban or something else altogether needs to come down to important questions about the team’s characteristics, work, goals, and intentions behind the decision.

Reasonably often, I hear someone at an organization say something like, “We decided to do Scrum because we thought our teams needed to learn how to be agile before moving on to an advanced method like Kanban.” The decision is made without any regard to realities on the ground - simply a belief that is not grounded in reality.

So, as your teams think about these decisions, make sure the discussion centers around the practical realities of the team and their work and not some general platitude that may not be true.