The Productologist

I wrote a comment the other day on another blog, Security Buddha, in response to a post about how Product Managers (at least not the ones who write blogs) are not really geared for rapid product release cycles. The author had reviewed several Product Management blogs, including this one, and came to this conclusion–

“I can’t help feeling that most of the PM gurus are cut out for old school software development with long release cycles and would balk at the real meaning in the Agile Manifesto.”

My comments on Security Buddha went something like this (paraphrased, but you can see the original here):

“Rapid release cycles can work for some products and I would like to be able to have more frequent releases, but there are trade offs and for me (specifically, my products), the trade offs are too great to adopt a strict Agile or rapid release cycle.”

There are aspects of Agile development (from here on out, I will use Agile to refer to any/all rapid release cycle methodologies; I know that there are significant differences between them, but for simplicity’s sake I am referring to them together) that I believe are beneficial for all software development. I called them out in my reply, but here they are again–

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity–the art of maximizing the amount of work not done–is essential.

For some products and software, Agile development works great. Consumer web applications are a prime example. I use several web-based applications on a regular basis (email, RSS, maps, search, auctions, community sites, etc.) and while I don’t expect changes everyday, I like when new features appear regularly and get enhanced shortly after release based on user feedback. I am equally annoyed by new features that don’t work or when features that previously worked get broken or disappear.

In addition to getting users new functionality faster, quick release cycles let Product Managers and Engineering tweak features so that they better match user requirements. Kathy Sierra over at Creating Passionate Users had a great post about a year ago about the impact of Agile development on consumer services like MySpace.

She commented on how her daughter is an avid user of MySpace and one of the main reasons that she (the daughter) loves MySpace is that it is constantly changing and growing organically every day–and that more and more Web 2.0 sites are adopting Agile development so that they can stay competitive. This is fine, but no one is using MySpace or most other consumer web sites as mission-critical software. If they are, they really should look at their definition of mission-critical.

Stability is another reason why Agile development is not always a good fit for software development. For example, enterprise applications are not well suited to Agile development because of the overhead involved in putting enterprise software into production at large organizations. One of my current customers has a 2-3 week validation process (sometimes longer depending on the scope of changes) for any new software before it can be put into production. Another customer has to rely on a third party organization to install any new software into their production environment and it has to be scheduled almost a quarter in advance.

Agile development can also place a significant burden on internal teams. While there is less coding to do during each cycle, other aspects of the release have to be repeated more frequently and at the same level as for longer release cycles. Documentation, Training, QA, and collecting user feedback all take more time in aggregate for multiple small releases than they do for the equivalent larger release. And for organizations that are not practiced in executing Agile, there is a high degree risk involved, too.

Don’t get me wrong, I think Agile can be a useful software development method, but just like religion, there is not one that works for everyone.

NOTE: for an interesting counter-perspective on why Agile is NOT good for any software development, check out this post on Tech Republic.

Popularity: 42% [?]

This entry was posted on Tuesday, April 10th, 2007 at 10:08 am PT and is filed under Documentation, Processes, Time.You can follow any responses to this entry through the RSS 2.0 feed.You can leave a response, or trackback from your own site.