I had an interesting conversation with Masa Maeda of Shojiki Solutions a few days ago. Somewhere in the conversation the observation that a Kanban board was a value stream map (VSM) was mentioned. A value stream map shows your workflow as well as the time it takes to do the work. Here is a simple example:

I have been using value stream mapping for 5 years or so. I have seen organizations get huge value from VSMs. An extreme case was where two people working on a VSM for a 100 person organization directly, and quickly, resulted in a significant (20%) improvement to the organization (see pages 18-22 in Lean-Agile Software Development: Achieving Enterprise Agility).

A few weeks ago, I was helping several teams create their Kanban boards. The discussions revolved around the way they should do their work: the workflow they should use and the proper sequence for doing their work. It sounded just like the conversations people have when they are creating value stream maps. And that makes sense: the columns of the Kanban board do represent a kind of value stream map!
It is also a visual control of your process that can be kept up to date. It always reflects that current state of the process (or it should). Without any wasted effort.

Compare the Kanban board below with the value stream map above.

Notice that the time in and between steps is lost... or maybe not. On a Kanban board, you delineate the queues. VSM times get translated into these queues.

The Kanban board is only part of the VSM

The Kanban board only covers part of the VSM, usually only from input to development through deployment. It does not cover the first part of the value stream (request through sign-off), as shown in the figure below.

While the first two columns of the Kanban board may appear to be covering the beginning of the VSM, remember that those columns are under the control of product managers and often isn't part of a real board. This illustrates two other important things about Kanban:

• Kanban typically does not include product portfolio management.
• Kanban does provide visibility into how the work is done, which can provide valuable information to those doing product portfolio management.

BTW: If you are interested in learning more about product portfolio management, look at our book Lean Agile Software Development: Achieving Enterprise Agility.

Why a Scrum Board is not a VSM

I have seen very few Scrum boards that are defined workflows. While the Scrum board might look like a Kanban board, it does not reflect an underlying value stream process and lacks the well-defined stages between "backlog" and "done."

Rather, the Scrum board has a collection of work items on the left that represents the sprint backlog. Teamlets or individuals select work items from the backlog based on their own judgment according to (usually loosely defined) set of rules. This approach is based on the belief that the team is working in a complex, unpredictable environment and so individual judgment is required.

When a team is working on their Kanban board, they are refining their understanding of their value stream and can update it immediately to reflect what they have learned with no extra work. Continual learning and refinement are built into the Kanban approach. Scrum tends to relegate this learning and refinement to the retrospection stage at the end of a sprint.

Why managing Work-in-Progress (WIP) is good but doesn't make Scrum Kanban

Many Scrum practitioners have been making it sound like Scrum and Kanban are just a collection of different tools. This is not really true. There is a mindset behind kanban that is significantly different from that of Scrum (see Comparing Scrum to Lean, Not Quite Apples to Oranges). When one realizes that a Kanban board is a subset of the value stream map of software development it becomes clearer that in Kanban, you take a systemic approach - one based on the theories of flow and creating full transparency in terms of what is happening. I suppose in Scrum you could do this as well - but it isn't called for. The fact is, many Scrum trainers have said defining your workflow is an anathema to Agile development. In any event, it should be clear that managing WIP and defining a workflow are not the same thing.