Comparing Agile and Waterfall for Project Selection

Compare agile and waterfall for one specific project by scoring uncertainty, risk, stakeholder access, team and compliance, then record the choice.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Comparing agile and waterfall is a decision about one project, made before work starts. The question is which way of organizing the work will reduce the risks this particular project carries. Some projects are mostly uncertain about what to build. Others know exactly what to build and are mostly exposed to integration, safety or contractual risk. The two approaches handle those risks differently, so the right answer depends on which kind dominates.

Waterfall organizes work into sequential phases. Royce's diagram runs from system requirements and software requirements through analysis, program design, coding and testing to operations. Winston Royce drew that sequence in his 1970 paper and then wrote, "I believe in this concept, but the implementation described above is risky and invites failure" (Royce, Managing the Development of Large Software Systems). His concern was that testing, the phase where problems surface, comes last. Craig Larman and Victor Basili point out that Royce recommended doing the job twice, with a pilot version first, and that many people misread the paper as endorsing a single pass (Larman and Basili).

Agile organizes work into short cycles that each end in working software. The Manifesto's principles ask for delivery "from a couple of weeks to a couple of months, with a preference to the shorter timescale" and welcome "changing requirements, even late in development" (Agile Manifesto principles). That makes change cheap and surfaces problems early, but it depends on stakeholders who can give feedback often and a team that can decide for itself.

This skill turns the comparison into a short, structured workshop. The team scores five dimensions, discusses where people disagree, and records the choice with the reasons behind it. The method page covers the history and the broader comparison with Scrum and Kanban. This page is about making the call for one project.

The output is a one-page decision record: the scores, the choice (agile, waterfall, or a named hybrid), the risks the choice accepts, and the event that should trigger a review.

How It Works

The comparison rests on five dimensions, each scored from 1 to 5. A low score favors a plan-driven approach and a high score favors agile. Scoring separately keeps one loud factor from deciding everything.

Requirements uncertainty. How well do the sponsor and users know what they need? A 1 means the requirements are written, agreed and unlikely to change, such as reproducing a published calculation. A 5 means the team is testing hypotheses about what users want. Agile's second principle exists for the high end.

Technical and integration risk. How new is the technology, and how early do you need to know whether the parts fit together? Royce called the test phase "the phase of greatest risk in terms of dollars and schedule" (Royce). When integration risk is high, both approaches need early working versions, which pushes toward iteration.

Stakeholder availability. Can the people who decide what is valuable review working software every few weeks? The Manifesto asks that "Business people and developers must work together daily throughout the project" (principles). If sponsors can only meet at phase gates, agile's feedback loop breaks.

Team structure and experience. Is there a stable, cross-functional team with authority over how it works? Agile relies on self-organizing teams. A team assembled from many departments, each with its own approvals, will struggle with short cycles.

Compliance and documentation. Does a regulator or contract require documents, sign-offs or verification at defined points? A high need for formal evidence lowers the score. It does not rule agile out, but it often leads to a hybrid where agile delivery runs inside formal gates.

Average the five scores. An average near 1 points to a plan-driven approach, near 5 to agile, and the middle to a hybrid. The average is a starting point for discussion. A single very low score, especially on compliance, can outweigh a high average, and the record should say so.

Step-by-Step Guide

Step 1: Gather the brief and constraints

Collect the project goal, known requirements, deadlines, budget model, contract terms and any regulatory obligations. Note which of these are fixed and which are assumptions. Ask the sponsor what would count as success and what would count as failure. Without this, scorers will argue from different pictures of the project.

Step 2: Invite a small, mixed group of scorers

Include the sponsor or product owner, the delivery lead, a senior engineer and, where relevant, someone responsible for compliance. Different roles see different risks: engineers see integration risk, sponsors see market risk, compliance sees audit risk. Keep the group small enough to discuss every score in one session.

Step 3: Score each dimension independently

Share the five definitions and have each person score privately before any discussion. Independent scores avoid the anchoring that happens when the most senior person speaks first. Collect the scores and show them side by side.

Step 4: Discuss the spreads

For any dimension where scores differ by more than a point or two, ask the high and low scorers to explain. The spread usually reveals a hidden assumption, such as a sponsor who believes requirements are fixed while engineers know the underlying platform is changing. Agree on a final score for each dimension and write down the reason.

Step 5: Choose and name the approach

Use the average as a guide, then check for any dimension that overrides it. If you choose a hybrid, name exactly which parts follow which approach, for example iterative delivery inside fixed funding and compliance gates. Link the team to the relevant method: Scrum, Kanban or Waterfall.

Step 6: Record the decision and the accepted risks

Write a one-page record with the scores, the choice, the reasons and the risks you are accepting. A waterfall choice accepts that late discoveries will be expensive. An agile choice accepts that the full scope and cost will be less certain at the start. Share the record with everyone who will be asked to live with the choice.

Step 7: Set a review trigger

Name the events that should reopen the decision: a large change in scope, loss of stakeholder access, a new regulatory requirement, or repeated failures at integration. Put a check on the calendar after the first few delivery cycles or the first phase gate. A decision recorded with its reasons is easy to revisit honestly.

Best Practices

• Score the project in front of you. A company that usually runs waterfall can still have a highly uncertain project, and the scoring should reflect the project in front of you.
• Treat compliance as a constraint on how you document and approve work. Many regulated teams run iterative delivery and produce the required evidence along the way.
• Ask for Royce's pilot even on plan-driven projects. His own advice was to build a first version of the critical design and operations areas before the one you deliver (Royce).
• Check stakeholder availability with the stakeholders themselves. Teams often assume a sponsor will attend reviews every few weeks and discover otherwise after the first cycle.
• Keep the scoring definitions stable across projects so the organization can compare decisions over time and learn which scores predicted trouble.
• Revisit the choice when the facts change. The Agile Alliance describes agile as "the ability to create and respond to change" (Agile 101), and that applies to the choice of process as well.

Common Mistakes

• Deciding by ideology: Picking agile because it is fashionable or waterfall because it looks controllable skips the analysis. Score the five dimensions and let the project's risks drive the choice.
• Calling a waterfall plan agile: Running fixed-scope phases in two-week chunks with no customer feedback keeps waterfall's risks and adds meeting overhead. If scope, reviews and priorities cannot change, say so and plan accordingly.
• Ignoring integration risk: Projects that defer all integration to the end repeat the problem Royce described. Whatever the choice, plan an early end-to-end version.
• Treating the hybrid as a compromise nobody owns: A vague hybrid lets each group follow its own habits. Write down which decisions happen at gates and which happen in cycles.
• Never revisiting the decision: A project that started with clear requirements can become uncertain after a market or regulatory change. Use the review trigger.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Agile

Related Skills

• Choosing Between Scrum, Kanban, and Scrumban
• Running Sprint Planning and Agile Sprint Execution
• Agile Coaching: Guiding a Team Through Adoption
• Scaling Agile Across Teams with SAFe, LeSS and More

Sources

• Winston Royce: Managing the Development of Large Software Systems
• Craig Larman and Victor Basili: Iterative and Incremental Development, A Brief History
• Principles behind the Agile Manifesto
• Agile Alliance: Agile 101

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.