Not understanding Buffer Fever Chart

I get the use of fever charts and buffers in CCPM. What I am struggling with is how these would apply when utilizing the Kanban Board and usage of Monte Carlo simulations.

In CCPM we reduce the estimates by 1/2, then apply the remainder of the estimate as a buffer. Then we track our actual task completions and monitor how far our end date is pushing into the buffer. Green/Yellow/Red tells us how we are doing and whether we need to start taking action.

The above has two requirements:

  1. there is an estimate for each task
  2. The tasks are tracked individually.

I have been using Dan Vacanti’s tool to determine when my projects will be done. There are no estimates for each deliverable. We simply track each deliverable as it works across the Kanban board and record the date it is completed. Focus is on maintaining Flow and monitoring the age of our Work In Progress to insure work items don’t stagnate. Each day/week we record how many work items completed. This establishes our throughput distribution which is used to feed the Monte Carlo simulation.

Once we have several items completed we can begin the simulations, realizing that our throughput history is not very good. The Monte Carlo simulation takes random samples from this historical throughput history and applies that value as an predicted throughput value for the next day in the future. This is repeated for each day into the future until there is nothing left in our backlog for the project. This is our predicted date for the project to complete, but it is just one data point.

The process above is repeated 10,000 times which generates a distribution that looks something like this. Our red zone indicates that if we are promising a date that falls in this range we are living on the edge. If we are promising a date that falls in the green range, we are in much better shape.

TameFlowPost

Each week, our throughput distribution is updated with the results of the past week. Assuming no material change has occurred to our “system”, these data points are included in the throughput distribution with all previous completed items and this “new” distribution is used to feed our next Monte Carlo simulation. The new simulation now has new data, and less items to complete, and the simulation is recorded from today’s date forward. Again, we get a distribution of 10,000 samples showing what the new probability is for completing by the date we promised our customer.

The big difference here is that I don’t see a need for the buffer and tracking with a fever chart. I simply continue to feed the simulations each week with the latest throughput data and monitor the date I am most likely to complete the project. This calculation of 10,000 samples takes less than a minute. If I am really feeling frisky, I run the simulations for a million samples which takes less than two minutes.

I feel this is better than fever charts as the estimates (notoriously bad) don’t come into play. We utilize the modern tools to continuous monitor our delivery dates. As we collect more and more data, our risk continues to reduce and we start to zero in on our true completion date. We still leverage the Red/Green/Yellow, but in a different way.

We simply ask the teams to focus on Flow and minimize queueing time as much as possible. We rely on the team’s knowledge of the work to properly sequence the work and monitor the throughput output to determine how we are doing the and where we stand.

FWIW

2 Likes

Welcome !

We use Buffers as signals in the hope of detecting common cause variations. That which no other approach does.

We had a chat on that very topic on one of the earlier campfires … Using TH distribution is the long way home. Campfire no 3 at 50:50 onward … and campfire no 2 at 42:00 onward

Judging by your level of sophistication, I am sure you have Flow Time distribution. Use those.

We need a reminder here that a plan at no cost is required, as was pointed out in yesterday’s campfire no 8 with Herbie at 41;40 onward.

Cheers

I guess I am unclear on how I would set the buffer if I am not performing task estimates and / or developing a CCPM plan. However, I will review the campfire sessions you reference and see if it helps.

1 Like

Hi @euim817boling

Glad to see your contributions here.

  1. Great that you use Dan’s AA + Montecarlo. If you have a Montecarlo projection, just place the buffer say between 50% and 80% percentile.

  2. If you only want to answer the question “When will it be done?” then you are right: using AA + Montecarlo is all you need. You can drop Buffer Mangement…

  3. But in that case you would be missing the signaling system that comes from buffer management, and that has profound implications on the Informational Flow which you would not have otherwise.

  4. If you don’t take notice of the signals and maintain a “Reason Log” (see Chapter 21 in the “Hyper” book for that), then it will be very hard to systematically address Common Cause Variation, which is where the process can be improved a lot (note: this in knowledge-work, not in manufacturing).

  5. We do NOT use estimates. In fact we advise to use the methods that Dan Vacanti teaches.

  6. We do NOT use the planning practices of CCPM.

  7. We DO use the execution management practices (i.e. buffers and buffer monitoring) of CCPM.

  8. Like with your description, the buffer placement can be updated on a rolling basis; though I would advise against doing that. It is far more significant for overall performance improvement to have a system of signals and handle them; rather than being maniacally obsessed about predicting the date of delivery.

  9. In a PEST environment, without Buffer Management, you will not be able to focus on the Herbie team of the moment (i.e. Constraint in the Work Execution). Buffer charts “normalize” the criticality of all teams, and you can zoom in on the one that needs help. See Chapter 20 in “Tame your Work Flow” or the blog post Visual Portfolio Managment

In short Buffer Management is not about forecasting when will it be done; it is about triggering the right conversations, at the right time, with the right people and provide an overarching system of governance. So what matters most? Predicting that delivery date, or having a system that allows the right people to keep their eyes on the right ball at the right time?

