Shouldn't Delivery Time be included in Flow Time?

On page 54 of Tame Your Work Flow, you specify that Delivery Time must not be included in the Flow Time because it is not part the the Work Process and thus it is out of our span of control.

Even though I am in expert in manufacturing I tend to agree that this statement most probably applies to physical goods which need to be delivered after they have been manufactured. The Delivery process being most probably a whole different process than the manufacturing one I can understand why we do should not include it the Flow Time.

But in the domain of Knowledge Work, or more precisely for IT Delivery Teams building IT components should’nt the Delivery Process by part of the whole Software Delivery process?

With organization adopting DevOps more and more, it would then create an incentive for them to improve the delivery part of the process if this is in deed there Constraint. I have seen a lot of teams washing there hands about the Delivery process, when they actually have a lot of control on this process. It may not be 100% control, but in principle as long as they demonstrate/prove that they did there homework they should actually be in a position to deliver as soon as they are done building the solution.

In my opinion from the moment we have the Full Kit and the Flow Time meter starts and it should stop only the the solution has been delivered to the end user (i.e. deployed to production).

Thanks for sharing your thoughts on this.

1 Like

Hi @dplourde

It’s a “yes-and-no” kind of situation, and truly depends on what “delivery” means in your context.

Yes, you have manufacturing settings, where the job “is done” once the pallet leaves the gates. Yes, you have full featured CI/CD where the delivery process is fully automated, and virtually consume zero time of the “resources” involved. In either cases the delivery is not part of the Work Process that creates the product/service.

But then you have cases, as you observe, where there is actual delivery work done by the team(s); then you are right - and you should account for that.

At the end it is a judgement call: establish the boundaries of what you want to consider as Work Process and account for the Flow Time therein. Often, the boundaries are defined by the Span of Control that you have in the entire Value Chain. Map out your Value Chain/Stream and find those boundaries. Where you set those boundaries, is context specific; and it is your call.


Thanks for the clarification.
As you indicate using Span of control as the main criteria to include any activity in the Flow Time is certainly the good question to ask ourselves.

But in my view, as well as my pro-DevOps colleagues we truly believe that the teams need to make Delivery part of the span of control.

Obviously top mangement must adhere to this and the teams must be provided with the means to do such things like CI/CD. And then again wearing our DevOps hat we consider that “we are not Done until the solution is made available to the end user”.

Thanks again,

1 Like

@dplourde it is still a judgement call, that only you - in your context - can make.

If you are producing embedded software that goes into hardware products (think “cars”) which are delivered via a supply chain to a network of resellers, there is a delivery phase which is clearly outside of the company’s Span of Control (though it is in its Sphere of Influence). Yet, you are still developing software, and presumably there are DevOps activities too.

You do not (and cannot) “make something part of the Span of Control.” Either it is or it is not. It is not a matter of deciding. It is a matter of observing reality and gaining awareness of where that boundary is.

In this instance it is also a matter of reaching agreement on what the term “Delivery” means. If you are developing a web/mobile app, then of course delivery is within your Span of Control. If you are developing embedded systems, probably it is not. And then there might be cases that fall in between these extremes.

Again: exercise your judgement with the knowledge you have about your context by observing what is within and what is outside of your own Span of Control.

In #tameflow there are now hard rules, except the one to always think about we are doing with reference to the most appropriate Mental Models that we are fit for the purpose.

1 Like

Totally agree with you for cases where delivery is definitely out of or span of control, such as with embedded software.

But, in many cases, such as our’s at the Bank, we are in deed talking about web/mobile apps as well a whole suite of legacy systems.

One of our main problem is that many of our teams work and/or think in silos and too easily fall into the trap of not addressing the issues simply due to the fact that parts of the work process (e.g. Release Management, Change Management, …) are not directly under their span of control.

I guess one way of avoiding to fall into this trap is to group teams into value streams which as a whole should definitely have delivery within their span of control. This is what I met by making it part of your span of control.

Otherwise what I see to often at the Bank, is that we fall in the trap of local optimizations on what we believe is the constraint simply because we do not have an end-to-end view of the work process, which delivery value to our end-customers (both internal and external).

I am currently reading for a second time “Tame Your Work Flow”. I am convinced that I will find some more material on this matter in future chapters.

Thanks again for the great work and inspiration.


Ah… I see what your concern is. The silos. Yes, it typically is a major pain point.

The reason why in #tameflow we give great attention to Informational Flow is related specifically to this issue. Once something is outside of your Span of Control, you need to reach out to your Sphere of Influence. Typically that is your boss, or your boss’s boss, all the way up to the CEO.

Even CEOs might have the same problem, and reach out to their Sphere of Influence, such as buyers, suppliers, competitors, associations, regulators etc.

But assume that we are only within the company boundaries.

Then: the purpose of Informational Flow is to tighten the feedback loops and accelerate the pace, quality and relevance of decision making. That’s why we have the Management by Exception paradigm in place. Of course, the upper echelons of management need to be onboard and wiling to play an active role when their attention is called for.

So back to the key point about silos. While…

… is a good step in the right direction, the key (from a #tameflow perspective) is to define one overarching company Goal. Just like Goldratt described in his “The Goal”. Unless such an overarching Goal can be defined, then any other attempts will fail.

If you have that kind of Goal, with Informational Flow and Management by Exception, then as soon as some issue is outside your own Span of Control, you escalate the issue via your Sphere of Influence up to your bosses, all the way up until the issue falls within the first Span of Control of someone who can act on it. Notice that if you have a common shared Goal, then the actions or decisions required by that person will be immediately obvious; and the other silos will recognize how those actions will benefit them as well in the quest towards that common Goal.

In all of this, though, there is one big bogey man: namely Cost Accounting. As long as the management decisions are taken with the Cost Accounting mindset, there simply cannot be alignment of interests towards a common Goal. Every budget / operational / business / organizational unit will engage in perennial fights with their peers - because they have their own budget to protect and their own KPIs to achieve.

Yes! #tameflow is a Sytems Thnking approach. If you apply its ideas - no matter how good - at the local level, without appreciating how all the pieces fit together, it will not work.


Totally agree with your statements.

The good news in our context at the Bank, is that the buying by our executives is there and we are more and more adhering to good DevOps, Agile and even Flow practices.

What we are still facing though is some resistance to change from some teams or players on the floor. Some still tend to keep on doing what they’ve always done and push the “Delivery” activities to a phase which in their opinion is not under their span of control, when in fact it is.

I frequently face this issue with “Agile Coaches” that apply the sprint ceremonies to the extreme. This to the point that they insist of not making “Delivery” part of their DoD simply because this would prevent them from completing the User Stories within a single sprint. They are trying to “protect the team”. Which is why in our case we elected to officially include “delivery” as part of the Work Process.

In then though, I can understand that this may not apply to all situation and in the end it remains a “judgment call”.

Thanks again

1 Like

I see. You are falling trap of one of the most prevalent Agile anti-patterns.

The concern about “protecting the team” effectively creates artificial barriers, and prevents the holistic, system-view approach.

I always say: protecting the team is great in a dysfunctional organization, but if the organization becomes functional and starts to reason in terms of end-to-end value chain, then what needs to be protected is the Constraint - no matter where it is.

Unless the Constraint is a specific team, the rationale of “protecting the team” is counter-productive.

Unfortunately Agile Coaches and Scrum Master are not equipped to grasp this. Their mental models are attuned to making teams work in a dysfunctional setting, and they cannot envision anything different.

Therefore: escalate to whomever is the boss, and make an effort to change the prevalent mental models of all parties involved.