Make the team go faster, we've got so much to do and so little time!

This article is republished from my original 'Make the team go faster, we've got so much to do and so little time!' post in LinkedIn.

It's surprising how often I hear this.

Today I was part of a team presenting a bid to a prospective client. A few automobile metaphors had already been used (for example my GM made the comment that we're not the sort of company that follows the letter, but the spirit, of the contract - i.e. not "Oh, you'd like an engine with that car? That will be extra").

I was discussing Kanban with one of the panel members and was asked if I'd focus on velocity or WIP (Work in Progress) limits. To which I replied "I'd focus on lowering WIP and getting the team humming and velocity will take care of itself".

Unfortunately I didn't think of a clever automobile metaphor until later in the day, but the discussion is worth sharing because it illustrates an important issue. Many people are focused on velocity and how they can make teams "go faster" (note: I'm not saying this was the case with this particular prospective client, but it certainly is the case with other clients I've had).

Hopefully I can make this point without stretching the car metaphor until it breaks :-)

Imagine your team of 8 people is equivalent to a car with a 2000cc engine, and you tune the hell out of it by reducing WIP, removing bottle-necks and generally just improving things to the point where the team is really cranking through the work. Your highly tuned two litre car might do 220 kmph.

Now imagine someone says "I need to travel 2100 kilometres in less than seven hours, can't you go faster?" (i.e. I have all this scope and limited time, can't you just whip the team a bit harder?).

So how do you make a finely tuned 2000cc car go faster? Well, if you accept the engine is highly tuned, then it can't, unless you:

• Add a bigger engine, but you'll need to stop the car to do this (i.e. add more team members, which will slow you down before it speeds you up). It will also use more fuel ($$$$). You may also not speed up - adding people to a late project typically just makes it later. This strategy works best when you do it early enough to make a difference (i.e. before you are late!)

A common variation on this is to recognise you can't pay for the extra gas a bigger engine would use so you start mixing cheaper gas into your tank (you add a few cheap developers who most likely will slow you down permanently and/or degrade the quality of your product).

• Swap out some of the metal parts for plastic ones to reduce weight. That might speed you up (i.e. reduce quality. No one might notice until the car is out of warranty)
• Just start throwing things out of the car to reduce weight, or cut half the car away like this one I photographed in Stuttgart (i.e. let's ditch some scope)
• Add a turbo charger and hope the engine doesn't blow or other parts fail under the stress (i.e. just make the team work 12 hour days. Surely they won't start producing bad code, right?). Again this will burn through the gas ($$$$) - great, more money and a worse product!!!

For all you Star Trek fans out there, its real simple "You cannae change the laws of physics".

Likewise, if you trust that you've picked the right people, and they are working as smart as they can, then they're going as fast as they are going to go.

You need to re-balance your project constraints in a way that makes sense for your circumstances (i.e. maybe don't try and do 300 kmph in a car that tops out at 210 kmph).

Carl Weller is a Principal Consultant specialising in Project Management and Agile Leadership, based in our Wellington office.