Choose a methodology that suits your project

In some of my previous posts (The project and the business analyst & System development lifecycles & requirements) I wrote about different development methodologies that have been used for projects. These methodologies range from very process-oriented ones (e.g., Waterfall) to people-oriented ones (e.g., Agile.) One thought I would like to leave you with is that you should determine which methodology works best for your initiative.

On his blog, Harry Nieboer posted a write-up called On predicting the success of a project from the characteristics of its team members. The just of the post was that a team could make most projects work with any methodology and fail on any project with any methodology. He quotes Alistair Cockburn who concluded that, "...people's characteristics are a first-order success driver of projects!" I agree with this statement, for the most part. There are circumstances where I would favor an Agile approach versus a Waterfall model. And, there are times when I would favor the Waterfall (or other more process heavy) approaches.

Would you use an Agile approach to build an oil rig?

Let's suppose you are working on a software development project. You find that there are many different features that your client wants and that your client's needs are evolving rapidly. First off, you'll probably want to institute a change management process so you can bundle up work packages for your developers; but in terms of approaches, an Agile approach with small (e.g., 2-4 week) iterative cycles will allow you to show your client progress and give them a good look-and-feel. This approach encourages lots of feedback that will allow you to incorporate good ideas into the next iteration. After a few iterations you will be closer to meeting your client's needs. Note that, over time it may be necessary to revisit a component to modify it to work with another component that was developed later.

Alright, so what are the characteristics of an Agile approach:

• Short iterative cycles.
• Frequent client feedback.
• Changes or evolution between iterations.
• Modification of previous components so they will work with newer ones.

Under what conditions would you not want to use an Agile approach:

• Suppose you are manufacturing a product (or in construction) and the different parts are made in different geographic locations but assembled at one place. I was watching the Discovery channel and they were showing a program documenting the construction of the Hibernia Oil Platform. They mentioned that some of the major compartments of the platform were constructed on 3 different continents and then shipped via boat. If the parts did not work together there would have been long delays, devastating cost overruns and (probably) lots of screaming & yelling.
• You will not run into clients who will be constantly twiddling with different features and functions. There are relatively stable and predictable requirements that must be met.
• The risk is too great if you don't know it upfront. Suppose you were an astronaut, would you want them to use a people-oriented process (e.g., Agile methodology) to build your moon rocket? Perhaps, but I'm sure you would express some concerns about your safety. Now if you were the NASA administrator signing the checks, would like this?

In concluding, I believe that some care should be taken when choosing an appropriate methodology for an initiative. Consider the costs associated with rework and the anticipated amount of evolution to requirements from clients as factors into your decision.