A Response to ‘Scrum Is Dead. All Hail Kanban, the New King’
In the land of the blind, the one-eyed man is king
Emanuel Marques wrote an article in which he claims Kanban is superior to Scrum. After reading his article, Scrum Is Dead. All Hail Kanban, the New King, all I can conclude is that his team never really practiced Scrum in the first place.
It is easy to topple the king when it’s actually a checkers piece you’re competing with!
Let’s dissect all the misunderstandings in his article. I want to stress, I’ve switched many teams from Scrum to Kanban and there are cases where it absolutely makes sense to do so. The whole “Kanban is better than Scrum” or vice versa, debate makes no sense. I’m just not interested in it.
I’ve written about this topic before and here’s my stance on the whole Scrum vs. Kanban debate:
I do not prefer Scrum or Kanban. It does not make sense to say one is better than the other. It all depends on the context. Slippers are great in summer. Uggs are amazing in winter. Uggs still look hideous in all seasons, though☺. The same holds for Scrum and Kanban. The context and expected outcome determine which method will likely perform better.
Whether you choose Scrum or Kanban depends on the context and what you’re trying to achieve. Plus, Kanban and Scrum can be used together perfectly. Kanban complements Scrum. There’s even is a Kanban guide for Scrum Teams.
The author claims that Kanban is superior to Scrum, that Scrum isn’t agile, and that Kanban is the new king. When you use such strong words, you’d better get your facts straight! Unfortunately, the arguments in his article have nothing to do with Scrum, but rather an ill-informed, self-invented interpretation of Scrum.
That’s why I’m writing this response. I couldn’t care less if somebody uses Kanban or Scrum. Whatever floats your boat is fine by me. Just don’t use misunderstandings and misconceptions to make your point.
Let’s get started with the first argument:
After a few years, I started noticing one thing: In the last days of a sprint, everyone was rushing to deliver everything they had done in the previous two weeks to avoid carry-overs, frequently taking unnecessary risks.
There are two problems with this paragraph:
The goal is never to finish all tasks in the Sprint. The goal is to deliver a Product Increment that meets the Sprint Goal. There’s a big difference. The goal is stable, but how you achieve it is entirely flexible, as long as the Sprint Goal is not at risk. Not everything in your Sprint Backlog should relate to the Sprint Goal. If you try to finish everything in the Sprint, you either are setting Sprint Goals incorrectly, or you’re not using them. You should never allocate 100% of your capacity to the Sprint Backlog to meet the Sprint Goal, because then there’s no room for details to emerge or capacity to deal with the unexpected.
Carry-overs aren’t a problem, as long as they don’t put the Sprint Goal at risk. Being bothered by carry-overs is a mindset problem, outside of Scrum’s influence. Nowhere in Scrum does it say you should finish all items that are present in the Sprint Backlog. There is only one thing the team commits to every Sprint: building a product increment that meets the Sprint Goal. If there are Sprint Backlog items that do not relate to the Sprint Goal, you don’t need to finish them.
If you want to read more about Sprint Goals and how important they are to Scrum, I can recommend Sprint Goals Are The Beating Heart of Scrum.
The next argument is that, according to Scrum, carry-overs are bad:
Why? Couldn’t some tasks wait for next week? Was the delivery of every task before the weekend that critical? No, it wasn’t. We did it because “Carry-overs are bad.”
Those tasks can wait until next week. It’s not a problem unless they’re necessary to meet the Sprint Goal. Please point out the exact paragraph in the scrum guide where it says carry-overs are bad. It’s not in there — it’s something that was made up by the team. I’ve already written about why carry-overs are good when you use Scrum.
Next, the author claims that Scrum is not Agile and that when you need to deal with the unexpected your Sprint will fail:
If you needed to do unexpected work (bugs, problems in production, etc.), it would affect your time and consequently make you fail the commitment you made in the planning meeting.
If you commit to the Sprint Backlog and plan at 100% capacity, you’re setting yourself up for failure. It is inevitable then that you won’t be able to deal with the unexpected. But why would you do that? That’s a choice your team makes.
Planning at 100% capacity is the same as consciously exceeding the Work In Progress (WIP) limit you’ve agreed upon together. With a too-high WIP limit, you’re creating your own problem: a giant traffic jam of backlog items. Just as you shouldn’t exceed the WIP limit when you use Kanban, committing to the Sprint Backlog is not how you should do Scrum.
The flexibility and emergence of the Sprint Backlog is clearly stated in the Scrum Guide:
The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
A flexible Sprint Backlog is necessary to do Scrum, otherwise, you can’t include what you’ve learned to better achieve the Sprint Goal. The whole point of the Empirical core of scrum is to inspect and adapt during the Sprint. You must adjust the Sprint Backlog during the Sprint. Doing it after the Sprint is too late. When you fill your Sprint to the brim, there is no room for empiricism and it’s inevitable that you will run into problems — surprise, surprise: the Sprint will fail.
In the article, the author states that the most common metric to evaluate success is commitment vs. done. Here’s the relevant snippet:
The most used metric to evaluate success is commitment vs. done, which compares the stories that you committed at the beginning of the sprint and what stories you accomplished (I won’t even bother to mention what problems this can bring).
Only companies that don’t use Sprint Goals would care about this metric. Nowhere in the Scrum Guide does it say you should use this metric, or even that you should use stories. Your company decided to use this metric and even though you were aware it was a poor metric, you kept on using it — why?
Here’s what you should be doing instead:
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month.
— Scrum Guide, Nov 2017
The team only commits to the Sprint Goal. There’s no commitment to individual Sprint Backlog items. Therefore, commitment vs. done stops being relevant. Instead the main question becomes: Did we meet the Sprint Goal? And if we can achieve the Sprint Goal by completing fewer Sprint Backlog items, even better!
Scrum is a process framework. The point is that you figure out your own better way of working, including your metrics of choice. Your team did not do this. In fact you kept clinging to something that did not work. I believe it says more about your team, the company, and the organizational culture, than it does about Scrum.
The author then uses a table from Cuelogic to show the differences between Scrum and Kanban. The table is full of mistakes, showing a poor understanding of both Scrum and Kanban.
Mistakes in this table for Scrum:
The team does not commit to a specific amount of work, they commit to the Sprint Goal. The Sprint Goal may require less or more work than initially planned. The scope of the Sprint is flexible and negotiable, as long as the Sprint Goal can still be met, so the amount of work will also vary depending on what is discussed and decided.
Velocity isn’t the default metric, it’s not even part of Scrum. Velocity is an optional, complementary practice.
Using a burn-down chart is not prescribed. in fact, it’s not even mentioned in the Scrum Guide. Maybe this table is using an ancient version of the Scrum Guide as its source of truth? Burn-down charts were last present in the 2010 version of the Scrum Guide.
You can add, change, remove items to an ongoing iteration, as long as it does not endanger Sprint Goal.
Mistakes in this table for Kanban:
WIP does not have to be limited per workflow state, you can also limit it only for the overall system.
Lead time isn’t the default metric for planning and process improvement. For planning, you definitely need the overall work-in-progress and throughput as well, so you can use Little’s law to forecast when work will be completed.
For process improvement, cycle time, time spent in each status, resource efficiency, and flow efficiency are important.
As a general remark — this table just contains a minimalist version of Kanban. There’s far more to it that isn’t even mentioned — process policies, classes of service, managing flow, and so on. Scrum is being compared to a bare-bones version of Kanban.
Then the author goes on to claim that Scrum uses these metrics:
Commitment vs. Done: the percentage of stories that were committed and delivered
Velocity: the number of story points delivered each sprint
Burndown chart: a graph that shows the evolution of the stories of a given sprint
Absolutely false! All these metrics are completely optional when you do Scrum. None of these metrics are present in the Scrum Guide. All you’re showing is that the metrics that your team decided to use, don’t work. On top of that, I know I’m repeating myself here, you don’t even have to use stories.
Start Doing Scrum, Before You Claim it Doesn’t Work
If you don’t know how to do Scrum, then it’s no surprise that it doesn’t work for you. If you’re unfamiliar with Scrum, however, it makes no sense to preach that Kanban is better.
I’ve tried to show how all arguments the author has presented have nothing to do with Scrum. All arguments put forward are the result of a subjective interpretation of Scrum — a mixture of elements conflicting with the Scrum Guide or not even present in the Scrum Guide.
The Scrum team of the author invented their own version of Scrum prison. Limited by these imaginary and self-constructed walls, he then claims Scrum limits you and isn’t Agile. If you decide to cut your finger with a self-constructed shiv in your imaginary Scrum prison, you can’t blame the knife for causing your finger to bleed!
Kanban is better than what you were doing before. But what you were doing before was, at best, something Scrum-like. You just wrote an article chronicling the poor decisions your team made when trying to apply Scrum in the context of your organisation and culture. You could have just as well decided to work a different way while using Scrum, but you didn’t. That’s on you, and not on Scrum.
If you ever want to give Scrum another try, drop me a line and I’ll help you to get started properly.