The proposal is due on Friday. The client’s procurement team wants a fixed price, a go-live date and a full requirements list. Their operations manager, who will use what you deliver, says she will “know what works when she sees it”. Your lead consultant wants to run it agile; your finance director asks how to invoice work with no fixed scope. Someone proposes “a bit of both”, and everyone nods.
This guide is for that moment. It treats waterfall vs agile vs hybrid for client delivery in professional services as a set of operating decisions you make and write down before the work starts.
Waterfall vs agile vs hybrid: the short answer
Use a predictive (waterfall) approach where the requirement is well understood, change is expensive and approvals are sequential. Use an adaptive (agile) approach where the right solution can only be discovered through feedback from real users. Use a hybrid when an engagement contains both kinds of work, and only when you can name which commitments are fixed, which work may change, and who decides when it does.
The choice is rarely one label for the whole engagement. It is usually a decision per workstream, followed by an agreement about how planning, feedback, acceptance and commercial change will work together.
Four terms that are not interchangeable
Much of the confusion in method conversations comes from treating these words as synonyms.
Predictive delivery (often called waterfall). Scope, design and plan are defined up front and delivered in sequence, with approval gates between stages. It does not mean the client gives no feedback: feedback is concentrated at planned review points, and changes after approval go through formal change control. Nor does it guarantee an accurate budget. A detailed plan built on a misunderstood requirement is precisely wrong.
Agile principles. The principles behind the Agile Manifesto were written for software teams. They include early and continuous delivery, welcoming changing requirements, and business people and developers working together daily. They describe values, not a process. Note the daily-collaboration principle: a client who can give you two hours a month cannot support a fully adaptive engagement, whatever the contract says.
Scrum. A specific framework. The Scrum Guide (November 2020) defines fixed-length Sprints of one month or less, a Product Owner who is “one person, not a committee”, and a Sprint Review whose purpose is “to inspect the outcome of the Sprint and determine future adaptations”. A weekly client status meeting is not a Sprint Review, and two-week cycles do not make a project Scrum.
Kanban. The Kanban Guide (May 2025) defines it as “a strategy for optimizing the flow of value through a process”, built on defining and visualising a workflow, actively managing items in it and improving it, with explicit control of work in progress. A board with columns is not Kanban on its own, and its service level expectation is a forecast, not a contractual SLA.
For a broader primer on the methods themselves, see our agile, waterfall and lean documentation. The rest of this article is about choosing between them for a client.
Five questions that decide the delivery approach
Answer these per workstream, with evidence rather than preference.
- How well is the requirement understood? Has the client done this before? Can they describe acceptance in observable terms? If users cannot yet describe how the new process will work, a fixed specification is a guess. Evidence: discovery notes, use cases, examples of current work.
- How reversible is a wrong decision? Changing a report layout costs an afternoon. Changing an ordered hardware specification, a signed-off structural design or a migrated data model may cost weeks. The more expensive reversal is, the more you should decide before you build.
- How many external dependencies are there? Suppliers, other contractors, site access, regulators and client IT teams usually need dates they can plan around. Adaptive work inside a dependency-heavy programme still needs fixed hand-off points.
- How available is the client? Adaptive delivery depends on someone with authority reviewing work frequently and deciding quickly. If the only decision-maker is a monthly steering committee, short cycles will stall waiting for answers.
- What approvals and commercial terms are fixed? Regulatory submissions, board dates, financial year-ends and fixed-price contracts are constraints, not preferences. Know which ones are genuinely immovable before you promise flexibility.
Waterfall, agile or hybrid? A method selection matrix
Use this in the proposal meeting. For each factor, mark which column describes the workstream better, then look at the pattern rather than adding up scores.
| Factor | Leans predictive when | Leans adaptive when | Evidence to check |
|---|---|---|---|
| Requirement clarity | Client can state acceptance criteria now | Users will recognise the right answer only by trying it | Discovery record, testable use cases |
| Cost of change | Reversal is slow, physical or contractually expensive | Reversal is cheap and quick | Supplier lead times, rework estimates |
| Dependencies | Many third parties need fixed dates | Team controls most of the work | Dependency list with owners and dates |
| Client availability | Decisions come at scheduled gates | A named decision-maker can review every one to four weeks | Named person, diary commitment, authority limits |
| Approvals and contract | Fixed regulatory, board or go-live gates; fixed scope priced | Budget or timebox fixed, scope prioritised | Contract terms, regulatory calendar |
| Nature of output | Repeatable deployment, known design | New workflow, new service, unproven idea | Similar past engagements |
If most rows point one way, use that approach and borrow the useful controls of the other. If the rows split by workstream, you have a hybrid, and the next section matters.
What a workable hybrid looks like
A hybrid is defined by its boundaries. Three patterns hold up well in client work:
- Iterative design inside a governed rollout. Design and prototyping run in short feedback cycles until a named client decision-maker accepts the design. Build, migration and rollout then run to a fixed plan with change control.
- Fixed milestones, flexible content. External dates, such as a regulatory submission or a training window, are fixed. The work between them is a prioritised backlog, and lower-priority items move out when new items come in.
- Predictive project, flow-managed stabilisation. The main delivery follows a plan. After go-live, defects and small requests move to a Kanban-style queue with a work-in-progress limit rather than being forced into the original plan.
Each pattern answers three questions in writing: what is fixed, what may change, and who can authorise a change at each level.
“Wagile” and the contradictions to catch
“Wagile” is an informal label with no agreed definition. Some use it for a sensible hybrid; others for a project that runs sprints in name while every decision waits for a phase gate. Because it means different things to different people, it should never describe your way of working in a proposal.
Look instead for promises that cannot hold together. The classic failure: the contract fixes scope, date and cost, and the team also tells the client new ideas can join the backlog at any time. Every addition either breaks a fixed commitment or silently consumes margin. Other contradictions:
- Two-week sprints, but every output needs a steering committee that meets monthly.
- “Continuous client feedback”, but no named client reviewer with authority to decide.
- A fixed specification signed off, while users are invited to “shape the solution” in UAT.
- A backlog with no one who can say what gets dropped when something new comes in.
If you find one, fix it before the contract is signed. It is much harder afterwards.
A process for choosing and agreeing the approach
| Step | Owner | Evidence | Decision point |
|---|---|---|---|
| 1. Split the engagement into workstreams | Delivery lead | Charter, statement of work | Which parts behave differently? |
| 2. Run the selection matrix per workstream | Delivery lead with lead consultant | Discovery notes, dependency list | Predictive, adaptive or hybrid for each |
| 3. Name the fixed commitments | Engagement manager with client sponsor | Contract, regulatory and business dates | What cannot move, and what flexes instead |
| 4. Set the feedback and acceptance rhythm | Delivery lead with client decision-maker | Diary availability, acceptance criteria | Who reviews what, how often, and how acceptance is recorded |
| 5. Define change handling | Engagement manager | Pricing model, contract change clause | Who can approve which size of change |
| 6. Sign off the working agreement and review it | Client sponsor and delivery lead | The one-page agreement below | Revisit at the first milestone or after the first two review cycles |
Step 1 connects directly to your project charter: the charter says what outcome is authorised; the working agreement says how you will get there.
Hypothetical example: one consultancy, three engagements
Hypothetical example: a 30-person IT and operations consultancy has three new engagements in the same quarter.
Engagement 1: deploying laptops and docking stations to four regional offices. The client has specified the standard build, the offices and the dates. Hardware lead times are six weeks and site access must be booked. The matrix points predictive on almost every row. The team plans the rollout in sequence, holds a pilot at one office as a planned feedback point, and handles changes through a simple change request.
Engagement 2: redesigning a client’s quote-to-order workflow. Nobody can describe the new process yet. Sales, finance and operations disagree on where approval should sit. The matrix points adaptive. The team agrees a fixed eight-week timebox and budget, fortnightly working sessions with a named operations manager who can decide on the client’s behalf, and a prioritised list of outcomes. The first two outcomes are guaranteed; the rest are delivered in priority order within the budget. The same approach works for a purely advisory engagement: each cycle produces a draft recommendation that users test against real cases.
Engagement 3: implementing a compliance reporting system with fixed regulatory submission dates. The submission dates cannot move, and the data sources are known. The report design is uncertain because the client’s team has never produced these reports internally. This is a hybrid: iterative design of report layouts and validation rules until the compliance lead accepts them, then a governed build, test and cutover plan working backwards from the submission date.
The difficult exception. In engagement 3, the compliance lead says she cannot approve report designs without the monthly risk committee, so fortnightly reviews would stall for weeks. Rather than simply extending the design phase, the team proposes that the committee delegate design decisions within the regulator’s published requirements to her, escalating anything outside those limits. The committee agrees for layout and wording, but not for data definitions. Data definitions therefore become a predictive, gated item tied to the committee’s meeting dates, and the plan changes before build starts rather than after.
The same firm used three approaches in one quarter, and the hardest part was not the method but decision authority.
One-page delivery working agreement
Complete this with the client sponsor before work starts. Keep it to one page, attach it to the charter and revisit it at the first milestone. Example entries are for engagement 3 (hypothetical).
| Section | What to agree | Example entry |
|---|---|---|
| Approach per workstream | Predictive, adaptive or hybrid, and why | Design: adaptive, fortnightly cycles. Build and cutover: predictive, fixed plan |
| Fixed commitments | Dates, budget, outcomes and regulatory gates that cannot move | First submission 31 March; budget R850,000 (hypothetical); mandatory regulatory reports |
| What flexes | The variable that absorbs change | Number of design iterations and optional management reports, in priority order |
| Decision rights | Who decides what, including limits | Compliance lead approves layouts; risk committee approves data definitions |
| Feedback rhythm | Who reviews, how often, in what format | Working session every second Tuesday, 10:00 SAST, with sample data |
| Acceptance | How acceptance is evidenced and recorded | Acceptance criteria per report; signed test record per cycle |
| Change handling | Thresholds and approvers for change | Swap equal-sized items: delivery lead and compliance lead. Anything adding cost or moving a date: sponsor, written approval |
| Documentation | Records that must exist and when | Decision log weekly; design specification at design acceptance; handover pack before go-live |
| Escalation | Route and response time | Unresolved decision after five working days goes to sponsor |
| Review of this agreement | When it will be revisited | After second design cycle and at build start |
To make acceptance evidence meaningful, write the criteria in testable terms; our guide to documenting use cases and acceptance criteria covers how.
Limits and the common failure mode
No approach removes uncertainty; it only decides where you deal with it. A predictive plan cannot protect you from a misunderstood requirement, and an adaptive one cannot compensate for an absent client. Hybrid is not a guaranteed middle path either: it adds a boundary, and boundaries need owners.
The Agile Manifesto and the Scrum Guide were written with software development in mind, and most Kanban guidance today targets knowledge work. In engineering design, advisory or campaign work, translate the intent (frequent inspection, early feedback, limited work in progress) rather than copying ceremony names.
The most common failure is choosing a label instead of making decisions. Nobody writes down what is fixed or who decides, and the contradiction surfaces at the first disputed change request. The working agreement forces those decisions while they are still cheap. Record the method-related assumptions in your risk identification as well: “client decision-maker available fortnightly” is an assumption that can fail.
Supporting the approach in your project tool
Whatever approach you choose, the plan should show it. Predictive workstreams need dependencies and dates; adaptive ones need a visible flow of work and priorities. Chronodesk project management includes a Kanban board, an interactive Gantt with dependencies, list and timeline views, and a risk register for each project, so a hybrid engagement can keep its governed plan and its adaptive work in one place alongside timesheets. The tool records the approach; it does not replace the working agreement or settle who has authority to decide.
Your next step
Take one live or upcoming engagement and run the selection matrix per workstream this week. Then fill in the fixed commitments, what flexes and decision rights sections of the working agreement. If you cannot complete those three rows, you have found the conversation to have with your client sponsor before the next milestone. When you plan the near-term work, use our guidance on how much detail a project task should contain, and agree with the sponsor how often to review project risks so the working agreement’s assumptions are checked regularly.
Frequently asked questions
Is hybrid project management better than waterfall or agile?
Not automatically. Hybrid works when you can say exactly which commitments are fixed and which parts of the work are allowed to change, and who decides when they do. Without those boundaries, hybrid usually means the team carries the obligations of both approaches and the protections of neither.
Can you run an agile project on a fixed-price contract?
Yes, but scope has to flex rather than price or date. The usual pattern is a fixed budget and timebox with a prioritised backlog, where lower-priority items drop out when new work comes in, plus a small set of outcomes that are guaranteed. What you cannot honestly do is fix scope, date and cost while also accepting every new request.
What does wagile mean?
Wagile is an informal label for a mix of waterfall and agile practices. It has no agreed definition, so it is often used to describe a team that plans in phases but runs short cycles inside them, and sometimes to describe a project with contradictory commitments. Replace the label with a written statement of what is fixed, what is adaptable and how change is decided.
Does agile mean the client does not get documentation?
No. Agile principles favour working results and conversation, but they do not forbid documentation. A client engagement still needs the records the client and your team will rely on later, such as decisions, acceptance evidence, configuration and handover notes. Agree which documents are required and when they will be produced.
Should one consultancy use the same method on every client engagement?
Usually not. The right approach depends on how well the requirement is understood, how costly change is, how available the client is and what approvals are fixed. A consultancy can keep consistent controls, such as a charter, risk review and acceptance records, while choosing a different planning and feedback rhythm for each engagement.