Model workflow stages – not people or roles

A recent discussion on the leanagile list compared Scrum and Kanban with respect to team swarming.  The suggestion was that swarming doesn’t occur in kanban due to the way work flows from role to another.  This is a common misconception, leading to the perception that kanban is more like waterfall than agile.  Here’s my response.


I would say that limiting WIP in a kanban system can encourage swarming because team members have to help each other rather than pick up new work

And then:

The stages in a workflow are not people, or even roles.  Just stages.  So anyone can do them.
It just happens that people tend to specialise their roles to stages.
So kanban allows specialisation, but also encourages people to break out of their specialisation by limiting WIP.

For example, I might have an analysis stage, and Bob, a Business Analysis specialist.
If the kanban system has throttled analysis work, Bob could probably work with developers or testers to help them improve their productivity.
And vice versa.

Its this focus on workflow, while allowing for specialisation, that means that kanban is a suitable technique for teams of all agile maturity.  As teams learn to swarm, then their agility should improve as a result.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Lean & Kanban 2009 Miami Rescheduled

The Lean & Kanban 2009 conference which I promoted (am am speaking at) has been rescheduled to May 6-8.  Its still in the same location in Miami, and the schedule is pretty much the same, although Don Reinertsen is unable to make it.  There are early mutterings of a European based version of the conference towards the end of this year, so hopefully he might be able to attend that instead. The hope is that postponing the dates will allow more people to be able to attend.

Details of the conference can still be found at

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

A Kanban Sidebar

I was kindly asked by Rachel Davies and Liz Sedley to write a sidebar on kanban for their upcoming book on Agile Coaching (no links yet).  Here’s what I put together:

An alternative approach to planning work in time-boxed iterations is to use a Kanban system.

A Kanban system uses physical tokens to limit work in progress and to pull work as single units. This helps create a one piece flow, where features of value move through the system individually, rather then being grouped into batches. Kanban is the Japanese word for “visual card”. When applying a Kanban system for software development the Kanban token can be an index card representing a user story.

A key characteristic of a Kanban system is that it limits the work in progress in order to improve cycle time, reduce investment in inventory and enhance teamwork. For example, if the team sets a limit of only three user stories being in progress at a time, the team can exclusively focus on those three stories, and defer analyzing and planning new stories until there’s space in their queue. Instead of having an iteration planning meeting, the team simply waits until they complete one of these three stories. Now they have the capacity to pull the next most important story, as prioritized by the customer.

Following this approach, task estimates are no longer necessary, and any task breakdown becomes a purely analysis and design activity. Releases can still happen early and often, but a kanban system allows the planning and release cadences to be de-coupled. The customer might prioritize user stories on a weekly basis but releases might only happen fortnightly, and releases contain whatever is ready, rather than a planned set of stories.

Instead of the team committing to deliver each feature within a time-box, the team commits to delivering features at an agreed throughput (rate of stories per release) and mean cycle time (how long each story takes to get done). These agreed metrics are arrived at by measuring the team’s performance over time.

Applying this approach with a team that was using Scrum, but struggling to deliver reliably, allowed a more natural process that enabled the team to improve and become more successful.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Announcing Lean & Kanban 2009 Miami

The Lean & Kanban 2009 conference in Miami (KSE : Miami) is officially open for registration at Its February 18th-20th at the Mandarin Oriental Hotel.

From the Flyer:

Two and half days featuring a full day of presentations with separate tracks for Lean and Kanban, plus a full day of open space and a half day of lightning talks. You will learn the latest thinking in applying Lean techniques like kanban to shorten cycle time and deliver more value from your software projects. Mix with the experts and practitioners using these ideas every day in organizations around the world.

Come and enjoy the beautiful South Beach venue. Enjoy the Florida sun in winter. Mix with your peers, extend your network and enjoy deep discussions during frequent breaks, open space and at our cocktail  reception Feb 18th sponsored by Ultimate Software. Be part of our community. Be part of the next wave of software management and leadership.


  • Donald G. Reinertsen
  • Alan Shalloway
  • David J. Anderson

Other speakers include:

  • Myself
  • Amit Rathore
  • Dean Leffingwell
  • Corey Ladas
  • Peter Middleton
  • James Sutton
  • David Laribee
  • Others

I’ll be opening the kanban track with a version of Kanban, Flow and Cadence to introduce the basic concepts and set-up Corey to talk about Scrumban – Scrum & Kanban,  I’m really looking forward to it – it should be the start of a regular conference which has the potential to grow into something big.  Hope to see you there!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

