The Delivery Spectrum: Choosing Your Approach

Not a Binary Choice

One of the most common mistakes people make when first learning about agile is treating it as an either-or decision. Either you are running a traditional project or you are running an agile one. That binary framing sounds tidy, but it does not describe how real projects work. Most organizations operate somewhere across a spectrum of delivery approaches, and understanding where your specific project sits on that spectrum is more useful than declaring an allegiance to one method or defending another. The word "agile" in an executive directive means something different than it means on a software product team. The word "waterfall" in a job posting may mean rigorous planning or it may mean outdated habits. The spectrum gives you the vocabulary to move past labels and into the actual question: what does this project need, given what we know and what we do not?

The spectrum matters because the consequences of picking the wrong end are real and expensive. A project that applies predictive planning to a problem where requirements cannot be known upfront will spend months building the wrong thing and discover the error at delivery. A project that applies agile delivery to a situation with fixed regulatory sequencing, fixed contracts, and a fixed move-in date will confuse the team, frustrate vendors, and produce a governance trail no one can make sense of. Neither failure is inevitable. Both are common. They share the same root cause: a delivery approach chosen by default, by mandate, or by habit rather than by reading the project's actual conditions.

Three Positions on the Spectrum

There are three meaningful positions on the spectrum, and they describe the vast majority of real-world project environments. The first is predictive delivery, sometimes called traditional or waterfall. Scope is defined fully upfront. The project follows a sequence of phases: requirements, design, build, test, deploy. Changes are controlled through a formal change request process, because changes in later phases cost dramatically more than changes in earlier ones. Predictive delivery is the right choice when requirements are stable, the domain is well understood, and the cost of discovering problems late is too high to absorb. Building a hospital wing, running a regulatory compliance program, implementing a fixed-scope ERP migration with defined contract deliverables: these belong in a predictive approach. When the destination is clear and the path is known, planning comprehensively at the start is the most efficient route.

The second position is agile delivery. Work is organized into short cycles called sprints or iterations, typically one to four weeks. The team pulls from a prioritized backlog at the start of each cycle, delivers working product at the end, and adjusts the backlog based on what was learned. Requirements do not have to be fully defined upfront because the process is designed for them to emerge through iteration. Agile fits when the customer cannot fully articulate what they need until they see something real, when the market or technology environment is changing fast enough that an upfront plan would be outdated before it was executed, and when early course correction is worth more than a perfectly maintained schedule. Software products for emerging markets, digital platforms, innovation projects where the right answer surfaces through feedback rather than specification: these belong in an adaptive approach.

The third position is hybrid, and it is more common than either pure alternative. Hybrid combines predictive governance with adaptive delivery. The project's phases, gates, budget cycles, vendor contracts, and executive approvals run on a predictive timeline. Within those phases, teams manage their work in sprints, maintain backlogs, and run retrospectives. Hybrid is not a compromise between two methods and it is not a fallback for organizations that cannot commit to either one. It is an accurate reading of the actual environment most projects operate in. Regulatory requirements, fixed-price contracts, mixed team experience, and executive governance structures pull in a predictive direction. Technical uncertainty, customer discovery needs, and quality improvement through iteration pull in an adaptive direction. A project that ignores either set of forces does so at its own expense.

Iterative and Incremental: What These Terms Actually Mean

You will encounter the terms iterative and incremental in discussions about agile delivery, and they are worth clarifying because they are often used interchangeably when they describe different things. Iterative means the team revisits and refines existing work based on what each cycle reveals. The same feature, the same process, the same design gets better with each pass through the loop. Incremental means the team adds new pieces of working functionality in each cycle. Something new is delivered in each sprint. Together, they describe how most agile teams actually work: a new capability is built (incremental) and previously delivered capabilities are refined based on user feedback (iterative). Both happen simultaneously in most active sprints.

