_edited.png){kind=logo}
A person's trajectory through software development agility sometimes looks like this:
Try to scrounge up resources to learn about agile software development
Learn about Scrum
Try Scrum
Experience challenges
Get Scrum certification
Notice that challenges didn't evaporate in the presence of the certification
Research solutions
Discover that there are plenty of other agile methodologies out there
Become embroiled in a seething cauldron of claims and counter-claims as to which methods are best
Panic
This trajectory is unfortunate and often unnecessary, but when people are trying to walk this path on their own, they're at the mercy of what information they can gather and/or the perspectives of a coach they hire.
There is a reason different methods and frameworks have sprung up over the years, and that's because organizations are different and situations are different. Your teams have to come up with the best ways to work for them, and that may involve one methodology over another or some combination.
In this process, there's a bit of "wisdom" that gets floated around when advising people what road to take, and I'm running into it more and more. That bit is:
Scrum is best for product development; Kanban is best for product support.
FULL DISCLOSURE: At Integrity, we use Kanban for just about everything. Although I'm also a Certified Scrum Master, I'm biased by my own experiences on this issue, just like everyone else. Take that into account as you weigh my point of view.
The Problem
To understand why anyone would say this (and why they might not be correct), you have to understand the problem that gave rise to it in the first place.
For many organizations, Scrum is the default. In fact, when a business says that they "do agile," there's a very good chance that they're telling you that they do Scrum. I can't tell you how many prospective clients I talk to that, when I tell them we're big on agile software development, ask us things like how long our sprints are.
There's all kinds of reasons Scrum because so popular, all the way from successful marketing to the easy prescriptiveness of the system to the fact that you could originally get certified by sitting in a room for two days while someone talked about Scrum. That's not to say it's a bad system; that's not my point. My point is that it's popular and considered by many as a default.
So, hold that thought. In the popular conception, agile software development = Scrum.
When Scrum comes into contact with product support, though, there's a hitch.
Scrum limits work in progress through the use of the planned sprint. You timebox a sprint from two weeks to a month, you plan in advance the work that goes into that box, and you try your best to do that work and only that work.
That works totally fine when you're dealing with a pre-existing body of work that you need to move through - as in product development.
In product support, though, work comes in erratically. Priorities may shift at a moment's notice depending on the severity of the issue. It's very difficult to plan your work even two days in advance, much less two weeks in advance.
Kanban, by contrast, limits work in progress by dictating the number of items you can have in progress at one time. It doesn't put specific items into a timespan, it just says, "We can only be working on X amount of things at once." Whatever those things are can flow freely and be reprioritized on an item by item basis.
Some organizations have found that Kanban's method of handling work in progress fits better with their frequently changing, ad hoc work than a planned timebox fits.
Ergo, Kanban is a better fit for production support, and Scrum is a better fit for product development. Simple logic, right?
The Logic is Wrong
In my toolbox, I have a hammer and a screwdriver (and a checkbook - if I can't do it with a hammer or a screwdriver, I'm paying someone).
Both of these tools can drive nails, and both of these tools can remove nails.
Let's say that, for months, I beat nails into wood using the handle of the screwdriver, and I extracted nails by prying them out of the wood with the screwdriver's flat head.
One day, I decide to give the hammer a shot at nail removal. I use the claw of the hammer, and it pulls the nail out with ease. Upon discovering that the hammer is much better for removing nails, I declare:
Hammers are better at removing nails; screwdrivers are better at driving nails.
That's crazy, right? Anyone who heard that would say, "Well, you might try driving the nails with your hammer. You might find it's better than a screwdriver for that, too."
I'm doing (at least) two things wrong:
I'm assuming that the screwdriver is a good choice for driving nails.
I'm assuming that the fact the hammer is better at removing nails automatically means the other tool must be better in the other situation.
Just because I discover a tool is better than another tool in a particular area, that does not automatically mean that the other tool is better for something else the first tool can also do. Each tool should be evaluated in how it performs in each scenario on its own. Just because a tool is bad at a particular job does not mean it'll be great at some other particular job, and vice-versa.
In this analogy, it turns out that the hammer is superior for both jobs. Each tool has to "prove itself" in each situation.
However, with experimentation through the full range of things I needed to get done with tools, we'd find situations where the screwdriver was a much better fit for the job than the hammer. But the point is that each situation and each tool needs to be evaluated on its own.
So, Scrum or Kanban?
Both Scrum and Kanban can be used for both product development and product support. Both Scrum and Kanban can perform well in both areas, and both Scrum and Kanban can perform poorly in both areas.
Every organization is different, every team in an organization is different, and every mission for every team is different. There's no way to prescribe a single method for every organization to use for every team for every mission. That's what makes agility a collaborative journey; the teams doing the work have to figure out the best ways of getting that work done.
I'm a Kanban guy. I also borrow things from Scrum and XP. I also have advised clients to stick with Scrum because that's what was working best for them or that's what their people were the most familiar with.
There are all kinds of reasons a team might choose to use one or the other or neither or some of both. But what we don't want to do is pre-commit to the idea Scrum is better suited for one kind of software work and Kanban is better suited for a different kind.
You have to discover the best fits for your scenarios. Anything else just doesn't make sense.