Have you found yourself at the crossroads? Tearing between Agile vs Waterfall project management? Caught off-balance by the recent stats showing Agile software projects to be over three times as popular as Waterfall? They also have over three times as many successful outcomes. Does that mean that Waterfall has outstayed its welcome? Our take: that depends. Every particular situation calls for a specific solution. It’s best to take a balanced approach and consider what really matters.
Use the plan to learn how to choose the best approach to your software product development.
A quick look at the two methods: Agile and Waterfall
The difference between Agile and Waterfall is best seen by comparison. Both methodologies have pros and cons. By understanding the development techniques, you’ll know when to use each and how to develop a better strategy for your project.
Waterfall model
This traditional approach to software development was named by analogy with its visual representation. The process is divided into subsequent stages cascading one into the other in a waterfall manner. Each stage involves new performers (designers, developers, QA’s) and has a ‘gate’ in the form of a client’s or business analyst’s approval and acceptance.
Here’s the regular procedure:
- Writing requirements specification
- Design
- Coding
- System testing
- User acceptance testing (UAT)
- Debugging and issue fixing
- Release
Read also: DevOps vs Agile: Myth-busting.
Agile product development methodology
A more recent and complex approach to developing software in short iterations (sprints) each resulting in some shippable functionality (increment).
Here’s how the workflow is organized:
- Sprint Zero: Big Idea, ideation, planning big
- Sprints 1 – n: Planning small – Design – Engineering – Showcasing potentially releasable increment – Reviewing
- Release
So what factors to consider while choosing between waterfall and agile project management methodologies?
Let’s Compare: Difference Between Agile and Waterfall
Strengths
Plan-driven Waterfall will appeal to natural planners, careful about detailed documentation of processes, used to seeing a whole big picture before getting into development. However, there is a fear to oversee an essential detail at an early stage as well as a risk of a product’s concept evolution. Thus embracing change is what makes value-driven Agile so irresistible.
| Waterfall | Agile |
|---|---|
| Plan-driven development | Transparent: the customer’s involvement throughout the development, getting a clear idea of the workflow and process organisation |
| Secured cost and time variables | Economical: eliminates waste (time for SRS, ramp-up between stages, lengthy stabilization, unimportant features) only the necessary functionality due to close ‘customer – vendor’ collaboration and product/market fit analysis |
| Clear expectations of a product’s functionality | Focused on customer and business value: value-driven approach resulting in the product’s success |
| Project management is easier due to ready specifications | Early delivery: the product is potentially releasable after each Sprint (2 weeks’ period) |
| Flexibility: change is welcomed, prompt reaction to market needs | |
| Intrinsic quality: workable code throughout the process |
Consider the time
It may seem that Waterfall, being timeboxed, may take less time, as you make a beeline with clear specifications, whereas with Agile you tend to go in circles because of changes. That’s true to some extent. However, with Agile, your product starts bringing revenue early, while still in the making, and it has a minimum of functionality. Thus the time-to-market is considerably reduced. Moreover, the client ultimately gets the best value for money as the development process goes hand-in-hand with market discovery.
| Metric | Waterfall | Agile |
|---|---|---|
| Planning time | Long | Short |
| Time between specification and implementation | Long | Short |
| Development path | Straight, plan-driven | Curved, value-driven |
| Time to discover problems | Long | Short |
| Time to a shippable product | Long | Short, timeboxed |
| Time-to-market and ROI | Fixed | Adjustable |
| Project schedule risk | High | Low |
Check also: Earned Value Management (EVM) for Agile Software Projects
Consider the budget
Waterfall and Agile utilize different pricing models. If a budget has to be determined at the start and cannot change as additional funding will require a lengthy procedure, then go for Waterfall on a Fixed-price contract. By choosing Agile project vs Waterfall, you start with a vague idea of overall cost, but in the end, you will get better value for money.
| Metric | Waterfall | Agile |
|---|---|---|
| Project’s actual cost | Higher due to included risk premium | Value dependent |
| Pricing Model | Fixed-Price Model | Time-&-Materials or Cost+ Models |
| Project estimation | Initial order of magnitude estimate, detailed estimate after SRS creation | Initial order of magnitude estimate |
| Project’s cost control | Frozen at the start by a Fixed-price contract | Not fixed initially, but determinable and strictly controlled by tracking tools and metrics |
| Cost-value dependency | Only the functionality included in the SRS | High-value features are delivered early and may start bringing revenue |
Check also: How to Manage Cost and Time of Agile Software Project
Consider the complexity
More complex projects will need a more elaborate initial analysis and run a higher risk of scope creep. Agile may considerably reduce time by eliminating big planning up-front. By delivering piecemeal and tweaking as you learn, you will eliminate the major risk. Where the scope is clear from the start and is not likely to change, Waterfall is a safe option.
| Metric | Waterfall | Agile |
|---|---|---|
| Project’s scope | Fixed, well-defined at the start | Flexible, can be changed at any stage |
| Possibility of scope change | Low | High |
| In case of necessary changes in scope | Lengthy procedure of change requests. The project may have to be started anew | Change is part of the development process |
| Project’s complexity | Low | High |
| Additional stages of testing technical feasibility | Prototype development | None |
Deciding on the right method, consider Dave Snowden’s Theory of Complexity (aka Cynefin framework). He differentiates four types of projects and corresponding strategies to tackle them:
- Complex (partially repeatable) – use guidelines;
- Knowable (repeatable) – focus on best practices;
- Chaotic (not repeatable) – use principles;
- Known (repeatable) – comply to rules.
Only the last type goes well with Waterfall. The rest are safer with Agile.
Alternatively, determine the level of complexity by adapting the Stacey matrix for software development. The two axes – requirements (what) and technology (how) range from the known to the unknown. What it means is adopting new technology requires a learning curve. Evolving requirements add uncertainty to the timeline of implementation. Accordingly, any project can be classified as: simple, complicated, complex, or chaotic. Check the graphics below.
Consider your role
Are you ready to be actively involved in decision-making on a daily basis? If yes, you can assume the role of a Product Owner and go for Agile. Being able to influence development directly at any stage will translate into quality. Consider if you are ready to assume this role and get a new hands-on experience. The Waterfall is adversarial rather than collaborative due to possible misinterpretations of SRS.
| Metric | Waterfall | Agile |
|---|---|---|
| Distance between customer and developer | Long | Short |
| Customer’s involvement in the process | Initially and at milestones | Throughout the process, on a daily basis |
| Ability to influence the project’s flow | Only at the pre-production stage (before signing the contract) or through change requests procedure | Inherent in the workflow model through Product Backlog prioritization and grooming, via regular feedback at sprint reviews |
| Degree of formality | Very formal | Adjustable |
| Communication modes | With Project Manager (in person, calls, formal documents) | With Scrum Master and Development Team (in person or via collaboration tools) |
| Customer-vendor relationship | Adversarial: divided by the contract’s provisions | Cooperative: synergic problem-solution process. |
Consider the process
The major advantage of Agile is efficiency – minimum waste, maximum involvement and collaboration, early value delivery, regular quality assurance and automation. Waterfall is ideal for manufacturing, but software development is a whole other thing.
| Metric | Waterfall | Agile |
|---|---|---|
| Stage cohesion | None, linear stage-gate process | Cyclic iterative process |
| Collaboration of the team | Limited to handoff points, specialists may be unavailable due to their engagement in multiple projects | Coordinated and organized: specialists collaborate most of the time during each sprint |
| Feature prioritization | None. Rigid process structure | Value-driven prioritization, the most valuable features are delivered first |
| Efficiency | Lowered by the rump-up/rump-down between stages | High, as soon as the team develops stable velocity |
| Product quality | Fragile, unstable till the very end. Testing and refactoring takes up loads of time & effort | Enhanced by test-driven development, secured by process automation, continuous delivery and continuous integration |
| Criteria of project’s success | Compliance with SRS (being on Time, on Budget, on Target) | Actual business value (being on Time, on Budget, on Goal, Value and Satisfaction) |
Read also: Software Product Development Process at CodeTiburon
Best-fit project types
We’ve given a list of project types that go well with Waterfall in our article on a Fixed-price model. Let’s see how various attributes of a project comply with the two methodologies.
| Metric | Waterfall | Agile |
|---|---|---|
| Project’s size | Small, middle-sized | Any size |
| Project’s requirements | Well-defined, unlikely to change | Unclear, need further learning and are likely to change |
| Project’s scope | Clear at the start | Likely to creep due to complexity, unknowns or high risks |
| Project’s budget | Has to be fixed and documented to get the project initiated | Available as an order-of-magnitude figure |
| Project’s specificity | Has to be delivered in one piece | Can be delivered piecemeal |
| Project’s success | Determined by the defined feature set | Ensured by early delivery of a minimum set of valuable features |
To conclude
Choosing the right approach to your project is crucial to success. Knowing the ins and outs of both methods, you can make an informed choice – regardless whether it’s Agile or Waterfall – and thus anticipate the project’s outcome.
Which methodology fits your project best? Have you found the article helpful? Feel free to leave a comment or give us a call if you have questions.
What’s your take on Agile vs Waterfall project management? Share in the comments.
Nice article and a great comparison of two completely different methods! =) However, in my opinion, every project should leverage iterative methodology. Waterfall as well as any other method that attempts to freeze or fully define requirements at the start is fundamentally flawed, based on a false assumption that the specifications are predictable and stable and can be correctly defined at the start, with low change rates. That assumption underlies many failed software projects. Research (collected from many sources) shows conclusively that the 1960s and 1970s-era advice to apply the waterfall was ironically a poor practice for most software projects,… Read more »
This article is pretty good. Tanks for sharing. A reader from Beijing.
Thanks, Andy!