Working faster isn't working?
Do you want to understand why that is?
Warning
If you are working with development teams (and aren't a developer or ex-developer) then this might be jarring, but it's intended for good and not for offense.
The reason it takes so long for work to be done? I know from a distance it seems like it's "they're not working hard enough," but it's very possible (better than 50/50) that they're working too much.
The queues
Wherever there is a handoff, there is a queue.If the person receiving the work is busy, the queue becomes a wait.
How long work waits is largely a matter of:
- How many things are in the queue?
- How often can someone pull the work from the queue?
- How long does it take to complete the job once started?
- How long does it take one task to clear all of the other queues and reach production?
We tend to think of our workflow like this:
[Step 1] ---- [Step 2] --- [Step 3] -- [Release]
In reality, it looks more like this:
[Queue 1][Step1] -> [Queue 2][Step2] -> [Queue 3][Step 3] -> [Queue 4][Release]
For simplification, imagine that every step took exactly one day. The fastest any item could go from start to end would be if all the queues were empty (later steps were idle, waiting for work). It would take 4 days, since release is a step also.
Now lets say that there is one item waiting already in each of the queues when our task reaches that step. You can imagine readily enough that it doubles the time. Each queue will take a day to process the item ahead of our task and one day to process our task. We're not taking any extra time to do the work, but the quickest possible release is 8 days out.
Let's make another change, and imagine that step 3 takes 2 days instead of one. In an empty queue situation, it's only 5 days to release, but imagine that we keep Steps 1 and 2 as busy as possible in the meantime.
| Day | Queues | Expect Thru | |||
| 1 | 0 | 0 | 0 | 0 | 5 |
| 2 | 1 | 1 | 0 | 0 | 5 |
| 3 | 1 | 1 | 1 | 0 | 5 |
| 4 | 1 | 1 | 2 | 0 | 7 |
| 5 | 1 | 1 | 2 | 1 | 7 |
| 6 | 1 | 1 | 3 | 0 | 9 |
| 7 | 1 | 1 | 3 | 1 | 9 |
| 8 | 1 | 1 | 4 | 0 | 11 |
| 9 | 1 | 1 | 4 | 1 | 11 |
| 10 | 1 | 1 | 5 | 0 | 13 |
You can see that going full-speed in steps 1 and 2 merely make the queue in front of step 4 fuller, so that by day 10 the new item that arrives in the first queue can be expected to take at least 13 days to make it out the door if all goes well.
Now imagine that, in an attempt to get work done faster, we double the speed of the people at the first queue. What is the result then? it build up a queue at step 2, and work does not arrive at queues 3 and 4 any sooner.
If we add twice as many people doing steps 1 and 2 but do nothing to speed work at task 3, we exacerbate the problem. This is explored much further in works by Elihu Goldratt such as The Goal and Critical Chain.
Individual Queues
Work is often assigned to individuals, so a new jobs coming into the system will wait for the availability of the assigned person, no matter who else has time. I doesn't matter if three unassigned developers have finished a task, since they can't pull work from someone else's assigned load. That job will wait.
That means that we have many early queues and waits, and often these flow into fewer queues for review, scanning, testing, approval, and what-have-you. The cardinality differences often mean that queues build.
Most people don't even track the size of the queues. They can, but don't.
Most people don't even track the size of the queues. They can, but don't.
What about the rework?
When work in the front of the queue is hurried, it is more likely to fail a quality gate and return for rework. This is disturbingly common in many programming organizations.
Now the issues must be remediated, and the work resubmitted. This rework goes through the same queues and quality gates.
Now the issues must be remediated, and the work resubmitted. This rework goes through the same queues and quality gates.
With rework flowing from the first task, the second queue may have all the original work and also all of the repaired work piling up. As the queues build, the release time stretches out to the horizon.
Without so much work-in-progress (really work-in-queue), there would be faster starts and completions. Sadly, instead of reducing WIP and queuing, and spending time to get the pass rates up on the quality gates, the standard naive answer is to "make programmers work faster" -- which results in even slower releases due to quality gate rejections and code resubmissions.
Without so much work-in-progress (really work-in-queue), there would be faster starts and completions. Sadly, instead of reducing WIP and queuing, and spending time to get the pass rates up on the quality gates, the standard naive answer is to "make programmers work faster" -- which results in even slower releases due to quality gate rejections and code resubmissions.
You could track your system and attack issues with a systems mindset, but odds are that nobody in your organization has ever done so. Instead, everyone is super-busy and nothing is getting done.
There's more to this, but maybe check and see what the system's load is like before declaring "they have to work harder" since the system of work may be inflicting most of the slowness.
