A New Lean And Agile Picture

David Harvey posted a brilliant piece on his blog entitled “The Scrum Picture is Wrong”. I highly recommend reading it. His ideas and suggestions for an alternative Scrum picture got me thinking about how to visualise Lean and Agile software development in a process or label agnostic way. David’s picture looked like a figure of eight, and there seemed to be 2 inputs (a vision and reality), and 2 outputs (the product and the team). A quick google found me what I was looking for here – a figure of eight with a bar across the top and bottom. “A time sign that according to Diderot’s Encyclopedia meant hour for the chemists in eighteenth century France”. That seems quite appropriate. An hour would be quite a good interval for a feedback loop 🙂

This is what I came up with. A vision and reality come together to produce a product and a team through process and improvement (and process improvement)

Process Picture

Now I just need to find a good label to stick on it…

Is Kanban A Relabeling of Scrum?

Firstly, this post is not an attempt to be divisive or competitive. Instead it is meant to be exploratory. What would it mean for the statement in the title to be true? Actually, the full statement was “People have so misunderstood Scrum, that they’ve reinvented it and called it Kanban”. It was made by Jim Coplien at Scan-Agile, after (but not necessarily the result of) a conversation over dinner where myself and a few others were describing how we used Kanban. Each time we described different aspects of our processes, Jim would say something along the lines of “but I do that with Scrum”.

So what would it mean for people to have so misunderstood Scrum that they have reinvented it and called it Kanban?

  • It might mean that at their heart, Scrum and Kanban have the same intent. That both are really focussed on helping teams think about their processes in order to help them succeed.
  • It might mean that the way that Scrum was originally articulated (and is still articulated according to the latest Scrum Guide) was not as clear as it could have been. That teams might misconstrue the focus on roles, meetings, artefacts and rules.
  • It might mean that there are alternative ways of articulating the same intent. That teams might find alternative articulations valuable.
  • It might mean that Kanban can be equally misunderstood. That teams might be bewildered by a less prescriptive approach.
  • It might mean that we should spend more time on understanding how to help teams solve their problems and less time arguing and fighting over preferred solutions.

These are just some of my thoughts. They do not mean that I think Scrum is bad – just not perfect. They do not mean that I think Kanban is perfect – although it’s currently my first language.  The topic drew a good crowd at the Scan-Agile Open Space and we had a good discussion. What else might it mean?

Balanced Software Development

Agile2009 provided me with 3 sources of ideas which all complemented each other, and which I think make an important point that I want to repeat.

Firstly, on the flight over, I read John Shook’s blog post about his work with Starbucks. In it, he responds to the suggestion that by advising Starbucks on using Lean methods, he is transforming them into a robotic fast food joint like McDonalds. That suggestion sounds similarly like the common claim that Kanban transforms software development back into a robotic process. The piece that stood out for me was this:

Toyota combined old IE Scientific Management principles and techniques with social dimensions appropriate for the modern world. Even workers who do “manual labor” with their hands are knowledge workers. Front-line employees become the scientists.
By redefining roles, Toyota changed the answer to the question of who is the scientist in scientific management.

In other words, Scientific Management is still relevant for knowledge work, when the workers are the scientists. That keeps the balance between the Process and the People.

Secondly, Alistair Cockburn talked about three pillars of Effective Software Development in the 21st Century in his Agile2009 keynote. The 3 pillars are:

  • Cooperative Game
  • Craft
  • Lean Processes

Again, this to me demonstrated the need for a balance between the People and Process focussed elements.

Finally, I attended Jon Dahl’s talk on Aristotle and the Art of Software Development. This focussed on the differing ethical philosophies of Kant, and Mill and Aristotle:

  • Kant looked at the Acts, known as Deontology. This can be equated to looking at Process.
  • Mill looked at the Effect, known as Utilitarianism. This can be equated to looking at Outcome.
  • Aristotle looked a the Actor, known as Virtue. This can be equated to looking at the Participant.

Chatting with Matt Wynne after the talk, we both had the same thought. While individuals will probably sway to one form of these philosophies, there is room for all of them, and again, a balance is good. I would even go so far as mapping the three philosophies on to Alistair’s three pillars.

  • Deontology is Lean Processes
  • Utilitarianism is Craft
  • Virtue is the Cooperative Game

In many of the recent discussion I have seen and been involved in on Lean and Agile, and Kanban in particular, it seems to me that most of the debate is because the various participants are talking from the perspective of one of these pillars or philosophies. We should remember that they are all important, and that achieving the right balance is what is going to help us be successful in delivering valuable software.

Reflections on #Agile2009

I’m just about recovered from Agile 2009, and about to disappear off the grid for a much needed break in the sun. Before I do so, I wanted to jot down my immediate reflections on the conference while they were still fresh.

