Why Kanban is better than Scrum

I think Kanban is much superior to Scrum. This position sometimes is attacked so viciously, that it’s hard to have a productive conversation about it – at least some people defending Scrum remind me of believers, who will protect their dogma at all costs. But this debate doesn’t have to be unfriendly, it’s just a rational decision that every project has to make, and my personal opinion is that Kanban beats Scrum in every respect we should care about. Which is to say, just two things: productivity and predictability. I would argue that nothing else is important, and whichever management framework gives us better productivity while providing enough predictability – wins.

Before comparing the 2 systems, let me just make it clear that it’s not only my opinion. Kanban is the framework of choice in many software projects. Here’s a great short article, here’s a longer and more detailed success story, and here’s a talk on Iterationless Kanban and Continuous Deployment that blew my mind many years ago.


What gives business a competitive advantage is ability to be nimble. Software project mutates continuously and it goes basically like this:

  1. Business stakeholders come up with an idea
  2. The team gets it done
  3. Implementation code gets pushed to production
  4. Business gathers feedback
  5. Go to 1

Clearly, in any given project, what we want our management framework to improve is the speed of 2. I would argue that Kanban ensures the lowest possible time spent in step 2, which makes it the best system. Here’s why.

In Scrum, we try to time-box work into Sprints – artificial iterations of a fixed length, normally 1 or 2 weeks. The idea is that by time-boxing we can commit to delivering certain stories. This commitment idea is an illusion, but let’s look at the cost we have to pay for time-boxing in terms of productivity loss first.

So we have a team, and developers are in the time-boxed iteration. No matter how good your estimates are, some devs will finish their tasks before the sprint is over, and some devs will fail to deliver their tasks on time. Both cases are inevitable, will happen on almost every sprint, and both have an associated cost.

For the dev who finished the work earlier, he or she will have to pull a task he never really looked into deeply enough, because the task was never assigned to him, he never really took ownership. In Kanban, as a developer, you always work on the highest-priority task in your pipeline – the one you take responsibility to estimate carefully, so you get familiarised with every task and make sure that if there are any questions you iron them out with the product owner and other team members well before it hits your “In Progress” column. By contrast, in Scrum, as a developer you inevitably end up having to start on tasks that are, firstly, not ideal for you (it’s just a random leftover task from the current iteration), and secondly, are not familiar to you. This contrast is especially stark when seen through the eyes of a developer. The lateral movement of tickets kills motivation to familiarise oneself with tasks – what’s the point figuring it out carefully, if it’s going to be taken away from you and assigned to someone else by the end of sprint? This never happens in Kanban, because your task is your task.

By the way, the very term Sprint illuminates the flawed nature of Scrum philosophy – software development should not resemble sprinting. Sprinting is high-intensity, short exertion of energy – you basically run for 50 meters and then you rest. Sprinting is only done in the context of exercise or athletic competition. I’d say hiking is a much better analogy – you have a long way to go to reach your goal, you walk for 8+ hours every day, and you have to sustain the pace and direction for months and years at a time. Sprinting won’t get you far! Another useful analogy is gardening – software development is very much like gardening, you cultivate it, it grows, it evolves into sometimes strange shapes that you have to trim, and you plant some seeds into prepared soil, and you give it your caring attention every day, and you enjoy the flowers and harvest the fruits, and protect it from the bugs. Sprinting is just the worst analogy ever. Anyway…

For the second situation, when we have tasks not finished during the sprint, there’s a managerial cost involved – those tasks have to be moved to the next sprint and possibly re-prioritized, re-estimated, and some of the previously planned work for the upcoming sprint has to be squeezed out from the sprint. Not a lot of effort, but 100% of it is waste, with no benefit to the project.

The idea that the team will commit to the tickets is also flawed. You can call it “commitment”, but it’s not really it – there are no rewards, no punishments, no dev really cares if some tasks have to be pushed to the next sprint, or some tasks have to be pulled from the next sprint, what’s the difference? The best we can ever do as a team, and what this “commitment” is in reality, is we break the work down into tickets, we try to estimate them to the best of our ability, we prioritise them – and then we can predict the future with some degree of confidence. Both Scrum and Kanban frameworks do this similarly, the practical difference is in the way those predictions are made available to the business people: Scrum can only say at the beginning of every iteration “we will deliver tickets A, B, C by date D” (D being the end of the sprint), and Kanban can provide exactly the same reporting format, but it’s more flexible: it can also give an expected date of delivery for any specific ticket on the board (and therefore, any specific story). From my experience, this is a much more useful format. All estimates are always up-to-date, every day. When things change – some task takes longer to finish, developers take unexpected days off, urgent tasks come up, – the board changes basically in real-time, so the feedback loop is as short as it can ever be. It also allows for true continuous delivery – we can push to production every day and be the most Agile possible. Anything less than this is artificial reduction of team productivity and goes against the Lean philosophy that we all know and love. Or at least we should.

There’s also, of course, a stream of high-priority tasks, usually bugs, that have to be squeezed in and fixed as high-priority items. This doesn’t disturb Kanban process one bit, Kanban is made for this: just put the ticket on the board, assign it to the best developer in the right priority, and the management effort is done. For Scrum though, this can be a source of much stress, because of the perceived danger: omg we are not going to follow through on our commitment! Management goes into fire-fighting mode, puts unnecessary pressure on the team, makes panicked decisions of all sorts and renders the whole process unfun. Happy developers are more productive, so this can be a huge productivity and motivation killer. Also, it burns you out and when the real fires come, you have no energy to fight them anymore.


It is true that Scrum process can be a little more predictable. I would argue that the degree of just how much more predictable is very low, and the impact of this small improvement in predictability is also quite small, certainly not worth the cost lost in productivity.

The reason Scrum can be more predictable is because it has the concept of “protecting the Sprint” – the idea that the team (represented by Scrum Master) should resist putting more tasks into the sprint so as to not disturb the flow of development. Team should also “under-commit and over-deliver”. So we can predict with a slightly higher degree of confidence which tasks will get done within an iteration.

It’s important to understand just where exactly this slight increase in predictability is coming from: we have to say no to unexpected high-priority tasks that come up during the sprint. This makes the business slower, less Agile, less Lean. Let me repeat this so it resonates: to “protect the Sprint” we knowingly ignore high-priority tasks in favour of lower-priority tasks. This is almost the definition of sabotage.

And how important is predictability anyway? You have to have some predictability, just to be able to plan public releases, presentations, meetings, marketing campaigns and so on. But what is more important, the ability to predict the future with slightly higher level of accuracy, or that the future is actually good? Would you rather predict with high degree of confidence that you’re going to get 30 tasks done within a week – and deliver exactly that, making your prediction 100% accurate, or would you rather predict with low degree of confidence that you will deliver 60 tasks (including the 30 from previous example, twice as much business value) and than end up delivering 75, making your prediction quite inaccurate in fact? Clearly the latter situation is preferable.


Kanban wins if you want to build software fast and be happy doing it. Scrum provides slightly better predictability at the cost of lost productivity and often times unnecessary stress.