Going slow

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:

Starting fast, slowing down

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:

Starting slower, getting fast

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.)

4 Responses to “Going slow”

  1. Exploration Through Example » Blog Archive » Six years later: What the Agile Manifesto left out Says:

    […] That’s a problem, because it seems to me that many new Agile teams are not executing. They’re floundering. [Here, I talked about teams starting out too fast, as I did earlier in this blog.] […]

  2. Exploration Through Example » Blog Archive » Mocks that specify essential implementation Says:

    […] than I could (in the early part of the project), but I don’t necessarily think that’s a bad thing. I trust that it’ll keep the cost of change curve flatter — though my trust in myself […]

  3. Agile manifesto and skill up your team « Discover Poppy Says:

    […] That’s a problem, because it seems to me that many new Agile teams are not executing. They’re floundering. [Here, I talked about teams starting out too fast, as I did earlier in this blog.] […]

  4. Exploration Through Example » Blog Archive » How I messed up a medium-scale refactoring Says:

    […] world” job - and even though I still believe that teams have to have the discipline to go slow to get fast - I keep going too fast. That in itself isn’t so interesting, but, in practically every case […]

Leave a Reply

You must be logged in to post a comment.