Buffer size - DBR board

I am referring to the buffer placed in front of the constraint on the DBR board (Chapter 14).

The size of the buffer is discussed in terms of the number of tasks it should hold at any given point in time.

The size (or number of tasks) the buffer can hold is governed by the location of the constraint within the board. (i.e. if it is closer to the start, the size will be smaller than if it is located towards the end of the board).

Couldn’t we think of the buffer in terms of time?

Namely (things that we need to take into consideration):

  1. The total duration of work inside the buffer (regardless of the amount of tasks)
  2. The duration of the task currently in process (especially the time left to completion)
  3. The time it will take a task to get to the constraint buffer once it is released into the project.

There are some interesting dynamics at play, especially if the duration of each task is vastly different.

Point 3 is interesting because we need to prioritise each task in the Full-Kitting column. And yet, it seems as if, the time it will take a task to get to the constraint buffer will weigh on its priority. (In other words the priority of tasks yet to be released into the project, will potentially change depending on what is happening at the constraint, and how long it takes them to get there.)

Thoughts?

See Any tips on what value to use for initial buffer size on TameFlow-Kanban?

Note: Full-kitting happens way before anything goes into the “flow.” Not sure I understand your comment about point 3 in relation to Full-kitting.

In general: don’t get over complicate calculations. Be pragmatic. Let the buffer tell you what you need to do. Just start with a buffer on Herbie. If it is constantly depleted (like in the red), make the buffer larger (i.e. give more time to the upstream work to reach Herbie). No calculation needed, just observation and dynamic sizing of the buffer. If the buffer is always green, raise the bar and make it smaller. Buffer sizes/positions are never cast in stone.

4 Likes

Thanks @tendon ,

I read the link and it does answer a few questions and raises some others :slight_smile:

I agree we should keep things as simple as possible. What I am thinking about would not be complicated to put in place, and I like the conceptual symmetry it has with a fever chart. (i.e. managing the constraint buffer with a similar chart rather than a hard number.)

This is more an exercise in exploration, and would be unnecessary for small projects or when the constraint is close to the start of the work flow. (i.e. it would probably only make sense for managing a constraint that is required by multiple projects and happens to be located towards the end of the workflow.)

This get’s interesting because if the constraint is required by multiple projects it could be located at different positions with respect to the work flow for each project. (For some projects it may be closer to the start and in others it may be closer to the end.)

Yes, I am assuming several tasks are fully kitted in each project and are ready to enter the work flow at a moments notice. Each task (belonging to different projects) would have an overall portfolio priority assigned to them.

Let’s assume the constraint is currently working on a task, which it will complete in 3 days time. The constraint buffer is empty. The next most important task across the whole portfolio will take 5 days to reach the constraint if it enters the work flow now.

This isn’t good because the constraint will be idle for 2 days if we do that. So we have no other choice than to find the next most important task within the portfolio that can get their faster, hopefully within 3 days.

Now I understand we shouldn’t have an empty constraint buffer in the first place (but will get to that shortly). The next best (hypothetical) choices are listed below:

  1. Task portfolio priority 5, project A. Time to get to the constraint 3. Process duration 4
  2. Task portfolio priority 10, project B. Time to get to the constraint 2. Process duration 10
  3. Task portfolio priority 1, project C. Time to get to the constraint 5. Process duration 2

We are faced with a dilemma.

If we go with choice 1. we must hope Murphy will not strike and that we will get the task to the constraint in time. If it does strike then the constraint will go idle until it arrives.

With choice 2, we have a one day buffer in case Murphy strikes, however the problem is, this task has a really low priority and its process time is very long. So much so, that when the task with priority 1 arrives at the constraint buffer it will have to wait 8 (days) before being processed. (What is best letting the constraint go idle for 2 days and process the high value task quickly, or keep the constraint busy but make the high value task wait for 8 days?)

With choice 3, the constraint will be idle for a minimum of 2 days (all going well).

So what I meant by point 3 in my original post is that the initial priority needs to be adjusted when you take into account the time it takes for the tasks to arrive at the constraint buffer, if the buffer is running low.