The Kanban, Flow and Cadence Simulation

I use a simulation when I have time in presentations on Kanban, Flow and Cadence, which I hope makes the ideas a bitter clearer and more concrete.  I was asked if I could make the materials available, so here they are with an explanation.  Its not perfect, and can be slow and time consuming, so I’d love any feedback on how to speed it up and make it a bit snapper.

The simulation uses an example work flow with 5 stages; Analysis, Design, Code, Test and Release, and a set of Minimal Marketable Features which require varying amounts of effort at each stage.  The kanban board is set-up as below with WIP and Completed columns for each stage

The MMFs can be printed from this MMF document.  If you want to create your own, they are generated from a MMF spreadsheet with a MMF mail merge.

An MMF progresses through the system by rolling a dice for each days work per stage and subtracting the appropriate effort from the relevant total.  When a total reaches zero, the MMF can progress to the next stage.


This MMF requires 3 units of Analysis effort, 1 unit of Design effort, 4 units of Code effort etc.  If the Analysis role throws a 2, then there is 1 unit of effort remaining.  If they throw a 3 then there is 0 effort remaining and the MMF can proceed into Design.  If they throw a 4, then there is 0 effort remaining, the MMF can proceed into Design, and 1 unit can be used on the next MMF.

The simulation proceeds by each role throwing a dice once per day, from Analysis to Release, and pushing work through the system.  After each week (5 days) we can update the metrics spreadsheet with the current status.  For each MMF, set its its status in the Column for week 2 (i.e. the beginning of week 2).  In addition, to show how much work was started each week, set the status for all the new MMFs to Not Started in the Columns for week 1.


Continue for 3 or 4 weeks and you should start seeing a bottleneck.  The effort numbers on the MMF cards are deliberately weighted so that Code requires more effort than the other stages.  Hence in the CFD you can see that Test and Release are starved, while and Design is backing up.  You can also see that Lead Time is going up, but that Throughput has settled at 4 MMFs per week.

cfd-week-5 lead-time-week-5 throughput-week-5

If we continued to work this way we can predict that these trends would continue.  Code would be a bottleneck, causing lead time to grow, and constraining throughput.  However, at this point we can introduce kanban limits. I tend to set a single limit across both the stage and its completed column as I find this simpler.  An alternative could be to have each column have a limit of 2.  As we are implementing a kanban system we should also pull the work by rolling the dice from Release back to Analysis.

We can also re-focus our available effort to help Code be more productive.  We do this by artificially weighting the dice.  A normal dice has an average throw of 3.5.  By reducing the average throw to 3 for Analysis and Test, we can increase the average throw for Code to 4.  The following table shows how this works.  For example, to get an average throw of 3, a roll of 5 or 6 translates to 4.


Running like this for another 3 or 4 weeks should clear the backlog, giving smoother flow and resulting in Lead Time coming back down.  Throughput may also improve  as we have made Code more productive.  At this point further tweaks to the system may suggest themselves.  Shifting the allocation of effort by further weighting the dice may is one option.  Adjusting the limits is another.  Run until all the MMFs have been completed and see how the graphs look.


VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

XP Day London Wrap-up

XP Day London 08 was last week.  The slides and spreadsheet from my Kanban, Flow and Cadence are now available on the download page.

All in all, the conference was a good one.  Open Space went really well.  Too many interesting options to choose from, which is usually a good sign.  I ran a session on the Evolution of the Agile Model which was an interesting and lively discussion.  No concrete conclusions, but I’ll upload photos of the notes to the conference wiki.

It was also great to have Daniel Jones and Marc Baker giving a keynote on Lean Thinking.  While they haven’t worked in software development before, their general insights were useful and entertaining, with some horror stories from the NHS!  They also seemed genuinely interested in getting more involved in helping learn how to apply Lean to software development.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Support the Agile Fringe

Agile 2008 was driven by the vision of a music festival (e.g. Glastonbury).  In the same way that music festivals encourage new and emerging acts, Agile 2008 had a Breaking Acts stage with the same goals.  Agile 2008 also had a Questioning Agile stage in order to be transparent and encourage debate about Agile.  Agile 2009 has lost both these stages.

David Anderson has written an open letter to the conference committee proposing an Agile Fringe stage which will encompass both these areas.  The intent will be to allow an explicit means for the Agile community to encourage innovation and be open to new, different or rediscovered ideas and thinking so that we can continue to learn and improve in new directions.

If you agree with these sentiments, please go and read the letter on David’s blog, and show your support by signing the letter with a comment.

