The topic Kanban frequently came up during recent discussions. Often associated with the question “Do you still use Scrum, or have you already changed to Kanban?”.
That gave me the impression that many people think of Kanban as being the “successor” to Scrum. However, this statement is wrong! The contratry is true: Scrum and Kanban are both based on the same ideas. Even more: Scrum is one possible way of doing Kanban…
A detailed paper on this has recently been published by Henrik Kniberg ( see here). But don’t worry, you don’t have to read everything in detail. I’ll give you a brief summary:
If you try to categorize today’s project management methods, you can base your categorization e.g. on the number of rules and regulations these models contain, and the number of areas these models cover.
Obviously, there are two extremes:
- A model where there’s a rule for everything. Using this model, you’d never have to use your brain. Every possible decision is already contained in the model. As a result, you could call such a model as being “fully determined”.
- A model without any rules whatsoever. You could call this kind of model “fully customizable”.
Obviuosly, none of these two extremes make very much sense for actual projects. Real world models will therefore lie somewhere in between. So, let’s see how some of the more well-known models fit into this categorization:
- RUP and V-Modell XT are more to the “completely determined” end of the scale. This is because they deliver you much more than is necessary for a specific project. It is then your job to choose those artifacts you need and leave those out you don’t need. So to say, you have to “tailor” the model to fit your needs (“Extreme Tailoring”, e.g. is also what the “XT” stands for in V-Modell XT). However, there is a problem: When in doubt during tailoring, people tend to leave artifacts in they are not completely sure about (rather than cutting out one too many). These models in real life therefore tend to be heavier than necessary.
- Scrum and Kanban are more on the “fully customizable” end of the scale. As Kanban has even fewer rules than Scrum (e.g. no roles and no iterations), it will be even a little bit more to the right than Scrum. These models give you less than you need to perform a real project. You then have to add some more stuff in order to make them useable in everyday life. Scrum, e.g., does not say anything about engineering practices and therefore does not say anything about how to actually work on tasks. But when adding stuff, always keep in mind what is often called the ” lean rule #1″: Less is more!
This is how such a categorization could look like:
So, what exactly are the differences between Scrum and Kanban?
The first thing you’ll notice is that Kanban doesn’t prescribe any roles at all! This is different to Scrum where there are 3 roles (Product Owner, Scrum Master and Team). This, however, does not mean you can’t have a product owner when using Kanban. Just that it’s just not included out of the box. So, when using Kanban, part of your job is to define all roles needed to complete your project.
Kanban doesn’t include iterations either. So there is no fixed period of time at the end of which you’ll have a potentially shipable product increment. Instead, release planning in Kanban can be done in different ways:
- time-based, just like Scrum (e.g. “once every 3 weeks”), or
- feature-based (e.g. “we roll out a new version after we implemented 50 new features”)
Even mixed forms are possible: Service Packs once every x weeks. New product versions only if certain requirements have been implemented (“Minimum Marketable Features”).
This, of course, also affects planning.
In Scrum, planning is done by maintaining a prioritized list of features ( a “Product Backlog”), from which the most important items are moved over to a “Sprint Backlog” at the beginning of each iteration. The Sprint Backlog then remains unchanged until the sprint is over (and all the features in it have been implemented).
So, planning in Scrum is done in two steps:
- By prioritizing the Product Backlog (which is done continuously), and
- by selecting items from the product backlog into the sprint backlog during the Sprint Planning Meeting (once per sprint)
To visualize the current state of a sprint, you can use a “Scrum board”. It shows the sprint backlog items currently in development (one per table row), and the state of the tasks belonging to these items.
But because there are no sprints, this concept won’t work with Kanban. Instead, Kanban limits the number of consecutive items in each step of the workflow. This is done by using a “Kanban board”. It is almost exactly the same as a Scrum board, but it can have numbers written above table column. It indicates the maximum number of items that can be in this workflow state at the same time.
Unlike Scrum, changes to the “Todo” column can basically be made at any time. You might however think about introducing a new “backlog” column from which you then transfer items to “Todo”.
To make it a bit more clear, here some examples:
Figure 2 shows an Scrum Board with three steps, just like one you’d use in your project. Each requirement taken from the Sprint Backlog gets its own row. Then, it’s broken down into tasks of <= 1 day. Looking at the board, you can then see the state of progress a feature is currently in:
- If all tasks are in the rightmost column, the feature is considered done (like in row 1).
- If all tasks are in the leftmost column, work on a feature has not yet begun (here in row 4).
- In any other case, i.e. when tasks are distributed in more than one column (row 2 and 3), a feature is considered to be “work in progress”.
Figure 2 now shows a Kanban board. At first glance it looks exactily like the Scrum board from figure 1. The only difference is the number “2” written above the middle column.
This indicates the maximum number of tasks that can be in this state at any time. If this number is reached, to start a new task you first have to complete one of the current tasks. Of course, you could apply similar restrictions on all other columns as well (if it makes sense).
This is different to Scrum. In Scrum, the number of items per column is by definition unlimited. In practice, however, you’ll still have some kind of implicit restriction: As tasks are defined to be a day’s work for a single person, there shouldn’t be more items “in progress” than there are team members. Exceptions may occur, of course, but shouldn’t happen to often. If it does anyway, this mostly points to a more severe problem.
So, when will a slot for a new item become available?
In Scrum, this question is easy to answer: Tomorrow. This is, because items shall be no more than one day in size.
Kanban items, however, can be of arbitrary size. From “1 hour” to “1 month” and even more (although more than 1 month in most cases doesn’t make sense). This makes answering this question a little bit more challenging. To succeed, you have to
- estimate each item, and
- track the amount of time it has been in the current state.
Or, just like Scrum, introduce a fixed length for individual tasks.
Kanban is an empirical process, as is Scrum. I.e., Kanban allows review and adjustment of rules. For example, if the limit of 2 items in the column “In Bearbeitung” from figure 2 turns out to be too low, you can always increase it. Of course, you could also impose restrictions on the other 2 columns., if it makes sense to you.
One possible result of these modifications is shown in figure 3. The limit on column “In Bearbeitung” has been raised to 8 items. Also, there is now a new limit of 3 items on the “Todo” column. This means there must never be more than 3 items in this column at any time. Adding a fourth entry is not allowed anymore. You first have to remove one of previous ones before you can do that. Changes to the column, however, are allowed at any time (as long as you don’t exceed the limit).
This is different to Scrum, where adding items to the board is done only during sprint planning meeting by selecting items from the Product Backlog to the Sprint Backlog. After the sprint has started, “no changes” must be made to the Sprint Backlog until the sprint is over (and all items are “done”). Then, the board is reset, and sprint planning starts again.
This means a Scrum board undergoes a 3-step cycle during each sprint:
- At the beginning of a sprint, all items are in the “Todo” column.
- When in the middle of a sprint, items are distributed over all columns: Some items are already “Done”, some are “In Progress”, and some are still “Todo”.
- At the end of the sprint, all items are “done”, and a new potentially shippable product increment is created.
You can see an example of this cycle in figure 4.
A Kanban board, however, won’t show signs of such a cycle. Items will still travel from left to right across the board, but because Kanban does not include sprints, the board is not automatically “reset” after each iteration. Instead, the appearance of the board will remain more ore less the same. Just the number of items “done” will increase over time.
You can also observe that columns with limitations will typically have significantly lower fluctuation than columns without limitations. This is a result of Kanban’s continuous pull system: After one item has left the column, another one is immediately pulled in. Almost no time is spent in the itermediary state between the two transitions, therefore making the board look stable from an outside point of view.
What’s more, in Scrum, only team members are allowed to the board (whereas Product Owner and Scrum Master are not). A Scrum board therefore always reflects the work of the current (single) team.
A Kanban board instead represents a workflow. This workflow can be distributed arbitrarily to teams and individual persons. So, a given team may only be responsible for part of a workflow. The rule “one team, one board”, which is one of the basic Scrum rules, therefore does not exist in Kanban. I will talk more about this in part 2 of this article.
That’s all for now. Please come back later for part 2 of this article. Topics include (among others) the distribution of a Kanban board to teams, and how to work on more than one product at the same time.
Until then, so long…
BFI
Loading ...