Waterfall and Agile are two methods used to develop software. Supporters of either approach can be fanatic believers, so it’s hard to find a good objective comparison.
The Waterfall method was developed and tested in other industries. The project requirements are gathered, a project plan is created then the project is built. Other tasks, such as documentation and QA, are performed as needed. The requirements phase helps both parties agree on what needs to be done. The project plan helps the client understand what will be built. It also helps developers understand the entire project, so someone will know how their work fits into the other parts. In theory it should remove unknowns and create reasonably accurate time and cost estimates. In reality it often struggles with those tasks. Inaccurate time and cost estimates affect all industries.
Agile projects use rapid iteration. A single iteration is typically one or two weeks. Development starts almost right away and continues until the client is satisfied with the project. Each cycle focuses on small objectives. It offers greater flexibility for things like scope creep.
Waterfall and Agile aren’t the only two, just the most common. Some industries, such as aerospace and military, have more stringent requirements. New methods are created as needed to fill specific roles. Those methods aren’t discussed here.
Consider Waterfall and Agile to be algorithms. They are algorithms for the mind and are used by programmers to create software. As such the same principals of algorithm analysis apply. Both should be analyzed for strengths and weaknesses. The method that best fits the project should be applied.
Time and cost estimates are handled differently for either approach. In Waterfall, a company estimates the amount of time required for the next step. This is presented to the client and the client signs off on it before work proceeds. The project can be halted at any moment. Agile doesn’t provide a cost or time estimate. They offer a rapid cycle and they keep working until both parties are satisfied. Unfortunately for Agile, clients normally have time and cost estimates even if they are not specifically mentioned. Agile tends to do a little better, though for reasons unrelated to the method. (That is discussed later.)
Some projects have far more features than others. Waterfall does well with this because the combinations can be listed during project planning. When a programmer writes one section, all details of that section are known so it takes one step to make the solution. Agile tends to add one feature at a time. It can really struggle with feature rich projects. Code for a feature is rarely found in just one place. It’s reflected in many different files. This means programmers have to step on each other’s toes when adding new features. What mostly happens is that combinations are missed. This is a form of technical debt. So, while Agile creates rapid advancement, it’s often an illusion that’s soon mired in technical debt. New iterations demand new features so the project becomes a constant battle between paying off technical debt and adding new features.
Complex projects can be similar to feature rich projects. Sufficient planning can help reduce the complexity, so Waterfall works well. Approaching a complex project using Agile will often increase the amount of work and time required. The eighty-twenty rule describes this. Eighty percent of the time, twenty percent of the code is used. Agile developers focus on this twenty percent and get it done quickly. This creates the illusion of rapid progress while creating technical debt If developers focus on the entire project then they can structure the code differently and create more elegant solutions. Waterfall can avoid that pitfall, but it requires sufficient skill. A senior analyst can simplify the project with a good elegant design.
Scope creep shouldn’t happen but it always does. Agile excels at scope creep so scope creep doesn’t affect it as strongly. When requirements change for a Waterfall process, they could be shifted into the next release. If this isn’t possible then the project might have to be restarted, which is costly. If you enter a project where a client constantly changes their mind, Agile is often a better approach.
Iterations are an important concept in Agile, but most Agile developers fail to realize that iterations also exist in Waterfall. Both types of iterations have a completely different nature. Agile iterations create something a client can see and provide feedback on. So if a project isn’t going in the right direction it’s caught quicker and the course is corrected. They often use the rapid iteration cycle as a metric for quality, so they will compare a Waterfall’s single iteration to six of theirs. This isn’t a completely valid comparison because different things are done within each iteration. One major benefit from Waterfall is that the design stage can be iterated. Designing a project is far faster than actually programming it. So if the Waterfall design stage is iterated, it’s similar to creating a completely new version of the project with each iteration. While this isn’t always done, a good developer will iterate their designs because each iteration saves an immense amount of time. If the design is iterated five or six times, the project’s first release is well polished and stable. This takes a particular skill set which not all developers have.
This brings us to skills. Programmers develop skills while programming. This probably seems overly obvious but it’s important to state because it provides a limit to the skills they have. Programming is but one skill a good developer needs. Skills are the reason why Agile tends to be cheaper because Agile only requires the skill of programming. Since programmers are virtually guaranteed to have this, Agile projects are more likely to meet cost estimates. Interviewing clients requires a skill set, project planning requires a skill set, documentation requires a skill set and even QA requires a skill set. If programmers have all these skills then Waterfall can out-produce Agile.
Automated tests are considered the domain of Agile, at least by Agile developers. Unfortunately for them, automated tests existed well before Agile. Automated tests are just code that runs other code and checks the result. It’s an extremely simple concept. Even though automated tests are considered part of the Agile process, they are, in fact, rarely used. For these reasons, automated tests are neither Waterfall nor Agile and are mentioned to make this clear.
Code quality is another property that’s not related to Waterfall or Agile. Generally good programmers write good code while unskilled programmers find new inventive ways to mess up.
Project size is one property that changes based on Waterfall or Agile. With Agile development, the more programmers you have the more collisions they have. This happens when two programmers need to work on the same file. This leads to a point of diminishing returns. Where this point lies depends on the programmers’ skill. Waterfall breaks things apart into smaller independent sections. This means you can use more people to complete the project faster. So team size impacts the choice of Agile or Waterfall.
Polishing a project involves improving a finished project. It can involve any aspect of the project. Polishing is very beneficial to the project so all analysts should schedule time for it. During Agile development this should happen intrinsically but rarely does. Agile developers tend to focus on new features and don’t overly test old ones. During Waterfall development, this should happen in the project plan stage but rarely does. It requires a senior level of analyst skill, which not many have attained.
Remember that Agile and Waterfall are but two algorithms. There are many more so avoid falling into the trap of preconception. You can create new methods as needed to fit the project. Also you can mix the methods together. Suppose you have a large project that requires many programmers but they work best in an Agile environment. First create a high level design without getting into specifics. Break the problem into parts then define the interface for each part. Assign groups of programmers to each section. They can design and build their section however they want. Some will use Agile and some Waterfall, but the project ends up better for it.
Agile and Waterfall methods have strengths and weaknesses. There is no best method for every project. Analyze each project independently and determine which method would best suit it.