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.

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

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.

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

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.

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

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.

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

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.

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

Isn't Kanban Just a Task-board?

While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board, or team-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?

A Kanban System visualises some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualising the current tasks.

A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.

A Kanban System deals with these units of value through the whole system, from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.

By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.

A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.

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

Anxiety or Boredom Driven Process Improvement?

At the SPA conference recently, Joseph Pelrine talked about “Flow: The Psychology of Optimal Experience” by Mihalyi Czikszentmihalyi. The ideas behind this struck a chord with me as a way of describing something I originally said when discussing whether kanban is only suitable for mature teams. That is that rather than focusing on being Agile which may (and should) lead to being successful, Kanban focuses on becoming successful, which may lead to being Agile.

Mihalyi Czikszentmihalyi describes the state of Flow as having a balance between ability, and the skills required for a piece of work. If some work requires more skill than a person has ability, then they are in a state of Anxiety. If a person has more ability than the skills required for a some work then they are in a state of Boredom. Applying this to Process Improvement, we want to move teams up the Flow Zone so that skills required and ability increase equally.

Flow1

Increasing Skills and Ability equally at the same time is unlikely, so in practice there are two routes to move up the Flow Zone. The first is what I am dubbing “Anxiety Driven Process Improvement”. Move a team into a state of Anxiety such that they need to improve their skills to cope. I assert that this is the approach that makes time-box based method so effective. Time-boxing forces teams into a place where they need to improve their skills in order to deliver working software every few weeks. Many teams push back, and a common approach to this is to make the time-box shorter to emphasis the point! The other route is to do “Boredom Driven Process Improvement”.  Highlight to the teams where they need to improve their ability, and allow and support them in doing so such that they are able to taken on work requiring more skill. I further assert that this is the approach that kanban systems take. Visualising queues and work in progress in order expose the bottleneck where the ability needs improving.

Flow2

This might sound like I am suggesting the time-boxing and kanban are mutually exclusive approaches. That isn’t the case – I have already said that! Instead, I just find it an interesting angle to look at a different dynamic between two approaches.

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

Kanban and Time-boxes

I had a brief exchange of tweets with Ron Jeffries, Keith Braithwaite and James Shore after the Miami Lean and Kanban Conference ended regarded Kanban and its compatibility with XP and time-boxes. Unfortunately I wasn’t able to follow up immediately, due to an urgent (and eventful) trip to South Beach :) Rather than try and follow up late on twitter, I’ve decided to post my thoughts here to try and clarify my ideas.

The discussion started following a tweet about Kanban being easier to introduce than Scrum. This seemed to be a common theme at the conference, with several experience reports confirming what I have already written about whether Kanban is only suitable for mature teams. This led to the question of how much change (or not) a Kanban approach requires, which is where I jumped in.

A kanban approach introduces tools to visualise and measure queues and work in progress. While this is a change in process measurement, it doesn’t change the process itself. However, having highlighted the existence of queues and work in progress, it becomes easier for the process to be changed to specifically fix the issues highlighted. Thus a Kanban system sets a team up to begin continuous improvement. Time-boxing, used by XP and Scrum, is one way to manage queues and WIP, which is why they can be such effective processes, and why shorter time-boxes are becoming more popular. There are other ways of managing queues and work in progress, however, and thus Kanban is agnostic to time-boxing. This does not mean that XP is Kanban system however, because XP implicitly, rather than explicitly, manage the queues and work in progress.

Further benefits of time-boxing are the focus that they give, particularly given the finite or limited resources (i.e. people) within a team. Time-boxes give this focus not only by limiting the work-in progress, but also by setting the end of time-box as an SLA for when the work will be completed. Again, Kanban doesn’t lose these benefits, but provides for alternate means to limit work in progress and set SLAs.

To summarise, I believe that a Kanban approach is compatible with XP and Scrum in that it has a focus on managing queues and limiting work in progress, but also introduces alternate ways to achieve these goals which can be used alongside the XP and Scrum tools such as User Stories, TDD and Retrospectives.

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

Announcing the Formation of the Lean Software & Systems Consortium

I’m incredibly honoured and excited to have been able to be a founding member of the Lean Software & Systems Consortium which was announced today at the Lean & Kanban Conference in Miami. I hope that this is a significant venture which will have a major impact on the software development industry.  Further information can be found in the press release, which I have copied below.

Announcing the Formation of the Lean Software & Systems Consortium

Consortium to Promote Lean Software & Systems Thinking For Software Intensive Enterprises

SEATTLE, WA., May 6, 2009 / PRNewswire. The Lean Software & Systems Consortium (LeanSSC) was formed today to assist enterprises that depend on software – from start-ups to those that build complex, software intensive products, systems & services – with the application of Lean Thinking throughout the enterprise.

LeanSSC is a global, non-profit organization whose mission is to promote professionalism and create awareness of lean science and associated competencies by creating and promoting a body of knowledge and an associated certification program. This body of knowledge will be organized around three elements of Lean Thinking – lean science, lean management and lean education.

LeanSSC will assist organizations in applying Lean Thinking to reliably deliver business value, adapt to changing market conditions, manage risk, improve predictability, increase flexibility and reduce variability – with the clear goal of substantively increasing the ROI of their software investment.

Founding member David Anderson noted, “It has been recognized for over 30 years that the role of management is the most significant leverage point on the economic performance of organizations that depend on software. During this period, management practices have not kept pace with innovations in software and systems development processes. The LeanSSC will bring Lean Thinking to bear on the organizational problem of creating software economically by providing a framework for better decision making and policy setting at all levels of the enterprise. We believe Lean Thinking adds value not only to individual contribution such as development, testing and analysis, but also to all levels of management.”

Other founding members also commented on the formation of the consortium:

“Lean Thinking brings an organizational solution to an organizational problem. I look forward to the LeanSSC making a substantial contribution to the industry.” – Dean Leffingwell

“The LeanSSC will help create a foundation of knowledge and foster a Lean Thinking paradigm shift that will greatly increase professionalism and improve outcomes in the software development industry.” – Alan Shalloway

“Enterprises building systems of significant scope have become increasingly lean, but not yet been able to engage its software development in this transformation. The LeanSSC provides the first practical mechanism to integrate software development into the lean enterprise.”
– James Sutton

About Lean Software & Systems Consortium

Based in Washington, USA, LeanSSC is non-profit consortium comprised of corporate members, academic institutions, and industry leaders who share the belief that understanding and application of the science of lean will be of great benefit to software intensive industries. LeanSSC’s mission is to promote professionalism and create awareness of lean science and associated competencies by creating and promoting a body of knowledge and an associated certification program.

The consortium is committed to community, communication and education and will be hosting Lean Software & Systems Conferences in Atlanta, GA and Europe in 2010.

Founding members of the consortium include David Anderson–David J. Anderson Associates, Alan Shalloway and Alan Chedalawada–Net Objectives, Dean Leffingwell–Leffingwell, LLC., Don Reinertsen–Reinertsen & Associates, Karl Scotland–EMC Consulting, Rob Hathaway–IndigoBlue, James Sutton–Lockheed Martin, Mike Cottmeyer–VersionOne, Peter Middleton–Queens University @ Belfast.

Information on the consortium will soon be available at www.LeanSSC.org. For further information, contact David Anderson at dja@agilemanagement.net.

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

Calendar and Download Updates

I’m pleased to have been asked to give a Lean and Kanban 101 talk at the Swiss Lean Agile Scrum conference in Zurich on June 4th.  I have added details to my Calendar page.

I have also now uploaded the slides from my “Kanban, Flow and Cadence” presentations at SPA and ACCU to my Downloads page.

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