The conversations in between sessions are always great at the Agile conferences, but this year, I think these conversations were the main highlights for me. I met lots of new people who I’d only previously known online, as well as re-acquainting myself with people who I usually only see once a year. My top 3 highlights were:

  1. Discussing team maturity and explicit and implicit Kanban WIP limits with Alistair Cockburn.
  2. Splitting hairs on the finer points of Lean (Kanban) and Theory of Constraints (Drum Buffer Rope) with Mike Cottmeyer (apparently it was a highlight for Mike as well)
  3. Debating all sorts of ideas around Kanban with Arlo Belshee and Bonnie Aumann – including drawing on beer mats and using beer glasses and other implements to aid visual representation.

As far as scheduled sessions went, Mary Poppendieck gave a good talk on Workflow and Scheduling in which she nicely transitioned from a time-boxed schedule to a kanban work-flow using a form of cumulative flow diagram. Jon Dahl also gave a thought provoking talk on Aristotle and the Art of Software Development, which for me tied in nicely with Alistair Cockburn’s keynote, and some other thoughts I’ve recently had. I’m planning on blogging more on both these topics more when I get back off holiday. See you then…

What is Cadence?

Mark Stringer gave me some good feedback recently, that I clearly hadn’t described what I meant be Cadence at the recent miniSPA conference. In order to try and correct that, I thought I’d try and clarify with a blog post that it not simply variable length iterations.

The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.

Time-boxing is one specialised form of cadence. It’s like a metronome, giving a single tick. All the main process events are based around this single tick, as shown below where the dotted vertical lines represent the Sprint boundaries. In this example, the unit of work is a User Story, and User Stories should be small enough to be scheduled into a Sprint, and subsequently completed in the same Sprint. Stories in Progress are limited to two, as a good Scrum team might, but Stories don’t always fit exactly into a Sprint. Note also, that while releases can happen each Sprint, User Stories are only potentially shippable product increments.


Kanban on the other hand has a cadence which is more like a drummer. The rhythm is more complex than the single tick of a metronome, and can be more varied, as shown below. In this example, the unit of work is a Minimal Marketable Feature, which while needing to be as small as possible, is not constrained be being required to fit into a schedule. Instead, an MMF is able to flow over a number of process events while it delivers some releasable value. Planning, reviewing, retrospection and releasing all still happen regularly, but they are de-coupled. They can happen independently, at differing rates, which may provide more freedom in creating a natural process which enables the team.


A cadence is usually ‘harmonic’, in that there is a neat overlap between the different rhythms, as in this example. However, it does not have to be. A look at some definitions of cadence can show why. These are some favourites I picked off dictionary.com

  • In music, the ending of a phrase, perceived as a rhythmic or melodic articulation or a harmonic change or all of these; in a larger sense, a cadence may be a demarcation of a half-phrase, of a section of music, or of an entire movement
  • Music. A progression of chords moving to a harmonic close, point of rest, or sense of resolution.
  • The flow or rhythm of events, esp. the pattern in which something is experienced: the frenetic cadence of modern life.

Thus cadence is what gives a team a feeling of demarcation, progression, resolution or flow. A pattern which allows the team to know what they are doing and when it will be done. For very small, or mature teams, this cadence could by complex, arrhythmic or syncopated. However, it is enough to allow a team to make reliable commitments because recognising their cadence allows them to understand their capability or capacity.

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.

Kanban Is My First Language

I was chatting with Benjamin Mitchell recently on the way back from the recent Skillsmatter event at the BBC and said something along the lines of, “I think in terms of Kanban, even when I teach Scrum”. I’ve been mulling over that idea more recently and decided that its a good analogy. Kanban and Scrum are just like different languages.

Different languages can all express the same ideas, but each has its own strength and weaknesses which can give a different interpretation. Its also important that when you speak in a language, that the listener speaks the same language. Conversations between two people who speak different languages can be very painful, and often confusing! It is possible to aid communicate by using multiple languages, however, swapping occasional words or phrases when necessary. Similarly, different methods or processes can all be expressing the same ideas slightly differently, which can cause confusion or help communication of those ideas.

I’m not multi-lingual (in the literal sense), but I can imagine that being able to speak more than one language gives a good insight into how languages work, as well as making learning further new languages easier. Knowing the various grammar rules and other such things that I don’t understand is probably very useful in being a better communicator. Similarly, understanding different methods or processes can give us deeper insight into how and why they work, and help us improve further.

However, when I try to speak in another language, I always think in English. I imagine that’s common and that it’s rare even for skilled multi-linguists to switch the language they think in. So using the language analogy, I currently think about software development in the language of Kanban. Its my first language.

The Fifth Primary Practice of Kanban

I recently wrote what I considered to be the four primary practices of a Kanban System for Software Development:

  1. Map the Value Stream
  2. Visualise the Value Stream
  3. Limit the Work in Progress
  4. Establish a Cadence

During subsequent discussions on the aspect of Continuous Improvement in a Kanban System, I decided that there was a missing fifth primary practice:

  1. Reduce the Kanban Tokens

I originally named this practice “Eliminate Kanban”, but was persuaded that this was probably overly sensational, and as a result potentially confusing or misleading. Its intent is that once a Kanban System is in place, the team should be constantly looking to improve it by creating an environment where the work flows naturally. There is a quote that I believe comes from Rother and Shook which says “flow where you can, pull where you must”. By striving to reduce the number of kanban tokens in the system, a team will move towards an environment where they are more self organising and the work can flow. This can be achieved by either lowering the WIP limits or by collapsing the number of distinct stages.

A Kanban Sidebar – Take 2

Back in January, I wrote a Kanban Sidebar for an upcoming book on Agile Coaching by Rachel Davies and Liz Sedley. The book is now out in beta, and I have updated the sidebar as part of the review process. I found it interesting to see how my thinking has evolved over the last few months.

A Kanban System for Software Development focuses on visualising work as it flows through various stages of transformation in a value stream, with limits on work in progress at each point. This enables a team to see bottlenecks and constraints in the system such that they can continually strive to improve the system and increase productivity and performance.

This focus on flow renders task estimates unnecessary, making task breakdown an analysis and design activity. Prioritisation, planning and releasing still occur regularly, forming a natural cadence around each activity. The team no longer estimates what it will deliver within a time-box, instead forecasting how much will be delivered from known cycle-time and throughput information.

A team setting a limit of three features being in progress at a time will concentrate on maximising the flow of those features to completion, while deferring time spent on new features until they have spare capacity. The prioritisation, analysis and planning of new work is therefore triggered “Just In Time”, as opposed to being scheduled with an iteration planning meeting. Prioritisation is based on the teams previous capability to deliver features, weighed against future business goals and objectives.

Kanban is the Japanese word for “visual card” and was the name given to the tool used to operate the Toyota Production System. A Kanban System for Software Development will often use an index card as the kanban token limiting work in progress, and a token might represent a unit of value such as a User Story. A Kanban System is, therefore, able to manage the flow of single pieces of customer value through the development system from idea to release.

How Is Kanban Different From Other Approaches?

There has been a lot of discussion recently around trying to define what Kanban is. Is it a tool? A process? A philosophy? During a discussion on the kanbandev list, Ron Jeffries led me (probably unintentionally) to an idea for a different way of trying differentiate Kanban from other Agile approaches. Rather than attempt a direct comparison and identification of unique differences, I realised that the various approaches are different only in where they place their emphasis. XP places a lot of emphasis on the technical practices. Scrum places more emphasis on the project management practices. Kanban, places its emphasis on business and value flow practices. As Ron would say, its all the same elephant, but each approach has a different view of it. At the end of the day, its having the most appropriate elephant for any given context that is most important.

Using Kent Beck’s distinction of Primary and Corollary Practices in XP (2nd Edition), I think that Kanban can be differentiated by identifying its Primary and Corollary Practices. As such, these practices may not be unique to Kanban, but are considered the most important. High performance Scrum and XP teams will inevitable use these practices in some form, but I don’t consider them to be clearly described as Primary Practices in those methods.

The Kanban Primary Practices I see (at the moment…) are:

  1. Map the Value Stream. A Kanban approach looks at the whole stream of work, from where it enters the scope of the team, to where it leaves. Thus typically, a Kanban system will explicitly include the transformation of work from the problem or idea, through to its release. i.e. Concept to Cash (or Consumption), or Incubate to Liquidate.
  2. Visualise the Work. A Kanban approach will make all the work as visible as possible, across the whole Value Stream. In particular, this includes the visualisation of expanding/contracting, or zooming in and out, of work items to make their value/solution, or other hierarchical relationships visible.
  3. Limit Work in Progress. A Kanban approach will explicitly limit work in progress. This is distinct from managing work in progress through the use if time-boxes as described by David Anderson. This absolute limiting of work in progress is what makes Kanban a pull system, rather than a very small batch push system.
  4. Establish a Cadence. A Kanban approach will create a natural rhythm by setting up a cadence which will help the team deliver. This will typically de-couple the input (planning and prioritisation) from the output (release), allowing more freedom than the time-box, but still providing a framework to release regularly, measure performance and continuously improve.

A Kanban team will almost certainly use Corollary Practices which may be considered Primary in another process. For example, a high performance Kanban team will inevitably use technical practices from XP, such as TDD and Continuous Integration. Other Corollary Practices from other methods might be the use of MMFs and User Stories to manage the work items. Equally Use Case Scenarios and Steps could serve the same purpose. Metrics such as Cycle Time, Throughput, Velocity, Cumulative Flow Diagrams and Due Date Performance are further Corollary Practices which could be used alongside the Cadence. The list is probably endless. The above Kanban Primary Practices set the foundation for a team use whatever other techniques help them be successful.