Opening the book…
Predictive vs. Adaptive
Predictive approaches work best when the path is known; Agile approaches work best when learning is part of the work. Traditional project management relies heavily on predictive planning. The project team attempts to define the entire scope upfront before any building begins. Once that scope is locked, the team estimates the time and cost required to deliver it.
Waterfall asks, “How do we protect the original plan?” Agile asks, “What have we learned, and how should we adapt?”\
This approach can work well when the work is stable and predictable. For example, if a company is building the same type of warehouse it has built many times before, a predictive plan may be appropriate. The requirements are known, the sequence of work is understood, and changes are relatively expensive.
Waterfall typically moves through phases such as requirements, design, development, testing, deployment, and closure. Each phase is completed before the next begins. The logic is simple: understand first, design second, build third, test fourth, release last.
The problem is that many modern projects do not behave this way. In software, digital products, data projects, AI initiatives, innovation work, and customer-facing platforms, the team often cannot know everything upfront. Users may change their minds. Competitors may release new features. Technology may behave differently than expected. Legal or compliance requirements may evolve. Stakeholders may only understand their real needs after seeing a prototype.
Agile approaches the problem differently. Instead of assuming that all requirements can be known upfront, Agile assumes that learning will happen during the project. The team delivers small increments, gets feedback, and uses that feedback to decide what to do next.
| Aspect | Waterfall | Agile |
|---|---|---|
| Plan |
Plan is often treated as a baseline to protect scope, time and cost boundaries |
Plan is treated as a living guide to deliver the highest value |
| Change | Change is often seen as disruption. | Change is seen as expected learning. |
| Success | Success is often measured by delivering the agreed scope. | Success is measured by delivering customer value. |
This distinction is central to PMI-ACP. The exam will often present a situation where the original plan conflicts with new learning. The Agile answer usually favors value-based adaptation over rigid plan compliance.
Project Management Triangle in Waterfall and Agile
Waterfall and Agile handle the triple constraints differently. In a traditional Waterfall approach, the project scope is usually defined and fixed early, while the schedule and cost may change as the work progresses. In Agile, the team fixes the timebox and cost, usually through sprints and stable team capacity, while the scope remains flexible. This allows Agile teams to adjust priorities, refine requirements, and deliver the highest-value work within the available time and budget.
Figure \(\PageIndex{1}\): The Diagram shows the how Agile and Waterfall are like inverted triangles. (CC BY 4.0; Guha Janakiraman). Accessible text description of Figure \(\PageIndex{1}\)
However, this does not mean Agile is always better than Waterfall. The best approach depends on the nature of the work. If the requirements are stable, the solution is well understood, and change is costly, a predictive approach may be appropriate. If the requirements are uncertain, the solution must be discovered, and feedback is valuable, Agile is usually a better fit.
The exam may use the phrase predictive life cycle to describe Waterfall-like approaches. It may use adaptive life cycle to describe Agile approaches. It may also refer to hybrid approaches, where predictive and adaptive methods are combined.
For example, a construction project may use predictive planning for regulatory approvals and structural engineering, but Agile techniques for designing a digital customer portal. A large enterprise may use predictive budgeting cycles but Agile teams for product delivery. The PMI-ACP exam expects you to recognize that the delivery approach should fit the work.
Myths of Agile
A pervasive myth is assuming that Agile teams avoid planning. Agile teams actually plan continuously. They may not lock every granular detail upfront, but they plan rigorously at the roadmap, release, iteration, and daily levels. The key difference is that Agile plans are treated as living hypotheses expected to adapt as feedback emerges.
Agile teams do plan, but they plan continuously and update their plans as evidence emerges. Agile planning is not weaker planning. It is planning that stays honest when reality changes. Whenever you hear any of the following statements, it is a clear misunderstanding o what Agile is.
- “We are Agile, so we do not need estimates.”
- “We are Agile, so we do not need documentation.”
- “We are Agile, so the team can change direction every day.”
- “We are Agile, so management should not ask about progress.”
Some of the common myths above also appear in the exam and try to trap you with answers that sound Agile but are actually irresponsible. These are dangerous misunderstandings. Agile teams estimate, document, plan, track, communicate, and manage risk. They simply do these activities in a lightweight and adaptive way.
Multi-Level Planning
Agile teams may plan at several levels.
- At the product vision level, they clarify the overall purpose of the product.
- At the roadmap level, they identify major outcomes, themes, or release goals.
- At the release level, they decide what valuable capabilities may be delivered within a certain timeframe.
- At the iteration or sprint level, they decide what work the team will focus on next.
- At the daily level, they coordinate progress, identify impediments, and adjust execution.
- This means Agile planning is not the absence of planning. It is continuous planning.
Agile planning should be just enough to guide action, not so heavy that it prevents learning. A team does not need to document every detail six months in advance if the product is likely to change after the first customer demo. However, the team still needs a product goal, prioritization logic, a shared understanding of the work, and a plan for the next increment.
A better way to think about Agile planning is that Agile teams plan based on what they know now, deliver something useful, learn from feedback, and then re-plan based on better information.
This page titled 1.2.3: Agile vs Waterfall was last modified on Thu, 27 Aug 2026 21:49:36 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Guharaman Janakiraman.
The book could not be loaded just now.