Kanban, Flow and Cadence

Intro

There has been some noticeable increase in interest in Kanban recently, with a number of people asking for more basic info, and more people writing new blogs and articles.  This is my attempt to describe in more detail my take on it all, which I refer to as Kanban, Flow and Cadence.

  • Kanban – Controlled Work
  • Flow – Effective Work
  • Cadence – Reliable Work

Kanban

A Kanban system is a mechanism for controlling the work in the software development system.  Kanban can be defined as “visual card”, as shown below – kindly written for me by Kenji Hiranabe at Agile 2008.

The origin of kanban is the Toyota Production System. Taiichi Ohno, in his book Toyota Production System, wrote:

“The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.”

Kanban is what enables a pull system for just-in-time work.

What does a Kanban System look like for software development?  Very simply, there is a queue of work, which goes through a number of stages of development until its done.  When work is completed in a stage, it goes into a downstream queue for the next stage.  When someone needs new work to do, they pull it from their upstream queue.  This can be depicted as below.

That looks very like a typical Agile Task Board, with maybe a few more steps, although there is nothing to say there can’t be a single development stage. However, there is one more important element which really defines a kanban system – limits.  There are two basic limits – Queue limits and WIP limits.

Queue limits are designed to avoid premature work.  This how just-in-time is achieved.  The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritisation (i.e. having things sitting in the queue for too long before they are begun).  Ideally the queue should be FIFO, although this is a guideline rather than a hard rule, as sometimes available skills or other resources mean that it is not always possible.

Work In Progress limits are designed to reduce multi-tasking, maximise throughput, and enhance teamwork.

Reducing multitasking is beneficial for two primary reasons.

1) 20% time is lost to context switching per ‘task’, so fewer tasks means less time lost (from Gerald Weinberg, Quality Software Management: Systems Thinking)

2) Performing tasks sequentially yields results sooner.  As the diagram below shows, multi-tasking A, B and C (on the top), delivers A much later, and even C slightly later, than sequentially (on the bottom).

A great exercise to demonstrate the effects of multi-tasking was described by Clarke Ching.

Throughput is also maximised by decreasing WIP.  Simple examples of this effect are traffic jams, where traffic speed reduces as more traffic builds up, and CPU load, where application performance goes down as CPU load increases.  The effect can be be explained by looking at Little’s Law for Queuing Theory:

Total Cycle Time = Number of Things in Progress / Average Completion Rate

Therefore, to improve cycle time there are two options; reduce the number of things in process or improve the average completion rate.  Of the two, reducing the number of things in progress is the easier, and once that is under control, then the more challenging changes to improve completion rate can be applied.

Finally, by having fewer work items in progress, then the team is able to focus more on the larger goals, and less on individual tasks, thus encouraging a swarming effect, and enhancing teamwork.

Limiting Work In Progress like this can seem unusual for teams, and there is often a worry that team members will be idle because they having no work to do, but are unable to pull any new work.  The following guidelines can be useful to help in this situation.

  1. Can you help progress an existing kanban? Work on that.
  2. Don’t have the right skills? Find the bottleneck and work to release it.
  3. Don’t have the right skills? Pull in work from the queue.
  4. Can’t start anything in the queue? Is there any lower priority to start investigating?
  5. There is nothing lower priority? Find other interesting work.

They key question here are what constitutes lower priority investigative work or other interesting work.  Essentially it is work which won’t create any work downstream, will improve future throughput and can be paused as soon as existing kanban related work is available.  Lower priority work could be spikes or analysis for known impending work.  Other interesting work could be refactoring, tool automation, personal development or innovation.

WIP limit sizes can depend on type of work and size of team and should be adjusted to achieve maximum flow.  One approach is to start small (e.g. a limit of 1) and increase as necessary.  Another is to start larger (e.g. a limit of half the team size) and reduce until the sweetspot is achieved.

The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e.Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations.

Flow

Flow describes how the work in the system can delivery maximum value.  As Mary and Tom Poppendieck write,

