Sunday, September 23, 2012

Agile or Waterfall? Criteria demystified…

One of the major concerns across many organisations is whether to go for Agile or Waterfall methodology. Most of the project managers higher up in the corporate ladder have to take this decision. And this becomes more difficult when one has the pressure to deliver a successful project at the end.

Thankfully, there are certain criteria’s that help in deciding whether to go for Agile or Waterfall. Again the problem lies when managers tend to use it more like a cookie cutter and hastily draw conclusions.

So, the first lesson is not use these criteria’s as mere criteria’s but as indicators that guide you in the process of deciding Agile or Waterfall.

Here are some of the key criteria’s (or rather indicators):

1)      Project Scope: When we say Project scope, it is more to do with whether it is a dynamic one and is ever-changing (typically faced in IT – Software projects where the customer is not very clear on how he wants the software to operate due to its abstract nature) or whether it is fixed – (most of the construction or power projects where the goal is to build a dam of specific dimension for a specific criteria or certain fixed units of mega watt power generation capacity). If it is Dynamic in nature – you may need to go for Agile, else go for the waterfall approach.

2)      Type of Projects: Here we deal with whether the project is an experimental one (like proof of concept as in software or a drug trial experiment in pharmacy) or whether it is about delivering a product, service or idea. Dynamic projects can be better handled using Agile while others can be managed with waterfall.

3)      Delivery - how do we deliver? : This is related to point 1 and 2, based on which the customer may expect incremental deliveries in parts or may expect the whole product at the end. If the scope is dynamic, then the customer may expect frequent iterative deliveries and this will mandate for agile methodology. E.g., a software product where the customer would like to see which parts of the product is built over each iteration. Or a road construction where the road might be built part by part in phases to cover all the areas of the city. Projects where the customer may expect end result at the end would be say, a 100 MW power plant to be installed at the site and this may warrant a waterfall approach.

4)      Technology: Agile methodology is more suitable in case of projects dealing or creating new technologies. An iterative approach will help in getting continuous feedback and scope to improve. Waterfall methodology can be used where the technology is already stable and proven.

5)      Culture: Culture plays an important role in deciding if an organisation wants to go for Agile or waterfall. If the customer is active and very much involved and the management believes in self management and supports Agile, then it is easier to implement Agile. Else a waterfall approach is recommended.


However these criteria’s are mere indicators and cannot be applied in isolation. E.g., Point 1, 2, 3 and 4 may compel the organisation to go for Agile and then go about creating an environment of cultural change so that there is more support from senior management and that the customer becomes more active. If the customer cannot adapt, then it may bring in Business Analysts who can proxy the customer and take continuous feedback from the customer.


So, a better approach is to measure each of the above points from 1 to 10. Where 1 is purely agile, 10 is purely waterfall and 5 is hybrid approach of both.

Then measure each of the criteria’s separately in a scale of 1 to 10.

Apply weightage depending on which of these criteria’s are more important to the organisation.

Get a weighted average score and then decide on whether to go for agile or waterfall.
One may add more criteria’s to the above ones. Also, measuring each individually will give an idea where does one need to make changes to help implement the appropriate methodology.

No comments:

Post a Comment