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):
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.
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
- 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
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.