“In lean enterprises, traditional organizational structures give way to new team-oriented organizations which are centred on the flow of value, not on functional expertise.”

In particular, Lean emphasises ‘One Piece Flow’.  This means moving one piece at a time between stages in a workflow as opposed to moving  batches of work between stages in a workflow.  The ‘One Piece’ in a Kanban system for software development can be thought as the Minimal Marketable Feature, as described by M Denne & H Cleland-Huang in Software by Numbers.

“A minimal marketable feature is a chunk of functionality that delivers a subset of the customer’s  requirements, and that is capable of returning value to the customer when released as an independent entity”.

The kanbans should be minimal so that they are as small as possible in order to enable progressive delivery  to realise the product sooner, reduce feature bloat and focus on the the core features which are the most important, and minimise complexity because each feature has a cost to a user.

The kanbans should be marketable in a number of ways.

  • Table Stakes – these delivery parity to the competition and are the minimum needed to be in the game
  • Differentiators – these differentiate the product from the competition and delight the user
  • Spoilers – these nullify a competitors differentiator and raise the bar for parity
  • Cost Reducers – these reduce cost and improves the profit margin

A useful guideline is that an MMF is marketable if it is something that could be written about on a product blog.

The kanbans should be features which are distinct, deliverable and observable.  The INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) as described by Bill Wake, can also be useful for applying to MMFs.

The Marketable element of MMFs means that they may sometimes be larger than typical User Stories, which often break work down such that while they can be incrementally delivered, and show some element of value, they are not marketable in their own right.  Therefore, it is important to understand an MMFs Value Stream in order to deliver the whole MMF as quickly as possible.  A value stream describes the steps, delays and information required to deliver a product, and can often be used to decide the steps in an initial kanban system.  With large MMFs, the User Stories become more of an analysis technique in order to enable incremental delivery of an MMF, without losing sight of the overarching MMF.  I describe how a continuous flow can be achieved with MMFs in The Anatomy of an MMF.

A number of techniques can help manage the relationships between MMFs and User Stories in order to realise the benefits of both.  One is User Story Mapping, as descried by Jeff Patton.

I have also recently been working in a regulated environment where User Case Goals and Sub Goals have provided the MMFs, with the detailed scenario paths and steps providing the additional details.

A further enhancement is to use two-tier Kanbans, with one tier for the MMFs, and another for the User Stories.

The consequence of applying the concept of Flow is that emphasis is placed on using larger, value-focussed MMFs, rather than smaller, more incremental Stories.

Cadence

Cadence is the approach to achieving commitment and reliability with a kanban system.  I often get a question something along the lines of,

“If the team isn’t estimating or planning with fixed time-boxes, how can it make reliable commitments?”

To quote Mary and Tom Poppendieck again,

“A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity.  An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”

The time-boxed iteration is one form of cadence, which couples planning, review and release together.  A kanban system de-couples these events and allows them to have separate cadences, as well as adding two additional ones.  Throughput is the amount of output of a process in a given period of time, and Cycle Time is the length of time to complete a process.  The relationship between the two is:

Throughput = WIP / Cycle Time

Throughput allows forecasting of future capability, without needing to specify what might be delivered.  Cycle Time allows commitment by becoming an SLA with the business (see Kanban Commitment).  Where the size of work varies, from large new features to small fixes and change requests, then a classification of MMFs can enable a range of cycle-times.  Both Throughput and Cycle Time can be charted and trended, in a similar way to XP’s Velocity, as a means to encourage the team to improve.  A Cumulative Flow Diagram can also make visible how the work is flowing through the system and highlight bottlenecks.

For longer term forecasting, a quarterly planning cadence focusses on quarterly goals and objectives.  MMFs can subsequently prioritised to meet those goals and objectives.  A regular release cadence will build up trust that the team will work to its full capacity and throughput.

