What is the real difference between Waterfall and Agile? It’s a question that you may be starting to consider—or are already considering—as you start to explore the impact of each software development approach. And with almost 71% of organizations reporting their use of Agile approaches sometimes, often, or always, you may be even more curious as to why Agile seems to be edging ahead in the race.
To begin, let’s review the chief differences between the two approaches:
Waterfall is the more traditional approach to software development and typically takes a linear approach. In this model, projects are long… typically 12-18 months or more. Often, many small enhancements are gathered into the larger project. The requirements are gathered. The system is designed, developed, tested and delivered. The project team is often assembled at the beginning of the project and disbursed at the end of the project.
Agile was first documented in the “Agile Manifesto,” which outlines the four Agile values and 12 principles. Agile is a more iterative approach to software development and focuses on products not projects. Instead of viewing the project as one whole project, work is prioritized and broken into smaller pieces with the goal to deliver something valuable in about two weeks that the customer can review. This two-week process is typically referred to as a “sprint” and has its own defined beginning, end and scope.
Agile teams are persistent. They stay together. If there is no more work on a particular product, the small team of about 5-7 members moves to another product as a team.
The Benefits of Agile
There are a number of reasons that businesses are increasingly embracing an Agile approach to software development, over the more traditional Waterfall approach. Let’s take a look at some of the chief benefits Agile provides to both the project team and the customer:
- Shorter Cycles and Ability to Change: In software development, change is New ideas, products and technologies come into the market all the time. Agile accepts and anticipates that there will be change and allows project teams to be nimbler. As the Agile manifesto states, Agile is about “Responding to change over following a plan.” When change happens, Agile says “No problem! This change will make our customer more satisfied.” The short cycles and sprints make change easier to incorporate.
- Partnership with Customers: Agile teams interact with their customer frequently, whereas with a Waterfall approach, communication is less regular. The constant interaction builds trust and partnership. A small piece of work is prioritized, created and delivered to the customer to use and provide feedback. This feedback helps the team create the most value in the shortest possible time. Imagine trying to create cell phones and their apps in a few large projects with none or very infrequent feedback from customers.
- Experiment and Fail Fast: An Agile team is always striving for excellence and experimenting on new ways to do things without fear of failure. The term “psychological safety” is often used to refer to a shared belief that the team is safe for interpersonal risk taking. The idea is that if the teams stay together and are more comfortable taking risks, they will deliver better, more customer-focused products.
- Focus on Excellence: Agile teams are together long enough to work through the Tuckman Model of group development. The model outlines a progression that starts with a group being very polite (forming), figuring out where individuals stand (storming), working towards a common goal and creating norms (norming) then being able to easily make decisions as a group (performing).
Bringing Agile into Your Environment
It’s hard to dispute the growing interest in Agile as a means to accelerate successful project outcomes and keep the customer as part of the development process. In fact, Agile is becoming so popular as a methodology that it’s not just for software development anymore! Folks in Marketing, HR, Finance, Education and many other areas can use the values and principles in the Agile Manifesto to deliver greater value in a shorter period of time. One of my favorite principles from the Agile Manifesto is team related:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Still there are other times when Waterfall might make sense—like when the project is naturally small, with fixed scope, time and budget, or with few unknowns, variations or changes in requirements. An example of fixed scope, time and budget would be paving a road. An example of few unknowns would be standing up the second or third data center in a small timeframe.
At the end of the day, it’s about understanding your project goals and determining the best course of action for your development team to hit your desired outcomes. Using Agile is only the first step. The real growth and benefit comes in by developing an Agile Mindset, or being constantly focused on collaborating with your customers, seeing failure as a learning experience and delivering value.