Kanban as Earned Freedom: Why Most Teams Still Need Scrum

Most developers will tell you they prefer Kanban over Scrum. It feels lighter, freer, less ceremonial. But that freedom isn't free. The entry fee is team maturity.

Kanban often gets sold as “more freedom”. Fewer meetings, less process, no sprint commitments. And who doesn't like that? It sounds attractive, especially if your experience of Scrum has been slow and rigid.

The problem is that Kanban is not “Scrum without the annoying parts”. Kanban assumes you already paid the price that Scrum forces you to pay by making it explicit: discipline, visibility and alignment.

Scrum as training, not the enemy

Scrum looks heavier because it forces structure on you: fixed sprints, planning, reviews, retrospectives. It feels like bureaucracy until you realize what it is actually doing.

Done well, Scrum trains the muscles that Kanban simply assumes. You get used to making work visible, slicing scope, negotiating priorities, reflecting on how you work, not just what you ship. Over time, a good team starts to need the ceremonies less and less, not because they are lazy, but because they already think like a swarm. At that point, moving toward something closer to Kanban is natural, an organic evolution.

Scrum is not the opposite of Kanban. For many teams, Scrum is how you become ready for Kanban.

The lazy argument for Kanban

There is one line I hear all the time:

“We can't do Scrum because tasks keep getting added in the middle of the sprint, so we need Kanban.”

It might even sound reasonable. I know, because it did to me when I had much less experience, but it is usually just an admission of chaos.

Unplanned work is not a reason to move to Kanban. It is a sign that you do not control your input stream, your priorities or your stakeholders. If your product owner keeps changing priorities in the middle of every sprint, Kanban will not fix that. It will just hide the lack of planning behind a fake sense of freedom. The team feels less constrained. It might even look like everything suddenly fits perfectly in Kanban. What an incredible coincidence. But what really happened is that the product owner is no longer exposed by a structure like Scrum. In a team that is not ready for it, Kanban mostly makes it easier to keep avoiding hard decisions.

Kanban can be a great fit for genuinely interrupt-driven work, like L1 support or SRE rotations. But “we keep changing our mind” is not interrupt driven work. It is poor planning.

What a mature team actually looks like

When I say “mature team”, I do not mean senior titles or years in the industry. I mean a team that needs very little operational management and still moves in a consistent direction. Teammates know each other's strengths and weaknesses, work gets picked up, finished and improved without someone playing traffic cop all day.

One simple signal is how they handle estimation. In an immature team, story point discussions feel like philosophy. People are really arguing about what a “point” is.

In a mature team, the unit is already shared. It is more like asking a friend how far a tree is. You are both looking at the same tree. One person might say 100 meters, the other 120, but you both agree 100% on what a meter is. You are disagreeing about the distance, not redefining the whole metric system every time. I am not even touching how you should define a story point here. That alone is worth three other posts, and it always starts a fight.

That is what maturity looks like in practice: shared mental units, shared direction, and very little need for someone to orchestrate every move.

Kanban works when your team is already at that level. Same mental ruler, same direction, almost no need for someone to micromanage the basics.

Kanban as earned freedom

Kanban often gets pitched as the “freer” option. Fewer rituals, less structure, more room to breathe. That pitch skips the most important part. And, unsurprisingly, you often hear it from people who are not very senior yet, who avoid going deep on the hard parts but still recommend Kanban with full confidence.

Freedom by itself is worthless. Freedom only matters if you have the discipline and the shared criteria to use it well. Otherwise it is just a nicer word for chaos.

That is why I strongly believe Kanban should be seen as earned freedom. You pay the entry fee first. You learn to make work visible. You learn to say no. You learn to respect WIP limits. You align on what effort means. You move as a swarm instead of a collection of individuals. Once you have that, Kanban ways of working start to appear naturally. They finally make sense. Only then can you drop most of the ceremonies and still keep the benefits.

Kanban is not how you escape process. It is what you unlock when you have done the hard work.