At the Lean Kanban Netherlands 2012 conference I gave a talk entitled Enhanced Risk Management in Kanban via the Theory of Constraints, proposing how one can combine Kanban with the Theory of Constraints. In this post I will describe how I do this.
If you are not familiar with the Theory of Constraints, you can read about the essential concepts in my earlier posts, which I published in preparation for the conference talk. You can find those posts here:
- Critical Chain Project Management in the Theory of Constraints
- Buffer Management and Risk Management in the Theory of Constraints
- Root Cause Analysis and People Factors in the Theory of Constraints
Similarly, if you have a background in the Theory of Constraints and need some notions about Kanban, you can read these two posts:
The Kanban Method was Influenced by the Theory of Constraints
The Kanban Method was deeply influenced by the Theory of Constraints, as David Anderson says [ANDERSON-2012]:
What I didn’t expect to find in Eli Goldratt’s writings were the foundations of what we now call the Kanban Method — the foundations of an incremental, evolutionary approach to change and an explanation for why people resist change in the organizations and in their working practices. […] It is clear […] that the Kanban Method can be described as an evolution of the Five Focusing Steps (Drum-Buffer-Rope) embodiment of the Theory of Constraints, most heavily associated with Goldratt’s work in the 1980s. Goldratt’s Thinking Processes emerged in the mid-1990s and are now widely regarded by that community as representing the main body of the method. […] [Goldratt] developed the Thinking Process as a systematic approach for managing change.
It is revealing to see how David Anderson looks at the development of the Thinking Processes with respect to what then became the Kanban Method:
Coming to a similar conclusion about the problem with change, I chose not to pursue the Thinking Processes, which define an outcome known as the Future Reality Tree (FRT) and a managed change program known as the Transition Tree. Instead I chose to develop an evolutionary approach that does not define an outcome or prescribe a transition plan. It pursues a guided-evolution approach based on a scientific understanding of the flow of work and the implementation of safe-to-fail experiments that evolve the existing process in a series of steps. […] We could think of the Thinking Processes and the Kanban Method as evolving from a common ancestor, the Five Focusing Steps. The slight irony is that the Thinking Processes do not offer an evolutionary approach, but rather a planned transition to a defined outcome, whereas the Kanban Method follows the implied evolutionary approach inherent in the original Five Focusing Steps.
One can still see how the Five Focusing Steps (5FS) are at the basis of Kanban’s event driven risk identification and issue escalation policies. A part from this obvious use of the Five Focusing Steps, none of the deep body of knowledge of the Theory of Constraints is used; and this is by deliberate choice.
In this proposal I suggest that there are parts of the Theory of Constraints that can actually improve how Kanban is put into practice. By completely disregarding anything beyond the Five Focusing Steps, we are indeed looking at a case where the “baby was thrown away with the water!” While it is true that the entire armory of tools of the Thinking Processes might not be entirely aligned with the idea of an evolutionary approach (since they aim at defined outcomes), there are parts therein which are very powerful.
Keeping the Useful Parts of Critical Chain Project Management
The Critical Chain Project Management promoted by the Theory of Constraints is characterized by a network of project activities, at the end of which a single Project Buffer is placed to absorb any variability that might adversely affect project delivery.
The project network is used for planning the project. It is similar to the project network of the better known Critical Path method; only that the logic used to schedule the activities is different. For our purposes, the project network of CCPM is not interesting.
The essential part that we preserve from CCPM is the project buffer. The project buffer is used during the execution of the project. The interpretation and use of the project buffer is what we will transfer over and use with Kanban. We will use the project buffer, exactly in the same way, and thus getting the advantages that come thereof:
- Leading indicators of imminent risk materialization
- Just-in-time risk registry compilation
- Frequency Analysis to identify sources of common cause variation
- Root-cause analysis identifying the source of those problems that are most expensive or frequent
- Process of ongoing improvement driven by focusing and leveraging solution to those expensive or frequent problems
The most significant outcome of this approach is that it will allow one to improve the process one is using, resulting in increased throughput and decreased cycle time. One will increase the capability of the team and/or process, with improvements that will be beneficial not only for the project being worked on, but also for all other, future projects one will undertake. The improvements are systemic.
It is important to notice that the improvements induced by this approach are not replacing those that one achieves with Kanban alone, because the two are complimentary. One completes the other in a significant way. More specifically, one achieves the benefits of both like this:
The event-driven risk management typical of Kanban that allows one to react very quickly to special cause variation; and
The buffer-monitoring driven risk management typical of CCPM that allows one not only to identify sources of common cause variation, but to discern and select those which are adversely affecting the team’s and/or the process’s capabilities.
The Kanban Method is not Changed, but it is Augmented and Enhanced
This proposal changes nothing in the Kanban Method as it is presented and taught by David Anderson [ANDERSON-2010]. This proposal is an enhancement which provides a powerful tool for focused and ongoing process improvement.
The Theory of Constraints Gains the Agility Needed for Software Projects
Likewise, this proposal can be seen from the Theory of Constraints perspective. Software development has seen a proliferation of Agile methods in the last 15-20 years. The CCPM is in many ways anchored to approaches which cannot benefit from the advances seen with Agile methods. Therefore, this proposal can be seen as an enhancement that introduces the Kanban Method within the Theory of Constraints operational practices for project execution (Buffer Management, etc.). TOC practitioners will gain the complimentary advantages offered by the Kanban Method which are most significant in the event-driven risk management capabilities; but which are also more generally all those positive aspects that distinguish Kanban from other Agile and/or Traditional methodologies.
A Perfect Match between Kanban and the Theory of Constraints
In the earlier post Risk Management in Kanban it was shown that Kanban has a number of advantages to offer in terms of Risk Management, especially compared to earlier approaches. It is already the most reactive method available, enabling Event-Driven Risk Management.
Unfortunately, Kanban’s Event-Driven risk management leaves out the identification and handling of common cause (and possibly other, minor special cause risks). Only major special cause risks will be noticed, as they are the ones that will produce clearly visible “events” that we can react to, and handle via risk management policies. If minor problems occur or, especially, if they accumulate, maybe we need another approach.
In the earlier post Buffer Management and Risk Management in the Theory of Constraints, we learned that it is possible to manage the project buffer and get leading indicators of oncoming risk materialization. Naturally, a leading indicator is even preferable over an event-driven approach. You can take preventive action just in time, rather than reactive action after the fact, no matter how quickly you react.
A Process of Focused and Ongoing Improvement
If we can combine the two approaches, then we get the additional advantage in terms of the systematic method that the Theory of Constraints gives us to clearly distinguish between Common Cause variation, and Special Cause variation. We simply need to keep track of reason codes, and monitor their frequencies every time we have a buffer penetration instance. Once we can identify Common Cause variation, we have the opportunity to improve our processes; but we will do so in the typical Theory-of-Constraints-way: by focusing on the weakest link. In this case the weakest link will be the problem that occurs most frequently; or that has the most adverse impact. The philosophy is clear: not all problems are worth our attention. We focus only on one problem at a time, the one that creates the largest weakness in the process.
In Kanban, issues are seen as Special Cause Variation. It is evident that Kanban is not well equipped to identify Common Cause Variation. As we learned in the earlier post, it is only by monitoring and keeping track of frequency occurrences of common cause variation that we get the correct focus and leverage to improve our process in a systematic way.
This is were some innovative thinking and cross-pollination becomes useful: we need to add buffer management to Kanban. The obvious justification for buffer management is in getting the extra “margin” that can absorb uncertainty, and make due date delivery more reliable. The less obvious, but more important reason for introducing buffer management is to have a tool that enables a process of focused and ongoing improvement.
The Kanban Method with Buffer Management
The Project Buffer of CCPM is a time buffer. Kanban is concerned with time in terms of the Lead Time and or Cycle Time metrics. In Kanban you ordinarily keep track of lead and cycle times of the individual work items, and typically calculate their average lead and cycle time. (Often this is further partitioned by classes of service; which we ignore for the time being — though all of the following will still apply when using classes of service too.)
Kanban considers work as Continuous Flow. There appears to be no definite start and end time to determine durations — and hence corresponding time buffers.
The Link is in the Minimum Marketable Release / Minimum Marketable Feature
When partitioning a project in Minimum Marketable Releases (or Minimum Marketable Features), in addition to all other reasons that might justify this partitioning as described in [DENNE-2004a], we have one decisive property. As we saw in Virtues of Minimum Marketable Releases, a MMR/MMF can be considered as a fixed scope mini project. We know in advance how much work we intend to perform.
Typically, we count the number of work items (for instance, user stories) that are included in the MMR/MMF. Therefore, simply by multiplying that number of work items, by their average cycle time we have an expected duration for the implementation of the MMR/MMF.
Little’s Law and the Assumption of Steady/Ideal State and Sustainable Pace
Naturally, what we are doing is using Little’s law to make this sizing meaningful. Little’s law is significant only when the system is in a steady state; that means that the input is balanced to the output.
We further assume that the team is working at its maximum sustainable pace. Notice that a steady state might be achievable also at a level of throughput that is less then sustainable. In this case, one would apply the normal Kanban strategy to increase the WIP limits, and gain more throughput.
However, there comes a point when by increasing WIP limits, the team’s ability to cope with the additional work load will become unsustainable. It is at this point that any further attempt of increasing throughput by increasing WIP limits will fail. The failure will show on the Kanban Board, but the application of the five focusing steps will only reveal the reason why the greater pace could not be sustained. It will not reveal the reason why the pace cannot be increased. The focus of any improvement attempt has to shift from the individual resources, to the entirety of the team, seen as a system. We want to find what prevents the team from increasing their maximum sustainable pace, all the while we keep the process in the ideal/steady state!
It is like an athlete practicing endurance sports. An increase in WIP limit will just result in a sprint (might the readers who are into Scrum pardon the pun here!). It is at this point that the WIP limits should be kept untouched! and allow the team to maintain its maximum sustainable pace. While the team is doing this, we will use buffer management to reveal what is preventing the team from being even more productive. The improvement that will result will affect the entire process. The improvement will not just remove one impediment from the current project; it will be of benefit to all future projects too.
The Key Innovation: The Minimum Marketable Release Buffer
With the assumption that you are using Minimum-Marketable Releases (or Features) as units of work, and that you keep your team at a steady state and maximum sustainable pace, I propose the following innovation:
When an Minimum-Marketable Release is chosen for implementation, it is associated with the average cycle time, as per historical Kanban flow metrics of your team. It is suggested to use that average time to size a corresponding MMR Buffer, which can be considered by all means analogous to the Critical Chain Project Management’s Project Buffer, and used in the same manner, in order to get leading signals to identify and categorize oncoming risks.
The Choice of Average Cycle Time
Note that you could use either lead time or cycle time averages. However, when using MMRs, lead time is less meaningful than cycle time. This is because the MMR is released as a single unit of work, and during the implementation of that MMR no further work items are released into the work flow. It is more meaningful to consider the average cycle time of the work items (stories, use cases, scenarios, etc.) which are part of the MMR.
Signal Reaction
Whenever the MMR buffer raises a signal, you must identify the Root Cause (with the Current Reality Tree root cause analysis technique). If the resolution requires action by the team, then you create a corresponding Issue/Impediment card. Since we are managing work flow with Kanban, you must assign a class of service to the impediment card. Hence the impediment card will be handled through normal Kanban work in process policies.
Buffer Sizing
You must choose the size of the buffer carefully. To start, consider the expected average cycle time from historical flow metrics. Conceptually, sizing the MMR buffer is like going in the opposite direction of what happens in Critical Chain Project Management. In CCPM, you halve the Critical Path time, to get a 50% due date probability; then you add the project buffer to the end of that.
In the case of the MMR Buffer, we start with the historical data; because it is an “average,” we can consider it as roughly equivalent to the 50% probability due date duration used by CCPM. So as a first approximation we can size the buffer to half of that average expected cycle time.
It can be worthwhile to experiment with different sizing techniques for the MMR buffer. The size of the buffer is critical for the leading effectiveness of the signals. If the buffer is too big, signals come too late. If the buffer is too small, signals come too frequently, with many “false positives.” Eventually, one can use the advanced dynamic buffer sizing technique of the Theory of Constraints to get the optimal buffer size with respect to your project’s unique characteristics.
Root Cause Analysis and Continuous Improvement with the Theory of Constraints
As mentioned earlier, whenever the buffer signals a new problem, you must perform root cause analysis. If the source is in your own team (span of control), it might be a system constraint: if so, apply the Five Focusing Steps to improve the overall process, and avoid future recurrences of the problem. If it is a policy constraint, or a root cause residing in your sphere of influence, use the Thinking Processes to gain agreement on the problem, the solution and the resolution.
With entrepreneurship, change is not only seen as inevitable, but also as an opportunity to improve. With change comes risk — and risk requires even more changing, either as imposed by circumstances (risk materialization and crisis); or enacted as preventive measure (risk management) and resulting in improved processes. The Thinking Processes can be adopted both to identify root causes, and as the main instrument to achieve a process of ongoing improvement.
Conclusion
By combining the Kanban Method with the Buffer Management techniques of Critical Chain Project Management, we achieve superior risk management. Not only can we act on leading indicators and cater for problems before they become critical; but we are also able to identify common cause variation. Identifying common cause variation is the corner stone of ongoing process improvement in the Theory of Constraints; by applying the other tools of the Theory of Constraints, we can improve our processes considerably, in a laser-focused manner.