Waterfall vs. Agile – What’s right for our product development initiative?
A good half-a-decade ago, Waterfall was the benchmark when it came to product development. Within a matter of time, Waterfall turned out to become the traditional approach to all things product development – although more recently, Agile has made inroads into the world of development methodology. But here’s the deal: in the Waterfall development vs. Agile battle, there’s one thing to take into consideration – It’s not an academic debate. There is a telling impact on your product rollout.
Sure, Agile is the next big thing and Waterfall is trusted tradition – but there really is no one-size-fits-all way about this. Don’t wing that decision for it could cost you dearly.
Waterfall is a straightforward methodology that comprises a simple seven-step structure. You start with gathering document requirements, build a design, run development and unit tests, test the system, test user acceptance, fix bugs and then deliver the final product. Each unit being a distinct stage of the software development process, the steps are typically watertight and require completion before the next begins.
The Agile development lifecycle, on the other hand, rides the new-age tide of interaction. An iterative approach in its own right, the Agile development process is built on the edifice of team-building. What works here is the emphasis on the rapid delivery of an application within complete functional components.
The method does not rely on creating water-tight tasks and time-schedules, but rather uses phases called sprints – where work is time-boxed. Each of these phases lasts for a particular duration, comprising specific deliverables (typically a week to two weeks). The deliverables are decided one sprint in advance, and where there is a possibility that it may not be completed within the stipulated time, work is re-prioritised, and all the information is made use of for future sprint planning. At each stage, the customer evaluates the work as and when it is completed. Agile looks at the customer (sponsor, as s/he is called) as the most critical member of the team.
In the Agile development vs. Waterfall evaluation, you might want to make note of the fact that one seldom can make a linear choice. The very fact that each project will require a certain degree of acclimatisation and the choice of methods most suited to its needs is enough to require a certain adaptability in choosing the approach itself.
When should Agile be your choice?
You should consider using Agile in any of the following situations:
- If you or your customers are very clear about being fully involved, and have the wherewithal to do just that.
- If there is a time crunch and you want to remain in charge.
- If the project involves any effort that has the propensity for change at your behest
- If you are discerning, hands-on and fully in control of the requirements and can take charge of the direction – leaving precious little room for any disappointment in the end product.
- If flexibility, adaptability and evolutionary development are the qualities you expect, particularly in scenarios where the product evolves as you learn from the market
Hold your guns and don’t use Agile if…
- The project is less susceptible for change, the schedules are inflexible and you have a clear idea or want to know what you are getting into well in advance. Laying out the entire scope of work, Waterfall would be a better option in such situations.
- The outsourcing team decides that it should be the one in charge – a contextually appropriate decision where you are either unavailable or unwilling to take part in the process – Waterfall would be a wiser option.
- The amount of time and effort available on hand for the team involved with the project might be a bit of an issue. Agile might not work well because it begs greater commitment.
- Done is better than best – Iterative development cycles (unless the team follows test driven development) can quickly add technical debt (the shortcuts you take to launch a set of features within a sprint can be at odds with the long term performance and scalability of the product). If you planning for a prototype, Agile could work wonders. If you are planning for a mission-critical product, have the support processes in place to balance the impact on code quality that iterative development may introduce.
Agile or Waterfall, is not a debate on what’s fashionable on the ramp for this winter’s collection (though many first time product managers approach it that way). Waterfall is not un-cool and Agile is not a panacea. Choose wisely!