Doing too much: worse than too little

The last couple of years, I’ve run a big San Francisco race, Bay to Breakers, and it’s coming up again in May. I’m not much of a runner, and I’ve slacked off lately. But if I’m going to survive 12k with hills, now’s the time to start training.

How doing too much hurt me

The first part of my training is pretty simple. For 30 days, every day I do 30 minutes of mixed walking and running. (Want to start yourself? Use Hal Higdon’s plan.) But two days ago, I did too much. I met up with a more fit friend, and I let her set the pace. I did a lot more running than usual, and because it was fun to run with a friend, I did it a lot longer than usual: 60 minutes. I felt great, but like I had run a race, not gotten a workout.

It was fun, but I paid a price. The rest of the day I was a little loopy, a little unproductive. And then the next day, I was sore and tired enough that I didn’t work out at all. I knew I was supposed to go, but I just couldn’t bring myself to get out the door. And heck, maybe I should have taken a day off. Maybe my body needed the break. Doing extra seemed like it would be better, but it caused me to break training, and in the end, I got no more running in.

How it hurts teams

All that reminds me of a common novice mistake: overestimates causing productivity crashes.

Imagine a team just getting started with an Agile method like Extreme Programming. The first week, they guess they can do 20 points. However, they only get 10 done. How many should they pick to do the second week?

  • 30, because they’re behind and want to catch up;
  • 20, because the first week was an anomaly, and now they’re sure they can do 20;
  • 10, because the evidence says that’s what they can do in a week; or
  • 7, because they bit off too much and want to recover.

The most common answers are 30 and 20. They are wrong.

When people say that they are “behind”, that’s an indicator to me of a non-Agile culture. Their initial guess was just a guess. It is always a mistake to turn guesses into promises or plans, no matter how much stakeholders want promises or plans. A team picking 30, trying to catch up, is prone to spiraling out of control. They will repeatedly up the ante to gain back lost credibility, and repeatedly fail, either by not meeting goals or by producing junk.

Trying again to meet an unrealistic goal, as in 20, is a more insidious mistake. Especially early in an Agile adoption, a team is trying to learn how to do things right. But if they are continuously over-committing, they won’t have time to learn. Failing repeatedly to meet goals will discourage them. Regular over-commitment prevents successful Agile adoption.

The right answer

In the example above, I’d be happy if the team picked either 10 or 7. Why?

Guessing that they’d do next week what they did last week, picking 10, is an agile practice known as Yesterday’s Weather. It’s a realistic, data-driven answer, and assumes that you can get done about what you got done. There’s a risk that the team has still bitten off too much, in which case they’ll miss the goal again, but Yesterday’s Weather will sort that out in an iteration or two.

But what if they pick too little and say 7? Well, too little may not be too little. After blowing an iteration, the team can use a little slack to recover, to figure out what the problem is, and to fix things. But if it really is too little? That’s fine. It sets a team up to exceed the goal by pulling in something extra. That makes everybody happy, and it’s a habit you want your teams to develop.

Until a team has a strong record of regular quality output and consistently meeting goals, always err on the side of biting off too little. Challenging your limits is great, but first be sure you know what those limits are and how to recover from pushing them. When making plans or promises, do it based on a demonstrated track record, not on what you or your employers would like to be true.

One Comment

  1. Steve Bockman:

    Tom DeMarco’s book, Slack, makes a case for slack being where creativity and innovation come from. You make an equally convincing case for slack being where learning comes from. Thanks for that insight!

Clicky Web Analytics