How should the priorities be adjusted is the open question. (and is perhaps too academic, but found it interesting nonetheless.)

How did the constraint buffer get empty in the first place?

Let’s assume we have several tasks ranging from 1 to 10 in process duration, with a mean of 2 (I really think median is a more accurate parameter).

The task with a duration of 10 is currently being processed on the constraint, but the average in-state flow time is 2.
The average time for a task to reach the constraint buffer is 6
The constraint buffer has 4 tasks in it, each with a duration of 1. (No other tasks are on their way to the buffer).

When the constraint finishes its current task, it will then process the 4 tasks that are currently in the buffer within 4 days. Even if the signal to replenish the buffer is immediately sent the minute it starts working on the first buffer task, it will be idle for 2 days (at best) before the next task arrives.

Rather than using hard numbers for the constraint buffer we could elegantly deal with such situations with a chart. (but only for multiple project scenarios).

This indicates either (1) there’s been Mr. Murphy (special cause variation) visiting the upstream part or (2) buffer management was not done properly.

Again: this is what buffer management is designed to prevent. And in no case should you skip the priority order.

Artificial dilemma. You won’t find yourself in that situation if buffer management is done properly. Unless, as mentioned, you have Mr. Murphy doing something bad to you.

Also, you seem to be skipping the “Commitment” column in your narrative. If things are not committed, you can very well reschedule them according to last minute information - like the unplanned impact of Mr. Murphy. But once something has been Committed to, you don’t change, no matter what reason. Committed is Committed. Period. It is a policy that we institutionalize and enforce. A single exception will allow all other sorts of exceptions to creep in, and then you’re back fighting HiPPOs and multi-tasking. Non-negotiable. Agreed to with the social contract involving all from the CEO downward. Part of the system design.

Of course the counterpart here is that you should limit things in Committed to the minimum possible, so as to keep the options open, but not so much that you are then starving Herbie. A heuristic is to keep the amount of items in Committed equal to the size of the DBR buffer. But once they’re in committed, they’ve boarded the plane. Any other things will have to wait for the next flight.

Whenever there is new information (like the Murphy effect) that suggest you need to reschedule (anything outside of commitment), you should not reason in terms of absolute delays or idleness of Herbie. The only decision criteria is overall difference in terms of Financial Throughput.

So your 1, 2 and 3 alternatives are missing one important - actually essential - piece of information: what is their Financial Throughput Rate on Herbie? And what is the variation (Delta) of Financial Throughput between them?

You optimize for maximizing Financial Throughput. Draw a Dollar-Time diagram with the three Total Throughput lines for the three options. You will easily see which alternative gives the most bang for the buck. This diagram works both for a single team as well as for multi-team settings.

Don’t readjust schedule according to timing criteria; but according to economic criteria.

With your examples, I fear, you get lost in the details. Look at the overall Throughput, from a Little’s Law, probabilistic perspective. This urge to go for detailed time analysis is reminiscent of traditional Gantt chart style project management. I feel it is distracting from what you are trying to achieve.

Another thing: not sure we are aligned on the granularity here. You talk about “tasks” but what is subject to the full-kitting activity are not tasks. The units of Full-Kitting are MOVEs. It is more like a “work package” in conventional project management terminology.

1 Like

I wonder if there is a simpler solution. To me, if the buffer in question is so challenging to fill, perhaps the wrong constraint has been identified. If the three work streams are not sufficient to keep the designated constraint utilized, then that would call for adding additional input workflows. If additional input workflows cannot be added, then the workflows or something leading to them would be the actual constraint.

OK

Thanks for clarifying. It helps solidify all of these concepts.

ditto.

OK

I am only using a concrete example to make things easier to follow.

What I am trying to get at is, the standard variation of the duration of the tasks is actually important and can have a detrimental impact on the constraint buffer management strategy.

This can be resolved in two ways:

  1. Either we ensure the task durations have a small standard deviation
  2. Or we use a more precise feedback mechanism to manage the constraint buffer

I was trying to figure out if TameFlow had a preference for point 1 or not.

