If only we could anticipate things like requirements, hiccups, risks, interruptions, work, life and personnel issues in advance – software development would be a much smoother process. For decades, those within engineering fields have strived to streamline the processes, to automate where possible, and to stop starting from scratch on each project. Software engineering and development is no different.
The need for things like greater transparency, linking requirements to delivered software, appropriate levels of documentation, reporting accurate progress, managing change, and continuous delivery has given rise to various software development methodologies. These methodologies are most often broken out into two primary camps: Waterfall and Agile.
Waterfall is probably the most widely known and the favorite of the PMI (Project Management Institute). It is very well structured and lends itself well to commoditized project efforts; those of the wash, rinse, repeat flavor. If only software development were so accommodating. In Waterfall, the requirements are fixed and drive the plan, including estimates, resources and budget. The rigid structure means that changes are not easily absorbed. Often times, requirements are handed off to a development team and it could be several months before the customer gets to see and vet the results.
Iterative may be familiar to you as incremental versions of waterfall, where a project may be phased out into smaller releases or software versions. This was an attempt to reduce the inherent risk surrounding vague requirements and the inability to adapt to change in a structured waterfall process project. By breaking the project into smaller pieces, the thought is that requirements will be more defined and the project can adapt to change, allowing the requirements to drive the plan.
Agile has been around for some time and yet might be the most misunderstood. Many organizations share that they are in some stage of Agile adoption. Agile lacks the formalities of Waterfall, but excels in flexibility, adaptability and engaging customers. Agile provides the ability to respond and adapt readily to changes in business strategies, market, requirements or vision. In Agile, the resources and time drive the feature set to be released. This adaptability and flexibility lends itself to instability. You build what you need, get the code out and respond to feedback.
Customers seem to like the structure that Waterfall provides them with regard to an estimated timeline and budget based on fixed requirements. There is a perception of control that one can plan , market, or manage in their environment. However, Waterfall is slow, unresponsive and doesn’t conform to today’s continuous delivery model. In an age of immediate gratification, customers want deliverables quickly. Agile supports shortened development cycles where teams produce production ready deliverables at the end of sprints that can vary from two to four week increments. Agile also has its pitfalls. In a world of constant change, the original vision may never be delivered. For example, when you’re providing an API – what are the consequences of constant updates to customers of that API?
There is no distinct winner between Waterfall and Agile. Agile seems to be the best adopted practice within software development for now, because it is best adapted to continuous delivery.
In order to accommodate the desire for enough structure for planning and budgeting in contrast with the desire for continuous delivery, some organizations adopt a hybrid approach of both Waterfall and Agile – otherwise known as “Wagile”. Waterfall provides the structure for a defined start and end date, as well as traditional change management, but the inclusion of Agile techniques within the planning and execution phases supports today’s need for continuous delivery.
What are your thoughts on Waterfall vs Agile or other methodologies?