Shifting Gears

Shifting gears in a car can be a metaphor for process change in software teams; pushing them without change risks burnout, while letting them adjust their processes and take responsibility for improvement leads to sustainable, faster progress.

I often use the metaphor of shifting gears to describe why learning and process change is important. If you’re old (like me), you may remember driving a car with manual transmission.

Revolutions Per Minute (RPM) is the measurement of how much work the engine is doing, and Mile Per Hour (MPH) is the measurement of your speed. Most cars work well around 12,000- 15,000 RPM. You can push the RPM higher, but you risk serious damage to the engine if you do this continuously for long periods of time.

If you’re going 20 mph in 2nd gear, and you’re over 5500 RPM, to go faster, you have two choices, give it gas to get more RPM, or shift to 3rd gear.

Your best choice to not burn out the engine is to shift gears.

So, you take your foot off the gas pedal (and the car starts to slow).

You push in the clutch to disengage the transmission (and the car slows more).

Then you shift to 3rd gear and smoothly engage the clutch (and the car slows even more), while re-applying pressure to the gas pedal.

As the clutch engages. The car maintains, and then starts to gain, speed.

Now in a higher gear, the car can go faster while keeping RPMs within a safe range to not burn out the engine.

Slow Down To Go Fast  

I’m sure you all see the metaphor coming.

The “MPH” in software is a measure of how much the team produces. The “RPM” is the amount of effort that your teams are doing to create that software. Pushing a team to work harder is the same as pushing your RPMs higher in your engine. Eventually, the team will burn out and work much slower, or even quit on you.

Instead, the team should switch gears (by slowing down temporarily). Teams need to experiment and change their processes to make them more effective. Your team should regularly re-examine how they do their work. They should decide (because they’re the experts at creating software) how to make the changes that will allow them to work in the next higher gear.

Some ideas they can examine:

• Is this iteration length working for us? Should we make it shorter? Should we make it longer?

• What meetings can we cut out? What meetings are we not having that we need to have?

• Should we work solo, in pairs, or as a collaborative group?

• Do we have too much Work-In-Progress? What’s the right amount for our team?

Giving a team the responsibility to get better and allowing them the opportunity to follow through on that responsibility will slow down production output, but like switching gears, it will only be short term, and will allow for more rapid development at a sustainable pace in the future.

If you don’t, you will burn them out, and cause complete engine failure.