Why No Delivery Process Works for Every Team and Project

If you are choosing a delivery method, start with the uncertainty and constraints in front of the team, not the framework label.

No delivery process fits every team, project and stage of work. Scrum, PRINCE2, Lean and Extreme Programming can all help. Each encodes useful lessons. None removes the need to understand the people, uncertainty and constraints in front of you.

A process is a working hypothesis about how this work should be organised. Treating it as a universal law is the silver-bullet mistake.

Methods solve different problems

A process normally arrives with a success story. It made work visible, shortened feedback, improved governance or helped a particular organisation deliver more reliably.

The mandate often retains the visible practices while losing the conditions that made them useful.

Daily meetings do not create collaboration when nobody can raise the real problem. A backlog does not create priorities when every request remains urgent. A stage gate does not reduce risk when approval happens after the expensive decision has already been made. A retrospective does not create learning when the organisation cannot change the rule that caused the problem.

The ceremony is not the mechanism.

Match the method to the uncertainty

Different parts of the same project may need different operating styles.

Early concept work benefits from rapid experiments because the team is still discovering what should exist. A mature implementation phase may benefit from more predictable sequencing. Safety, finance or regulatory decisions may need formal evidence and approval. An incident needs a short command loop that would be oppressive as a permanent way of working.

In my experience, a more formal structure can work around the meta-project, including commercial milestones, dependencies and external commitments, while teams use shorter feedback loops inside it.

That is not process impurity. It is recognising that a client contract, an art pipeline and an uncertain technical prototype do not have the same problem.

Introduce change through a real piece of work

In the original post I suggested a “beachhead”: introduce a new practice within one suitable part of the project before imposing it everywhere.

A gameplay-programming team might trial a new planning loop. A platform team might test a release practice. A product group might use a different discovery method for one uncertain decision.

The point is not to run an easy pilot designed to succeed. It is to learn:

• which part of the method creates value;
• which assumptions do not fit the organisation;
• what training, tooling or authority the team lacks;
• how the practice affects neighbouring teams;
• whether the people doing the work would keep it without a mandate.

If it works, the first team becomes a source of evidence and practical help. If it fails, the organisation has learnt before turning one local mistake into enterprise policy.

Hybrid does not mean arbitrary

Saying ‘we use a hybrid’ can become an excuse for an incoherent collection of habits. Every disliked discipline is dropped and every comfortable ceremony remains.

A defensible hybrid can explain why each part exists.

Use a practice because it shortens feedback, protects a necessary control, exposes risk, coordinates a dependency or makes a decision reversible. Remove it when it no longer performs that job. Do not keep it because the framework diagram contains a box for it.

This is where documentation must work for the people using it. A process described perfectly at enterprise level still fails if the people acting on it cannot find, interpret or challenge what they need.

Agile is often enforced in an unagile way

In some organisations, teams spend months planning two-week sprints, then lock scope, capacity and dates in advance while calling the result ‘agile’. The enterprise may need committed dates, predictable return and auditable governance. Those needs are legitimate. The problem is using Agile vocabulary to hide a fixed plan.

Detailed sprint planning can be useful when the work is sufficiently understood. It becomes misleading when the plan cannot respond to new evidence. Treating velocity as a delivery contract can turn estimation into self-protection. Treating a backlog as approved scope can make change expensive before implementation has taught the team anything. A retrospective also loses value when the organisation cannot change the rule, process or constraint it identifies.

This is not an argument against Agile methods. Short feedback, real prioritisation and authority to change direction can still help. It is an argument for being honest about the constraint: if quarterly commitments are fixed, say so and design the method around that reality rather than presenting it as continuous reprioritisation.

A team or organisation that genuinely wants to improve should be honest about what it needs. If stable quarterly commitments matter more than the ability to reprioritise every two weeks, use a method designed for that constraint. If the organisation wants both, it must accept the investment in flexibility: smaller batch sizes, reversible decisions and slack for discovery.

Calling a fixed plan “agile” does not make it responsive. It makes the gap between the label and reality another thing people must work around.

Signs the process has become the product

I become suspicious when:

• teams need unofficial work to compensate for the official workflow;
• metrics improve while delivery or quality does not;
• exceptions require more effort to approve than the underlying risk justifies;
• people cannot explain which problem a ceremony solves;
• local evidence is dismissed because the framework says otherwise;
• a method is rolled out through training before it is tested through delivery.

These are signs that standardisation is replacing judgement. My Victorian-production argument examines the wider organisational cost: people appear interchangeable, context disappears upwards and the system becomes brittle when conditions change.

Process should make reality easier to see

The best process is not the most modern, pure or comprehensive. It is the smallest coherent set of practices that helps this group of people make useful progress under these constraints.

Start with the problem. Choose a method. Test it against real work. Keep the mechanism that helps. Change it when the context changes.

If the organisation cannot adapt its process in response to evidence, its mandated vocabulary matters less than the behaviour it permits.