Agile software 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.