The reason this distinction matters is that some practitioners treat "iterative" or "incremental" as separate delivery categories sitting between predictive and agile on the spectrum. They are not. They are characteristics of how agile delivery works internally, not additional spectrum positions that require their own categorization. If someone asks whether your agile project is iterative or incremental, the honest answer in most cases is both. The sprint cycle delivers something new and refines what was previously delivered. Treating iterative and incremental as separate spectrum categories adds confusion without adding clarity.

The Two-Question Decision Framework

When you need to assess where a project belongs on the spectrum, two questions do most of the analytical work. They will not resolve every edge case, but they will put you in the right territory quickly enough to have a productive conversation with your sponsor or director.

The first question: are the requirements well-defined and stable enough to plan from the start? If the project's scope is determined by physics, regulation, contract, or a well-established business need that is unlikely to shift, the answer is yes. A facilities move, a compliance implementation, a hardware deployment with fixed specifications: these answer yes. If the scope depends on what users discover they need once they see something working, or on market signals that will only become clear through delivery, the answer is no. A new consumer app, a platform with undefined user segments, a product competing in a rapidly shifting market: these answer no. The answer to this question tells you whether planning can happen upfront or must happen iteratively.

The second question: does the customer need to see and evaluate working results frequently before they can confirm what they want? If the customer knows what "done" looks like and can confirm it without seeing intermediate versions of the product, the answer is no. If the customer's understanding of what they need will evolve through contact with real working product, the answer is yes. A customer who moves into a completed office knows whether it meets their requirements. A customer who first uses a software product discovers requirements they could not have articulated in a requirements workshop. The answer to this question tells you whether frequent delivery cycles produce valuable feedback or just overhead.

When requirements are stable and the customer already knows what done looks like, both signals point predictive. When requirements are unclear and the customer needs to see working results before they can confirm direction, both signals point agile. When the answers diverge, you are in hybrid territory. The most common real-world outcome is the mixed answer, which is why hybrid is the most common real-world configuration. And when different workstreams within the same project answer the questions differently, the right response is a delivery approach that runs predictively where the conditions call for it and adaptively where they do not.

Applying the Spectrum in Practice

The spectrum is a thinking framework, not a classification exercise. You are not filling out a form and getting a method assignment. You are reading a set of project conditions and asking what delivery approach those conditions actually support. Before committing to an approach, a working PM should be asking: what does the sponsor need to see and when? What are the contractual and regulatory constraints on sequencing and delivery? What is the team's experience with each approach, and what is realistic given where they are starting? What does the customer genuinely need in order to provide useful feedback, and when can they realistically provide it?

These questions reveal where the project belongs on the spectrum better than any methodology certification or organizational directive. The PM who can read those conditions accurately, choose an approach that fits them, and explain that choice clearly to sponsors, teams, and vendors is doing something genuinely difficult. Most organizations have had the experience of forcing a project into a method that did not fit: the agile project where the sponsor demanded a fixed-price statement of work, the waterfall project where requirements changed every two weeks and there was no mechanism to manage the drift. The spectrum exists to prevent both failure modes by naming the conditions that determine which approach serves the project's actual needs.

What's Next

The next chapter gets into Scrum, the most widely adopted agile framework, and how the sprint creates the discipline that makes self-organizing teams consistently productive.

Reflect

• Think about a project you have worked on or observed. Where did it sit on the delivery spectrum? Was that the right position given the project's actual conditions, or was the method chosen by habit or mandate?
• The two-question framework asks about requirement stability and customer feedback needs. Apply both questions to a project in your current organization. What do the answers suggest about the right delivery approach?
• Hybrid delivery requires the PM to manage both a predictive governance layer and an adaptive delivery layer simultaneously. What specific skills does that require that pure predictive or pure agile delivery does not?
• The scenario describes a PM who received a "go agile" mandate for a project with fixed contracts, fixed regulatory milestones, and a fixed move-in date. How would you have handled that conversation with the director?