Introduction

Last week I attended a meetup of Agile Holland, which was all about Kanban-style software development. An interesting presentation about the application of Kanban at a large Dutch insurance company got me thinking about the way they interpreted and visualized the concept of “pull” in their story boards. It has lead me to believe that the correct visualization of pull actually requires us to depict our story boards backward.

Kanban

Kanban is a Japanese word that is used in lean manufacturing to represent a signaling card. These are cards that are used in lean production systems, that indicate the need for an item. E.g. a customers buys the last monitor X from a store. The salesman takes the monitor from the stockroom and puts a Kanban in its place. This card is then picked up by the replenisher, who starts the ordering process for a new monitor at the central warehouse. The central warehouse delivers one or more new monitors X and if its own stock runs out, Kanbans are used to signal that and trigger the process to the manufacturer, etc. The whole idea behind this mechanism, is that items are only moved and produced, when there is actual demand for them in the supply chain. This creates a “pull” mechanism, instead of traditional “push” mechanism, which mass production is known for.

Software development and story boards

In software development, traditionally, a lot of features are thought up in the beginning of the process and are pushed in bulk into the software development process. The most extreme form of this is the waterfall software development approach. Luckily, agile principles have lead to much better software development life cycles, like Scrum. In Scrum, story boards, like the one depicted below, are used to track progress of individual items (features or user stories). Items move from left to right when they are being worked on. But there is actually nothing really stopping a Scrum team from moving the items in bulk from left to right, which is often considered to be a “push” mechanism.

I say “often”, because the essence of this post is that it actually isn’t a “push” mechanism. But before I go into that, let me talk a little more about last week’s presentation. They presented an enhanced version of their story board: Kanban-style. The core idea is that you want to limit the team’s freedom to push everything through the process in bulk, but instead focus on creating flow, by limiting the number of items that can be simultaneously in one phase of the process, e.g. like so:

This story board restricts the number of items allowed in the “planned” phase to 6 and in the “in progress” phase to 3. Now, only when one of the three items move from “in progress” to “done”, is a team member allowed to move one of the “planned” items to “in progress” and start working on it. If that means that a team member finds himself stuck because he can’t start working on a new item, he is forced to help other team members to get items to “done”. This focuses the whole team on getting things done.

The visualization problem

The problem I found in last week’s presentation was with the visualization of “pull” in the story board picture (side note: the actual story board presented had a few more phases, but that does not matter for this argument). Here’s the arrow that they drew to show how pull works:

It was argued that a freed up space in one phase on the right side leads to the pull of an item from the phase to its left. This then leads to an overall pull from right to left. But if you go back to the parallel of lean manufacturing, then this is not the actual pull that this at the core of this process. The actual core pull is established by the fact that the development process is only triggered by customer feature requests instead of internal assumptions about what the customer needs. Note that this is also the core idea behind Scrum, and therefore a Scrum story board represents a pull system as much as a Kanban story board.

Now, for almost all readers in the western world, push is most naturally depicted as something moving from left to right. Thus pull feels like it should be originated from the right side of a picture. In that case, the visualization of a pull-based software development process would actually need to look like this:

So for software development professionals in the western world, I would argue that Kanban-style story boards would benefit from a backward visualization, if the characteristic of pull is to be emphasized explicitly.