I have a lot of feelings about Kanban. Mostly because I’ve had brilliant experiences with it, and I see it go wrong so often. As with anything new in software development, knowing why it was designed a certain way is essential to its successful adoption.

The main reason I see teams make the switch from Scrum to Kanban is because they think it’s more flexible, and there’s essentially no rules. While in some ways that’s true, that mindset is a common pitfall. And, of course, this misconception will often lead to the conclusion that Kanban sucks, and a frustrated team switching back to Scrum or some strange hybrid for the n-th time.

Let’s have a look:

There is no commitment in Kanban.

FALSE: while the team does not commit to a set of stories over a cycle, once a task is picked up and moving along the board, it is committed to. It cannot suddenly be taken out or abandoned for no good reason.

You can constantly change prioritization in Kanban.

FALSE: once an item is picked up, it has to move forward on the board and cannot be swapped with something deemed higher priority. However, as the team doesn’t plan for a sprint cycle, anything in the ready column or in the backlog can be moved up or down in priority. So it does give the team more flexibility in prioritization to a degree.

There are no rituals in Kanban.

TRUE: Kanban does not dictate that the team must have retro or planning sessions like Scrum does, but it also leaves teams free to have them if they so please. Many teams still prefer having a regular retrospective to reflect on their process or check in on team dynamics. And that’s totally fine!

As you can see, although there are fewer than in Scrum, ground rules definitely exist. I’d even argue that to be successful with Kanban, the few rules it has should be followed quite strictly. There are reasons these rules exist, and, just like the rules in the Scrum framework, I would not forego them unless you know why they exist and why you’re doing it.

Most of the “why” boils down to this: Kanban is designed to show you flaws in your process. The goal is to optimize your work pipeline to be as smooth as possible, always flowing. This means your main priority is to remove bottlenecks. The rules in Kanban all work towards showing you where these bottlenecks exist:

• Each column has transitioning rules dictating when a task can be moved into it.
• Every column has a WIP (work in progress) limit. The amount of tasks in a column can never exceed it.
• Tasks move column to column from left to right. They never move back.
• You can only work on one task at a time (but multiple developers working on one task is allowed).

That’s really about it. The WIP limits prevent developers from moving forward with a task if the subsequent column has already reached its limit. Not being able to move tasks around makes it so that devs are forced to clear work further along in the pipeline.

The Phoenix Project is a “Dev-Ops novel” that follows a character who’s faced with the challenge of delivering a complex project in a highly unstable environment. He meets an enigmatic mentor, who compares the software development process to a factory, with work stations and conveyor belts. If you think about it, the above rules apply to such a factory too. If one work station has reached its maximum capacity, the conveyor belt has to be stopped until the work station is cleared. There’s no use in piling more work onto the work station, because it’s not going to make the work station clear out any faster. It will only make subsequent items get stuck on the same things, and actual output will be minimal. The same applies to your software development pipeline.

Following these rules strictly may become annoying, but that’s exactly the point. Kanban is meant to feel uncomfortable sometimes. Bottlenecks become painfully obvious, and the team is motivated to resolve them. This in turn improves predictability and productivity. Before you know it, the entire process feels smooth and beautiful ✨

Take a conversation that happened today:

This seems like a fairly straightforward decision. There’s no hard rules, right? Shouldn’t be a problem to increase the WIP limit, surely? Sure, but the question is always “why?”. Is there a reason the column can’t be cleared out?

And, sure enough:

By increasing the WIP limit any time the pipeline is blocked, this problem would never have been noticed. Now, with the underlying issue revealed, the team can ask themselves how to resolve it. Maybe the technical solution should be documented somehwere? Maybe everyone should push to origin before going home?

Of course, any decision is still up to the team. Nobody’s calling the Kanban police 🚓 if you break a rule. But trust me: you’ll do yourself a massive favor if you ask yourself “why?” any time you’re tempted to break a rule. More often than not, I think you’ll find you’ll change your mind.

Do you still have hangups about your Kanban process? Let’s see if we can resolve them in the comments.