Look anywhere online and you will find an endless supply of articles describing the choice between Waterfall versus Agile development methods. Most of these articles pit the two methods against each other, and describe the two as mutually exclusive choices: waterfall OR agile. Here we will describe the main principles of each method, and debunk the belief that we must always pit the two mythologies against one another.
Waterfall practitioners lead their projects with a fixed, concrete plan from day one, it’s a sequential process with clear, separated gates between each task. Developed in the 1970’s by Winston Royce, the Waterfall approach is traditionally used in the construction and manufacturing industries. The approach uses stage gates between phases, and treats each stage as a separate, fixed component. There is no going back between stages.
If you’ve ever heard the terms Lean, Kanban, or Scrum, you’ve come face to face with some of the many tools developed out of the Agile approach.
To understand Agile, let’s go back to the origins of the approach. Agile was first developed from a group of software developers, who gathered together at Snowbird ski resort in 2001, and decided to create a manifesto about what they viewed as great software development principles. Here are the principles they developed on that day in the Utah Rocky Mountains:
“That is, while there is value in the items on the right, we value the items on the left more.”
(Source: Forty Design’s excellent agile article.)
What followed from this manifesto was a development methodology, and an entire industry of tools and services supporting companies to adopt its practices.
Unlike Waterfall, the Agile approach embraces change and uncertainty as a core philosophy. It’s a piece by piece approach, where a project is broken into several iterations, often called sprints. Each iteration or sprint is a mini project in its own right, with a goal to deliver a working feature, before moving on to the next iteration.
Writers often love to pit the two methods against each other, suggesting the choice is black or white. In reality, Agile and Waterfall are more appropriately viewed as two extremes on a spectrum. When we think about applying some of these principles to our organizations and projects, we are most likely to gain success by looking critically at the main goals and benefits for each approach, and creating our own blend that’s optimized for our particular business— and the specific project at hand.
For example, a cloud solutions provider working on a new Software as a Service (SaaS) development will likely love the speed and flexibility of the Agile method, allowing the project to create incremental prototypes and pivot as needed. However, Agile’s lower value for documentation may not meet the needs of every team. For example, if the team expects to hire new developers during the project lifecycle or if turnover has been an issue in the past, they may prefer to integrate some of the Waterfall method’s principles for its strength in documentation.
In some cases, a company may implement both methods simultaneously to suit its different business units. For example, a cloud service provider may benefit from the Waterfall approach for its core products, servicing established customers. The defined, repeatable nature of the Waterfall approach would be ideal to sustain established products and services, during their lifetime. Meanwhile, the company may be engaging in new activities which will be a key to future growth, such as migrating customers to cloud solutions, or developing new Service and Infrastructure as a Service offerings to keep pace with competitors. The new technologies and the new customer demands will introduce many unknowns to the project, and will require many opportunities to be adapted from customer feedback— both during development, and after initial launch. These innovation projects would be a great candidate for the Agile methodology.
If there is any uncertainty about the product or the market, we strongly recommend incorporating some of Agile’s philosophy into the project. This will give the project room to grow and change, with a structure to experiment, adapt, and refine as the uncertainties are gradually understood. We recommend picking and choosing elements of the Agile philosophy that work for our projects and teams, without feeling the need to follow the approach devoutly.
Take the principles that you believe will work for your company, and create your own style that will allow for those principles to be achieved. Each project and team will be unique, and the success will lie in creating a unique method that works for the particular company, project and goal.
If you’re curious to learn more, here is a great white paper from The University of Missouri to further your knowledge about Waterfall and Agile principles.