I can foresee a potential problem if the task durations have a large standard deviation and the constraint buffer is located towards the end of the work flow. It might not play out in practice. I was just exploring and am happy to leave it at that.

Thanks for clarifying. I haven’t gotten to Full-kitting yet. My terminology is off (apologies). I was referring to the “full-Kitting” column as the column work enters into the work flow. (i.e. the starting point as shown on the figure of page 226).

From your previous explanations I should have referred to committed work. As you point out, once it is committed the priority will not change. End of story. :slight_smile:

That isn’t the contention. The issue is about the signal mechanism and the timing to allow new tasks to enter the work flow. I believe something more precise yet simple, is possible (rather than using the number of tasks in the buffer).

As Steve pointed out, he has never had an issue with it so let’s keep it (super) simple.

Shock statement: variation of task duration is mostly irrelevant.

So the solution is neither (1) nor (2); but simply to ignore it. It is noise, with no real signal.

Variation of task duration may have some relevance once you have killed all Wait Time. But if you are in a situation where Flow Efficiency is low - which is the case in Knowledge-Work - why worry about something that maybe has a fractional impact on 5% of the time that matters: the end to end Flow Time. And then only if you are really hitting the variation of task duration for Herbie, because for all other non-Herbie task durations, it will have even less of an impact, if none at all.

Focus on Wait Time first.

To kill Wait Time, you must get to a stable state.

To get to a stable state you must Limit WIP.

To Limit WIP you must use DBR.

To use DBR you must find Herbie.

@bvautier I appreciate your concern; but it is really looking at the small baby plants sprouting at the shade of a tree when there is a much larger forest to consider.

Please forget about task duration; it is a complete waste of brainwaves! Instead, think about Flow Time Distributions and how to make those curves nicer. Think in probabilistic terms, rather than point measures.

Use the Work Execution Signals to continually address the outliers. Your deviations will get smaller as a side-effect; with no special effort or planning for making it happen. Focus on Work Execution; not on brainy planning. You risk getting yourself into the proverbial “analysis paralysis.” Let the Work Flow and help it to flow smoothly.

Yes the Full-Kitting column on page 226 is another aspect of Full-Kitting; at the more granular team level. Like a pre-flight check for the team.

But the Full-Kitting activity is more thoroughly described and represented in Chapters 17 and 18, at the portfolio level.

As always, we must specify and agree on what is the system under consideration. Team or Portfolio or Organization. What is the Span of Control that we are concerned about.

1 Like

Thanks for the explanations.

Yes that is my assumption. We are only dealing with the DBR board. The only tasks waiting to be processed are in the constraint buffer waiting column. The only task being processed is on the constraint. Nothing else is on the board.

Yes, that is what I am trying to do.

I am not so much concerned about task durations but rather their standard deviation. (I used an example with a large standard deviation to illustrate what could happen. i.e. Range from 1 to 10 with a mean of 2).

I am thinking about the wait time in the constraint buffer in terms of Kingman’s equation, which defines the wait time as being directly proportional to the the standard deviation, squared, of the service duration. Because we are using DBR and controlling the flow it is also important to know how long it will take a task to get to the constraint buffer. And the time it will take the constraint to process the current tasks in the buffer.

Because the standard deviation is allowed to be large we could end up with a scenario where the tasks in the buffer get processed quickly and the task that is introduced into the flow (to replenish the buffer) is large and takes longer than normal to get to the constraint, and causes the constraint to be idle.

I understand this is purely academic. As you stated in practice it makes no difference. I thought it was interesting but won’t dwell on it any longer. I have learnt a lot from this discussion (thank you!).

I look forward to reading the remaining chapters to get a better understanding of how everything fits together.

@bvautier
“The issue is about the signal mechanism and the timing to allow new tasks to enter the work flow.”

I suggest that the scenario described has incomplete variables. These would be the state of the identified constraint and the state of the workflow preceding the constraint.

If the constraint is idle and the workflow preceding the constraint is idle, then to maximize the throughput, one wants to get the constraint active as soon as possible. Release all 3 work items and the first to arrive will be addressed by the constraint. To get to this state, however, the actual constraint would seem to be the arrival of work.

