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?

Evolving a Workflow

Mary Poppendieck gave a talk on Workflow is Orthogonal to Schedule at Agile2009, during which she very neatly transitioned a schedule-focused view of work, into a flow-focussed view. At least I thought it was neat, so I’m going to try and reproduce the basic elements here, using my favourite agile workflow.

4 Week Time-box Schedule


Here we have a schedule showing an average of 4 features being delivered every 4 week time-box. Each time-box is preceded by 2 weeks understanding the next features, and a release is made every 8 weeks. Its not a bad schedule. There’s a regular release every two months which is better than a lot of projects, but it could be better.

2 Week Time-box Schedule


Now we reduced the time-box to 2 weeks, meaning that we do an average of 2 features in each time-box. This means that the preparation now takes only 1 week. Additionally, we are now releasing at the end of every time-box, which is also reduced to 1 week. Much better.

One Piece Flow


If we continue the evolution we end up working on a single feature at a time and releasing it immediately. Each feature only takes a week to build, and preparation and release times are now down to 1/2 a week. At this point, we don’t really have a schedule anymore, but a natural workflow.

Cumulative Flow Diagrams

One of the things that strikes me about the diagrams above, is that each step in the evolution transforms them more into a smooth Cumulative Flow Diagram. In fact, in the same presentation, Mary showed the following picture taken from Building the Empire State. This is the building schedule from from around 1930, and itself looks remarkably like a CFD. Another example of how we are not inventing anything new, but can learn from other industries and successes.


#lkuk09 – A Tweetrospective

I ended up making notes at the Lean & Kanban UK Conference with good old fashioned pen an paper. Rather than try and write up those notes into something coherent and meaningful, I have decided to write them up in the style of a twitter stream. These are the things I would have tweeted if I’d been on my laptop. The quantity of “tweets” in no way represents the quality of the presentations. I also make no promises that all of the following “tweets” are actually <= 140 chars!


Mary Poppendieck – The The Tyranny of the Plan

  • Plans – what did construction do before computers?
  • Eliminate design loops by consulting experts early
  • Design for decoupling workflow
  • Cash Flow Thinking – Cost of Delay
  • Design based on constraints of situation
  • Establish a reliable workflow 1st
  • Schedule is orthogonal to workflow
  • Build schedules based on experience, not wishful thinking
  • Variance from plan is a learning opportunity, not a performance failure
  • Reliable workflow – output, pathway, connection, method, improvement – Steven Spears, Chasing the Rabbit
  • Polaris Success – Quality of Leadership, Focus on deployment, Decentralised Competitive Org, Emphasis on Reliability, Esprit de Corps

Alan Shalloway – Creating a Model to Understand Product (and Software) Development

  • 3 types of value: Discover what a customer needs, Discover how to build it, Build it

Jeff Patton – Lean Product Discovery

  • There is a difference between Delivery & Discovery
  • Undelivered software is a solution hypothesis (usually incorrect)
  • Include discovery in the VSM
  • Market demand = pull (but is post delivery)
  • “Lets go to marble”
  • Discovery Kanban + Delivery Kanban
  • Visualisation creates collaboration
  • Storyotype 1: Bare Necessity – minimally demo-able
  • Storyotype 2: Capability + Flexibility – options-
  • Storyotype 3: Safety – invisible
  • Storyotype 4: Usability, Appeal, Performance – differentiating
  • Chess analogy – Opening Game, Mid Game, End Game
  • Use options when cost of iteration and failure is high

John Seddon – Re-thinking Lean Service

  • If you manage costs, costs go up
  • Failure demand is a signal
  • Incentivising workers get less work done
  • Predictable failure demand is preventable
  • Lean is getting a bad brand
  • The only plan is to get knowledge
  • Improve flow – walk the flow
  • Pull the help, keep the work
  • Do “productivity” tools improve productivity?
  • Make them curious


Don Reinertsen – Second Generation Lean Product Development: From Cargo Cult to Science

  • Understand causal relationships and salient phenomena
  • Scientific v Faith (Science Free) based approaches
  • Faith based = Cargo Cult
  • Every system has Push / Pull interfaces
  • No bad tools, only wrong times to use them
  • In Product Development, Requirements are a degree of freedom
  • Inventory is information and invisible (physically and financially)
  • Agile practitioners are going a better job at LPD than LM practitioners
  • In engineering we are making economical (Profit + Loss) decisions and we have no clue what we are doing
  • Quality = Process x People – If either drops to 0, the quality of the result will drop to 0
  • Don’t tolerate initiative – demand it
  • Chief Engineer doesn’t know better than the customer

Kenji Hiranabe – Learning Kaizen from Toyota

  • Balance process control and process improvement
  • Management fosters human potential
  • Go to the gemba != PowerPoint
  • To know and to understand are different
  • Think within your constraint

Hal Macomber – Lessons from Target Value Design

  • Meld planning with execution + control
  • What signals do we pay attention to?
  • Articulate + activate the network of commitment
  • Only start work when it is in the condition to be finished.
  • Embrace the contradictions of Lean
  • Focus on tool users, not the tools
  • PDSA – Study, don’t Check
  • Creating constraints creates innovations
  • Create constraints so that we can do our work
  • Don’t open the trenches until you know you can fill them

Marc Baker – Lean Thinking: what is distinctive about it and where it is going?

  • Pull means take the payment first
  • Visual controls mean that nothing is hidden
  • Standardised tasks are the foundation of employee autonomy
  • Go see, ask why, show respect

XP As A Kanban System

During recent discussions with XP folks on the topic of Kanban, it occurred to me that based on my understanding, XP can be described in terms of a Kanban System for Software Development. This is an attempt to do that, on the basis that it might be useful in helping teams understand Kanban concepts. I have structured the description around the five primary practices of Kanban that I have previously blogged about.

