Agile seems to be becoming the default approach to projects. However, here are a few of my own observations to those considering this methodology for their next project.
Agile was born out of a realisation that projects often delivered results that were obsolete or had little relevance to the business by go-live day. This was mostly because:
- The requirements changed drastically from the start of the project; or
- The business wasn’t able to describe the requirements at the start of the project.
Agile wasn’t designed to be the most economical approach and it inherently has features that mean it often costs more overall than waterfall.
The financial benefits of an Agile approach are attractive because of techniques associated with it (i.e. Prototyping, constant user interaction, prioritising requirements), but these are for the most part applicable to traditional waterfall projects as well. I would be interested to see metrics comparing waterfall versus agile where these specific techniques have been applied to both.
On the other hand Timeboxing, as a means of attaining flexibility, is a technique that sets Agile apart from the convential waterfall.
Sponsors and PMs should bear in mind that the core methodology is inherently inefficient, in that:
- Applying iterations means that code is revisited and may be modified several times (with multiple rounds of testing).
- Non-functional Protoypes are an overhead, if not used in the end solution.
- Greater user interaction means that customers must devote more time to the development process.
- And from a technical point-of-view code that has been rehashed several times can result in poorer performance.
But, on the assumption that a solution that is not ‘fit for purpose’ post implementation is a waste of time and money, what Agile was designed to offer is confidence.
- Confidence in timescales and budget – later iterations can potentially be dropped if either runs out.
- Confidence in suitability – that the solution will have undergone frequent review in the course of the project, rather than fixed from the start.
Back in the 1990’s DSDM (Dynamic Systems Development Methodology) included a suitability test, to establish whether the project was a credible candidate for it. From what I have read XP and “Scrum” don’t have this step. So the Project Manager must perform this assessment outside of the methodology, and I suspect that many projects are managed in an Agile way, without due consideration of whether it’s the right tool for the job.
So, rather than follow the herd, take a moment; weigh it up and conduct your next project in the most appropriate way. Don’t simply assume that Agile is always best.