If the constraint is idle and the workflow preceding the constraint is active, then the buffer preceding the constraint is insufficient and should be enlarged. Release new work in order of value as allowed by the new buffer size.

If the constraint is active and the workflow preceding the constraint is idle, then there is no indication of an issue. Release new work in order of value as allowed by the buffer size.

If the constraint is active and the workflow preceding the constraint is active, then there is no indication of an issue. Release new work in order of value as allowed by the buffer size.

One final condition to look at for the last three situations is whether the batch size of the incoming work can be reduced. This will reduce variation and may allow a reduction in buffer size.

Yes. I realise now that I did not make my assumptions clear in my original post.

I mentioned that I was looking at the DBR board and assumed we were in a perfect DBR state. I.e. the constraint buffer is full (but not over full). The constraint is in the middle of working on a task. No other tasks have entered the workflow. All other columns (except for the constraint and those downstream of the constraint) are empty.

We need to be careful. We can only release tasks that are in the committed column. They can only be released one after the other based on their priority.

The work has already been committed. My understanding is that once something has been committed it can not be changed.

The important point is that this scenario should never occur in practice.

I find it useful to hypothesis and look at “corner” cases, in order to reinforce the learnings and improve ones grasp or understanding of a subject matter, but I feel this thread has run its course.

Consider the full TameFlow Kanban board!

@bvautier the considerations made above by @WayneMack are excellent.

I have to ask: have you read the Hyper book? And in particular, Chapter 18 “TamFlow-Kanban: The Throughput Focused Kanban?”

If you do a full implementation of the TameFlow Kanban Board, with COWIP, DBR, Kanban tokens and Replenishment tokens, then you would get early signals of Mr. Murphy potentially disrupting your flow - both upstream and downstream of the Constraint. This instrumentation should go a long way to prevent or mitigate the failure scenarios that are worrying you.

@WayneMack is spot on with this:

The full TameFlow Kanban Board will give you visual indications of those states, and even of the state of the workflow downstream of the Constraint.

If you haven’t read that chapter, I invite you to do so, because the TameFlow Kanban Board is designed to address all of this, but without getting “crazy” :slight_smile: with duration calculations. You just look at the board and “see” what is going on.

2 Likes

Replenishment affects Full-Kitting too - and Patient in the Hospital metaphor

Reading…

…and…

Note that when the DBR buffer gives a pull signal, you should not only release work from the Committed column at the Portfolio level into the Work Flow. That pull signal should also be translated into a pull from the Backlog into Prioritization and Ranking, as to replenish the Commited column too.

While the Full Kitting activity is often scheduled on a cadence, because of potential escalation to top management during Ranking and top management appreciate regularity, that is not the driving rule. The driving rule is that Full Kitting, like all other things in TameFlow are triggered (ad hoc) by Work Signals.

If you do this properly, the scenarios feared by @bvautier should not materialize.

Another observation: yes things need to be released according to the priority order calculated, negotiated or decreed in the Committed column. This does not mean that Work will reach the Herbie team (and/or any other team) in that order. Mr. Murphy might be nasty with the most important item, and the less important ones will overtake in due course.

It is for this reason that we have the rule for managing - actually avoiding - Flow Backs. It is the Patient in the Hospital metaphor. When some item gets stuck, you get people to swarm on it. If that means dropping a less important item (because it reached me first) to go an help colleagues that are stuck with a more important item, then that is what you should do. At any moment, give attention to the most important items. Never send it back. Always move it forward. We want One-Piece-Flow as much as possible, and in order of priority.

So, in the unlikely failure scenario, @WayneMack’s strategy to release as many items as possible is correct. And if one overtakes another, that is fine too. The only detail is that if a more important item gets block, then unblocking that item should have priority over anything else.

1 Like

On Batch Size and Prioritization of MOVEs and/or User Stories

@WayneMack

This cannot easily be done in TameFlow. Why? Because we use MOVEs as the partitioning mechanism of all incoming work. By definition a MOVE cannot be made any smaller than what it is without changing the economics. If the economic can define a smaller MOVE, then the initial size was simply wrong.

