On July 26, 2020, I delivered a presentation at the TOCICO 2020 Virtual Conference. Many have asked me to make the presentation available online.
So here it is in its entirety.
In the presentation I go over the origins of the TameFlow Approach, how it shares some common heritage with Scrum, the role of Alexandrian Patterns, the discovery of TOC and Kanban. My mission of overcoming Kanban’s inability to find the real Constraint in knowledge-work, and to do so using all the concepts of TOC.
I explore the nature of knowledge-work, with iterations, interactions and increments. I consider the impact of uncertainty, incompleteness and interactivity in the presence of digital computation.
I highlight the Core Conflict between Agile and conventional project management practices. I consider Critical-Chain Project Management as a collection of patterns, and think about which patterns are still good in a knowledge-work setting.
I develop a rudimentary Current Reality Tree, Future Reality Tree and a Prerequisites Tree, while highligting another core conflict between Kanban and Scrum. I show a resolution with two Injections.
The first injection is the usage of Probabilistic Forecasting, which though needs the conditions of Little’s Law, with a stable process and the necessity to Limit WIP.
The second injection is to resort to DBR Scheduling as an alternative way (in place of Column WIP Limits) to achieve the limitation of WIP.
I go on reasoning about how Flow Time Distributions allow us to find the percentiles and place a CCPM-style Buffer. Actually this is the MOVE Buffer as it is called in the TameFlow Approach.
Using Little’s Law and Linear Projections (with all the caveats of doing so!) we can derive the Buffer Consumption of that Buffer on the forecast timeline of a MOVE in progress.
Though this requires some deeper thinking about how to size and where to position the Buffer exactly. In particular, that Buffer sizing and placement depends on how well the Conditions of Little’s Law are upheld.
The more stable the system, the more “aggressive” we can be with the Buffer’s size and position. Therefore, in order to keep the system as stable as possible, we must Limit WIP by using DBR Scheduling.
Now, DBR Scheduling necessarily requires identifying the Constraint in the Work Process - as if it were a manufacturing plant. We can find the Constraint in the Work Process by looking at the Work Process Stage with the longest Average In-State Flow Time.
Hence a DBR Buffer is placed in front of that step, i.e. a Column on a TameFlow Board.
Bringing these two factors together, we can manage time via the MOVE Buffer, and the Work Load / Work Flow via the DBR Buffer.
A final consideration on the difficulty of sizing and placing the Buffer, I show how it can be done interactively - taking into account the need to keep the team in a state of Pscyhological Flow. The idea here is to calibrate the actual position of the Buffer as to strive to keep the team in the Yellow Zone. That Yellow Zone can be considered as a tangible representation of the team’s Flow Channel.