Other cadences, are daily stand-up meetings, and regular retrospectives and Operations Reviews as described by David Anderson.  Some teams are using a Retrospective Kanban to signal when a retrospective is necessary, and I have already blogged briefly about Kanban and Retrospectives.

The consequence of Cadence is that commitment and reliability is achieved though measurement as opposed to planning.

Summary

They key points of Kanban, Flow and Cadence are:

  • A Kanban System manages the workflow in a way which allows the Product Backlog, Timeboxed Iterations and Estimations to be eliminated.
  • Flow is about effectively delivering maximum value by focussing on optimising the value stream of larger MMFs
  • Cadence allows iteration input and output to be de-coupled and achieves commitment and reliability via measurement rather than planning.

Further resources and information can be  on my Kanban Page, including most of the material which has influenced and directed my thinking.

VN:F [1.9.22_1171]
Rating: 4.8/5 (30 votes cast)
Kanban, Flow and Cadence, 4.8 out of 5 based on 30 ratings

65 comments on “Kanban, Flow and Cadence

  1. I like your article a lot. But I am unsure about the commitment. In Kanban you wouldn’t have an explicit commitment of the team, right?
    You end up with a average cycle time / throughput. Since these are average values they vary over time. If one value is a little better oder worse than that before, what does that mean? Is there a problem or is it just an expected variation?

    Stefan

  2. Hi Stefan
    In Kanban, you do have an explicit commitment of the team, to an SLA which is determined by measuring the mean cycle time. There will be variations in cycle time, but you should be able to agree on a value with which you can say, “If you ask for something now, we will deliver it within X days/weeks”.
    Karl

  3. Pingback: rob bowley » Blog Archive » Lean is the new Scrum, and it will fail for the same reasons

  4. Pingback: Kanban simulation | Lean Software Engineering

  5. Pingback: rob bowley - adventures in software development » Blog Archive » excellence through simplicity

  6. Hi Karl,
    Very interesting article. Regarding the SLA what happens if the client asks for ‘everything’ now? Doesn’t it need to be qualified in some way and if so how is this expressed?
    Adam

  7. Adam,
    The short answer is that they can’t have ‘everything’ now. They need to decide which one thing they want next. However, they can set an overall goal.
    Karl

  8. Karl,

    I understand that the client can’t _have_ ‘everything’ now. My point is that the example SLA doesn’t prevent them from _asking_ for everything now and consequently looks like it could get you into trouble i.e. if the client keeps asking for features (all nicely prioritised) faster than the team can deliver them then at some point they _will_ fall short of the SLA as expressed.

    I asked my question to see if the SLA was qualified by some notion of a minimum flow-rate for the team. I assume that the SLA limit is simply so large that the team are unlikely to be overwhelmed? I assume also that until you have a reliable “mean cycle time” for the team one would just have to guess the SLA limit?

    Adam

  9. Adam,
    One of the things Kanban will give you is a way of avoiding the client asking for features faster than the team can deliver. Features are pulled as capacity allows.
    Flow-rate is throughput, or velocity if you are estimating/categorising features, and is measured along with cycle-time. So you have an idea of how much you can do, and how long each feature might take, so you can still forecast. Until you have a reliable measure you are guessing – just like you guess velocity to start with on a Scrum/XP project.
    Karl

  10. Pingback: XP Days Germany Blog » Kanban-Referenzen

  11. I think we need to be precise about what the Client “asking” for something actually means, the definition of the “queue of work” and the relationship between this and the Product Backlog (assuming there is one in a Kanban system).

    Is the “queue of work” the entirety of the Product Backlog (i.e. there is no Product Backlog) or is it a (literally) limited amount of work pulled from the Product Backlog to be worked by the team? I am assuming it is the latter and that there is still a Product Backlog lurking about somewhere ‘upstream’?

    If this is the case then when does your SLA apply? Is it when the new features hit the Product Backlog (i.e. are asked for by the client) or when they are pulled from the Product Backlog into the “queue of work” by the team?

    Adam

  12. Ah. I think I see the confusion.

    The SLA kicks in when the client prioritises a feature into the queue of work. This is the point at which the team are able to commit to delivering within their capacity.

    The Client may keep a separate product backlog, but that is outside of the kanban system, and is more of a ideas pool, rather than anything that is prioritised, estimated or invested in in other ways.

    Karl

  13. Right I see. In that case it all makes perfect sense. I feel like I am slowly starting to get a better understanding 🙂 Thank you for your patience Karl.

  14. Pingback: Getting started « Limbering Up

  15. Pingback: Answers to common Kanban questions « Lean and Kanban

  16. Pingback: The Kanban board « Lean and Kanban

  17. Pingback: Scrum vs. Kanban « Scrum 4 You

  18. Pingback: Evolution of Kanban Board - Part 2 « Lean and Kanban

  19. Pingback: Evolution of Kanban States - Part 3 « Lean and Kanban

  20. Pingback: Kanban: What Is It? | Coded Style

  21. Pingback: Kanban: Some Kanban Resources | Coded Style

  22. Pingback: Kanban « The Art of Software Development

  23. Pingback: Lean and Kanban Software Development Digest | Edge of Chaos. Agile Development Blog

  24. Pingback: Daily Links for Wednesday, July 8th, 2009

  25. Pingback: Scrum or Kanban? «

  26. Pingback: Day One Done! «

  27. Pingback: Kanban In Time-Boxes: The Cadence of WIP and Sprints - new ThoughtStream("Derick Bailey"); - Los Techies : Blogs about software, programming and anything tech!

  28. Pingback: links for 2009-08-31 « Csom Gyula Blogja

  29. Pingback: Lean and Kanban Collection : Software & Technology @kirkk.com

  30. Pingback: 5 Steps to Kanban – Software East November talk | The variation point

  31. Pingback: links for 2009-11-05 | Nathan Jamin’s Weblog

  32. Pingback: links for 2009-11-06 | Nathan Jamin’s Weblog

  33. Great article, but the following confuses me:
    “A further enhancement is to use two-tier Kanbans, with one tier for the MMFs, and another for the User Stories.”

    Could you explain this a bit further, is it like using two swimlines? Basicly I have a flow where parts of the workflow uses different subflows. Step X could go to step Y or step Z, depending of the charesteristics of the story.

    • Hi

      In the context of the article, I was referring to different levels in a work breakdown structure. However, you could have a swimlane split into two, depending on implementation characteristics. Presumably this would be because of some form of specialism required, and it would be a good way of managing the demand on the specialists, and encourage collaboration and multi-skilling when the specialists were overloaded.

      Karl

  34. Great post Karl.
    I’ve driven change initiatives to convert product organizations over to Agile over the last 9 years, last one using Scrum, driven bottom-up…yikes, I must say Kanban seems like something that would be easier to implement as an Agile team matures rather than trying to start with it. Thoughts?

  35. Pingback: ToolBlog » Personal Kanban

  36. Good post, Karl – I stumbled across it via the LimitedWipSociety.
    I have a question on One-Piece-Flow and the example by Clarke Ching you give in the first section:
    What is proposed here to avoid multitasking is actually one form of batch processing, which is not lean, and in fact, muda.
    The lean way would be to cross-skill, and to fill in one line, then proceed with the next.
    So you’d have One-Piece (= “Line”) Flow, actually.

    Or is that a misconception?

    Greetings from Berlin, Germany,
    -Martin

    • Hi Martin

      Good question. What I didn’t make explicit is that for the bottom line, the A B and C are each effectively MMFs. They can’t be broken down anything smaller and still deliver any meaningful value. So in that context, I don’t think each full A, B and C is a batch, but is a single piece.

      Karl

  37. Pingback: From KFC Development to PVC Systems | limitedwipsociety.org

  38. Excellent article. Your interpretation of Kanban is more in line with my experience thus far. Great stuff!

  39. Pingback: Finding your Rhythm « Becoming an Agile Family

  40. Pingback: The kanban support journey

Comments are closed.