Why Kanban works better than Scrum (at least for us) | kooaba blog


In an earlier blogpost we summarized how we do Scrum at kooaba. And this is exactly how we worked until recently. However, in October 2010 we decided to try something new: Kanban.

The word Kanban is Japanese and stands for „card“ or “signboard”. The term is mostly known in the world of Lean Manufacturing, a school or process developed for manufacturing at Toyota. In that context the term is mostly used for Kanban cards – little cards used for synchronizing process stages in Just in Time (or Lean) manufacturing processes.

Recently, the term has also been used to label a technique applied mostly in software project management. In this context the name Kanban stands for the whole process instead of “just” the cards. But it is a clear reference to the source of the concept and thus, in a way, pays tribute to the inventors of the concept.

To further elaborate on this, we first have to understand the motivation behind the lean manufacturing concept at Toyota. Traditional manufacturing used to be organized around large batches of work. That is, one processing step produces a part of a product, this batch of parts is stored in an intermediate inventory, before the next step takes the pieces from inventory and starts the next processing step. This is illustrated in the figure below.

Batch manufacturing. (Source: J. Liker "The Toyota Way"

There are several problems with this approach:

  • First, the time it takes until the first finished product leaves the pipe is long.
  • Second, if there are defects created in one step, it will be noticed often late. This is since the defect parts are stuck in inventory for a while, before the next step starts processing and discovers the defect (hopefully).
  • Third, huge piles of inventory are created. Inventory costs. The key insight is, that in fact inventory is a liability, and not an asset.

What Toyota did, was to work towards a process, where no inventory is created between steps (or only very small batches). The ultimate goal is called „one-piece-flow“, where literally just one single piece passes through the complete pipeline. This is illustrated in the next figure.

One-piece flow in lean manufacturing (Source: J. Liker "The Toyota Way")

Of course, the challenge now is to synchronize all the steps in the pipeline. (This is where the Kanban cards come into play). The result of the lean approach is reduced inventory, which has drastic effects on performance and quality of the factory.  So, the key thing, that lean manufacturing does, is removing or limiting inventory.

Overall, the goal of a lean process is to eliminate all waste (Jap. “Muda”) in the process. I.e. anything that doesn’t deliver value is to be removed. Ad inventory turns out to be one of the largest piles of waste. Of course, this is only a very shallow and brief description of a small, technical piece of Lean Manufacturing. There is a lot more to it. Read more here. Or read a whole (really excellent) book on it.

Now you may wonder how all of this applies to software engineering. In particular as treating software engineering as a manufacturing process is definitely dangerous.

One of the key insights is, that the counterpart to inventory in manufacturing is unfinished (or undeployed) work in software engineering. This is often just summarized as Work In Progress (WiP).

Consequently, the counterpart of limiting inventory in lean manufacturing processes, in software engineering the goal should be to limit limit work-in-progress. This is one of the main concepts of Kanban in software, which has been popularized by David J. Anderson.

And this is already pretty much all that is to it. This simple measure can have a great effect, though. In practice this work as follows: the development process is depicted on a board, with several columns reflecting the states of the development process. The tickets (or stories) pass through the stages (columns) on the board. However, each column has a limit on how many tickets it may hold. This is how WiP is limited.

The best illustration to date, of how a typical Kanban workflow might look like has been given by Henrik Kniberg with his post “one day in Kanban land”. Note how each column represents a stage of the process, and how each of the columns/stages is equipped with a limit on the number of tickets (all figures by Henrik Kniberg).

Ultimately, Kanban mostly differs from Scrum in what it does not have, rather than what it has. Another nice illustration by Henrik Kniberg puts different processes next to each other in order to illustrate this:

Image Source: Henrik Kniberg

You will have noticed that Kanban does not know the concept of sprints. You could say Kanban is one endless queue of stories, just like a pipe just limited by the flow that is able to pass through your process. Or, you could see as an endless series of mini sprints, where the sprint backlog is the “selected” column in the Kanban board. And this again is quite similar to the one-piece-flow in lean manufacturing.

In other words, Scrum works with batches (=Sprints). Kanban works with (one-piece) flow. By now, I think the latter is more elegant.

However, many of the artifacts of Scrum can or XP still flexibly be used in Kanban – and it does make a lot of sense to do so:

  • User Stories, Story points, and estimation with planning poker
  • Planning and review meetings: those can just be placed at regular intervals, like once a month, and the team simply shows what has been achieved (moved to the “Live” column) in the time since the last Sprint
  • Roles like product owner, “kanban master”, and team
  • While Kanban does not know burndown charts, there are so-called cumulative flow charts, which allow for the same process transparency as does Scrum

The main reasons for introducing Kanban were the following

  • we had some really long running tasks in computer vision engineering (it does not make sense to break them down. We tried. Really.)
  • we do have some specialists, for instance in computer vision or iPhone development
  • thus, in reality, the two points above made it hard to timebox certain tasks in Sprints and we ended up with “water scrums”: at the end of the sprint. Many tickets wer started, but none finished

With the limited WiP concept we attack this problem at the source.

Also, our team wanted more responsibility for larger goals. Thus, we set now goals quarterly, and combine it with roughly monthly review meetings. In the review meeting everything that made it to the column “Live” is demonstrated to stakeholders. Kanban gives us this flexibility.

We do the “daily standup” every two days, and separated by teams (in engineering we have a platform team and a product team, with 4 team members each).

We have Story estimation meetings at regular intervals (ok, ok, not that regular) where stories are estimated in story points using planning poker.

We started out with a physical Kanban wall:

Our original, physical Kanban board

We use the following columns on the board:

Backlog > Selected -> Ongoing -> Review -> Done -> Deploy -> Live

This is pretty much standard except for the Review column. In this stage we do code-review.

In the meantime we are using a digital tool called Kanbanery. In our opinion, after some evaluation, by far the best tool you can get these days. Our current board is shown below:

Kanbanery, our digital Kanban board

We display the Kanbanery Kanban boards on two wall-mounted screens in our office. This way we follow the lean concept of visual control, i.e. having the current state of development visible at all times.

Visual Control: two screens with Kanban Boards (and a third one showing incoming queries)

To date I believe we can say we found our best way of working so far. Work is steady and there is more freedom, which is valued by the team. Personally, I have to say Kanban keeps most of the benefits of Scrum, but feels more realistic or maybe even more “honest”.

The one thing we could probably improve is doing estimations more regularly. The goal of this is to have good data at hand for longer-term estimations. (An alternative would be dropping estimations all together, as some people argue that all estimation efforts are essentially “muda” (waste)). Planning would then be done just with average ticket cycle times. We will see and keep you posted.

Also, we are really happy that our marketing team started to use Kanban, too. This just shows how flexible the process is.

So, this is how we do Kanban. Let us know your comments. In a future post I would like to tell you about how we use A3 reports.