16

In The Phoenix Project the single graph in the entire book shows that as a person's workload increases into the high 90%s the wait time on them increases exponentially. In fact in the book it claims that:

Wait Time = (Percentage Busy/Percentage Free)

So if a resource is busy for 35 out of 40 hours per week then:

Wait Time = 0.875/0.125  = 8

However if a resource is busy for 39 out of 40 hours per week then:

Wait Time = 0.975/0.025  = 39

This is multiplied up by the number of waits in the workflow. It's obviously something we want to keep an eye on!

So, given all of this it's obviously vital that we keep people's utilisation at a sensible level. Given the book's insistence of the importance of this formula it offers little practical advice on how to measure these values. My question is, how can you practically measure a person's percentage busy?

12
  • 2
    This deserves an answer that quotes the book Slack amazon.com/dp/0767907698. The myth of efficiency by burning resources at 100% is also the main topic in Theory of Constraints. Mar 7 '17 at 11:36
  • 2
    Before I have time to write a full answer, I'll just add that in ToC you abandon efficiencies everywhere, to focus on efficiency only on the constraint. Because that allows everywhere else to absorb variety and avoid creating waste (quote Lean here. like overproduction, too much inventory, etc...) since that is non-value-added (quote Lean again) activities. Mar 7 '17 at 11:41
  • 2
    Constraint is rarely a human, even in The Phoenix Project, Bret was first a constraint - but its "his work" that is the actual constraint. Mar 7 '17 at 12:13
  • 1
    @Evgeny looking forward to the full answer!
    – Liath
    Mar 7 '17 at 12:14
  • 2
    An answer here should also use Martin Fowler's "You Cannot Measure Productivity" - martinfowler.com/bliki/CannotMeasureProductivity.html
    – David Bock
    Mar 8 '17 at 19:26
7

TL;DR: It is the wrong thing to measure. By measuring and increasing utilization in employees across the board, you create problems in the system and reduce overall throughput.

Throughput Accounting

What you actually want to measure is throughput, inventory and operating expense all together and try to reduce inventory and reduce operating expenses while at the same time maximizing throughput. This method is known as throughput accounting.

In software development, inventory is the work in progress that is not bringing benefits to the customer yet. Anything that has been done, but not released. Throughput is the amount of work useful to the customer that is being released. Any work done that is not directly useful to the customer is accounted as operating expense.

Simple system

In a simple system with single human or multiple humans working independently with independent equipment as much as each one does will directly increase the throughput of the whole system. This leads to the common misconception that is basis for this question that increasing human utilization will lead to increased throughput in all systems. But you still measure the throughput of the system, inventory and operating expenses.

Complex System

In a complex system, even with as little as two dependencies, increased utilization of one part of the system can directly lead to decrease of utilization in the bottleneck, which decreases throughput of the whole system. Any increase in productivity outside of the bottleneck is a mirage.

Example: Team of software engineers has all code reviewed by the software architect, who also makes plans for new features. This person is a bottleneck, code not reviewed by the architect will simply increase inventory, if the architect does not have time, no new features will be properly planed. If you start measuring utilization of software engineers, they will each try to make more changes, rather than better changes. The time the architect will need to spend on each change will increase and the total time spent reviewing will increase further by the increased amount of changes to a point where no time would be left to plan new changes. Eventually the whole system grinds to a halt. If on the other hand they decrease utilization, even spend time idling, they spend longer on each change or peer reviews, this could lead to decrease in time required for reviews and eventually increase in throughput. This is just single team with 2 dependencies. Engineers depend on architect for new changes to be planed and for changes to be reviewed.

Clearly the benefits are to be gained in properly managing the bottleneck and trying to gain productivity at the bottleneck, where hour gained, is hour of throughput of the entire system.

This is the real message of The Phoenix Project and comes directly from the Theory of Constraints by Eliyahu M. Goldratt. You might also read an article on utilization thinking vs throughput thinking. I would also suggest to read more on Critical Chain Process Management.

Remember: What you measure is what you get. And you definitely DO NOT WANT to get increased individual utilization. A road to Hell is paved with good intentions.

1
  • I definitely learnt something from reading this answer and the linked articles! I'm left wondering though, how to practically measure the throughput of a software development team.
    – Craig
    Oct 17 '20 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.