Kanban, Flow and Cadence at the Brighton Agile Forum

I’m going to be talking about Kanban, Flow and Cadence at the Brighton Agile Forum next week on Wednesday 18th March, 7.30pm. The venue is The Skiff, 49 Cheltenham Place.  More details can be found on upcoming.

If you’re in the area, I hope to see you there.

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

Lean & Kanban Conference London 2009 – Call for Ideas

Update: The provisional dates have moved to from Sep 21-22 to Sep 27-29.

I am pleased to announce that we have started to plan for a Lean & Kanban Conference to take place in London, provisionally set for Sep 27-29 at the RSA (http://www.thersa.org/house).

As well as hoping to get these dates pencilled into your diaries, we would like to get your ideas and feedback on what and who we could include in the conference program.  Please let us know if:

  1. There is something you would like to talk about
  2. There is something you would like to hear about
  3. There is someone you would like to hear talk
  4. There is a format you would prefer (e.g. more talks or more open space)

We’d particularly like to hear from you if you are based in Europe so we can have a strong ‘local’ flavour, and we’re also looking for recommendations of people beyond software development who might add a different perspective.

Looking forward to getting lots of replies!

p.s. Don’t forget the Lean & Kanban 2009 Miami conference on May 6-8.  See http://leankanbanconference.com/

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

An Agile Workflow

A common topic of discussion around kanban is whether the workflows or stages in a kanban system are counter to the Agile principles of cross functional and collaborative teams.   Its easy to talk about a feature going through the following flow in a kanban system:

Analysis –> Build –> Test –> Release

which I confess looks very waterfall-ish and I can understand why this can raise warning flags about the suitability of the kanban approach.  This got me thinking about how best to express a typical agile-friendly workflow.

Lets begin with the common basic stages on an agile team’s ‘story-board’.

To Do –> In Progress –> Done

Ideally, ‘Done’ means In Production, but often it means Ready for Release.  From a Lean perspective, features that are ‘Ready for Release’ but not yet ‘In Production’ can be thought of as inventory, and we want to minimise inventory, so visualising that inventory would be useful.  Thus we can change the workflow to:

To Do –> In Progress –> Ready for Release –> In Production

Looking at the start of the workflow, a common practice in Scrum is shaping the backlog, or grooming the backlog.  This is the process of ensuring that the the Product Backlog Items that we take into Sprint Planning are well-formed.  That is, that they are small enough, and understood well enough, for the team to be able to plan and deliver them within the time-box.  I don’t think this is Scrum specific.  There will always be a step of taking a business problem or goal, and transforming into pieces that can delivered incrementally and iteratively.  Sounds like Analysis to me.

To Do –> Analysis –> In Progress –> Ready for Release –> In Production

Features which are ‘To Do’ have not had any significant time invested in them yet but they are generally formed to some extent.  We can say that they Incubate. ‘Analysis’ has baggage associated with it so we can give it a different name. I like the idea that we Illustrate what we need to do as it seems to allow for the notion of using executable requirements or other lightweight, quick feedback techniques.  ‘In Progress’ now really means ‘Build (and Test)’.  We can say that at this stage we Instantiate the illustration.  ‘Ready for Release’ means that we can Demonstrate what we have instantiated.  This could also include any validation or acceptance by the business. Finally, when a feature is ‘In Production’ it should be generating value, so we can say that we Liquidate it.

So for each feature, one by one, we end up with:

Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate

Does that still seem like a waterfall process?

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

A Scrum and Kanban Comparison

In a recent thread on the kanbandev list, Tim Uttormark asked about how Kanban handles teams with different dysfunctions without the Sprint timebox and associated meetings.  He gave the following example:

In Scrum, all tasks for the iteration are estimated by the team in sprint planning. Tasks assignments are not known at the time of sprint planning. The task estimate results from a team consensus, so the one doing the work on a task is not (solely) responsible for creating the estimate.

In my example, Harry (due to his incompetence) and Bill (due to his laziness) would fall short of the standard set by the team’s task estimates. Jeff’s behavior will not point as clearly to him as the problem, but will still be manifested as a team issue. Since he is highly skilled, he is probably able to produce at a higher rate than the average team member, and he can finish his tasks on time despite overengineering them. The team however would be better off if he stopped at “good enough”, finished early and moved on to other tasks. Jeff’s dysfunction would likely be manifested as the team missing their sprint commitments — the team needs the above average performers to complete more than their share of tasks to compensate for the lesser performers. In this case the team’s estimate of how much work they can commit to completing in an iteration provides a standard for comparison of team performance. Of course this can be gamed too, but requires more of a team conspiracy than just individual efforts to undermine it.

I responded by trying to map the Scrum process onto a Kanban process in order to show how a kanban system might deal with the same situation.

Sprint Planning is where the team collectively and collaboratively plans and commits to a small increment of work. As you say, this meeting will highlight any mismatches in understanding of the problem or solution by generating the Sprint Backlog with tasks and estimates, such that the whole team has a common understanding of what needs doing and how long it should take. Harry’s incompetence can be mitigated because he should have a better understanding of the solution. Bill’s laziness can be mitigated because he has been part of the estimation process, and Jeff’s over-enthusiasm can be mitigated because scope has been clearly discussed.

The Sprint Review is where the team are accountable for their Sprint commitment. This accountability should again mitigate for Harry, Bill and Jeff, because they have to demonstrate their progress and explain variation from the plan.

The Sprint Retrospective is where the team can explore reasons behind variations from the plan (and strengths and weaknesses in general) and can inspect and adapt in order to learn and improve. Over time, this can also mitigate individual weaknesses.

So for Kanban…

Sprint Planning becomes Feature Planning. Rather than planning a timeboxes worth of product increment, the team plans a single valuable increment at a time – sometimes referred to as a Minimal Marketable Feature (MMF). The team limits the amount of work in progress in order to minimise the cycle time of these MMFs. Once they have completed and released an MMF, the pick up a new one and start by planning it. The Planning can happens as a team, and break down into tasks and estimates as per Scrum, thus bring the same benefits and mitigating weaknesses in the same way. A possible downside is the break in flow that may happen when you bring the team together. A solution to this could be to keep a prioritisation and planning cadence – e.g. a weekly meeting to decide what the team will be working on next, and to plan it out. The frequency of this meeting will probably depend on throughput. The more frequently the team is able to complete and release work, the more frequently this meeting can be scheduled. A difference between this planning cadence meeting and a sprint planning meeting, is that the planning is ‘de-coupled’ from the release. In other words, whatever is planned does not have to be completed and released before the next planning meeting. In an ideal world, however, the MMFs are able to be small enough such that they can be completed and released within a week. In this case, Scrum with weekly Sprints can look very similar to Kanban.

Because of this ‘de-coupling’ of planning and release, a commit and deadline is made per MMF. This is sometimes referred to as a Service Level Agreement (SLA) between the team and business. The SLA says that the team will deliver features X days from when they are prioritised in the planning cadence, and is usually derived from past measurement of cycle-time. Where there is variability in the size of MMFs, different SLAs can be set for different sizes. Standard Scrum story point estimating can be used to classify the MMFs into different SLAs. A Due Date Performance (DDP) metric can also be measured, which is the percentage of MMFs delivered within their SLA. This SLA and DDP is what creates the equivalent team accountability in Kanban. I blogged some more about this here.

Sprint Review can still happen as part of the Release cadence. However, as we have de-coupled planning from release, this can happen as frequently as necessary, depending on the cost associated with a release. In the ideal world, this cost is zero, and you could release small MMFs daily. In this case, a small review of each MMF as it is completed might be appropriate. If there is a small release process the team needs to go through, then a weekly release cadence might be better, with a weekly Review. Whatever the frequency, the release cadence brings the same accountability for what has been delivered, and how long it has taken.

Sprint Retrospectives, similarly, can still happen with their own cadence. Kanban does try and shift the emphasis on the improvement to be as continuous and ‘kaizen’ as possible, but a fortnightly or monthly retrospective would certainly be a good thing to start with. Again, the retrospective brings the same benefits as in Scrum. I blogged some more about this here.

So I’d say in summary that a kanban approach includes all the elements of Scrum (including stand ups as well), but decouples them from all being tied to the Sprint. This can create a more natural process. On the other hand, it can also be less clear what to do when as its not so defined.

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

Lean & Kanban 2009 Miami Update

From the kanbandev list:

Just wanted to remind you that our Lean & Kanban 2009 Conference is taking place in Miami May 6-8. http://www.leankanbanconference.com/

We’ve confirmed a few additional speakers for the event. Notably Joshua Kerievsky who’ll talk about the iterationless, estimationless XP process at Industrial Logic, and Jeff Patton who’s been using kanban with his clients in North America. It’s great to have Jeff, a recipient of the Agile Alliance Gordon Pask Award, on our roster.

We’ve also got Rob Hathaway from London who’ll be presenting a kanban case study from IPC Media in London and Sterling Mortensen who’ll revisit the Lean implementation at Hewlett-Packard LaserJet Development that revolutionized their cycle time and productivity.

This is undoubtedly the best collection of practitioners of Lean techniques in software development ever assembled. Don’t miss out. Register soon. http://www.leankanbanconference.com/

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

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 http://leankanbanconference.com/

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 http://leankanbanconference.com/. 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)