i

Description

Un embranchement de routes vu du ciel, où il faut choisir sa direction

Source

Wikideas1 · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Choosing Your Method and Hybridizing

You'll know how to choose a method based on context (size, uncertainty, regulation, contract, maturity, data nature) rather than trends, with a decision tree and a table of…

In brief

• You'll know how to choose a method based on context (size, uncertainty, regulation, contract, maturity, data nature) rather than trends, with a decision tree and a switching table.
• You'll know realistic hybridizations: “wagile,” Scrum + Kanban for run operations, predictive framing + agile execution, stage-gate governance + sprints, versioned kits + continuous flow.
• You'll know how to contract an iterative approach (fixed-price with variable scope, two phases, conditional tranches).
• You'll know how to lead method change: start small, measure, avoid the “big bang.”
• You'll identify classic pitfalls and ways to defuse them.

On this page

1. 1. A context-based decision tree
2. 2. The six dimensions, one by one
   1. 2.1 Size
   2. 2.2 Uncertainty
   3. 2.3 Regulation and evidence requirements
   4. 2.4 Contract
   5. 2.5 Maturity
   6. 2.6 Data nature
3. 3. Typical cases and recommended methods
4. 4. Realistic Hybrids
   1. 4.1 “Wagile” (water-scrum-fall): the most widespread, the most criticized
   2. 4.2 Predictive framing + agile execution
   3. 4.3 Scrum + Kanban for run (team Scrumban)
   4. 4.4 Stage-based governance + sprints (PRINCE2/PMI + Scrum)
   5. 4.5 Predictive for structure, agile for detail
   6. 4.6 Versioned kits + continuous upstream flow
   7. 4.7 Hybrid combinations to avoid
5. 5. Contracting
6. 6. Driving Method Change
7. 7. Pitfalls
8. 8. AI Contribution
9. 9. See Also

Level: 🟢→🔴

1. A context-based decision tree#

🟢 Novice — Choosing a method means answering a few questions in order, starting with what eliminates the most possibilities. Suggested order: external constraints (regulation, contract), then the nature of uncertainty, then the organization (size, maturity).

This diagram is a starting point, not an algorithm. It is intentionally incomplete: it leaves out the human factor and the team's history (see §2 and §7).

2. The six dimensions, one by one#

🟡 Hands-on — For each dimension: the question, what points toward predictive or adaptive, and the pitfall.

2.1 Size#

2.2 Uncertainty#

Distinguish three kinds of uncertainty: about the need (what do we want?), about the solution (how do we do it?), about the data (what does it contain?). The fuzzier the need, the more short feedback loops you need; the more uncertain the solution, the more prototypes and spikes you need; the more uncertain the data, the more early profiling you need. Data projects often combine all three.

2.3 Regulation and evidence requirements#

When an auditor, regulator, or customer asks who decided what, when, and based on what evidence, you need traceability. This is not incompatible with agile: an agile team can produce an evidence file (user stories with acceptance criteria, archived test results, decision log) as long as it is planned as work (extended Definition of Done). In a heavy-evidence context (healthcare, rail, regulated finance), the design phase and verification remain sequenced and formal; agile applies within each phase.

2.4 Contract#

The contract is often the real method constraint (see §5). A firm fixed-price contract with detailed scope pushes toward predictive; a time-and-materials or capped-budget contract pushes toward iterative. An internal project (without a contract) leaves more freedom, but the annual budget plays the same role.

2.5 Maturity#

Maturity is read on three axes: technical (automated tests, continuous integration, reproducible deployment), product (a business counterpart able to decide and prioritize), organization (does management accept autonomy?). Rule of thumb: don't add ceremonies where engineering is weak; start by equipping testing and delivery (see CI/CD: Continuous Integration and Delivery). The matrix Continuous Integration and Delivery gives the levels.

2.6 Data nature#

What changes when it's data (details in Methods Specific to Data Projects):

• the increment is reliable data (loaded, reconciled, historized), not a feature: you test numbers;
• historization and replay (idempotence) are structuring decisions and hard to reverse;
• migrations (database version, model, product) are predictable projects with comparative plans and acceptance testing;
• volume and confidentiality constrain test environments;
• the business acceptance tester is the bottleneck (availability, legitimacy);
• reports consumed by third parties (customers tied to a measurement ID, for example) lock in interface contracts: you can't freely rename a measure or a column.

3. Typical cases and recommended methods#

🟡 Hands-on — Cases, with context and default recommendation (to adapt).

4. Realistic Hybrids#

🟡 Practical — Purity is not a goal: almost all high-performing organizations combine approaches. The art is doing it explicitly, without breaking the properties that make each building block work.

4.1 “Wagile” (water-scrum-fall): the most widespread, the most criticized#

An upstream predictive phase (requirements specification, budget, contractual schedule), sprint-based execution, and a downstream predictive phase (formal acceptance testing, batch production release). The term has an ironic tone (water-Scrum-fall) because feedback does not pass through upstream and downstream: sprints optimize what is already locked in.

4.2 Predictive framing + agile execution#

Most useful for projects with contracts or annual budgets: a short framing phase (2 to 6 weeks) produces a vision, a scope in envelopes (MoSCoW), a budget and timeline, a target architecture, and source profiling; then execution is iterative within that envelope. Scope varies, the framework does not.

This is the spirit of PRINCE2 + agile or DSDM: governance takes the form of stages with tolerances; within a stage, delivery is iterative. See Predictive Methods (Waterfall, V-Model, Spiral, RUP, PMBOK, PRINCE2, Merise, CMMI) and DSDM.

