Posts Tagged holy grail
Fixing the On-Ramp
Posted by Alex Kell in Agile, Management on March 13, 2012
I figured it might be fun to continue this one-sided discussion about Productivity, so here we go! For lots of managers, there’s a holy grail – the idea of 100% efficiency – which, as we all know from the 2nd Law of Thermodynamics is impossible! (What? That’s just for heat engines? oh.) No, the real reason it’s impossible is because it’s unsustainable. At some point, variation will enter the system which will cause disruptions to that 100% efficiency. If you’ve ever done the “airplane game” at some agile training workshop or other you’ll know the concept. If not, think of a traffic jam. If a highway is full of cars, adding more cars won’t speed up the traffic; in fact, it’s the opposite. Adding more cars will slow it down even more.
For example, take a machine that can stamp out 60 widgets in a minute. It takes three inputs that must be entered into the system simultaneously. If any one of those inputs varies by a little bit, the machine will fail and the new inputs will start piling up behind. And then you have to stop the line, and fix whatever the problem is. Maybe it’s a quick fix, seconds even, but you’ve messed up the efficiency and you’ve created defects.
The fix is to introduce buffers into the system. By slowing the system down, problems caused by normal levels of variance will not reduce the efficiency of the system. This is kind of the same idea that created those ramp meters at the highway on-ramps.
So how does this relate to Software Development? If we try to complete more work in a given timebox than the team is capable of completing, the effort expended in trying to complete that work will actually make the team less productive, not more. Putting an amount of work that is lower than (imagined) capacity will increase the likelihood that it all gets done regardless of normal levels of variance, creating a more predictable and stable cadence. This will be more efficient than stuffing the iteration with as much work as possible. This is why Kanban has WIP limits. It creates that buffer to help ward off the effects of variance in the system.