Kanban isn't Agile. What about Scrum?

Somehow the Twitter thread about Management in Agile drifted into a bit about whether [Kk]anban¹ is Agile, is Scrum, and why.

When I say “Agile”, I usually mean something like “in accord with the values and principles of the Agile manifesto”. Many articles address that notion. Here’s an example.

Anyway, is Kanban “Agile”? In a word, no. In a few more words, while Kanban can be used in an Agile fashion, its principles are not those of the Agile Manifesto, and it can be used quite effectively in a situation where the Agile values are not in place. It’s a really good set of ideas, very compatible with Agile projects, very likely to help you improve. But it’s not “Agile”: it’s an independent set of ideas. Great ideas.

In the thread, I argued (well, said) that Scrum is Agile. But if Kanban can be used in a non-Agile mode, say a Tayloristic effort, isn’t it possible that Scrum could be used in such a non-Agile style as to be non-Agile?

Well, in the spirit of there not being an “IS / IS NOT”, I should stay away from that question. But let’s look at it this way: Is it really possible to operate according to Scrum’s rules, and still not be Agile? Maybe this needs to be a longer topic than this article, and if people write to me and I am minded to do so, I might write more about it, but here are a few ideas on how Scrum can go wrong. See also the Die in a fire series.

Misuses of Scrum

Waterfall

Waterfall is surely not Agile. Can Scrum be used on a waterfall project?

Scrum requires a potentially shippable product increment every Sprint, and Sprints are a couple of weeks long, four at the most. Waterfall produces its software at the end. Waterfall cannot deliver software every couple of weeks.

Big Long List with Deadline

What if the Product Owner has an infinite list of things to do and a fixed deadline? Isn’t that non-Agile Scrum?

Scrum requires two things that this approach does not do. First, it requires the Product Owner to be responsible for the ROI of the effort, and for setting a deadline and shipping the best possible product by then. So you can’t impose a big list and an impossible deadline if you’re playing Scrum according to the rules. Second, the Dev Team gets to decide how much work they can do in every Sprint. The Product Owner can’t command them or otherwise require them to take on more than they can do in shippable form.

So, no, you can’t do a fixed time fixed content project with Scrum by the rules.

Separate Testing Department

Here’s a mild one. Can you do Scrum if you have a separate testing department and have to pass its tests before shipping?

Well, Scrum clearly states that the Dev Team must have all skills required to produce the increment. And it clearly states that the increment must be tested and integrated. So if you have separate testing, there are few options. Either you have to get a feature from Dev through Test and back in one Sprint, or Dev has to do their own testing. It’s simply not OK to develop in one Sprint, and test in the next.

So, maybe you can have a separate testing department but it is at best problematical.

Which brings us back to Kanban. If we visualize the work in this situation, we’ll see backlog items bouncing back and forth between development and testing. This is visibly inefficient. Kanban will identify this problem, at least as well as Scrum will, and we’ll be invited to solve it somehow. We could solve it in an Agile, Scrummy fashion, by putting testing skills on the team (cross-functional, remember?), or we could solve it by coming up with some procedural rules and override Scrum’s silly idea of being done in one pass. Clearly that doesn’t apply here.

And sure enough, if we do that, we’re not consistent with Scrum, but we’re working consistently with Kanban.

Does this matter?

Does it matter whether some approach is or is not Agile? Well, you get to decide. I used to think that Agile was a thing, and that everyone should do it. I guess I kind of still do think that, for values of “Agile”. But the term is so watered down that it scarcely matters. I like clean definitions, so once in a while I choose to engage a topic like this one.

Mostly, what matters is operating your work and your life so as to maximize whatever you consider to be happiness. Scrum, Kanban, all that?

An it harm none, do as thou wilt.