But in general, we have variable size batches - the MOVEs - and they cannot be made smaller nor bigger because of the economic balance they represent.

The minimality requirement for MOVEs already caters for working with the smallest batch size that is economically viable.

Anther subtlety here is that priority order is meaningful only at the granularity of a MOVE, because it is established in terms of business value.

So if you are at the team level and you have User Stories (“tasks”) representing your portion of work for the MOVE you are working on at the moment, then they have no priority order at all. The only sequencing that could be needed is due to implementation dependencies; but there is no business reason to do one User Story before another. Why? Because unless the MOVE is delivered in its entirety, the Business Value will not be realized. As long as you deliver all User Stories of that MOVE, you’re fine. Their order of delivery is irrelevant.

On the other hand if that same team is having User Stories of two (or more) MOVEs on their board, then User Stories should be favored in order of priority of their respective container MOVE - for the obvious reason that that priority represents the higher Business Value first.

1 Like

I haven’t yet. I have purchased a copy though, and plan on reading it straight after I finish this one.

Right. I remember seeing something similar to that in a previous chapter. Probably the board illustrated on page 121.

In one of your previous posts you wrote:

Yes there are a lot of moving parts, and I understand now why this has turned out to be so confusing. If we are conceptualising different boards, we will not be able to effectively communicate. My original post was about the team DBR board (and has been all along. I have not thought about, or grasped the relationship of the other boards until now.)

I have only read up to (and including) chapter 14, so my understanding of how everything fitts together (including the portfolio and organisation boards) is limited.

The illustration on page 231 and your comments in this thread have helped clarify the relationship of the team boards with the portfolio backlog.

I thumbed through the upcoming chapters to see what the portfolio board looks like and found it on page 285 and how it relates to the team boards on page 291. (I am really looking forward to reading and digesting these last chapters. They look very interesting.)

The Full-Kitting column on the team board is different to the Full-Kitting on the portfolio board. The one on the team board is a final check before it enters the team’s flow, as you mentioned. (I have made a note of that.)

I am starting to get a sense of the larger picture now. Thanks.

My premise for the original post was to discuss the team board. In particular the team that has the constraint on one of its activities.

My understanding of DBR is that if the constraint buffer is green there should be no other work in process preceding it. i.e. All the team members allocated to the activities preceding it will be idle.

The minute the constraint finishes processing a task and pulls a new one out of the buffer, a signal is created to release a new task into the work process. Only then will the preceding activities have something to work on.

Maybe I have missed something. The answer to the following question will clarify a lot of things for me… Is it possible for activities preceding the constraint (on the team board) to be busy working on different tasks if the constraint buffer is full?

This does raise another question. Are all team members skilled at each activity or does each activity have dedicated team members? (I might be making a wrong assumption here as well.)

I think it is becoming clearer now that we have been conceptualising different boards.

In the context of the team board, wouldn’t releasing 3 work items simultaneously on the same team board cause multi-tasking?

Or as many as the constraint buffer needs to turn green but not much more?

Everything else you mention, in the context of the portfolio board, makes sense, and gives me a better understanding of the whole picture. Thanks.

Always glad to contribute to your entertainment!!!

:joy:

No, this is wrong. There can be Work Items that are “in flight” between the start of the board and the Herbie column. You want those Work Items to land in the Waiting for Herbie semi-column just-in-time as Herbie pulls another item from there. And that pull needs to be propagated upstream as a replenishment signal.

Depending on the time (the Herbie buffer is a time buffer, even if we see Work Items in it), the upstream resources could be busy or idle. The idea is to replenish the Herbie buffer just in time, so that it always stays green. (Then we have the tokens to more easily control WIP… but they are not strictly necessary for this.)

Yes. That is correct.

No. As I said, it depends on the time it takes from table entry to Herbie’s buffer.

Yes. With the understanding that those Work Items will be needed Herbie’s buffer shortly thereafter, just-in-time.

We want performance, and performance is best achieved via specialization.

Furthermore, do not consider the Activities as being defined by a role. We want all activities to be collaborative ones (that is the essence of knowledge-work); though each activity will typically have a resident expert that takes the lead during that activity.

