I don't think all development teams should always try to go faster. I think they should always try to improve, but this doesn't always imply speed. I am responding to an attitude I see prevalent in the agile, particularly XP, community, where speed is worshipped. It isn't that I think speed is bad, but too much of an emphasis on speed can limit your thinking. It may be easier to explain my concern with an analogy.

I frequently compare fitness and dieting to agile development, particularly transitions to agile development. If you have been lethargic for a long time, your goal may be to look like someone on a magazine cover, but this won't happen overnight. More importantly, you shouldn't try. Extreme dieting and massive exercise will place too much stress on your body. You shouldn't try to go too fast too soon.

In both the fitness and agile development scenarios, I think it is important to outline your expectations. Perhaps the development time cycle isn't as much a problem as the defect rate. Focus on techniques that improve code quality rather than speed to meet those expectations. Even if speed is a goal, your team's velocity is probably not going to improve ten fold after iteration 0. I think too many fledgling adopters of agile development underestimate the struggles they will encounter. (I think the basis for this, as with fitness, is that most people don't want to admit how bad shape they are in.) An experienced coach, for example, will address this, but I don't think the literature about agile processes addresses this well.

So far, I have only noted why it is okay to not to focus on, or expect, speed in early stages. What about mature agile teams? Returning to the fitness metaphor, many people discover that they are comfortable not looking like the magazine cover model. They realize the cost doesn't justify the benefit; they like eating Twinkies. Similarly, the agile team may have certain cultural, contextual and organizational factors that limit their speed. In certain circumstances, it is more important to maintain these constraints and accept the limits they impose so long as the organization adjusts their expectations to accommodate these limitations. Acceptance and contentment are necessary for happiness.

Mary Poppendieck talks about delivery speed and competitive advantage. The core idea is response time; this doesn't imply that increased programming velocity will result in better response time. It ignores all the other factors that go into shipping a software product. These factors, since ignored, are at a higher risk for being the bottleneck than programming speed.

I have seen many martial artists, who may not look fit and can't run very fast, but whose reaction times seem inhuman. They are flexible and responsive; they are agile in the truest sense. I think agile teams and organizations should learn from this example and look for all the ways that response time can be shortened.

I don't think speed is a bad thing. Its just important to think about how you define speed and what motivations and pressures drive your search for speed.