1. Mapping the Value Stream


Here’s an example of an XP Value stream

  1. A customer comes to the team with a problem they want solving, and collaboratively they write a set of User Stories
  2. The team then holds an Iteration Planning meeting to prioritise which User Stories they believe they can deliver within the next iteration (which is 2 weeks in this example)
  3. The team then pick the first of those User Stories, and plans how they will build it.
  4. They build a User Story (using good engineering practices)
  5. When the team has something to show, they review progress with the customer. In this case, every 2 days on average. I assume that the team will be collaborating with the customer more often than that, but am not showing that level of feedback for simplicity. Reviewing a User Story may result in re-planning and re-building (iterating). Completing a User Story will trigger another User Story being planned and built.
  6. At the end of the Iteration, the customer accepts all the completed User Stories. At this point the User Stories are re-prioritised again and another set chosen for the next Iteration.
  7. At the end of the Iteration, the software may also be released, and more User Stories may be written.

In practice, the workflow is not this precise, but I think its a close enough approximation. For example, new User Stories could be written at any point.

2. Visualising the Value Stream

XP Visualisation

An XP teams may use a very simple visualisation such as the one above, which focuses on the Plan-Build-Review section of the Value Stream. The User Stories (yellow) chosen for an Iteration are initially not started. When they are planned, then tasks (grey) are added, and the tasks are working on until they are all done, and the User Story is Done.

3. Limiting Work in Progress


An XP team will limit work in progress by working in pairs, with each pair only working on a single User Story at a time until it is Done. Thus in the above example, a team of four developers limits work in progress to two User Stories by two pairs.

4. Establishing a Cadence

XP Cadence

XP teams have a very specific and synchronised cadence which is created by time-boxing the Iteration. Prioritisation, Reviews, Retrospection and Releases all occur at the same time interval, and User Stories are planned to be completed within that time interval.

5. Reducing the Kanban Tokens


An XP team is always striving to improve, usually by using retrospectives. As such, in the above example, they may reach a point where all four developers are able to work on the same User Story, and as a result complete it sooner.

Assuming that this description of an XP based Kanban System is not widely off the mark, I hope that it serves to communicate that XP and Kanban are not alternatives, but different and compatible ways of describing a process. Further, I have found that by understanding a process in terms of a Kanban System, it has helped my think about alternative ways of evolving that process in order to improve it. There is of course, more to XP than I have mentioned here, such as release planning, and the usual good engineering practices.

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.

Does A Kanban System Eschew Iteration

There has been some recent discussion on the blogoshpere and twitterverse about the relationship between Kanban Systems for Software Development and the concept of iteration. The often raised concern that a Kanban System is “Waterfall 2.0” came up again, along with the suggestion that a Lean perspective might view iteration as rework, and as a result be waste.

One of the conclusions was that both a Kanban and Time-boxed approach are independent of iteration. I like Jeff Patton’s description of iteration. Iteration is used to find or improve a single solution. Incrementing is used to build up additional solutions.

It is perfectly possibly with a time-boxed approach to define a product backlog based on already decided solutions, and then prioritise User Stories to incrementally build up the functionality for those solutions. I don’t think this is that uncommon. Similarly, a Kanban System could be used to only incrementally build up the functionality for pre-determined solutions.

Done well, both a time-boxing and Kanban approach will prioritise work to generate knowledge and feedback which will help discover or refine solutions. What is really being prioritised in this case is a problem, or an ROI Component (as the Real Options tribe like to call it). This is where I think a Kanban System can help by explicitly managing the work at both levels. The ROI Components, which I prefer to call Minimal Marketable Features, can be prioritised and limited as Work In Progress. The MMFs can then be expanded to candidate User Stories which can also be prioritised, managed and limited in order to iterate the MMF. Eventually, the User Stories will be collapsed back together to actually deliver the MMF as an increment.

Thus a Kanban System can explicitly visualise that MMFs are being delivered incrementally, and are being iterated using User Stories. While this same approach can be used with time-boxes, it will often be implicit.

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.

Does Kanban Respect People, Self Organisation and Continuous Improvement

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.

Lean & Kanban Conferences – Looking back and looking forwards

Its a month now since the Lean & Kanban Conference in Miami and I haven’t had chance to blog about it. There’s probably not much I can add that hasn’t been said elsewhere already. It was an incredible week; stimulating, inspiring, focussed, energising. I learned a lot, and made and met old and new friends. For those who couldn’t make it, the presentations are available for download, and the proceedings book is available to buy. All profits from the proceedings will go towards the formation of the Lean Software and Systems Consortium.

Plans for the equivalent event in London are taking shape nicely. Registration is now open and we have had 40 registrations in the first week so it looks like demand will be high – book early to avoid disappointment! We have a fantastic line-up of speakers confirmed, and the program has now been published. The vision was to create an event which generates discussion and debate with a format that is hopefully a little different from the norm. The mix of presenter talks with interviews is intended to stir up some debate, and the Masterclasses are an opportunity to discuss ideas more interactively with the speakers and fellow attendees – more of a roundtable than a teaching session.

Zurich Lean Agile Scrum Slides

I have posted my slides for the talk I did at the Zurich Lean Agile Scrum event on my downloads page. Inspired by the quality of some of the “Zen” presentations at the Lean & Kanban Conference in Miami, I created a new deck, and included some more slides on some Lean history. I have added some notes to the slides so I hope they have some use for those that weren’t in the room!

The conference closed with a speakers panel, including Ken Schwaber, when the question of “Is Kanban an alternative to Scrum” was asked! Fortunately Ken and I are still friends after the discussion, and the general consensus was that regardless of what we do and what we call it, the primary focus should be on doing the right thing.