Product Management :: Product Marketing

25 June, 2010

Agile Software Development - put in historical perspective

I went to the Cambridge Product Management Network last night on 'Product Management in the Agile World' from Roman Pichler, author of Agile Product Management with Scrum: Creating Products that Customers Love.

Agile in a historical perspective
Paul Walsh made a very insightful comment:

Agile (2000s) = Rapid Application Development (1980s) + User Experience (1990s)

RAD was all about prototyping, customer involvement and fast feedback. BUT those prototypes tended to be technology prototypes and didn't include what the customer actually received or experienced, so that they could provide decent feedback and steer the development effectively.

Paul and I nattered afterwards and both agreed that Agile wasn't best for v1 development, but much better for enhancement and product extensions.

On big, hairy feature enhancements
In fact, Agile means that you tend to avoid big, hairy feature enhancements because by their nature, they require lots of work which can't fit into a 6 week release cycle. So you tend to pick off the 'easy' incremental enhancements while the whole product slowly degrades whilst product management frets about 'biting the bullet'.

This problem is only solved by kicking out a research project that is independent of the development cycle. Agony and paralysis occurs when development needs SOME of the research project NOW and development starts cherry picking out of research. Yuk - a big management and technology sink hole, but sometimes inevitable.

Also Agile was much harder in platform + products environment (ie products that were dependent on a platform on which other product relied upon) rather than a single product development track. I'm not saying it isn't possible, simply harder - particularly if the other products on which the platform relies have difficult development cycle times.

Thinking about it, for the same reason, products that require VAR /distribution & delivery partners mean that the feedback cycle is longer and more at arm's length than the development cycle demands. This means that there are lots of incremental releases that never make it into the market / customers' hands.

No comments: