From KFC Development to PVC Systems

I’ve been revisiting my earlier KFC Development work in light of my more recent focus on five primary practices. This is an brief overview of what’s changed, and what my mental model looks like now.

Firstly, I’ve stopped referring to the practices as such, in favour of calling them aspects. Practices always felt slightly wrong, but at the time I couldn’t think of a better way of describing what I wanted to be practical, rather than theoretical points. I think aspects still allows that practical focus, without giving the impression of being a prescriptive process. So the aspects are:

  • workflow
  • visualisation
  • work in process
  • cadence
  • continuous improvement

How does the KFC triad fit into that then. Here’s my thought process, which focusses more on conceptual ideas.

  • Kanban. In this context, Kanban is the tool. As I have become more interested in Systems Thinking, I have become less focussed on the tool. What is more important is the concept behind the tool. Kanban is a great way to create a pull system, but there are others; drum-buffer-rope and CONWIP are a couple. Kanban seems to be the one that’s easiest to explain, and the one that caught people’s imagination, but really its about Pull.
  • Flow. Given the first concept is Pull, and we should flow where we can and pull where we must, then I think Flow comes under the concept of Pull. What I tended to find myself talking about with Flow, however, was what should flow. There’s not point having a pull system where work flows smoothly if the work is useless, so the second concept is really about Value.
  • Cadence. Having identified Cadence as a Aspect, it can’t really be a concept as well. I talk about Cadence as a means of achieving predictability and reliability and of demonstrating capability. Cadence is just one way of doing this however, so the third concept is really about Capability.

So instead of KFC Development, I have moved to thinking of a Kanban System as a PVC System – one which exemplifies Pull, Value and Capability, and that can be described in terms of workflow, visualisation, work in process, cadence and continuous improvement. I quite like the ‘plasticity’ metaphor that springs to mind with this new triad; “the capability of being moulded, receiving shape, or being made to assume a desired form”. Its probably not very environmentally friendly though!

For me this also leads to the question of whether a process (such as, for example, Scrum) is a PVC System. That’s the subject of another blog post though!

VN:F [1.9.22_1171]
Rating: 4.4/5 (7 votes cast)

Kanban, Flow and Cadence – Russian Translation

Aleksey Goncharenko, a Project Manager at Flexis Corporation, has translated my Kanban, Flow and Cadence post into Russian. If you can read Russian, you can find it here!

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

Skills Matter Slides and Video Available

The slides from my Kanban, Flow and Cadence presentation at Skills Matter are now available for download, and the video of the session is also available for viewing.

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

Lean & Kanban Miami 2009 Videos Available

This is the announcement from David Anderson on his blog:

After some delay while we arranged for hosting, the videos from the Lean & Kanban 2009 conference in Miami are now available.

I need to thank InfoQ for making all of this happen. As a media sponsor, InfoQ intended to use these videos together with the presentation slides on their own site. However, the videographer didn’t follow their format instructions and the result was that they couldn’t use them. So after some editing and cleanup they donated them to the community – in this case the Lean Software & Systems Consortium.

As a sponsor of next year’s Lean Software & Systems Conference, Software Engineering Professionals (SEP) kindly offered to host this year’s videos.

View now!

In particular, I’d like to highlight the video of my Kanban, Flow and Cadence presentation.

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

Kanban, Flow and Cadence News

I did a re-run of Kanban. Flow and Cadence at miniSPA yesterday after being selected as one of the best sessions from the main SPA conference this year. I’ve just uploaded the slides on my downloads page. I had some good and appreciative feedback, and Mark Stringer has bee good enough to post some of his thoughts. I’m always glad to get this sort of feedback as it helps me understand how well I am explaining myself, and improve future presentations.

I have also recently agreed to do session at Skills Matter in London on the evening of July 30th – please sign up. This is the start of what I hope to be series of events jointly organised by Skills Matter and the London branch of the Limited WIP Society. While most of the ideas I will talk about remain the same, I am going to spruce up the slides and base them on the talk I gave in Zurich. The original version of Kanban, Flow and Cadence is nearly a year old now, and is refusing to die, so I’m keen to bring in some of my latest thinking.

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

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)

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

kanban-board
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.

mmf-card

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.

metrics-week-2

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.

dice-weighting

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.

cfd-week-13lead-time-week-13throughput-week-13

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

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)

KFC Consequences

One of the regular questions I get asked when I talk to people about KFC Development is about how it is different.  As a result I came up with a set of KFC Consequences to try and help articulate this.

  • Kanban Consequence – Eliminate backlogs, timeboxed iterations and estimates.

Eliminate might be a slightly strong word, but there is certainly less reliance on these things, and thus less wasted investment in them.  Ultimately a high performing team would not need them in a typically recognisable form, although they may use variations.  For example, an ‘incubation area’ might replace the backlog as a simple place to keeping ideas before they are refined into MMFs.  Similarly, classification might replace estimation.

  • Flow Consequence – Use larger, value focussed features

Rather than an emphasis on driving user stories into smaller and smaller pieces, there is more of an emphasis on right-sizing pieces of work based on their value.  User story decomposition is used more as an analysis technique.

  • Cadence Consequence – Commitment via measurement and SLAs, rather than planning and timeboxes.

Instead of planning batches of work into timeboxed iterations as a mechanism drive productivity and commitment, the mean lead time of MMFs is measured and used as an SLA against which due date performance is reported.  Thus it is actual performance which drives productivity, rather than forecast performance.

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

KFC Development

I’ve been referring to my latest thinking on development process as KFC Development. Its a bit of a gimmicky name, which makes it memorable, but there is some meaning behind it. KFC stands for Kanban, Flow and Cadence – three lean concepts which I think are important and complementary.

Kanban – Kanban is the mechanism which controls the workflow and helps manage inventory and investment, and identify bottlenecks.

Flow – More specifically One Piece Flow. The one-piece is a Minimal Marketable Feature (MMF) which ensures there is focus on the delivery of actual value. This avoids the temptation to artificially break work down into smaller chunks in order to fit them it into an iteration or sprint. A side effect of this flow, is that typical agile time-boxed iterations can become unnecessary.

Cadence – Cadences give the team the rhythm usually provided by time-boxed iterations. There can be a variety of cadences, from daily stand-ups, to quarterly roadmap planning. An additional cadence is that defined by cycle-time, which determines throughput, and allows a level of forecasting of future work.

I’m hoping to explore these ideas more in the future.

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