Update: I should also say that I have both privately and publicly supported Johanna and the conference committee.  You can also show support for the conference committee on Johanna’s blog.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Managers' Introduction to TDD at Agile2008

InfoQ has just published a video of myself and Dave Nicolette’s presentation at Agile2008 – A Managers’ Introduction to Test Driven Development

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban and the New New Product Development Game

One of the primary origins of Scrum is “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka, published in the Harvard Business Review in 1986.  This is the article in which the contrast is made between a traditional sequential or “relay race” approach and a holistic or “rugby” approach. Hence  the name Scrum was derived.  As part of their explanation of the differences between the approaches, the authors describe three types of approach:

  • Type A – single phases, proceeding exactly sequential
  • Type B – single phases, overlapping at their borders
  • Type C – multiple phases, overlapping each other

Phase Types

The Type C diagram was in my mind when I was putting together the diagrams towards the end of The Anatomy of an MMF, and I think this approach actually describes a Kanban based approach pretty accurately, where we recognise and allow phases to exists as necessary, but at the same time encourage whole team collaboration.

Jeff Sutherland has also reinterpreted the classifications to describe how Scrum’s Sprints progress:

  • Type A – single Sprints, proceeding exactly sequential
  • Type B – single Sprints, overlapping at their borders
  • Type C – multiple Sprints, overlapping each other

Another way of describing this evolution could be to say that Type C is multiple, overlapping MMFs, where each MMF is variable length and not time-boxed.  Its worth noting that The New New Product Development Game makes no mention of time-boxes!

VN:F [1.9.22_1171]
Rating: 3.0/5 (2 votes cast)

Is Kanban Only Suitable for Mature Teams?

Another hot topic around kanban is whether it only suitable to use with mature agile teams. In terms of Shu Ha Ri, is kanban a Ri process, or can it be a Shu, or even Ri process?

A good description of Shu Ha Ri can be found here.  To summarise, the concept comes from the Japanese martial art Aikedo and refers to the three stages of learning.

  • Shu is the first stage, where the student is imitating and following the master’s steps
  • Ha is the second stage, where the student is showing understanding, and breaking away from the master’s steps
  • Ri is the final stage, where the student is showing mastery and fluency by creating their own steps

So, is kanban a way of working which can be described such that teams can imitate and follow, or is it only achieved by teams who have mastered their process and become fluent?

A common perception is that kanban is a Ri level process. This primarily due to the fact that most prominent kanban implementations have been either by existing agile teams, or by teams with strong agile leaders. However, I think that this is a misconception, caused by a lack of understanding of kanban. A similar effect occurred in the early days of XP, when a lack of knowledge led to the idea that XP could only be used by highly skilled and experienced teams. This is now generally accepted to be untrue.

As the body of knowledge about kanban grows, I believe that kanban will become regarded as a Shu level process. In fact there is anectodal evidence of successfully introducing kanban to non agile, and hence low maturity agile teams. Comments on a recent thread on the kanbandev list include:

Eric Willeke,

“All that to say that ‘making a change to Kanban’ may or may not work, but embracing the Kaizen principles and adopting a waste-challenging behavior will very likely lead you to something like Kanban without the change-induced stress of ‘changing to kanban’.”

David Anderson,

“I would use kanban in preference to any other approach now because it doesn’t require teams to change their behavior initially and when the change comes it is incremental and based issues the team is having that are affecting its performance – a bottleneck, some waste or some variability in flow. As a result the resistance to change is reduced to an almost negligible amount.”


“I would use kanban because i have seen it create the conditions that lead to positive cultural change towards a kaizen culture and because it drives automatic organizational maturity with a culture capable of reaching a high maturity level.”

Chris Matts,

“A number of teams in London implemented Kanban after a one hour presentation by David. Scrum master training takes a couple of days.”

Allan Kelly,

“The Kanban team have needed less instruction and help, and I see a wealth of statistical data coming out of the team.”

Aaron Sanders,

“I also find Kanban to be easier than Scrum. Teams tend to intrinsically “get it”, understanding the madness behind the method. such as: collaboration, swarm on work, work outside your ‘expertise’ to get things done, continually look to improve, learn and grow, etc.”

It seems to me that there is in fact a subtle difference between kanban and typical agile processes such as Scrum. Scrum focusses on being agile which may (and should) lead to improving. Kanban focusses on improving, which may lead to being agile. However, being agile itself is not important – it just happens to be the best way we (or at least I) know at the moment. If a team improves in other ways, then its the improvement that’s important.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)