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)

Kanban, Flow and Cadence


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


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


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 (24 votes cast)

Page Updates

A couple of page updates for the blog:

Calendar – I’ve added two new upcoming conferences that I’m going to be speaking about “Kanban, Flow and Cadence” at.  They’re XPDay08 and SPA2009.

Kanban – I’ve created a new page to pull together various references on Kanban for Software Development.

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

Agile Business Conference 2008 Review

The conference was opened by BBC’s Ian Palmer, who also hosted Day 1, and he began by making the analogy between delivering a software project and delivering a news story.  There is a deadline, and a budget, but at the end of the day, its the story that’s important.

Keynote: Peter Morowski – Senior VP R&D Borland – Driving Agile Transformations from the Top Down

Peter talked about how Agile helped ‘bind’ together management and execution ‘planes’ of projects as opposed to simply ‘bridging’ them.  For example, frequent releases directly enables better market timing, customer involvement directly boosts quality and efficiency and ensures the right product is built, and demonstrations directly enable transparency and instil confidence.  His blueprint for an agile transformation is:

  1. Establish a Foundation – herd the converted
  2. Build Confidence – Guide the Curious
  3. Socialise Change – Win over the Sceptics

His results so far have delivered 100% improvement of on time delivery, smaller product teams, increased and higher moral.

Agile Development – Enterprise Delivery

This session was about delivering and large enterprise project with Agile.  My one line summary would be that the presenters showed that it is possible by using the usual tools and techniques with discipline.  Their ‘pillars’ were:

  • Risk first, architecture-centric approach
  • Quality built in
  • Monitor & Control
  • Frequent, Demonstrable Milestones
  • Development Processes & Tools

A couple of other ideas that stood out were the ideas of design documentation being a TOC into the code (necessary and sufficient) and the differentiation between a requirements catalogue and requirements detail.

The Battle of the Somme to the Present Day: Lessons in Agile

This was an interesting session which looked at various successful military leaders and battles and drew analogies between which ones were agile, and which ones weren’t.  Not surprisingly, the successful examples were agile, and the others weren’t.

Keynote: Rob Thomsett – Implementing Agile Project Management and Development – Key Learning from the Real World

A very entertaining talk.  Rob began by suggesting that Agile is primarily a cultural revolution, which I agree with.  He compared traditional engineering and construction culture, with an agile culture:

Traditional            Agile
Closed                 Open
Distrust               Trust
Dishonesty             Honesty
Lack of Courage        Courage

He then introduced Agile Project Management (APM) and its principles:

  • Simplicity
  • No Bureaucracy
  • Light Touch
  • Face to face over paper
  • Discretion

Finally, he talked about Rapid Planning Sessions (RAPS) which include a set of tools such as success sliders which can help make sure everyone has the same understanding of the project.  This sounded interesting and is something to look into more some time.

Keynote: Jutta Eckstein – Staying Agile in a Global World: Distributed Agile Software Development

Jutta began by describing some non-agiel specific research which had concluded that distributed projects worked best when there was:

  • Personal relationships
  • High Communication
  • High Trust
  • Bridging of Culture Gaps

Given that these are strongly aligned to Agile values, it can be concluded that distributed projects need Agile! She went on to talk though a list of tools or ideas she had found to be useful in her experience:

  • Don’t have a “remote side”.  Vary meeting locations and be wary of language e.g. if there is a “nightly” build, who’s “night” is it?
  • Prefer location feature teams, but its not essential.  They can be dispersed feature teams, which has the advantage of enabling cross team communication at each location.
  • Communicate with the highest available “common” bandwidth.  If one person or group is on the phone, then everyone should be.
  • Encourage discussion of common interests across locations e.g. weather, sport.
  • Have a Communication Facilitator role
  • Have location Ambassadors, who represent locations in other offices
  • Short iterations for quicker feedback
  • More frequent integration – typically 10% should be spent on integration between locations
  • Use a retrospective of retrospectives to scale the continuous improvement

Keynote: Chris Avery – Personal Agility and your Ability to Respond

Chris talked about the difference between the dynamics and the mechanics of agile, where the dynamics is the culture.  He suggested that the greatest opportunity to add value isn’t assigned to anyone, because it usually sits between groups.  He also differentiated between accountability and responsibility, where accountability is an external agreement, and responsibility is an internal ownership.  the best results come when responsibility is greater the accountability.  Chris’s model for responsibility takes the follow path upwards:

  1. Responsibility
  2. Obligation
  3. Shame
  4. Justify
  5. Blame
  6. Denial

His “Keys to Responsibility” are:

  • Intention
  • Awareness
  • Confront (as in face up to)
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Agile Business Conference 2008

I’m going to be at the Agile Business Conference this week, primarily to give another performance of “A Manager’s Guide to Test Driven Development” with Dave Nicolette.  I’ll try and blog highlights here again, and if you’re there, please say hello.  I’ll be looking for any opportunity to talk about Kanban I can find!

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

My Recipe For Success

I’ve been doing more introductory Agile and Scrum training recently, and have been thinking about the best way to get across the core ideas that underpin Agile.  I find the Manifesto Values a bit too woolly, and the Principles too wordy, to be immediately meaningful.  At the same time, David Anderson has blogged again about Recipes for Success.  I’ve decided that what might be useful would be to put describe what I believe to be the core ideas as my own recipe for success and this is what I’ve come up with.

The Power-Point version is:

Deliver a steady flow of successful and valuable software, by
Empowering collaborative, trusting and motivated teams,
Responding to feedback and adapting to change, and
Building quality in from the start.

The t-shirt version (if I ever designed a t-shirt) would be:

Deliver Frequent Releases
Empower Teamwork
Inspect and Adapt
Build Quality In

That’s not too different to what David has written about (not that surprisingly) but I think there are some subtleties that may be worth commenting on.

For me the primary goal of Agile is to deliver features and value early and often.  The other three points are means to that end, but are significantly part of being Agile that they are worth bringing out.  That’s why I chose the “A, by X, Y and Z” format.  I can’t imagine a good way of delivering software that isn’t early and often, so that on its own may not be what Agile is.  Agile is how we deliver early and often, and teamwork, feedback and quality are the main areas I focus on when working with teams.

Some things I haven’t explicitly mentioned are prioritisation, reducing WIP and balancing demand against throughput.  These are things are believe are important, and particularly apply to kanban systems, but at the end of the day I decided that they are more ideas and skills which will come out when teams inspect and adapt to deliver quality releases early and often.

What do you think?  Have I missed anything important?

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