While there are numerous software development methodologies, the two most popular are Agile and Waterfall (sometimes called Cascade). Waterfall is considered the more “traditional” methodology, while Agile is recently being considered the new kid in town and front runner. The Agile methodology has been around since the mid-1990s, but it’s gaining in popularity in part because of the failure of the waterfall methodology. While both methodologies have the same basic steps (requirements analysis, design & architecture, implementation, coding, quality assurance & testing, and maintenance, support, & documentation), the way each step, or phase, is implemented varies greatly.
Many companies are moving to agile development for software and business analysis projects and away from the traditional waterfall method. So, why do professionals now prefer agile development over the waterfall methodology? Any analysis of agile and waterfall should include the basic principles and possible pitfalls of each. Let’s start with waterfall, since it’s the older of the two.
The Waterfall Methodology – Cascading to the Bottom?
The waterfall method is based around the “80/20” principle, meaning that you do the bulk of the analysis, technical considerations, and architecture up-front, with the hope that you only spend 20% of your time building the product. Basically, plan well, followed the specified order of things, and everything will fall into place. For organizations like construction and manufacturing, waterfall has been and continues to be popular. If your deliverables are well defined and are likely to not change during the development cycle, then waterfall can work well in your business model.
The downside to waterfall is that it’s anything but agile, in more than one sense of the word. Waterfall methodology is rigid and structured. It’s also easy to get bogged down in the requirements phase because so much is riding on it. Because waterfall projects tend to follow a strict project plan, if the requirements phase gets extended, that overage trickles down into the next phase, and so on. By the time you get to what should be the end of the development cycle, it can often be chaotic while all the teams struggle to meet deadlines and play catch-up.
With waterfall, once you define your requirements, you don’t go back and modify or add to them. You move on to the next step. The same goes for any technical or coding challenges, which can make adapting to change difficult. And, worse yet, you can end up with a finished product that nobody likes because they wish it could do ten other things. Unfortunately, that means that your users must wait until the next release to get those ten things they wish they had right now. The same issue continues to rear its head; the waterfall methodology doesn’t do a good job of keeping up with user needs and expectations and being able to adapt quickly to those changes.
What’s So Great About Agile?
Agile is the cool kid in school, primarily because of the allure that it is both cheaper and faster to develop software than the waterfall method. The agile methodology is flexible, adaptive, and responsive; it doesn’t follow a linear model of software development like the waterfall method does. Agile can be cheaper and faster if it’s implemented correctly and the organization has the infrastructure to support it. For older organizations that are transitioning from waterfall to agile, the transition period can seem chaotic at first. Often, these organizations implement agile slowly or in a hybrid form, rather than making a one-time, large, corporate-wide change. This gives the business time to adapt their other processes to better fit the agile methodology.
The real value of agile is its ability to respond quickly to change. This helps to ensure that the product genuinely addresses the needs of its end users, rather than what the requirements analysts thought the needs would be many months prior. The reality of the world today is that we live in an ever-changing situation, and business requirements are no different. The odds of accounting for every requirement or need so early in the process yield a low chance of success. The failure of waterfall to properly address the needs of users is what helped make agile popular. Software development is expensive; for many companies that aren’t strictly IT shops, the IT department and software development teams are viewed as cost centers. Not only can agile development make an organization more flexible in its ability to meet customer needs, but it can save money because projects can be completed more efficiently and satisfy customer needs, which in turn, generates income.
Agile can benefit an entire organization, not just a project. Successful agile teams are collaborative and highly skilled, comprised of representatives from each group (requirements, architecture, development QA, support, and documentation). Agile teams are designed to manage and juggle priorities, which means the members of those teams have a more flexible skillset. Because agile projects tend to be faster to deliver the end product, that means that agile team members are often available (and capable) of working on multiple cross-functional teams. Being more flexible also allows the team members to keep their skills sharp by working on other projects or even attending training or seminars. If you consider the flexibility of not only the agile development process, but the team members involved, the agile methodology can decrease overall overhead costs and increase output, which would be considered a success by most organizations.
While there is no real consensus among the software community about how to define the success of a project, there were a few constants: Return on Investment (ROI), Stakeholder Value, and Product Quality. While these aren’t the only three measures of the success of a project, most software professionals agreed that if you succeed in two of the aforementioned three categories, you can consider your project as successful.
Various studies have been conducted to analyze the relative success of agile and waterfall methodologies. According to Ambysoft’s 2013 Project Success Rates Survey, the agile method has a 64% success rate, while the success rate of the waterfall method is just 49%. The survey used four measures of success:
1. Product Quality
2. Stakeholder Value
Agile was the clear winner, with the greatest advantages in Time/Schedule and ROI.
In the 2015 CHAOS Report, the Standish Group evaluated how successful agile projects were compared to projects developed using the waterfall method and various other factors. Chaos Reports are considered as a sort of “snapshot” of the software development industry.
The CHAOS Report considered a project as successful when the schedule, cost, and scope of the project was met. If only two of the three measures were achieved, the project is considered “challenged.” If only one condition is met, the Report considered the project as failed. Under the agile methodology, 42% of the projects were successful and 49% were considered challenged. The waterfall methodology had only 14% successful projects. 57% of the waterfall projects were considered challenged, and a staggering 29% were considered failures.
Furthermore, the Report found that agile development was superior to the waterfall method regardless of the project size. Agile had its greatest advantage in medium to large-scale projects, but it was a clear winner in all categories. Taking this data into account, implemented properly, agile seems to be the clear winner over the waterfall method for successful projects.
For agile development, success is all in the name. Experts and software professionals prefer agile to waterfall because it can make an organization more flexible and able to respond to changing needs in a timely fashion. While the waterfall method is still used and was once the most popular development methodology, the rigidity of its linear structure severely limits projects developed in this cascading manner. Agile became popular because of the failures of waterfall in delivering content that addressed the current (and possibly changing) needs of the users. We live in a time and a society where instant gratification is a requirement, not a “nice to have.” Older, more rigid methodologies like waterfall are falling by the wayside because it can’t keep up with changing demands. By the time waterfall adapts to a request for change, it’s yesterday’s news. Agile development is light and responsive, like the sportscar of software development. If you have all the right pieces and a quality product, it’s easy to adapt and change quickly to the environment. Well-managed agile development teams outpace the waterfall methodology with ease. When done right, agile is cheaper and faster, and that is why it has become a favorite of software professionals.