Different processes have different levels of safeguards built into them. Safeguards are used by processes to compensate for low skill, low maturity or low trust, but they also reduce speed or reward. With a waterfall process, the heavy up-front documentation is a safeguard to compensate for low trust (and often low skill and maturity). When a customer does not want to collaborate, then waterfall provides safeguards aimed at avoiding them rejecting the final delivery (not that those safeguards always work!). At the other end of the spectrum, extremely productive teams often have very few safeguards because of the high trust, collaboration and capability. Those safeguards that are in place (such as automated tests) are very different. Not having safeguards doesn’t make the process dangerous. It means that team doesn’t need them. So when we talk to customers about process, we can talk about the appropriate safeguards needed for the amount of trust that exists, the capability of the team, the desired delivery speed etc.

While exploring this idea, I became aware that at various points I was referring to kanban at different places on the safeguard continuum. At the high safeguard end was a kanban based process that looked like waterfall, but was limiting WIP and reducing queue and batch sizes. At the low safeguard end was a kanban process with extremely low WIP, no estimation and pure pull. That’s quite a wide range of processes. Similarly, we had Scrum down as a range on the continuum. Towards the high safeguard end, Scrum-but changes Scrum to add safety. Towards the low safeguard end, a highly productive Scrum team will just be using the raw essence of Scrum. Even at this end, however, the Sprint boundary in Scrum could be seen as a safeguard. It’s the opportunity to pause and reset if things are going awry.

In trying to articulate the different types of kanban system in terms of safety, I gave a nod to XP and labelled low-safety kanban “Extreme Kanban”, and high-safety kanban “Safe Kanban”. Not entirely happy with this we bounced some more ideas around and came to the Ski Slope metaphor. “Extreme Kanban” became “Black Kanban” and “Safe Kanban” became “Blue Kanban”. A further iteration led us to “Off Piste Kanban” and “Nursery Kanban”. The ski slope metaphor works quite well at a number of levels. Its a nice way of looking and risk and reward. As a beginner at skiing I don’t want to take much risk, but can get some reward on the nursery slopes. As my capability improves, and as I trust my ability (and instructor) more, I’m prepared to go onto more difficult runs and take more risk to get more reward. Nursery slope groups are generally more controlled, staying in a single file group. As capabilities improve, individuals are given more freedom to try things out for themselves. If I were ever to become an expert, I’d be happy to go off piste to get a high reward. Additionally, when I get to a level where I go off piste, I probably don’t need an instructor anymore, but I may need a guide.

Using the ski slope metaphor allows us to decide what level of process to start a new team with based on how good they currently are. We may want to stretch them a bit, but we may not want them to go straight onto a black run process. We also want the team to be able to move up to more challenging but rewarding levels as they improve. This is one of the reasons I prefer a kanban based approach. I believe it allows teams to start with an safer process to begin with and move to more rewarding processes later by removing or changing safeguards, as opposed to pushing teams straight into a process with less safety before they are ready.

The Primary Practices of Kanban that I describe, are not Boolean practices that teams either do or don’t use. Rather they are practices that teams should be constantly revisiting, and re-implementing, as they improve and their context changes. To recap, the primary practices I talk about are:

• Map the Value Stream
• Visualise the Value Stream
• Limit Work in Progress
• Establish a Cadence
• Reduce the Kanban Tokens

I currently describing these practices as like trail markers on the team’s journey of process improvement. At any point in time, the team’s Value Stream, Visualisation, WIP Limits, and Cadence identify where the team currently is, and when combined with Kanban Reduction, point the way forward. As when on a hike, only the group knows where it is, and only the group can decide where it should be going. The hiking group must work together, helping each other out and making sure that everyone reaches the destination. If you’ve read Eli Goldratt’s “The Goal” you’ll recognise the comparison to the one he uses.

Where the analogy breaks down is that a team’s trail markers are only ever unique to that team. They cannot be followed by other teams. Instead, they will only show the journey the team has been on in their quest for success.

1. Decide and agree on an Outcome, in terms of working software
2. Use daily Sync Steps to decide how to best achieve the outcome

Since we had that discussion (which also touched on GTD), I have found that this a great a way of describing the essence of Agility. Inevitably it has also triggered thoughts on ways of comparing and contrasting Kanban with more traditional Agile methods such as Scrum.

In a Scrum based approach, the Outcome is defined by the Sprint Goal, with the Sprint Plan being a means of making a commitment to the Outcome. There is a single Outcome, which is constrained by the length of the Sprint. The Sync Steps are provided by the Daily Stand Up Meeting.

In a Kanban based approach, the Outcomes are the limited work items in the system. There can me multiple Outcomes in progress at a time, but the WIP limits constrain the Outcomes. Planning, and as a result any commitment (or SLA) on the Outcomes is done per Outcome, and Just In Time. The Sync Steps are usually provided by the same Daily Stand Up Meeting, but could also be formed by other forms of Cadence.

So both Scrum and Kanban focus on team Outcomes, with regular Sync Steps to achieve the Outcomes. The way in which those Outcomes and Sync Steps are managed are different.

(*) Unfortunately, I don’t have a reference to this paper. If you recognise it, please let me know!

Update: Jeff actually calls them SynchSteps. References can be found in this 2001 paper, and in early emails. He also refers to Outcomes as Mutations.

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?

This event will take place at Red Gate Software, Newnham House, Cambridge Business Park. See the location map for Red Gate Software.

BOOK NOW for this event. Tickets (including light buffet) £15 if booked on or before 16th November, £25 thereafter. Places strictly limited.

Monday

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

Tuesday

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

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

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

I’m also really pleased to have been invited to speak at the Scan-Agile conference in Helsinki, where I’ll be talking about Five Steps to Kanban. Here’s the abstract.

A Kanban System for Software Development provides an alternative means of creating an Agile Development process using Lean Thinking. Creating a Kanban System is not as simple as adopting a previously defined process as a starting point. Instead, a team needs to come up a model of its own process which will form the basis for further continuous improvement. This talk will introduce 5 steps that a team can use to create their own Agile process using a Kanban System for Software Development.

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.

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.