At a retrospective meeting with a client not to long ago, a really interesting point came up. The client had deliberately attempted to push a lot of feature work onto the development team, while keeping a fixed deadline - presumably to have the team work harder, and thereby producing more features before a particular deadline. Interestingly quite the opposite happened.

A total of 7 features were requested by the customer, while neither deadline nor scope change could be tolerated. The result? 7 features were reported done on the deadline. Unfortuately it turned out - in production - that only 2 was working as supposed, meaning that 5 was more or less defective.

When these numbers were clear to everybody an obvious question came up. Could the team instead have aimed for a total of 4 features (instead of 7), and actually completed 4 features upon the deadline (instead of 2)? Significant amounts of time had been invested in 5 features that were not completed anyway.

Who were to blame for this? The development team were only doing their best, trying to accomplish a goal not set by themselves. How could the client know any better? They did not know the kind of problems that are induced by using a push approach.

What the client and the development team had experienced was simple physics.

Little's Law:
Work in process = Flow time * Throughput

Little's Law describes the relationship between multiple key variables in any value stream (including software development projects)

What Little's Law says, is that - The more work you start, the longer it will take you to finish (given that your capacity/throughput is stable). Now imagine what happens if the customer asks for a fixed deadline - The amount of work that can be done before that deadline is indicated by the current capacity.

How about if we attempt to get higher throughput/capacity by increasing the amount of work, and asking people to work harder. Which variable do you think will be affected? ..you guessed right, Flow time will increase, as throughput (or capacity) does not increase magically over night.

I wonder how many people in the software industry are trying to outrun Little's Law, by putting pressure on the "floor" workers (e.g. developers and testers) ?

Lesson learned?
1) Don't try to run above the speed limit indicated by your current capacity. You will pay more and get less.
2) Favor pull systems over push - for instance as advocated in Scrum.
3) Never attempt to fix scope if you have a fixed deadline.

By Sune Gynthersen