4.3 Scrum + Kanban for run (team Scrumban)#

A BI team handling both project work and support:

4.4 Stage-based governance + sprints (PRINCE2/PMI + Scrum)#

Governance (business case, tolerances, committee) wraps around sprints. The project manager translates sprint reviews into progress reports for the committee (burn-up, goals achieved); the Product Owner keeps detailed prioritization. Rule: one single dashboard, fed by agile artifacts, not a second reporting set.

4.5 Predictive for structure, agile for detail#

For a large project with dependencies: a master plan (macro milestones, architecture, interfaces frozen first: data contracts) and agile teams executing by domain. Interfaces are where predictive is justified (they are expensive to change); inside modules remains flexible.

4.6 Versioned kits + continuous upstream flow#

When delivery is constrained to installation kits (clients are delivered numbered versions, with installation windows on their side): upstream (development) can be continuous (Kanban, continuous integration on a main branch), while downstream is paced by versions (freeze, stabilization, version acceptance testing, maintenance line). This is a delivery train at the cadence of the version, with a flow inside. You then need to resolve branching (see Branching Strategies) and parallel maintenance of multiple versions.

4.7 Hybrid combinations to avoid#

5. Contracting#

🟡 Practical — A contract is a risk-allocation mechanism: who bears overrun risk? In a fixed-price, fixed-scope contract, it's the vendor; in time-and-materials, the client. The challenge in an iterative approach is to allocate uncertainty risk in a way acceptable to both.

Clause elements that make a contract compatible with iterative delivery:

• a fixed objective and budget, with an evolving scope governed by a lightweight change procedure (an equivalent swap: add one item, remove one of equal value);
• continuous acceptance testing (sprint review) with objective acceptance criteria (numbers, tolerances);
• a right to exit at each milestone (the client can stop by paying for what has been delivered);
• guaranteed business access (Product Owner availability: this is a client obligation, and should be written down);
• ownership and documentation of deliverables (code, model, scripts, test sets);
• reversibility (knowledge transfer, repository access).

6. Driving Method Change#

🟡 Practical — Changing methods is a change management project, with its own resistance. The approaches that fail most often: the big bang (change everything on a Monday), training alone (without guided practice), the top-down imposed method (without understanding the “why”).

A realistic five-step path:

1. Diagnose: measure the current state (lead time, delivery frequency, defect rate, satisfaction). Without a starting point, no improvement can be demonstrated.
2. Choose a pilot scope: a volunteer team, a clearly defined product, a sponsor. Avoid the most critical and the most insignificant project.
3. Start with the highest-leverage, lowest-cost practices: visualize work, limit WIP, shorten the acceptance testing loop, automated tests on critical items; then ceremonies.
4. Measure and adjust at short intervals (retrospective, review at 6–8 weeks); decide whether to scale, adjust, or stop.
5. Scale through proof: pilot results convince more than slides; communities of practice help spread adoption.

Levers to activate: visible sponsor; learning by doing (coaching alongside the team); tool adjustments (boards, workflows in the tracking tool); indicator alignment (don’t keep measuring plan compliance if you want value); addressing fears (everyone’s role changes).

🔴 Expert — Resistance has legitimate causes. A project manager sees their control role diminish, a manager sees their visibility threatened, a developer fears exposure of daily output. Ignore them, and you lose. Listen to them, and you often discover a real governance need that the new method must serve differently (reports derived from artifacts, portfolio reviews). The Team and Collaboration matrix and the Adoption and Change Management theme provide guidance.

7. Pitfalls#

🟡 Practical — Classic selection and hybridization mistakes, with symptom, cause, and remedy. The general catalog is in Project Management Pitfalls and Best Practices (Cross-Cutting Summary).

🧪 Example of a tracked decision — Context sheet for a work batch: Batch “new family of shelf-length measures” — team of 5, business availability 2 h/week, evolving need, stabilized source, no external contract, quarterly kit deliveries, medium technical maturity (partial data tests). Choice: 2-week Scrum, metrics-based review with the business each sprint, Definition of Done including reconciliation and release note; method review in 8 weeks; alert criterion: more than 20% of sprint consumed by support → switch to Scrumban.

8. AI Contribution#

🤖 AI — Can prepare and support the decision; does not make it.

Example prompt: “Based on these 12 retrospectives, group recurring pain points by theme (acceptance testing, dependencies, tools, workload), count their frequency, and propose three six-week experiments with a success indicator.”

Limits: AI has no memory of your context, ignores internal politics, and readily suggests “balanced” answers that avoid difficult choices. See AI for Project Management (General, Then Data).

9. See Also#

• Methods: Predictive Methods (Waterfall, V-Model, Spiral, RUP, PMBOK, PRINCE2, Merise, CMMI) · Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…) · Methods Specific to Data Projects · Project Management Methods Comparison.
• Scrum: Scrum Framework (Scrum Guide 2020) · Scrum in Practice · Scrum Applied to Data, BI, and Datamarts · Project Management Fundamentals.
• Delivery: CI/CD: Continuous Integration and Delivery · CI/CD for Data: Databases, Datamarts, Pipelines, and Reports · Project Management Pitfalls and Best Practices (Cross-Cutting Summary).
• Tools: Branching Strategies · Azure DevOps Server (Formerly TFS) In Depth · Planning Tools Comparison.
• Maturity: Governance and Steering (GOU) · Scoping and Vision (CAD) · Budget, Value, and Benefits (VAL) · Lead Time and Industrialization (DataOps).
• Glossary · Rating: How to Read Scores, Ratings, and Legend.

✻ Written by Claude Sonnet 5.5