In a forthcoming Campfire we will maybe develop the topic further.

3 Likes

The other chart that is routinely used is the WIP Aging chart which shows where the current work items sit in relationship to their predecessors. Each column on the Kanban board has a red-yellow-green area just like the buffers you are suggesting. They represent the historical distribution for each column on the kanban board and where the current work items are in relationship to the other work items that have flowed previously. As you have previously stated, living in the yellow means we are pushing the team.

It seems to me that this chart performs the same function as what you are suggesting. Am I interpreting it correctly?

2 Likes

I just got limited by the “new user” restriction to only one image per post, so here is my final contribution.

Additionally, we try to improve the process by monitoring our cycle time for the board utilizing the Cycle Time scatterplot. The goal is to shorten the cycle time which will tighten up the Throughput distribution as well.

I believe this is the equivalent of Flow Time distribution that Daniel mentioned in a previous post. Flow Time = Cycle Time in my world.

These are the three charts routinely used to monitor our processes.

For what it is worth, Dan’s tools are available as standalone on his website. Kanbanize has recently standardized on this tool as their metric tool of choice. Metrics are directly obtainable from any board in their system.

2 Likes

Hi,

The WIP Ageing chart is indeed a signaling mechanism. But it is not an indicator of a plan getting into schedule and execution risk materialization. It is not related to a Buffer Fever Chart at all.

For that you need a CCPM buffer, which comes at no cost as you are building your MOVEs.

Hope this helps

Thanks for all the feedback. I am going back through the Hyper Productive book and re-reading several parts of it. Actually never read it fully as my first introduction to Tameflow was the latest book. I have to admit that reading either of these books all the way through is not feasible for my old brain, but that’s a whole other problem

The whole buffer thing around each workstep on the Kanban board is just now starting to sink in. Thanks again to Daniel and Steve for the feedback. After all, feedback loops are great, right? Hang with me as I catch up to the rest of you guys/gals. I am pretty sure I am the Herbie in the group.

2 Likes

HI,

I have read both the Hyper book and Tame Your Work Flow books … I am still learning … Literally …

Thank God there are spaces between each words so I can take a 30 minute break!

No.

We use this chart too. See Chapter 20 of the "Tame your Work Flow book.

It is great for detecting single work items that are… well… ageing.

But it is not giving you any signal at all on the health of the MOVE to which that item belongs.

The ageing chart and the MOVE Buffer could give different signals - and that is OK because they focus on different things. The MOVE is the collection of Work Items that give you some business value.

1 Like

No it is not the same kind of diagram. The Actionable Agile tools has another diagram (cannot recall the name, maybe “Cycle Time Distribution”) that is the equivalent.

We also use Scatter plots. They’re good to detect certain patterns. Dan Vacanti describes them in detail in his first book.

1 Like

We all subordinate to Herbie! We leave no man behind! :slight_smile:

1 Like

Again, thanks for the continued feedback. The focus on Herbie (me) to help him remove the weights in his backpack (my weights are lack of knowledge) will help my pace increase. Soon it will be time to start focusing on another Herbie…

3 Likes

@euim817boling I read your post a few hours after you published it, but didn’t have time to reply until now.

I must admit it did raise a lot of red flags and alarm bells as it seems to go against so many of my mental models. (My two biggest ones being “Keep things as simple as possible but not simpler” and “Feedback control is extremely powerful when done correctly”).

I am, however, genuinely interested in understanding the thought process and environment you operate in to correctly grasp the benefits this simulation provides for you.

  • When you record the completion times for each task at the end of each week to you also keep track of who did the work and the “nature” of the work? (i.e. each task fundamentally falls into different “categories” or may have several defining features. Do you explicitly record these when entering them into the system?)

  • Do you enter all the tasks you feel need to be completed, with their defining characteristics, at the very start of the project? (i.e. break a project in to many different tasks.)

  • Are you allowed to enter new tasks during the project as hidden complexities manifest themselves and need to be accounted for? (Or perhaps “refine” the categories a task belongs to, as the project unfolds?)

  • At which point within the duration of a project can you start feeling confident the project will finish within a given window? (i.e. at what stage do you feel certain you have a 90% or 95% confidence interval within which the project will finish?).

  • What I like about such a system is that it keeps track of all the information from the beginning so you can double check how accurate the projections were at every stage (and from week to week). From your experience how accurate is it? i.e. when it calculates the projections for the coming week, how well did it predict what actually happened when you get to the end of that week? How close were the projections for the project completion at the 1/3, 1/2, 2/3, 3/4 marks when you finally completed the project?

Having asked all these questions, my biggest concern is actually not the numbers or the accuracy of the projections, but rather the psychological impact or expectations it sets on team members.

  • Of all the projects you have done using this method have you ever finished earlier than the mean? What is the best standard deviation (to the left) you have achieved at the 2/3 mark?

  • In your experience what are the biggest benefits of using such a system?


In the case of CCPM, the biggest advantages as I see them, are its simplicity and feedback mechanism.

