Exploration Through Example

I find myself advising new Agile teams to go slower than they could. Here’s the thing: at the beginning, they’re probably working on a bad code base, and they have yet to learn important rules and habits. They will find it easy to go faster than is compatible with making the code more malleable.

They are nevertheless likely to delight the business, because it’s getting actual observable features at a steady pace. They’ve also established a velocity. As they learn more, they will find their velocity needs to decrease. From the inside, a decreasing velocity is part of a necessary improvement. From the outside, it looks like things are going wrong. Pressure arrives, even if only pressure generated internally by the team. They may therefore not slow down enough, which is buying trouble for the long term. That looks like this:

My preference is to go slower at first, but always fast enough to keep the business happy. That’s often pretty easy, as they have such low expectations. With a tolerant business and an appropriate velocity, you have nowhere to go but up. You can improve your skills, your code, and your velocity all at once. Like this:

Now, a bird in the hand is worth two in the bush, a euro today is worth more than a euro tomorrow, and a rational actor might be justified in preferring the first curve to the second. However, the novice teams I coach are in places that have already paid the price for going too fast, so that argument probably does not apply.

Because people are not rational actors and are acting in a world of radically imperfect information, we have to be careful. Because the business will structurally err on the side of wanting the team to go too fast, the team must err on the side of going too slow. In order for slowness to be tolerated, they must have an even more relentless focus on the business value and product-director-pleasingness of the velocity points being delivered. It may also require some mule-like intransigence. (Someone—Schwaber, maybe—once told me that one of the advantages of Scrum is that it has rules. When, for example, a executive wants to take aside a programmer for a special project, the Scrum Master can depersonalize the conflict by saying that The Rules say that means blowing the sprint, and does he really want to do that? It’s a shame the code internals have no such protection.)