Agile and Fr(agile)

Imagine you are a building contractor and a person wanting to build a house comes to you. He tells you he has a piece of land on which he wants to build a house but he doesn't know what kind of house he wants. What approach would you take?

Approach A (Agile):

• You get your team to start digging the ground from next day 
• You are told by the person who wants that house (your customer) what he really wants on a daily basis (almost) 
• You don't know how many floor and rooms your customer wants until he himself knows and chooses to tell you 
• You are ready to re-do the brickwork as many times as the customer suggests changing the size and location of the rooms 
• You team meets every morning and discusses what they did yesterday and what they need to do that day
• Your team works without any blueprint but talks very often 
• You start building a wall and stop when the customer and team members feel it looks wide enough

Approach B (Traditional or Waterfall): 

• You make sure the requirements are known to a reasonable extent before starting the digging 
• You work with the customer to crystallize the requirements to a finer degree as the construction progresses You agree on the structure and overall design such as the number of floors and rooms 
• You are flexible but in a disciplined way, changes are welcome but done based on techno-commercial feasibility analysis which becomes more and more formal as the number of walls and rooms increases 
• You meet as and when required (and periodically as well if it makes sense) but the discussion is not only on yesterday and today but also what is needed to deliver the house to the customer as committed while ensuring your margins remain intact 
• Your team talks and also refers to critical guiding documents like the blueprint, electrical wiring layout, etc. You know the exact width of a wall before the first brick is laid

Approach A versus Approach B - Is Agile Really Better than Waterfall? Or is Waterfall Model, Original and Forever?

If you are a contractor you will most likely prefer approach B. The first approach is what would be an agile approach. It may work perfectly well but the change dynamics will make every day a challenge. This approach has an inherent fragility where it is difficult to predict what kind of house will emerge finally. It is possible the customer gets his dream house but that will depend on nothing going fundamentally wrong until the very end. At the same time the contractor may not be able to protect the profit margins because of too many change cycles. The second approach is what would be a traditional approach. Here the customer needs to know a great deal about what his dream house is going to be like and in case he was not right in his assessment of what a dream house means for him may end up not getting it. In this case the contractor may be very well able to protect the target profit margins.

Now consider what would you prefer if you are the customer? But obviously approach A. Isn't it interesting? As a customer you'd want maximum bang for your bucks and you'd love to get every change in your mind implemented till the last day at no additional charge. Besides, no one can blame you for not thinking hard through your requirements in the beginning because in this kind of agile approach you not supposed to do that.

Using Waterfall and Agile Together or Using Whichever Seems More Appropriate

Agreed there are situations where the final solution emerges through experimentation with alternative approaches (especially in emerging technologies where the behaviors are still not fully understood). In such cases being agile during the solution building process has its merit. However, even in such scenarios at some point in time the solution needs to be pinned down and taken to its conclusion. The fragility in such situations is a natural outcome of not understanding how a particular approach will work but needs to be frozen nonetheless to deliver the final solution.

Agile though fragile has its own advantages. The closeness between the two words agile and fragile is an interesting co-incidence. For any new technology though the initial work may happen using approach A there has to be a constant attempt to migrate to the approach B so that predictability and profitability is assured. This is crucial in a business context. For research, academic, first of its type, prototyping kind of work approach A (agile method) is probably a right choice however the inherent fragility in this approach has commercial implications and needs to be frozen to move towards the approach B (traditional method).

P.S.:

The adoption of agile methods in software development is considered to be a kind of revolt against the heavy, plan-driven, waterfall-like methods and models. It is clear however that these two approaches complement each other. If you are sure go traditional, if not go agile but try to be sure rather than not.