The estimates are nearly completely irrelevant. If anything they might provide some psychological comfort to team members that their opinions were considered, but at the end of the day it is just an opinion and not much would be lost if this step was skipped altogether.

The biggest advantage of the fever chart is providing a signal that there is a problem and provides the means of quickly locating it, so that it can be effectively managed. It is actually better than that. It is a signal that a problem is about to occur and gives people an opportunity to fix it before it does. It is a focusing tool.

From a psychological point of view, we just need to make sure the buffer isn’t too small as to create an environment where people feel continually defeated. But you don’t want it so large that people become complacent. How you define the buffer, apart from that, really does not matter.

The fever charts provide an excellent focal point for teams to rally around and collaborate together in order to “win the race” against the buffer. Essentially it is just an excellent feedback mechanism that helps teams focus on what really matters at any given point in time. What more could we ask for?

In other words, what is more useful:

  • Knowing you will complete a project in the shortest possible time from the very start (even if you don’t exactly know when that will be)? … or …
  • Knowing the completion date of a project with a 95% confidence interval only at the 3/4 mark?

(Just to be clear, none of my questions are meant to be rhetorical. I would genuinely appreciate an answer to them if you have the time. I may have missed something.

I also don’t want to give the impression that I am completely dismissive of estimates. They do provide a lot of valuable information, when compared to “actual” durations. My post is focused on the usefulness of using fever charts as a feedback mechanism.)

3 Likes

Thanks for your response. In order give your post its due, I feel the need to break it into multiple posts as I believe (and actually want) many of your topics/questions to turn into their own threads. Be on the lookout for multiple posts forthcoming. Just beware, you may have created a monster as I believe I will have just as many questions as I do responses to your questions. It’s all about continuous improvement, right?

2 Likes

@euim817boling and @bvautier… it seems that this will be really interesting… Please go ahead! I’ll grab some popcorn… :joy:

@bvautier I am not so concerned about accuracy of estimates/forecasts/predictions but of the dynamics of communication and interactions that can be triggered during execution. And as you observe, Buffer Signals are an excellent trigger of this kind. It is way more important to develop the right mindset/attitude than to have a perfect crystal ball! :slight_smile:

3 Likes

Thank you for accepting it in the spirit is was intended. I am curious by nature and enjoy learning new things. I am more than happy to be wrong and willing to change mental models when I find better ones.

Yes it is all about continuous improvement.

(My only reservation is that I am fairly busy during the week and don’t always have time to respond until the weekend.)

1 Like

We are on the same page. Large differences in estimates compared to “actual” durations often provide valuable feedback, such as:

  • A task was given to the wrong person (Improve the way we allocate tasks, or upskill the worker or team)
  • A task contained hidden complexity which should have been split into 2 or 3 tasks. (Learn how to recognise this for next time)
  • etc…

Yes that is how I feel as well, but there may be some merit in using monte carlo simulations which is not immediately obvious to me.

It may not be of use for me, but I am genuinely interested to know how it benefits others within their context. (My context may change one day, and knowing myself, the probability that I may have overlooked something important is very high.)

1 Like

Hi Doug,

These six articles from the chronologist dating as far back as 2012, truly explain what buffer management is and what is was inspired from :

It is a very very dense read. Here they are :





Ciao

Thanks for the articles. Very helpful, but I admit I still don’t get one part of this.

Let me better outline my scenario. Let’s assume we have a set of teams that each provide a unique service to the organization. These teams each have a well established Cycle Time. The cycle time is derived from a cycle time scatter plot. A Flow Time histogram is a direct derivative of the cycle time plot.

The teams do not perform estimates as part of their planning for a new project. They use probabilistic forecasting. As such, the teams focus on breaking down their work into chunks that they believe can be worked within their particular team’s cycle time.

The work items are grouped in MOVEs. For the sake of simplicity, let’s assume my project has only one MOVE. That contains 35 work items/deliverables. A Monte Carlo Simulation is generated for the MOVE prior to the project starting and shows a 50% probability of completing in 40 days and an 85% probability of completing in 90 days. Using Steve’s guidance, we would establish our buffer between 40-90 days, a total of 50 days.

It is here where I start to lose it. I start my project. To generate the fever chart I need to determine how far into 50 days I have penetrated. At the end of the 10 days of work, I have completed 6 items. What is my estimate of penetration into the buffer?

It seems to me that in order to use TameFlow’s Fever Buffer charts I must have some sort of estimate for each task and a critical chain of tasks.

My technique is to update my throughput chart, use that as input into the Monte Carlo Simulation (MCS), reduce the number of items left from 35 to 29, calculate a new MCS, and notice where my 50% and 85% time to complete now fall.

After working 10 days, my new MCS now shows that it will take an additional 35 days to finish at the 50% confidence level and 82 days at the 85% confidence level.

My end date for the project (85%) has now shifted from my original estimate of 90 days to 92 days (10 days+82 remaining)

Where am I on your fever chart?

1 Like