How We Do the Kanban Method

May 28, 2013 — Posted by Al Shalloway

Sorry to be pushing back the 100 in 100 project but hopefully the readers of that will find this blog just as interesting.  If you are not familiar with Kanban, you should get familiar with it. It is one of the most exciting things to have happened in the Agile space.  See my article De-Mystifying Kanban for a brief introduction.

I have been involved in an interesting discussion on the Kanban Dev group (a great place to go to engage in discussions about the Kanban method).  I wrote up a description of how we (Net Objectives) does Kanban.  This is an appropriate paraphrasing of it.  Though it might be of interest.

To summarize our approach to the Kanban Method, and trying to be a bit clearer:

  1. Start where you are
  2. Create visibility by making a Kanban board
  3. Establish explicit workflow policies
  4. Determine if the Kanban Method is appropriate (I’ve sometimes veered away from it at this point and done more of a pure lean flow approach where we mapped out an approach that was based on swarming, not WIP limits).  This determination is often made based on who should pull the work.  Sometimes the folks doing the work now are not organized correctly and the value stream mapping makes this apparent.
  5. If Kanban Method is appropriate, establish WIP limits and a pull mechanism if it is not in place already
  6. As move forward look for opportunities to:
    1. Load balance
    2. Redo flow to reduce delays in feedback, error detection
    3. Have  folks work together
  7. Take these opportunities as they seem appropriate and validate improvement in flow/quality/discovery
  8. Repeat steps 4-7

A note about #4.  These seem to fall into two camps.  One is a significant change in the manner work to be done is initiated by the business stakeholders.  Improvements here can have dramatic affects downstream.

One of my favorite quotes is by Eli Goldratt: “Often reducing batch size is all it takes to bring a system back into control.”  By focusing on minimum business increments, this is often achievable.  The other camp is to improve workflow directly by changing how work is done.  This is often a dramatic change and most often involves changing the order of the work or who pulls the work.  We then do continuous improvement a la Toyota Kata. I would not suggest what was happening in these cases was the Kanban method.   In our practice we don’t really make such a distinction though, whether it is Kanban Method or Lean – that appears to be arbitrary.  But I am wanting to honor the distinction being made on this group.

Regardless of what happens in step 4, our focus is on delay as we believe that is the main problem.  Limiting WIP reduces delay, and is a great proxy for process improvement.   But I believe these four types of delay is what causes virtually all of the waste in software development:

  1. From when information is obtained until it is used (e.g., getting requirements too soon)
  2. From when an error is made until it is detected (e.g., delayed testing, delayed integration)
  3. From when information is needed until it is obtained (e.g., waiting for someone to be available)
  4. Delays in workflow – just stoppage due to an interruption

I would suggest just about every challenge to workflow shows itself up as a delay.  This is the striving for Just In Time of Lean. Limiting WIP is a vehicle for that.   There are other mechanisms (teams, ATDD, continuous integration, small batches).

I believe understanding delay is useful to explain why Kanban works so well.

To me, the power of the Kanban Method is not just improving flow, it is a great example of Toyota Kata (I strongly suggest reading this wonderful book by Mike Rother if you haven’t).

As always, if you have interest in this and want to see how it might help your organization, please contact me.  Always happy to provide a free consult.

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban