A lot of organisations trying to find a faster way to bring capability to market look to AGILE as a means to that end. Often they are larger organisations, hamstrung by bureaucratic processes and too many layers of decision making. AGILE is seen as a way to accelerate the development process vs traditional waterfall type development methodologies used by Product Managers. So the question is often asked: Does this mean the death of traditional Product Management??
In a word: NO!
It is true that AGILE allows faster needs recognition and development for pure software based offerings. But as soon as a service offering has some form of heavy IT or manufacturing, or is heavy reliant on process, the use of AGILE becomes more problematic…
On top of that, AGILE often results in the delivery of offerings that are often orphaned from the rest of the business. As an organisation, we do a lot of work with Telecommunications companies around the world – and see this A LOT. Many organisations see AGILE as a way to get to market quickly – but often what happens after launch is more important than what happens before launch!
AGILE also does little to address lifecycle management – which ultimately – while not as sexy as developing new products – is where the rubber hits the road in terms of revenue/profitability. As such, lifecycle is in many respects more important. AGILE’s focus on development often results in some of the basics like documentation, OSS/BSS & process integration, training being missed… This is where the risks lay when an organisation gets too fixated on AGILE.
But let’s be clear, AGILE has a place – and a very important one at that! AGILE is great in helping organisation accelerate needs recognition through to delivery for “software only” developments. Waterfall makes more sense in organisations with very complex offerings that include hardware, software and processes…
The whole AGILE vs Waterfall debate is, a redundant one. In some cases we see the use of a combination of both: AGILE for the software deliverables, waterfall for everything else. Ultimately though, any new product development needs to be delivered in the context of a Lifecycle Operational model – which is where “Traditional” Product Management comes to the fore.
