’The passage of time makes a mockery of all of our planning, estimating and forecasting efforts’. There are few one-liners I can retrieve from the top of my head, but this quote - from Agenda Shift’s Mike Burrows – has always stuck.
The other thing that is important to remember when it comes to time is that it is unidimensional and only goes in one direction: forward. While everybody knows this instinctively, we’ve only recently been able to prove this scientifically. And of all things, the second law of thermodynamics gives us the ‘thermodynamic arrow’ of time.
This relates to Throughput Accounting in Knowledge Work in many ways. Managing can be done on two axes: the scope axis or the time axis. Agile – with timeboxing - manages on the scope axis. Dr Eli Goldratt liked to manage on the time axis, meaning that a target scope is agreed upon and the time required to do it can vary. The DBR – Drum Buffer Rope - buffer is filled with ‘work’ so that the constraint does not starve. The buffer is calculated with material ‘work’ so that on the time axis, when the rope comes into play, signaling replenishment and limiting WIP, everything that is needed will be delivered on time so the constraint does not starve. A simple heuristic you can use for your first configuration of the buffer size is:
If you need three days to process an item at the constraint and it takes nine days for the raw material to get there from upstream, you only need a buffer of three items in front of the constraint.
This is a simple rule of thumb, but it beats the MIN/MAX inventory algorithm hands down. The illustration below will help with the math:
Contrary to the traditional column WIP limits – which we discard in a Flow Efficiency board – the DBR buffer does not hint at a maximum quantity but rather a minimal threshold level that serves as an advanced signal that the system is in danger of starving. We are of course talking about management by exception, where automated triggers gently warn us of potential risk materialization. Top management loves to know ahead of time.
Another use of the time axis within the Theory of Constraints is with the CCPM buffer in project management. There as well, time comes into play along with Little’s Law. More on this later.
Let’s narrow discussions of time down to the scope of this article, by examining these concepts as a continuation of the Five Focusing Steps. We need to dig down and see how the three constraints in Knowledge Work can be tamed. The three constraints each have a name:
Thus, understanding how to Identify, Exploit, Subordinate and Elevate each of the constraints listed above is part of the Five Focusing Steps - and fair game for Throughput Accounting - as you cannot succeed with Throughput Accounting with total disregard for the constraints of your systems. And for Knowledge Work, we need to create visual artefacts to render visible that which is invisible by nature.
There exists a tendency in agile nowadays – Kanban first and foremost – to get rid of all dependencies. All of them, everywhere, all of the time. So goes the algorithm and the saying.
Dr Eli Goldratt would not approve.
Let’s explore this concept. Which system below is simpler?
I always get a divided audience when I give this test. The answer is on the right. If you want to manage the system on the left – which is dependency free – then you must act at five different places. It has five degrees of freedom. If you want to impact the system on the right, you can touch it anywhere, once. It will have a ripple effect. That system has one degree of freedom and a lot of dependencies. What a gift!
The BLUF here is that a lot of smart undertakings deal with removing dependencies. They all have merits. My word of advice is to first be constraint-savvy. As you fix dependencies in the hope of improving, you are creating invisible and almost permanent layers of cost overheads. The lack of constraint awareness is the main cause of permanent increases in overhead costs created by Improvement Initiatives. Such is the nature of indirect costs. Do not let that happen. If you make an improvement, make it count on the Throughput of the system and act on the constraint.
If we take the same illustration, we can make a parallel between Cost Accounting and Throughput Accounting:
Cost Accounting systems do not come cheap. They have tentacles that penetrate every function of the organization. Throughput Accounting is straightforward and can be understood by all once you grasp the marginal impact of each of your decisions on (TH) – Throughput, (I) – Investments and (OE) – Operating Expenses. No need for data accuracy but rather relevancy of data. The choice between being roughly right or precisely wrong is a well-known idiom in the Theory of Constraints!
I could not finish this section without asking: how many degrees of freedom does time have? How many degrees of freedom does scope have? What do you want to manage, the entire system or the constraint? How do you want to manage: through time or scope?
One last word on the much-misused topic of Inherent Simplicity. Inherent Simplicity is a concept that you understand at 3,000 feet in the air. It is a discussion like the one we are having now regarding degrees of freedom and dependencies. You do not go to work every morning with the aim of changing the universe or architecting your environment toward ‘Inherent Simplicity’. At times, keeping the constraint from moving – and especially subordinating to the constraint – is not inherently simple and could require you to do some complicated things!
Here are the definitions of both terms in a Knowledge Work context:
Span of Control … is the part of reality over which we have control to change things. Impacting the delivery line with additional Investments is within our Span of Control. We can have it our way here without asking for permission!
Sphere of Influence … consists of the domains where we have a say. For example, it is here that we can help shape demand, defer commitment, and exercise our options through coordination.
There is a purpose to understanding the nuances. When faced with increasing demand, our first reflex is to add capacity. It is within our Span of Control!
But the key to reacting to a surge in demand is to postpone commitment, reduce WIP and exercise our options. We are within the realm of our Sphere of Influence and this is where we should intervene. Increasing capacity by buying capacity is always the last resort in Throughput Accounting. Always. No matter what. And especially at the constraint! There are other ways to increase capacity with existing assets and/or operating expenses.
The reason is obvious since (I) – Investments are the denominator of the ROI – Return on Investment metric. It has a leverage effect as per the formula below:
ROI = ((TH) - Throughput – (OE) - Operating Expenses) / (I) – Investments
For each of the three constraints, understanding the power of our Span of Control and how to navigate within our Sphere of Influence will be examined.
Collaboration occurs within one’s Span of Control or, for example, when this area is shared between teams. Coordination is strictly a matter of Sphere of Influence. Collaboration and coordination with existing investments and operating expenses is the preferred way to both Exploit the constraint and Subordinate to the constraint, and sometimes the preferred choice is to Elevate sprint capacity in order to better Exploit the constraint.
Purchase of capacity as a first resort should always be toned down by going through this ritual:
What to do next? Use selection and prioritization.
When to start? Postpone commitment and limit WIP
I don’t often get the chance to squeeze in Lucas’s critique, but this section is right on the money.
The saying goes in Agile that we evolve in complexity. For the Business Domain this is absolutely true, and Special Cause Variation can be expected. And it applies as well when we are executing our projects as Mr Murphy is always around the corner.
But for the way we work, the tools we use, the processes we follow, the channels we borrow to communicate with teams with whom we collaborate and cooperate every day: no.
There are not a lot of studies and papers dealing with Common Cause Variation in Agile, nor in Kanban for that matter. For this, you need to exploit the Constraint in your Work Process. If a hiccup shows up at the constraint, you are likely to be dealing with systemic issues. This is where the easy money is made. We are talking big and easy money. Exploiting the constraint in the Work Process is where the goose with the golden egg lives. And it comes at no monetary cost.
No one else in Knowledge-Work renders this better than Donald Reinertsen:
‘’In Knowledge Work, common causes have a greater impact than in manufacturing. Therefore, common causes should be taken into consideration, especially for finding improvement opportunities.’’
There is a subtlety that is often ignored by Lean manufacturing with Common Cause Variation and this cause of ‘no concern’ has been imported into agile. In manufacturing, Common Cause is not a bother. Doing cars serially for years will only have you react on Special Cause – as you pull the ANDON cord!
In Knowledge Work, the tables are turned: Common Cause will happen assuredly and must be addressed. When Special Cause Variation is observed, it is better to fix it if necessary or let it pass and move on, contrary to Lean manufacturing. But we have fallen into the trap of Lean manufacturing when importing Lean concepts into agile. We must be made aware of this and stop reacting to Special Cause Variation as they do in manufacturing. Being enslaved to the busting of column WIP limits is reacting to Special Cause Variation (flow issues) thinking that it is Common Cause Variation. It is a major cause of tampering with the system.
When the constraint starves, it is most probably a system issue due to Common Cause Variation. Why? Because we have a system built around that to prevent it from happening! When this occurs, we must act!
Sometimes, it is nearly impossible to distinguish Special Cause from Common Cause in Knowledge Work. For this reason, many have not bothered to dig further to address this topic.
It would be selling Dr Goldratt short for not coming up with the remedial tools. The Theory of Constraints comes fully equipped to properly classify - in a scientific - way Common and Special Cause with the use of a reason log, frequency analysis, pareto analysis … and common sense.
This constraint lies upstream. It is the business domain. Slack that you have everywhere on the value stream can always be repurposed here to help! It deals with the load distribution of work that is unevenly spread among teams, products, and projects.
One nice way to identify the constraint in the Work Flow with 25 teams is to examine the length of their respective backlogs. If team B has the longest backlog – based on time to finish the backlog – then that team is the constraint in the Work Flow. This is discrete data that you can transpose to a histogram easily.
Remember the phase of subordination? If you want to properly exploit that team, all the other teams could experience idleness. Slack and idleness are always observable in high-performing organizations. If this is not in line with the way you manage, then a lot of perishable inventory will find its way in terms of stacks of analysis, piles of architectures, outdated designs or untested code that will decay with the passage of time.
Members of teams that are not from the constraint in the Work Flow could literally go fishing. It would not make a difference on Throughput or Operational Expenses. But when they are needed … they must be sharp.
Once a team is the constraint in the Work Flow, it must manage its constraint in its Work Process with a DBR board. The other teams can use a simple Flow Efficiency board as discussed in a previous article. The change in instrumentation from a DBR to/from a Flow Efficiency board is trivial.
The constraint in the Work Flow is the place that you are looking for – the team with the heaviest queue in front of it – and where Special Cause Variation strives. There is one and only one team that is the constraint in the Work Flow.
There can be no ambiguity as to which team is the constraint in the Work Flow as the queue of work in front of it is discrete and clearly distinguishable among all teams. It is a decision that is done in one dimension on an absolute scale: which team has the biggest queue in front of it.
The below array depicts how to deal with Constraints in the Work Flow:
When teams come to you for extra budgets, investments or resources saying that they could go much faster with this or that, just remember, only one team – or some teams upstream of the constraints to enhance sprint capacity - may have a justified need for help. For teams downstream, this is seldom the case unless the constraint could shift as a result!
This is an important lesson in Throughput Accounting!
We have covered Flow Efficiency boards in a preceding article. We will leverage its use, first to help us discover the Constraint in the Work Process. Next, we will discuss how to exploit that constraint by adding the DBR Buffer to replace the ‘Waiting For’ queue of the constraining process.
If I were to take a sample Flow Efficiency board, the process with the longest flow time is the constraint in the Work Process as it undoubtedly has the least amount of capacity. Why? Because tickets passing through this specific phase spend more time there than anywhere else.
Let’s look at this illustration:
We can see that a ticket spends on average two days in Phase A, three in Phase B and one day in each of Phase C and D.
The constraint in the Work Process lies at Phase B, where the system has the lowest capacity. Let’s look at this from a different angle with the three types of capacity we have visited before:
Explaining this concept is best achieved with the use of similarities and analogies. No matter who I ask, the WIP Ageing chart is the favorite visual artefact of most Kanban practitioners and I assume that you are familiar with it.
We are all familiar with the Y axis and this is the main use we make of this powerful tool. But what about the X axis? It too can be transposed in terms of days for each of the DEV, UAT and DEMO processes!
Remember the point of managing on the time axis? If it works for the ageing of work items (Y axis), it works for the time spent while in each of the three processes (X axis)!
With the same tool, and by adjusting the parameters, it is easy to extract this data. It allows us to identify the constraint in the Work Process effortlessly. Remember that the team that is the constraint in the Work Flow must manage its constraint in the Work Process. This is important to grasp. The other teams need not worry about optimizing their Work Process. It’s key to understand this point, as we do not want to spend money and get nowhere faster by optimizing non-constraint teams.
With this information at hand, and having identified the constraint, we can now instrument with the DBR buffer as illustrated below by assuming this time that the proper buffer sizing is three tickets after having experimented and tweaked the system in an operational setting:
The use of the colors is in conformity with the Theory of Constraints.
The discussion does not render justice to the way the buffer unfolds as the change in color is dictated by the ‘emptiness’ of the corresponding slot, as shown next:
The DBR board is meant to exploit the constraint. It can be invoked by the only one team that is the constraint in the Work Flow or by at least one team experiencing noticeable constraints in their Work Execution. More on Work Execution signals in an upcoming section.
There can be one and only one constraint in a Work Process. The logic is similar to that of the constraint in the Work Flow: the metric is on a one-dimension scale and self-evident.
As we did upon ramping up the preceding section on the Jungle, here is a similar array for the Jeep:
We have covered the first two constraints in Knowledge Work. Both must be located at a precise point. The third and final constraint, dealing with Work Execution signals, brings us back on the time axis as these constraints are triggered with the passage of time when teams execute projects.
There is a lot of material in CCPM – Critical Chain Project Management – from the Theory of Constraints. Dr Goldratt designed this specifically for project management, for Knowledge Work. Engineers are fond of it. It is in stark contrast to CPM – Critical Path Management – from the PMI. The most distinguishing factor is that a buffer is placed at the end of each CCPM project, absorbing variability (not precisely, but I like the metaphor), while buffers are affixed at the end of pretty much everything you want in CPM, leading to local optimization! CCPM’s buffers are meant to complete the project on time, CPM’s buffers to finish tasks on time. CPM is engineered to start tasks as early as possible, CCPM to finish the project as soon as possible and avoid early starts at all costs.
CCPM and DBR both focus on the time axis to manage execution risks and have a lot of similarities.
Dr Goldratt always believed project estimates were bloated, thus the need to perform a few surgical operations before finalizing a project. In normal times, I would point the reader to a case study or an article. But there is a twist for Knowledge Work when it comes building a CCPM plan. We need to illustrate the mechanics as they stand in a normal context. We will then adjust and see how we can use this CCPM plan and buffer in an agile context.
Let us now proceed with a traditional PMI like plan of 34 days created with the project team:
Step 1: Critical Path Management - PMI
We can see that we have an unresolved constraint as the blue Skill B is in an overlap situation, which is not possible since we only have one blue resource with that skill. We must now adjust the plan and extend its duration from 34 to 36 days.
Step 2: Critical Chain Project Management - Remove Resource Contention for Skill B and extend the plan.
Step 3: Critical Chain Project Management - Cut 50% of Project timeline
Step 4: Critical Chain Project Management - Add a 50% CCPM buffer on compressed plan
The project duration that is communicated to the stakeholders is 27 days.
As mentioned earlier, Bob Sproull spells out verbally the analogy between CCPM and DBR. I took it upon myself to make the following illustration comparing both concepts as I don’t think it has been done before:
I hope you can appreciate the mechanics in the classical world. Now let’s venture into Knowledge Work, leverage probabilistic forecasting – thereby getting rid of estimating - and get a few Kanban tricks up our sleeves.
The Buffer Fever Chart is as rich as the WIP Ageing chart in terms of information given through visualization with the nuance that it gives us much more actionable information. Let me explain.
The Buffer Fever Chart has two axes where X = (%Buffer User) and Y = (%Project Completed).
When we see observations on a Buffer Fever Chart, all points are on a relative scale are called BBR - Buffer Burn Rates - and are given by the following formula:
BBR = %Buffer Used / %Project Complete
The BBR metric has this unique attribute in that it is a relative measure, independent of project size, scope, budget or any other dimension you can imagine. Any project/team can fit on a Buffer Fever Chart once it starts execution.
Some of the popular visual representations of the Buffer Fever Chart are given below, none of which is coherent with the others! The one that is most acclaimed for its construct sits at the bottom right-hand side and is outlined in green. It is the one we will use as a baseline for our discussions to follow :
The Green, Yellow and Red area have the usual meaning for managerial purposes.
How is that chart of any help? Well, you can have one hundred projects plotted on a Buffer Fever Chart, each of which has a different scope, budget, team, Product Owner, division, country etc. All that matters is how well they are progressing through time with respect to the CCPM buffer penetration and adherence to the CCPM schedule.
Imagine the management by exception gift for those managing Portfolios when you can identify among 100 projects those 10 that require preparation for the next monthly meeting! All the wasted time that would usually burden the other 90 teams preparing reports when they are forging ahead safely would be put to better use.
There are caveats. All Buffer Fever Charts have at least
These topics will be developed in the following sections and have never been addressed before for Knowledge Work.
The challenge for agile is to generate a plan that will conform to the 50% cutting of original estimates and adding a 50% CCPM buffer at the end.
And all this must come for free as plans are considered wasteful in all breeds of agile.
We can solve this.
We will demonstrate how to get a free plan that is already at the 50% mark and upon which we can affix a 50% buffer with data that you already have!
Below is a Lead Time distribution from a standard Kanban team board. I will use the average Lead Time threshold (50% is the mean) and add a 50% buffer. It will take me only ten minutes, which is as close as we can get to a free plan that respects the CCPM constraints!
We now have a plan that allows us to use the CCPM buffer and derive the Work Execution signals for each team! If it only took ten minutes, it is deemed a free plan.
We will now activate a real-life situation with Little’s Law. Little’s Law applies between two points when WIP is equal to zero: at the beginning of a release (target scope project) and at the end.
Let’s examine the empirical data we have gathered at work and suppose we have a target scope project of 50 work items. With the empirical evidence of our team, it will take on average 30 days. Time is allowed to slip. We manage on the time axis and the CCPM buffer is there for that very purpose.
For some dates during the execution of this target scope project, we will observe the progression and calculate three things: the Buffer Consumption, the Buffer Burn Rate, and the revised delivery date:
Note: The formulae will be expressed as we go. Note the reference to Little’s Law.
Let’s make it work with a real-life situation:
The project’s critical chain, buffer and key milestones are drawn below:
EXERCISE 1 – CCPM and BUFFERS
On September 7, eight work items are completed.
This team should change the instrumentation of its Flow Efficiency board to a DBR board to leverage the constraint!
Also, projects must never get into an early start mode as it is a key tenet of CCPM. This is where staggering comes into play. The new anticipated delivery date of October 14 must be communicated to avoid early start for those who are awaiting that project’s completion.
EXERCISE 2 – CCPM and BUFFERS
On September 14, 32 items have been completed.
Note the reversal of the previous situation. The CCPM buffer penetration is negative, meaning that it has not been consumed at all. Also, we are progressing at a relative pace of 0.828 days per deliverable when the normal pace of the DRUM is one day on a relative scale on the Buffer Fever Chart. We are going faster than the DRUM rate of ≈ 1.
This team can now revert to a standard Flow Efficiency board. Furthermore, the staggering information given by the penetration of the CCPM buffer would alert all stakeholders that the new revised delivery date of Sept 22 is approaching fast!
Imagine coming to your daily stand-up equipped in this fashion. What do you think the impact on TRUST will be? How do you think the C level will appreciate management by exception with the help of leading indicators of risk materialization on the time axis?
There must always be at least one constraint in the Work Execution, as we will see shortly. How do we proceed when we start three projects with three teams and not a single day of activities has taken place?
We still need to find at least one constraint in the Work Execution.
This is the procedure, beginning with three projects with their respective CCPM plans:
We know that parallelism is harmful and induces multi-tasking. It is a bad idea to start the three projects this way in all cases.
So, we must align the projects at a virtual integration point at the end of all the buffers. This way we reduce parallelism to the maximum and protect all three end dates as follows:
Now that all projects have been aligned and are all green by default since we have not started yet, we must find the constraint in the work execution. It is the one that has the longest path! If until the end of this undertaking, all projects never get to a red status, then Project B will always require a DBR board and be considered the constraint in the Work Execution!
As only one team at a time can be the constraint in the Work Flow, more than one team can be a constraint in the Work Execution with a red indicator. The reason is quite simple as the signal detected for the constraint in the Work Flow is in a one-dimension universe at a precise point in time. (The same is true for identifying the constraint in the Work Process!)
For the constraint in the Work Execution, things occur over time and we operate in a two-dimensional universe with relative scales. Team A and Team B can be totally decoupled on the time dimension making it impossible to discern who is in worst shape. Let’s look at a Buffer Fever Chart instantly by calculating some observations along the DRUM line where the BBR is equal to one (X axis/Y axis):
Every point on that graph has a Buffer Burn Rate coefficient. As a matter of fact, the DRUM line has Buffer Burn Rates of 1 all along its line. An infinity if we recall our basic geometry classes pertaining to the number of points along any line! This is the first time I see a Buffer Fever Chart with the DRUM line cutting through it. We will see that this is far from trivial when addressing downside risk and engineering psychological flow.
The same BBR value phenomenon can apply in the red zone as well where we could encounter many teams with a BBR of 2 for example. In this context choosing the ‘one team’ that is the constraint in the Work Execution becomes a misnomer.
This is why we must have at least one constraint in the Work Execution, and maybe more!
To conclude this section, here is the traditional array depicting the attributes and remedies for the Constraints in the Work Execution! Contrary to the two preceding constraints, this one is triggered by time (when). The other ones are a physical location (where).
We have covered all the materials pertaining to the three constraints in Knowledge Work and walked through both Flow Efficiency and DBR boards. The former (DBR boards) applies to the one team that is the constraint in your Work Flow and as well to at least one of the teams that have Work Execution Signals. The latter (Flow Efficiency boards) applies to all the other non-constraints teams.
Here is a table to facilitate the escalation process in a multi team setting once you find a constraint in the Work Flow and/or Work Execution and apply the remedy with managing the constraint in the Work Process for each of those teams:
As an example, let’s visualize the relative status of all teams with a Buffer Fever Chart in a Portfolio. Their BBR (BUFFER BURN RATE) is punctuated by colored triangles.
You can easily see here that three projects are in the RED zone. The X and Y axes of the Buffer Fever Chart are both one a relative scale. Being on a relative scale with two axes is far from being on a discrete scale with one dimension as was the case when we tried to identify the Constraint in the Work Flow, which was identified by the team having the single biggest queue of work ahead of it! For this reason, we should allow more than one constraint in the Work Execution.
In the situation above, I would not give too much thought to the GREY project as it is near the finish line and has BBR of 1.1. As far as the YELLOW and DARK BLUE projects on the upper left quadrant are concerned, I must admit that picking only one would make me uncomfortable for the simple good reason that they both have the same BBR of 3! I would therefore recommend that both teams instrument a DBR board to manage their respective constraints in their Work Process!
By looking at the graph that I have made of colliding BBR coefficients below, you can tell that there lies an infinite number of occurrences of 1.0. For a BBR of 2, there can be much more than for a BBR of 4, but too many to limit our thinking that there can be only one constraint in the Work Execution: too many synonyms and collisions! BBR’s in circle are all collisions.
Finding the ‘hottest’ one can be impossible at times and purely a judgment call, hence the argument to support the possibility of having at least one constraint in the Work Execution. Humans are very bad at integrating and interpreting data. Let’s not give Mr Murphy a say.
The representation of the Buffer Fever Chart above is the one that is most commonly used in the market and the most coherent. Despite this, it has a flaw that we will address in the next section.
Psychological Flow has been researched extensively by Dr Mihaly Csikszentmihaly. Flow is a state of mind in which a person becomes fully immersed in an activity. Festina lente is the best way I can relate the concept of flow to Agile and Lean and Kanban: sustainable pace at the team level!
Dr Mihaly Csikszentmihaly argues that flow is something that is self-managed for an individual, but the team is the unit of measure in agile – along with management – and in that perspective flow must be engineered on a collective scale.
More than a dozen factors have been tabulated in order to locate FLOW. Two dimensions suffice to derive it: Anxiety and Boredom. Being able to transit at will between these two states is how you manage flow as an individual. When you want excitement, you can go deep into the ‘RED’ anxiety zone and when tranquility is needed to replenish, you can find a safe harbor in the GREEN zone as illustrated below:
Can you notice the similarities with the Yellow strip of the Buffer Fever Chart and the RED and GREEN triangles that mimic all of the components of a Buffer Fever Chart?
Something peculiar arises when we give second thoughts to the RED and GREEN areas of the Buffer Fever Chart. And something totally wrong lies within the YELLOW area as we hinted earlier.
Let’s examine the familiar illustration below:
When a team is in the red area, it is performing poorly… or are the team members overloaded, overwhelmed and filled with anxiety? What can be done to rectify the situation and push the team into the yellow zone, the flow zone?
Contrariwise, when a team is in the green zone, is it a great team or one without challenge? A bored team? Is there a solution to resolving this dilemma and moving that team into the yellow zone?
Buffer Fever Chart comes in many flavors. All of them are wrong for Knowledge Work! There is a hidden beat in this graph, a DRUM-like beat discussed before when the BBR (Buffer Burn Rate) is ≈ 1. It is never shown on any of the visual representations. But being below that DRUM line – in the next illustration - is not a source of worry. It is what we can relate to downside and upside risk in finance with. We care only about downside risk. The risk that is in the upper part of the yellow zone trending to RED!
The Yellow zone, attributed as a ‘warning zone’ when the BBR is ≈ 1, is not actually something to fear. When the BBR is below the DRUM beat, we are in a safe place at a good pace. Well ahead of the plan. The color Yellow is not appropriate at all for psychological flow.
Blue is in fact a better representation for the flow zone. The tiny drums inside the new blue flow zone are shaded in blue near the white DRUM line and in light red or light green depending if you are getting close to either the red or green zone.
When we are below the white DRUM line, we are perfectly fine. We are not in a YELLOW mode as we all understand it to be. We are nothing short of GREEN.
Let’s see if we cannot find some insights in molding the penetration frequency of the RED, YELLOW and GREEN zones of the CCPM buffer that will impact the Work Execution signal generation. (We must revert to the traditional colors now as their meanings are appropriate when considering buffer penetration.)
The size of the CCPM buffer does not have to be 50%. We can orchestrate it to alter the frequency with which we cross into the three zones. This is where social engineering comes into play. It becomes a managerial decision depending on the circumstances. (For example, by next fiscal year end, we may want our development team to accelerate the pace to get some pension fund applications out before January 1st! In the summer we might revert to a slower pace by architecting the CCPM buffer accordingly as we will see below.)
The same project – starting October 01 with a due date of Nov 21 - appears below with three different CCPM buffer sizes:
The BLUE configuration is the standard one derived from the customary practice of the CCPM method, the RED configuration aims at hastening the pace, while the GREEN setup slows the cadence.
It will come as no surprise that the project with the smaller CCPM buffer will generate more Work Execution signals and that the project with the bigger CCPM buffer will send fewer signals. It is a way to do some social engineering on the flow of the teams with positive stressors. Of course, each project appearing on a Buffer Fever Chart can have different buffer configurations, since they are all represented on a relative scale irrespective of scope, budget, timeline and … CCPM buffer configuration!
We will now leverage the new representation of the Buffer Fever Chart for Knowledge Work, with the explicit white DRUM line and the blue flow zone.
The following depicts the same project with the three buffer configurations we have addressed above on the traditional Buffer Fever Chart:
We can see the different configuration of stressors dictating the random walk of the same project into the different zones as shown below:
There are a few things to be addressed in this new approach. For example, a yardstick for semi variance to assess downside risk. What is the numerical threshold for a ‘RED’ BBR? That is to be determined. When the BBR is equal to or less than one, there really is nothing to worry about. So maybe only two zones are needed instead of three.
We have touched on subjects that have never been addressed in Throughput Accounting for Knowledge Work. Let’s review them:
At the day-to-day level, this article is full of tangible and actionable knowledge that you can start using tomorrow if your systems are predictable, stable, and obey Little’s Law. You can ascertain this with your CFD and check if the demand and delivery lines are parallel when the work enters and leaves the system. (The Product Backlog is not the demand line as it lies outside the system).
Managing on the time axis should be a strategic imperative. It paves the way to management by exception. It is in line with the essence of Inherent Simplicity and the spirit of the teachings of Throughput Accounting as time lost at the constraint is Throughput gone forever. There is a broad enough knowledge base in Agile regarding what goes right and what goes wrong to embrace the new avenues that Throughput Accounting for Knowledge Work brings to the table.
I cannot stress enough that nowhere in the Agile Manifesto does it state that timeboxing is warranted.
The science behind CCPM is considerable and has taken aback many agilists, notably the Poppendieks. Simply taking the CCPM buffer and creating free plans at will with your empirical data can lead to project execution excellence that has no comparison in the world of agile. And to paraphrase a quote from my book: “What most approaches fail at is not in the planning itself, but in how the execution is managed. We should stop thinking about the execution of the plan, and more specifically about the execution of the work (work that was presumably planned) with the use of leading indicators and Management by Exception.”
Knowledge Work has yet to embrace constraints awareness. We know without a doubt now that the Work Flow, Work Process and Work Execution can all be subject of constraints. The biggest platitude we hear regarding constraints in Knowledge Work is that they move all the time. Not so. We can pin down a constraint by limiting its capacity for one thing. We have also gauged in article one that discretionary and targeted actions with Throughput, Investments and/or Operating Expenses could prevent the constraints from moving.
The cost of decision making at the Portfolio level defeats the purpose of decision making! The Buffer Fever Chart is a fantastic tool as it brings the panoply of projects attributes down to a relative scale. Just imagine the quadratic time savings obtained when you only need to invite the projects/teams that are in red and let the others work!
We need to simplify life for top management and embrace the time axis, for the times they are a-changin’!
- Daniel Doiron, CPA
I am three parts IT, one part Agile. The next part of my career will be in Throughput Accounting in the Agile arena where the space is still to be occupied. My contribution to the Agile World and Throughput Accounting is novel since I provide the first comprehensive content on that topic. Making money is very agile. It allows you to better yourself, to spend more time with your family, to contribute to society. What justifies the low bandwidth on that topic in agile? It certainly has to change.
I love systems, enjoy measuring improvement while embracing teamwork that actually works and find its way on the bottom line!
For more on Throughput Accounting for Knowledge-Work, visit https://www.agileagonist.com/
Staggering from CCPM is a gift to all stakeholders involved in a project. It deals with the CCPM buffer. When multiple projects run sequentially or in parallel, their start and end dates are adjusted in real time with the penetration level of the CCPM buffer. It allows for dynamically adjusting resources and providing proper communication to all involved. It is also a tool of management by exception: giving us advanced signals of risk materialisation on the time axis.
You can control the company’s workload in a Portfolio by pipelining and staggering projects to make realistic commitments to deadlines.
 This short video from Brian Cox: https://www.youtube.com/watch?v=uQSoaiubuA0 is captivating.
 BLUF – Bottom Line Up Front
 Oddly enough, this can be a reason why Cost Accounting systems are being used for managerial purposes. They are so expensive that management will find a way to leverage them! But they are not fit for decision making purposes in a daily and operational context.
 I always like to illustrate the topic of degrees of freedom of scope with the Table of Content of a book. Things can go exponential and quadratic quite easily.
 Smith, Debra. Page 92: ‘Measuring subordination is difficult but is key to ToC success’. Page 80: ‘Subordination is the basis for 90% of a company’s activity’.
 Maintenance work on the constraint must be well planned, Quality inspection upon entering the constraint is a must, increasing Sprint Capacity (capacity upstream of the constraint) with existing Investments and Operating Expenses, increasing buffer size, T Shape resources, etc.
 Lucas’s critique (1976), states that we often import and apply models out of context. Such is the case with the merits of Common Cause and Special Cause that are totally inverted in their significance from the world of Lean manufacturing to the arena of Knowledge Work. Lucas pointed out at the time that transposing macroeconomics models to the economics of the firm (micro-economics) was nonsensical.
 Some prefer the term ‘assignable cause’ - something that you can point to.
 Some prefer the term ‘chance cause’ - something that is endemic or systemic to a process and cannot be linked to one root cause
 There can be at most one team that is the constraint in the Work Flow and no more!
 In case of a tie breaker when more than one sub-process shows the same capacity constraint, you must elect only one as the constraint in the Work Process. The constraint is always the one under active management. This is a one-dimensional issue as identifying the constraint in the Work Flow. Constraints in the Work Execution are supported with metrics that are in a two-dimension construct with relative scales and are of a different nature. At least one team with a constraint in the Work Execution is warranted. There can be more than one!
 The CCPM buffer is a leading indicator of oncoming risk materialization. Donald Reinertsen’s principle V11 states that ‘buffers trade money for variability reduction’. The CCPM buffer comes for free but technically does not absorb variability! It is an advanced signal of upcoming negative variability.
 For a complete explanation of this, see Sproull, Robert and Nixon, Bruce. Chapters 16-17 and Appendixes 6-7
 Parkinson’s Law, Student syndrome, Sand bagging etc. are all foes of project estimates. Dr Goldratt accounted for resource contention, then cut all project estimates by 50%, and added a 50% CCPM buffer at the end.
 Book: ‘Epiphanized’. Page 194 – ‘’The critical chain is the drum, the buffer is the buffer, and the project due date is the rope.’’
 See Appendix A for details pertaining to Buffer Consumption
 See Appendix B for a detailed representation of staggering
 See Appendix A for details pertaining to Buffer Burn Rate
 The team delivers many types of work items: reports, CRUD, interfaces, queries, ETL and the likes at a pace of (50/30) 1.66 work items per day. (Observation: that 1.66 work items per day sounds like the beat of a DRUM!)
 Of course, when we revise the new end of project target date, we could end before September 30!
 Buffer Fever Charts transpose all projects on a relative scale during execution independent of budget, scope, team, division or schedule!
 Make haste slowly
 The topic of semi variance to assess downside risk is still eluding the world of Finance. The solutions harnessed have major flaws. Maybe the ToC community can come up with something pertinent.
 Song by Bob Dylan 1964 – If you listen to the lyrics, there is a lot that applies here in the last minute of the song! I propose it becomes the official song of Throughput Accounting and the Five Focusing Steps! Maybe at the next TOCICO conference. https://www.youtube.com/watch?v=K0w6ReLIPUc
Please subscribe and become a member to access the entire Business Agility Library without restriction.