This blog is an update to Why We Need a New Meaning/Name for Kanban because I felt the message there may have been lost in that blog. Furthermore, this represents some clarified thinking as I spent a lot of time talking to Kanban proponents at the Agile 2013 conference. Some, from LKU, follow what they call the Kanban Method and what I call LKU Kanban to help differentiate it from the whole family of Kanban approaches (see the blog I just referred to if you’re wondering why I consider this important). Virtually every other Kanban practitioner I talked to (some former members of LKU) approached Kanban more along the lines of what I am describing here. The preparation for my talk, De-Mystifying Kanban also clarified many of my about different Kanban approaches.
LKU Kanban
The LKU Kanban (i.e., the 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:
- Visualize
- Limit WIP
- Manage Flow
- Make Process Policies Explicit
- Implement Feedback Loops
- 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
We believe this approach needs to be modified in two significant ways to be generally applicable. The first is in the first core practice – “visualize”. Perhaps this is just a nuance since visualization can take many forms. So this point is more about a way of doing LKU Kanban I suppose. We have found great value in using a value stream as this visualization. The intention here is to see: workflow, delays, amount of work. Kanban boards at the beginning don’t demonstrate all of these although there is great similarity. It provides immediate understanding of gaps and delays in an organization’s current method of doing things. Furthermore, it provides places to do “five-why analysis.” We have seen this sometimes can result in immediate, dramatic improvement because of it exposing certain assumptions about the current workflow.
Visualization also helps set the stage for three other actions we have found to be valuable in 75-80% of the companies we help with Kanban. These are:
- Work level demanded of the system and size of items hitting the development organization
- How the folks in the value stream are organized to work with each other
- Workflow order
Let’s go through each of these in more detail:
Work level demanded of the system and size of items. This is the starting point of a pull system – use Kanban to limit the work being done by the development system. One can make drastic improvements in one’s development efforts by using Minimal 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. Having two three-month projects is an improvement over one six month project no matter how you look at it. 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.
Team structure. 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.
Workflow order. 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.
Extending LKU Kanban
We have found it to be extremely valuable to consider applying these before LKU Kanban’s mandate of managing queues by limiting work in progress. Be clear that we find limiting WIP to be of great value. However, it tends to focus in on the current workflow and often creates framework myopia when the other three methods aren’t considered first. Even if none of these can be implemented prior to managing WIP, they create an awareness that can avoid framework myopia that typically occurs later.
In any event, folks often don’t know how to set their work-in-progress limits – causing frustration right from the beginning. These are often difficult to achieve at the start. But, perhaps more importantly, the size of the queues may be due to other issues that can’t be solved merely by managing them. Focusing on queue size, which is a result of poor workload, poor team structure and poor workflow order is attempting to solve the effect without being clear of the cause.
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. The danger of LKU Kanban is that it ignores other, potentially initial, 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 Lean-Agile Yahoo User group.
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:
- Slides and recording of De-Mystifying Kanban at Agile 2013 Conference
- Why You Need a Hybrid System
- The Differences Between Lean Manufacturing and Lean Software Development
- Lightning webinars “Mapping a value stream to a Kanban board” and “Why Seeing the Value Stream is So Important” on the Net Objectives Lightning Webinars page
