Build-Measure-Learn as a Kanban System
The above measure-learn process can be mapped onto a simple kanban board. The boundaries of this Kanban are “ready for release” (upstream) and “validated” (downstream). There are policies for pulling work from one state to the next. For example, in order to proceed with improvement tests, you had to finish the controlled experiments and have statistical proof in hand that everything was OK up to that point. There are, obviously, tight work-in–progress (WIP) limits, as we were constrained on how many experiments we could run at the same time.
To be sure, there was no kanban method back then. David Anderson’s kanban book was still years away from being published. I am merely using a modern apparatus to think about a past situation. If we knew back then what we know now—for example, visualize—our measure-learn kanban board might have looked like figure 3 at some point. (I dropped the WIP limits from the board, because they would evolve anyway and the precise limits are not the point here.)
Figure 3: The measure-learn kanban board
“Ready for release” was both the upstream point of the measure-learn kanban and the downstream state of our build kanban. The exact software development process used to build a software feature is not important here, but we can use the modern kanban method to model it. The board visualizing it could look like figure 4 at one point.
Figure 4: A build (software delivery process) kanban board example