Why a Kanban Board is a Value Stream Map but a Scrum Board Isn't - and What This Tells Us

February 22, 2010 — Posted by Al Shalloway

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:

Example of Value Stream Map

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. Example of Kanban Board

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.A Kanban Board is only part of the Value Stream Map

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.

Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile