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.
In particular, I’d like to highlight the video of my Kanban, Flow and Cadence presentation.
I’ve just activated ratings on the blog. They can be found at the bottom of each post on their indivual permalink pages. If you have the time and energy, please find your favourite (or most hated) entries and rate them. Feedback is always good
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.
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.
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.
There has been a lot of talk recently about whether Kanban Systems for Software Development include the need to respect people, and allow self organisation and continuous improvement. It is true that the community has primarily focussed on the mechanics of Kanban Systems. I believe that this is because it is the mechanics that are the differentiating factors, and thus generally the most interesting to discuss. However, we should not forget the human factors, as they are inherently part of the Lean Thinking from which Kanban directly descends. This post is an attempt to try and redress the balance by showing how the five primary practices should enable the right behaviours.
A Kanban System should respect people by allowing them to take ownership of process decisions. Mapping the value stream sets up a team where everyone who is involved in creating value is recognised and respected equally for their role. Visualising the value stream enables a team to decide for themselves how best they want to manage the work. Setting work in progress limits gives the team a mechanism to manage their work/life balance effectively and avoid having more work pushed onto them than they have capacity to deliver. Establishing a cadence gives the team a way to create a rhythm which is natural and works well for them. Reducing the kanban tokens guides the team in creating their own process in order to allow the work flow. All these practices are about the people on the team having discussions and making decisions which work for them. They are not about the team having decisions made for them by managers.
By allowing the team to take ownership of all the process decisions described above, a Kanban System automatically empowers them to self organise and continuously improve all the elements of the process. The primary mechanism for enabling this self organisation and continuous improvement is making the work visible. The whole value stream is visualised so that the whole team can see where the problems are and where the improvements are needed. Limiting work in progress makes the bottlenecks or constraints even more visible, and will ultimately shut down the system so that the team has to self-organise fix the problems. The team’s cadence provides a regular rhythm to reflect on the whole system, alongside the spontaneous quality circles and kaizen events triggered by the visualisation and limits. Self organisation and continuous improvement are therefore crucial if the team are to successfully refine the process such that they can reduce the number of kanban tokens and allow the work to flow more freely.
A Kanban System is more than just a basic tool to be used to manage the work. It is a way of working which frees people to think for themselves in the pursuit of achieving success through improved productivity and quality.
I recently wrote what I considered to be the four primary practices of a Kanban System for Software Development:
- Map the Value Stream
- Visualise the Value Stream
- Limit the Work in Progress
- 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:
- 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.
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.
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:
- 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.
- 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.
- 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.
- 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.