Extending the Kanban Method - Updated

December 27, 2013 — Posted by Al Shalloway

This blog replaces the earlier ‘Extending the Kanban Method’

I got interested in Kanban around 2007-8.  It seemed to work in places I could not figure out how to get Scrum to work well.  Kanban was created through a combination of efforts by (listed in alphabetical order): Corey Ladas, Dan Vacanti, Darren Davis, David Anderson, and Jim Benson (apologies for any others I’ve left out). With the introduction of David Anderson’s Kanban: Successful Evolutionary Change for Your Technology Business Kanban emerged as a transition method – “The Kanban Method.”  However, the value of the original Kanban as a development management approach, has not diminished and has been expanded on by many.  Hence there are now two schools of Kanban, so to speak.  See A Tale of Two Kanbans … or Three for more.

I am a proponent of what I call Lean-Kanban and what Karl Scotland calls Kanban-Thinking.  This is essentially taking an overall Lean approach while using Kanban to manage flow. The Kanban Method, on the other hand, is a powerful method to transition an organization where low trust exists and little can be done up front.  The primary difference between them is the Kanban Method’s approach to focus on:

  • Evolutionary change
  • Managing WIP as the way to manage flow

In a nutshell, LKU’s Kanban Method says to first follow the foundational principles:

  • Start with what you do now
  • Agree to pursue incremental, evolutionary change
  • Respect the current process, roles, responsibilities & titles

Then adopt the core practices:

  1. Visualize
  2. Limit WIP
  3. Manage Flow
  4. Make Process Policies Explicit
  5. Implement Feedback Loops
  6. Improve Collaboratively, Evolve Experimentally (using models/scientific method)

This is taken from KanbanDev.  More can be found on David Anderson & Associates’ blog (of which LKU is a wholly owned subsidiary).

What’s Missing

Perhaps all that’s missing is an expansion of what “Limit WIP” and “Manage Flow” means.  From LKU training and writing I hear these to mean having WIP limits in the Kanban columns.  In other words, we improve flow by managing the delays at each stage.  But this ignores the system within which the work is flowing and the relationship between different parts of the system.  We have often found that one of the following can be implemented prior to managing flow directly with WIP limits:

  1. Decrease the batch size of work by attending to the core value needed
  2. Limit the amount of work hitting the team to match their overall capacity
  3. Attempt to create teams to the extent possible
  4. Improve the order of the workflow (e.g., integrate coding and test or use ATDD)

Be clear that before doing any of these one must look at where the organization is and see if they are appropriate.  Let’s go through each of these in more detail:

Decrease the batch size of work by attending to the core value needed. One can make drastic improvements in one’s development efforts by using Minimum Business Increments (MBIs, also referred to as MMFs, MVFs, MVPs, …), delivering the most important value quickest.  Even just splitting up the delivery into smaller batches can make a big difference. I find it ironic that this is ignored by the Kanban Method as Eli Goldratt, creator of Theory of Constraints, a cornerstone of the Kanban Method, once said “often reducing batch size is all it takes to bring a system back into control.” Smaller batches starting out is often a brilliant way to start.

Limit the amount of work hitting the team to match their overall capacity. This is part of the Kanban Method, but in isolation doesn’t seem to work well.  If one does not have the trust level to use MBIs, it will be difficult to get the business stakeholders to just accept the development organization working on fewer things (even if that’s the right thing to do). 

Attempt to create teams to the extent possible. I have long held that Scrum’s success is primarily based on two things, 1) smaller batches (a result of the Scrum timebox) and 2) cross-functional teams (see a somewhat dated blog from May 2007 Challenging why (not if) Scrum works). These two practices implicitly manage flow.  Teams are incredibly useful and should be created almost wherever possible.  While Kanban Software Development provides for Agile software development without true teams, it doesn’t mean they shouldn’t be used when possible. Some level of team (often a combination of a core team that’s stable with a few rotating members) is virtually always possible. Many challenges can be solved simply by temporarily assigning a member of a component team to a new application development team that requires changes to the component team.  Easy to do, great results.  See a three part blog series on this starting with Cross-Functional Teams Eliminate Waste and Manifest Lean.

Improve the Order of the Workflow.  Very often teams develop software in the wrong workflow order.  The development team takes a preliminary conversation about what to do and goes off and writes the code. The test-team goes off and builds tests and then after the software has been written, everyone gets together to see the results.  While this is often called “normal” it is not very effective.  Methods such as Acceptance Test-Driven Development/Behavioral Driven Development can be done in a light-weight manner that provides immediate results by changing the order of the workflow at the start of the project and avoiding much waste and rework.  People collaborate early on to understand the true challenge and solution and what it means to implement it.  This is something that can virtually always be done to some beneficial level.

Lean’s Influence on Our Approach

It is interesting that Taiichi Ohno (creator of the Toyota Product System from which Kanban sprung) explicitly suggests work level demanded of the system and size of items, team structure and workflow order must be set prior to attempting to establish flow with a kanban system.  The first one is the essence of small batches (Agile). Ironic to me that LKU Kanban tends to ignore the foundation on which it is based – Lean methods.

Lean provides both gradual (kaizan) and dramatic (kaikaku) change.  LKU Kanban’s great contribution to the Lean-Agile world was demonstrating the ability to manifest improvement through evolutionary change.  That flexibility is awesome.  However, that does not mean that one wants to limit oneself to this.  And, of course, our approach does not imply moving faster than one should or imposing change on an organization.

Summary

LKU Kanban has provided great insights and tools for the Lean-Agile practitioner at all levels.  It is definitely a tool in my tool-box.  But it is not a universally applicable approach. Rather I turn to it when I can’t do any changes up front – typically due to low levels of trust.  The danger of LKU Kanban is that it ignores other actions that might provide great value right at the start.  Besides losing the potential value of these activities, doing this increases the likelihood of framework myopia. Our experience with hundreds of clients demonstrates that in almost all cases, some improvements to managing the work load level coming in, team structure or workflow order can be achieved at the very beginning.  And, of course, one only undertakes any of these actions after looking at the value stream and understanding where you are and if it makes sense to those involved.

If you want to discuss this more, head over to the Net Objectives Support Group (LinkedIn)

And, as always, please contact me if I can be of any assistance both in your current use of Kanban or if you are considering adding it to your repertoire.

Al Shalloway
CEO, Net Objectives

Related resources of interest:

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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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