The most dangerous situation occurs when the distinctions between agile and rigorous methodologies become confused
Agile and rigorous systems development methodologies now sit side by side at the methodology board table. In fact, the range of methodologies available now is so broad that selecting the right methodology for the job can be quite a challenge.
The wrong choice, while not necessarily fatal, may significantly reduce your chances of delivering a successful project. On the other hand, the right choice in the wrong hands can lead to spectacular failures.
Agile methodologies are ideal for exploratory work. If you are developing an innovative system and need to explore the boundaries of process design or technology then an agile approach may be just what you need. Likewise, if the business requirements are likely to change, and if you have a highly talented and experienced team of developers, then this may be the right approach.
Rigorous (also referred to as planned or traditional) methodologies are ideal for optimising projects where the requirements are well understood, can be clearly stated and where a tightly scoped, highly critical project needs to be produced to a specific deadline. If you have a large development team a rigorous approach may be the safer option and it is your only option unless you can ensure that business representatives will be working side by side with the developers on a daily basis.
A common trap is the adoption of an agile approach in order to avoid developing a detailed project plan. An inexperienced developer or manager, for instance, may claim that a detailed plan isn’t necessary “because we’re using an agile approach”. This may be true under rare circumstances (on the extreme end of the exploratory optimising continuum) but in almost all other cases the development of a project plan will improve efficiency and effectiveness.
The most dangerous situation occurs when the distinctions between agile and rigorous methodologies become confused. One project that I reviewed started as an agile project, then ostensibly changed to a rigorous project in transit. The project was essentially a rewrite of an existing system, so the scope of work was quite tightly defined. As the existing system was reaching its end of support it also became a highly critical project.
The team had initially developed some very rough estimates for the completion of each major project phase but these were purely indicative and it was envisaged that they would change over time. However, once these phase estimates were unwittingly provided to the company’s customers (who were now counting on their timed delivery), the team realised that they could no longer use an agile approach and they adopted a rigorous one.
This team still resisted developing a project plan: at a personal level, the members still identified themselves as agilists. This was leading them down a slippery slope to disaster until the project manager was finally convinced of the need for a detailed project plan. With the plan in place the team felt more confident of success and more motivated to achieve important milestones.
In the final analysis, the choice of an appropriate methodology is important. However, being clear about what that methodology is, why you are using it and how to get the best out of it is absolutely vital. That way, even if your choice of method is mad, at least you can’t be called crazy!
Gerald Khoury consults, lectures and writes in IT strategy and planning and currently works as consulting director at Gartner. Contact him at gerald.khoury@gartner.com
Write to the Editor at Technology and Business
* All fields are mandatory.