This is the fifth and last post in preparation for my presentation at the Lean Kanban Netherlands 2012 conference, about Enhanced Risk Management in Kanban via the Theory of Constraints.
You can read the earlier 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
- Risk Management in Kanban
The first three described how the Theory of Constraints deals with Schedule Management, Buffer Management, Risk Management, Root Cause Analysis and Continuous Improvement. The forth described how risk is handled in the Kanban Method. The purpose of these posts is to gain some foundational knowledge in order to combine Kanban with the Theory of Constraints.
Before we can see how we can combine the Kanban Method with the Theory of Constraint, there is one further aspect that needs attention. The use of Minimum Marketable Releases in Kanban; and that is the topic of this post.
The Kanban Method and Minimum Marketable Releases
As we saw in the last post, Kanban allows for variable work item sizes. This aspect is of immense value, because it permits combining Kanban with the practices we saw in the Theory of Constraints. In particular, the linking element between the two approaches is the use of the so called Minimum-Marketable Releases (MMR). David Anderson [ANDERSON-2010] defines a MMR as “some atomic unit of value to the market or customer.”
A MMR is a redefinition with slight differences of the Minimum Marketable Feature (MMF), a minimal set of features delivering market value, as defined by the Incremental Funding Method [DENNE-2004a].
What is noteworthy is that, while it is desirable to have all MMRs to be of approximately the same size to smooth out flow and enhance predictability, it is possible to handle differently sized MMRs. It is worth noting that Kanban does not have the operational restraint of setting limits on work item sizes. (Kanban does set WIP limits, the number of items in process; but not on the overall size of the work in process).
It is possible to use Kanban to manage work flow compatibly with variable sized MMRs.
Minimum Marketable Release as Unit of Work
Strictly speaking, the MMR should not be considered as a work item per se, but rather as a collection — a batch — of work items. A MMR will contain several work items (user stories, use cases, features or whatever you are used to).
The size of a MMR will vary for two reasons. First, and most important, is that each MMR can contain a different number of work items. Second is that each work item will belong to a different class of service, each characterized by a different (average) size.
While a MMR is not a work item, from a risk management perspective it becomes interesting to consider it as a unit of work. We will consider the MMR as a unit of work that is released into the work flow, and not only as a unit of value that is released to the market once finished.
Minimum Marketable Release and Risk Management
Whether one uses MMRs or the original MMFs, the key notion is that of minimal amount of functionality that can be offered to a market.
Minimality is key.
This, together with the possibility of having differently sized MMRs, grants some significant advantages with respect to other methodologies, either Agile/Lean or traditional ones.
In particular, all other Agile/Lean approaches somehow attempt to limit accumulation in variation by fixing a time limit on iterations. Like:
- 30-day Sprints in Scrum;
- 2-week iterations in XP;
- 2-week upper limit per feature in FDD.
Other methods that do not prescribe anything in terms of limiting work in process, yet they use time boxes, like Lean Software Development or Adaptive Software Development. The intent of all these approaches is to use fixed time and variable scope to manage variability and risk. When things don’t work out well (risk happens!), the canonical remedy is to “cut the bottom of the backlog.”
Varying Scope is not an Option (within a MMR)
By using MMRs, we avoid resorting to cutting the bottom of the backlog — which is the typical “Agile” way of “dealing” with risk.
Agile attacks risks early in each iteration. Even Kanban and the Incremental Funding Method suggest to attack risks early. The significant difference is that Agile uses the general mitigation strategy of “varying the scope” of the project.
The guiding idea is to deliver the most valuable parts early: if schedule is at risk, the deadline can be kept by dropping what is at the bottom of the backlog. The items at the bottom are of less value, so leaving them out will have minimal impact on the whole project. When implementing a MMR, the Agile strategy of varying scope cannot be used. (Even though the principle of delivering value early should always be preserved.)
The similarity between Kanban/Incremental Funding Method and Agile ends with the intent of early risk resolution (within the development of every single MMF/MMR; and in the prioritization of the backlog in Agile).
Notice well that by definition of MMR, you cannot drop the items at the bottom of the backlog. A MMR is minimal. Removing items “at the bottom” will make the MMR unmarketable! Conversely, adding features implies waste, as the MMR is no longer minimal.
MMR as a Fixed Scope Mini Project
The MMR can be considered as a fixed scope unit of work and unit of marketable value, to be delivered in its entirety. No more, no less.
Here the emphasis is on Fixed Scope: you cannot change a MMR’s scope, less the very purpose of identifying the MMR in the first place becomes vain. (Naturally, if there was an error in the initial definition of the MMR, then it has to be changed; but this is an entirely different case!)
When using MMRs, we cannot have a variable scope: we must deal with variable time instead! This is where we start to see the connection with the buffer management techniques of Critical Chain Project Management: the Theory of Constraints teaches how to live with varying time through buffer management. (Soon we will see how to do this in practice.)
Agile’s Adoption of MMFs and Failure to Deal with Risk Management
This distinction just made is important because many proponents of Agile methodologies have happily adopted the concept of MMFs from the Incremental Funding Method. Often MMFs are equated to epics; though epics are not characterized as MMFs.
Agilists ignore the fact that proper risk analysis and management is absolutely mandatory in the IFM! IFM requires risk analysis and management in order to deal with the prerequisite of delivering all of the MMF; not a subset of it; not with standing all things that might go wrong (risk!).
If the issue of risk management is brought up, then Agilists offer the philosophy of cutting the bottom of the backlog, not realizing that such actions are in contradiction with the definition and intent of MMFs, and exposing a fundamental misunderstanding about the purpose of MMFs.
Agile proponents adopt the “marketability” of MMFs since it matches the generally positive idea of delivering value. However, they miss out on both the financial aspect (SANPV computation) and on the mandatory risk analysis required by IFM.
In a nutshell: The scope of a MMR must be fixed!
Explicit Risk Management is Mandatory but Not Prescribed
In the previous post we saw that the Kanban Method does not require explicit risk management because there is a lot of risk handling capabilities that are “built-in,” and come “for free” with Kanban. We also saw that while not prescribing risk management, Kanban strongly suggests that explicit risk management should be performed nonetheless.
As mentioned above, the Incremental Funding Method mandates explicit risk management, because of the nature (fixed scope) of MMFs. It follows to reason: If you implement Kanban and use MMRs, then explicit risk management becomes mandatory.
The interesting point is that while IFM demands explicit risk management, it does not prescribe how you should perform it. This is what allows us to take the best risk management practices intrinsic to Kanban, and combine them with what we can learn from the Theory of Constraints.
The Best of All Worlds: IFM + TOC + Kanban!
This is what I propose — A combination of IFM, TOC and Kanban (even if the IFM aspects are not deepened) as a means of achieving the benefits of MMFs/MMRs, all the while we have both the reactive event-driven risk management capability of Kanban to deal with special cause variation, and the leading/proactive risk management capability of TOC to handle common cause variation. The contribution of TOC is even more significant, as it will lead to systematic and sustainable process improvement in a manner that Kanban is currently incapable of.
Stay tuned to see how we can do this in practice.
Update 2017-07-01:
Recently, inspired by SAFe’s term of “Program Increment,” I have started to prefer the term "Minimum Marketable Increment" (MMI) rather than MMR. The notion is the same as the MMR, but it avoids the unwarranted expectation that is always created by something that is called a “Release.” The expectation that it has to be… released. The conveyed understanding is that a MMR is a unit of configuration management; but in reality it is a unity of scope and business value management. Hence the term “release” is misleading.
What matters here is that this unit of work and value is minimal in the sense that we cannot take anything else away without it losing its value. An actual “release” can thus contain multiple MMIs; and an actual “release” is what the end users will experience.
Also notice that in SAFe, a Program Increment is a timebox, while in TameFlow an MMI is a fixed amount of scope. As always, this does not mean that the scope is cast in stone. When new things are discovered or old things become irrelevant, they are added or removed from the scope; while all uncertainty and variability is handled through buffer management, which is expressed as time.
Update 2020-02-05:
In the “Tame your Work Flow” book, I have updated the term again, and now use the acronym MOVE, which stands for "Minimal Output Value Effort". The meaning of this is explained in the book.