Almost everyone (in the US) is familiar with the Healthcare.gov website and the drama that surrounded its launch. Interestingly enough the front-end was developed in 3 months using the Agile methodology, but back-end that had to connect multiple systems to IRS and Insurance companies used Waterfall methodology, the problem? Well, everyone decided to test all these systems close to the end, because that’s when you test them, at the end when there was not enough time, so they cut short testing and launch the website. As one can only imagine, the back-end systems simply did not work.
People who fixed that mess used Agile.
Rigid Plans vs. Incremental
Planning is important for combat, but the moment first bullet is fired, your plan goes up in smoke
Source: President Eisenhower
Waterfall relies on such “color-coded” and “detailed” plans that are good to look at but lack reality.
The idea that 100% of project requirements need to be captured and signed-off before analysis stage can be completed and design started, and that there will be no changes until the project is deployed is simply flawed.
Agile on the other hand is a time boxed, iterative approach that simply says instead of doing everything at once, build your software in 2-4 week iterations. Small bangs instead of a big bang. You still go through all stages that a waterfall project goes through, but in smaller chunks, so there is no compromise on design, quality or documentation.
Everything vs. High Priority
Waterfall processes require to implement 100% of requirements otherwise it is not accepted, so essentially all requirements are equal.
He who defends everything defends nothing.
Source: Frederick the Great
Time-boxed nature of Agile forces customers to prioritize, which means the most important stuff gets done first, and the least important is saved for last.
Delayed Feedback vs. Early Feedback
I worked on a project for a client where the waterfall was part of their DNA. After 6 months of analysis we took requirements to stakeholders for sign-off, and the very first comment, due to recent audit findings we need to add new requirements in scope.
Due to recent audit findings we need to add new requirements in scope
Back to the drawing board, after another 4 months we request sign-off, and once again due to org changes, we need to redo the whole analysis phase.
Let’s assume you successfully complete the development, and during the testing phase, your users interact with the software for the first time in months or even years. Usual customer response, you have developed what was in the requirements document but well this is not what and how we had imagined the system.
Not just users, this is the first time development team gets to test their architecture and design.
So Agile recommends to test and get feedback from users earlier and regularly, it welcomes the change.
Wasted Effort vs. Continuously Improve
Another issue that stems from waterfall methodology is that the expectation is 100% of requirements need to be implemented before software can be deployed. Study of hundreds of software systems show that users only use 20 % of the features, yet we deliver 100% of features, which means that the effort both money and cost spent on that 80 % of features might not have been necessary.
How do the iterative nature and requirements prioritization help? Agile recommends shipping early when you have completed 20% of the features that will deliver 80% of the value then deploy the software in production. And based on real feedback, re-prioritize remaining requirements, and then deliver 20% of those features. Within 2-3 releases you would have delivered more than 150% of the value. And you may or may not even need to deliver rest of the requirements and focus the effort on something else.
You only need to deliver what is needed, e.g. during the Iraq War, U.S. spent huge sums of money to build a chicken processing plant that did not get used, so finally, they asked villagers what they wanted? Villagers wanted a simple, foot bridge so that they don’t have to go all the way around to get supplies. It might not be as impressive but that was exactly what added value and was the need.
Poor Visibility vs. Improved Visibility
In waterfall being half way through the project does not necessarily mean you have implemented half the feature, but with Agile you always know how much work has been completed and how much is left.
You are also going to hear a lot of negative feedback about Agile, in my opinion, it is mostly propagated by people who do not do Agile the right way.