Agile Principle 6: Fast But Not So Furious

Agile development is all about frequent delivery of products. In a truly agile world, gone are the days of the 12 month project. In an agile world, a 3-6 month project is strategic!

Nowhere is this more true than on the web. The web is a fast moving place. And with the luxury of centrally hosted solutions, there’s every opportunity to break what would have traditionally been a project into a list of features, and deliver incrementally on a very regular basis – ideally even feature by feature.

On the web, it’s increasingly accepted for products to be released early (when they’re basic, not when they’re faulty!). Particularly in the Web 2.0 world, it’s a kind of perpetual beta. In this situation, why wouldn’t you want to derive some benefits early? Why wouldn’t you want to hear real user/customer feedback before you build ‘everything’? Why wouldn’t you want to look at your web metrics and see what works, and what doesn’t, before building ‘everything’?

And this is only really possible due to some of the other important principles of agile development. The iterative approach, requirements being lightweight and captured just-in-time, being feature-driven, testing integrated throughout the lifecycle, and so on.

So how frequent is *frequent*?

Scrum says break things into 30 day Sprints. That’s certainly frequent compared to most traditional software development projects.

Consider a major back-office system in a large corporation, with traditional projects of 6-12 months+, and all the implications of a big rollout and potentially training to hundreds of users. 30 days is a bit too frequent I think. The overhead of releasing the software is just too large to be practical on such a regular basis.

But consider a web site, a web-based product – or even more dynamic something like my blog. There’s no rollout overhead – it’s an automated central deployment to all users, and for the blog it’s a single click. No-one’s paying for the service. If something’s wrong, no-one dies. And it can be rolled back as quickly as it’s deployed. There may be thousands of users, even millions of users of a web site every month. But none of them need to be trained. And you can evaluate the impact on the user experience, and the user’s behaviour, through metrics within 24 hours and on an ongoing basis.

In that scenario, 30 days is a lifetime!

Competitors won’t wait. Speed-to-market is a significant competitive edge. The value of first-mover advantage is potentially enormous. Whilst it’s not always the case, research shows that those first to market 80% of the time win; and end up clear market leaders.

So how frequent is *frequent enough*?

Think carefully about your own situation. Think about the two extremes I’ve described above. Think about what’s right for you; your organisation; your product; your market; your customers. Think about what’s right for *you*, in your *particular situation*. There is no right or wrong answer. Only what works for you, and what doesn’t.

What is fairly important is to make this a positive decision to decide what’s appropriate for you. And then to stick, if you can, to a regular release cycle. A regular release cycle allows you to plan. It allows your infrastructure and ops teams to plan. It allows your business colleagues to plan. It allows your launch events, marketing campaigns, etc to be planned. And because agile development works to a fixed timescale, these plans are assured.

A regular release cycle also allows you to learn more effectively. Your estimating might be good, it might be bad. Hopefully it’s at least consistent. If you estimate features at a granular level (ideally less than 1 day) and track your velocity (how much of your estimate you actually delivered in each Sprint), in time you’ll begin to understand your *normal* delivery rate. And when you understand this well, you’ll be surprised how predictable you can be.

And let’s face it, managing expectations is really all about predictability. If people know what to expect, they’re generally happy. If they don’t, they’re not happy. Maybe even furious!

So, in agile development, focus on frequent delivery of products. And perhaps even more importantly, focus on consistent delivery of products.


3 Responses to “Agile Principle 6: Fast But Not So Furious”

  1. Derek Morrison says:

    I think the constant delivery makes good business sense – the ability for all stakeholders: sales, marketing etc to plan ahead and synchronise their plans with technical delivery of features/projects also makes good sense. I have posted an article on my blog a few days ago that discusses good business sense and technical sense coming together to make….


    All About Product Management

  2. Mishkin Berteig says:

    In my experience, which covers everything from large $100M+ projects to tiny projects, 30 calendar days is the absolute maximum Sprint or iteration length. Most organizations settle into a comfortable length of 10 working days. Letting your Sprint length be too long just leaves all sorts of problems uncovered. The shorter the sprint length, the faster you learn to do short sprints!

  3. Michael James says:

    One thing you might have missed here is the distinction between Sprint and Release. Scrum doesn’t require a release every Sprint, just a demonstration of potentially shippable product increment. “Potentially shippable” means we could bring it into shippable form after one stabilization sprint.

    As Mishkin wrote, I’d never go over a 30-day Sprint.


Leave a Reply

What is 6 + 10 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)