Take the foot off the pedal to go faster

Today I’m continuing with my chaotic efforts to draft the follow-up to my article Create your own dysfunctional single-page app in five easy steps…

Yesterday we looked at how you can identify where the waste and bottlenecks are in your development flow, and how the state of a code base depends on and influences the way a team work together on it.

If you’ve spent any time reading about lean, you’ll know that there is a big focus on utilisation. Specifically, the more heavily utilised the resources in a system, the longer the wait time for work to pass through that resource, and the longer the overall lead time.

In other words, if even one member of your team is always working flat out without any slack time, there will always be long delays and queues of work. This most often happens with the ‘ready for test’ queue.

The relationship between utilisation and queue length is not linear, either. Check out this graph from an article on the Kingman Formula:

This work originated in manufacturing - hence all the language about ‘resources’ and ‘queues’ and ‘flows’ which does grate a little when we’re talking about human ‘work stations’. However, software development flow behaves in a very similar way, which explains why lean thinking has gained popularity over the years.

I’ve worked in and with many product development teams that have fallen into the trap of over-utilisation. You will have almost certainly seen it too. Teams that try to pack in as much new feature development work as possible will skimp on quality and value assessment in order to ship. It’s a feedback loop. By taking on too much, the lead time grows, creating further pressure to deliver, and much hand-wringing about what’s wrong. This can go on for years.

The typical instinct is to add more resources (sorry, people) rather than increase slack time.

And if your product code base is hard to work with and add new value to, then the situation is compounded, because adding more people doesn’t necessarily reduce utilisation, and still nobody is working on incremental improvements.

So before you hire a bunch of new people to help rebuild a failing app, make the case for taking on less instead. Much less. Experiment with limiting Work in Progress (WIP). Try to make work units consistently small. Find a way to measure throughput in terms of value to users. Encourage team members to use some slack time to start making small, incremental, agreed improvements that target your ability to deliver value.

If you can show that you can add more value by taking on less work then you’ll be a in a better place to make the case for dedicating more time to ongoing improvements.

As a real-world example, GitHub’s long-lived migration project to remove jQuery could only have happened because of reasonable utilisation and slack time. Note that what they didn’t do was rewrite the whole of GitHub’s front end. They had a clear plan and executed it with some clever approaches for maintaining momentum.

What’s the utilisation level like in your team? What impact does this have? Hit reply and tell me an actual percentage (estimated is fine).

All the best,

– Jim