Of course all the considerations about “T-Shaped” people and staff liquidity are always valid - but the key to performance is really to get the best, most skilled folks to do what they know best; and don’t have them waste their brainpower on things that are not interesting for them.

We want to keep folks in the Flow Channel of Psychological Flow. If you want everyone to be equally skilled, you are forcefully dragging everyone down to the level of the least skilled person.

Also apply Roman Army veteran strategy: let all tasks be tackled first by the least skilled folks you have. They will feel the resistance of the medium. See Friction is Feedback. They will learn. They will get stuck and blocked. That’s when you send the veterans in. Pairing, swarming, mobbing with the veterans showing how it should be done. Remember: don’t keep work waiting for people. Make people wait for work. Better have the veterans on the bench and let them step in to help the junior; rather than having the veterans be the overloaded bottleneck while juniors are surfing facebook…

2 Likes

Yes, of course. I took that for granted!
:roll_eyes:

Just because you are releasing three MOVEs from the portfolio board, doesn’t mean that teams have to multitask. Teams should be instructed to Limit WIP and focus on 1PF.

Note a detail: you can imagine the Full Kitting column which is at the beginning of a team board, as still containing MOVEs - i.e. a collections of stories. (More precisely, each MOVE there will have only the subset of User Stories that are relevant for that team.). So it is like a backlog of MOVEs in front of the team. Typically you will have only one or two MOVEs there. The team is obviously trained to work on one MOVE after another, in order of the MOVEs’ established priorities.

When a MOVE is being worked on, the User Stories will be released into the team’s board, according to the signals from the Herbie column in that team.

I know it is hard to visualize without a proper simulation!

Thanks Steve. Much appreciated.

Yes :slight_smile: , I look forward to reading a new chapter every morning. Hope the Hyper book is as entertaining :wink:

Yes, you are right. I got caught up in my example, and got a bad case of tunnel vision.

When I am presented with a new scenario, I always look for “extreme” examples (i.e. testing the boundaries). They help me establish the context and assumptions people are operating under. I try and imagine “ridiculous” scenarios all around the contextual boundaries. And then ask myself… “How ridiculous is this scenario in real life?”. It has served me well when scoping or gathering requirements on customer projects. (I have also found that exploring the boundaries when presented with new concepts helps me assimilate information faster.)

(As an aside, the number of times a customer has told me a particular scenario will never happen in practice and to simply ignore it, only to see the exact scenario show up within the first month of using a solution, is uncanny.)

The ridiculous scenario I was exploring in this thread is that of a long task entering the team board followed by much smaller tasks, then another large task.

Ridiculous, in the sense that the large tasks take days, and the short tasks take at most 2 or 3 hours each.

So you have a large task (days) in the constraint buffer, It will be processed next by the constraint.
The other tasks in the buffer are short and will be processed within hours. The tasks “in transit” are also short.

The large task takes so long to process that all “in transit” tasks upstream of the constraint buffer will eventually arrive at the buffer before the constraint finishes the large task. (yes, ridiculous …)

Finally the large task is finished. At this point in time, the constraint buffer is full. There are no “in transit” tasks upstream (i.e. they have all reached the buffer). All the tasks in the buffer are short, and will each be completed within a few hours.

As soon as the constraint starts on the first short task, a signal is sent to release the next task into the Team board flow. This task is another large task that will take days to get to the buffer, as well as days to get processed by the constraint.

The constraint processes all of the tasks in the buffer within a day. It is now idle and waiting for the large task to arrive.

This has always been my intent. Here are some quotes from previous posts:

and

As I mentioned previously:

You replied neither, and I now understand why.

I read chapter 15 this morning, and fitly, it discusses MOVEs!

Well that explains everything … and elegantly resolves all these issues. It naturally takes care of the standard deviation issue. In practice if we are focusing on Minimal Outcome Value Efforts we will never have tasks that are much larger than the mean.

What I was worried about will never occur in practice because of the nature of a MOVE and how the whole TameFlow concepts interact with each other.

Everything makes a lot more sense now. Thank you.


Thanks. These quotes are all gems!