Building digital products is a complicated process that requires some way to organize all of the products' features. Think about it for a moment; every functionality on this website was created by a Web Developer. Every scroll, button, click, automation, page loads, and so much more, were mapped out as part of the software development process.
In some ways, building software from scratch is like constructing a building. There are layers built upon layers underpinning the actual structure that you walk through every day. In the same way you don’t see the steel and concrete holding up a building, you don't see the hundreds of lines of code underneath this website.
With any complex building project, you need a way to organize the process.
Complex software development is typically organized by either Waterfall or Agile methodologies. Both are design processes that focus on a series of sequential events. These methodologies are frameworks that house processes or steps that lead to the finished software. They include planning, building, testing, monitoring, and completing the software build.
But what is the difference? What types of software projects are best suited for Waterfall versus Agile?
Waterfall methodology has eight primary stages that are typically completed in six to 12 months. After each step is completed, the Software Developer moves on to the next step.
The eight stages include:
The methodology suggests that each step is a complete process within itself and the developer cannot go back to a previous step. If they do, the methodology suggests that the entire process must be scrapped and started over from the very beginning. Avoiding this requires extensive planning up front.
This approach is very structured and is easy to measure via clear milestones throughout the project. At the end of the development phase, testing occurs.
Waterfall is a solid methodology to employ when you know exactly what you’re building. It can force an organization through a complicated project in a full-steam-ahead approach that ensures you’ll reach the finish line and not get stuck in the small details.
Waterfall stresses documentation. It’s a tenet of the methodology that suggests keeping meticulous records is what will make the next project even better.
Waterfall is typically a solid process for enterprise organizations that lack the flexibility to shift a project midstream. Waterfall helps keep these behemoths on track by curbing any chance that the project will go off the rails. This is helpful to the customer, who knows up front what to expect for their deliverable.
Another benefit of Waterfall is that the meticulous documentation required by the methodology ensures that employee turnover will not derail the project.
“One problem is that the human brain’s forecasting capabilities are limited, leaving us prone to cognitive biases that lead to systematic errors of judgment.” – TechCrunch
While corporations may say they want to innovate, in fact, Waterfall actually can hinder true innovation. Waterfall can hamper a Developer’s creativity because it continually forces them forward toward project completion. They cannot go back to a previous step and make changes to the process. So while the software will be completed (perhaps) on time and on budget, innovative changes that occur during the iterative process have to be shelved until the next version is released.
Another problem is that if the development team and Product/Project Managers get the initial requirements wrong, they’re doomed to fail. If these teams lack experience in building new software, the chances are higher that they will make mistakes in planning. Imagine getting halfway through the project and realizing a mistake was made in planning. Waterfall methodology dictates that the team returns to the first step, scrapping the code that was created and starting over at square one.
What if the client’s needs shift during the Waterfall process? What if their budget increases? If the client requires changes to a software product being created with Waterfall, it’s back to the starting block no matter how far along you are.
Finally, under Waterfall, the digital product is only tested at the end. Since software code is built layer by layer, you can imagine the impact of finding out at the end that the first few lines of code you wrote are broken.
There is no “chicken or the egg” question here. Agile came about as a way to fix the drawbacks of Waterfall. The software project is drawn out with less detail to start, with development divided into modules or “sprints.” A sprint is a method of timekeeping, typically two weeks to a month. At the end of the sprint, tests are run on the completed code. Customer feedback is solicited, the project is tweaked, and then the next sprint occurs.
The Manifesto for Agile Software Development states:
Agile is the disruptor, and VersionOne’s State of Agile survey says 95% of American companies have adopted Agile workflows for their companies.
Unlike Waterfall, Agile allows for extensive changes after the initial planning. Change orders from the client are a common part of this process. This can cause the project to run long, which supporters of the Agile process say is a part of the creative software development process. Agile is perfect for finicky clients that don’t know what they want right out of the gate.
Agile is actually more suited for the technology of today. By the time you read these two sentences, some sort of technology disruption has probably happened; Agile methodology lets you shift with the market and with changes to the technology itself.
Also, unlike Waterfall which has a rigid series of steps, Agile makes improvements as development occurs. So while testing follows the build phase in Waterfall, with Agile, testing occurs concurrently as part of the programming lifecycle. Agile advocates say this creates a more elegant, bug-free code and an overall better product at the end of the project.
Client feedback is a crucial part of the Agile workflow. This naturally fosters collaboration between the client/end user and the developer team. Ultimately, it makes it more likely that the client will love the final product.
Testing is a huge benefit in Agile. Testing occurs at the end of every sprint. This guarantees that bugs are caught early instead of being a big pain at the end of the project. Because of this strong focus on testing, the software is more likely to be released, and in fact, could be launched at several points within the process.
TechCrunch reported on a study by Oxford researchers that showed Agile projects run long, and they cited cost overrun averages of more than 100%. Ouch. Without a definitive plan up front, it’s harder to stay on track and the end result can be a lot different than what was quoted or planned originally.
Additionally, Agile’s emphasis on sprints can push a developer team to cut corners, according to QA Symphony. When that happens, it usually means something is going to break during deployment, and that can be catastrophic. Celerity says the cost to “fix an error found after product release is four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.”
That’s exactly why finding the right balance between quality and speed is imperative in software engineering.
Waterfall is a more rigid methodology. On the flip side, perhaps Agile is why so many startups fail — it’s easy to overextend yourself by getting caught up in the creative process.
Software developed using the Waterfall method is seen as one single project with different phases. Agile is like many different mini projects or iterations designed to improve the overall software, driven by testing and a continuous feedback mechanism from end users.
In a head-to-head comparison of Waterfall versus Agile, here’s the scoop:
Waterfall is best when:
Agile is best when:
Generally, Waterfall is well suited for projects that have very clear requirements with no changes expected during the process. Conversely, Agile was designed to encompass the process of change management during software development. It’s a good method for creating new digital tools at a time when technology is rapidly evolving.
Both methodologies are effective for software development. Which one you use will depend on your project goals and work environment.
Need someone to help you figure that out?
Looking for someone to run your Agile sprints? How about a software developer? We know those people! Contact the Artisan Talent team to discuss your options.