Save Your Project

Good advice on how to keep your project from circling the drain.

Items #7 through #11 simply do not get enough play. They are:

• Prioritize
• Make features, not inventory
• Leave the team alone.
• Streamline decisions.
• Build quality in.

When I see teams in trouble, the hardest things to teach are these. Prioritizing means that you have to declare something more important (or at least more urgent) than another. People simply don't like to do that.

Making features (not inventory) means that we need to "see the whole" and measure our time from specification to *delivery* not just coding time. We can easily optimize the wrong things and create nothing but trouble, heartache, and last-minute drama.

The answer to getting things done is not to have more things in progress. Start rate has to match up with completion rate. If you start too few things, developers are idle and money is wasted. If you start too many things, then it is harder to get any one thing done. You end up with 80% of the work 80% done and nothing to ship. The smart (lean) thing to do is measure your completion rate, and feed in exactly the amount of work that can be finished. Adding more work doesn't help move things along by creating pressure, it slows things down by creating a large inventory of partially-done work.

Because your capacity is finite, you must prioritize. If you cannot prioritize, you clog the system and nothing gets done. You can try to increase your team's capacity to produce, but that is a matter of streamlining, staffing, training, and tooling and not a matter of stomping, screaming, cheerleading, or cramming more work into the funnel.

Leaving the team alone is a hard sale. It's absolutely right, but everyone suddenly decides that they could manage your team better than you can if they could directly handle your developers. They're flat-out wrong, but they are very well-intentioned and convinced. My manager and I have over 60 years of experience between us, but there are a million low-mileage would-be managers who think they can do it better. We struggle to keep our hands off too, because sometimes we want to dictate. I struggle more, as the junior of the two with only 30 years in the business. He's wiser. Luckily I listen to the developers I serve, and that keeps me from too much trouble.

Streamlining decision-making gets more difficult, too. As pressure mounts, people want to help with decision-making (and decision-reversing). It's just a bad idea. A team that is moderately productive can certainly go to hell in a hand basket once they get multiple work queues, multiple priorities, and increased thrash.

Quality may be the hardest sell. It is counter-intuitive that test-driving, testing more, thinking more carefully through code ramifications, and programming in pairs will actually make the team *faster*. Again, it's because people want to measure programmers' typing speed instead of how long it takes to successfully release a product increment.

See what the other author has to say, take a look at Lean Software Development, and join me back here for some followup later.