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. We break things up in milestones which also happen each couple of weeks, it has the same goal as classic scrum.

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.

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?

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

original content from here