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!




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.