Skip to content

Lesson 1 — Agile and Predictive Approaches

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. State the values and principles of agile software development and explain what they change in practice.
  2. Compare the assumptions behind predictive and adaptive delivery.
  3. Choose between them for a given project using explicit criteria rather than preference.
  4. Explain hybrid delivery and when it is the honest answer.

Prerequisites

Introduction

You have just learned how to build a plan: define the scope, decompose it, sequence it, estimate it, and baseline it. That approach works extremely well when you can know what you need before you build it. It works badly when you cannot.

Agile is a response to that second case. It does not reject planning — it changes what you plan in detail and when you plan it. This lesson sets out what agile claims, what predictive delivery assumes, and how to tell which situation you are in.

1. What agile actually claims

The Manifesto for Agile Software Development (2001) states four values and twelve principles. The four values are expressed as preferences, not absolutes:

Valued more Than
Individuals and interactions Processes and tools
Working software Comprehensive documentation
Customer collaboration Contract negotiation
Responding to change Following a plan

Two things are easy to miss. First, the items on the right still have value — the manifesto says so explicitly. Second, agile says nothing about how to achieve any of it; Scrum and Kanban are two answers, and there are others.

The operating idea is short feedback cycles. If you deliver something small and get a reaction, you learn faster than if you deliver something large and hear nothing until the end.

2. The assumptions on each side

Predictive and adaptive approaches rest on different assumptions about the world. When an approach "fails", it is usually because its assumptions did not hold.

Assumption Predictive Adaptive
Requirements Knowable up front Discovered by building
Cost of change High; avoid it Moderate; absorb it
Learning happens At the start Continuously
Progress means Delivering against the plan Delivering working value
Stakeholder role Approves at milestones Engaged throughout
Best when Stability matters more than flexibility Uncertainty is the dominant problem

Neither column is superior. A hospital appointment system's safety requirements are not going to be "discovered by building"; a dashboard's useful measures very often are.

Two example projects (illustrative)

The mobile banking application has security and regulatory requirements that must be specified and verified before release — a strong pull toward predictive planning of those parts. The analytics dashboard cannot be specified up front, because nobody knows which measures matter until they see them — a strong pull toward adaptive delivery. Both are normal projects.

3. Choosing with criteria

Use the conditions, not the label. Four questions do most of the work:

  1. Can we know the requirements now? If yes, planning them in detail is efficient. If no, detailed up-front planning commits you to guesses.
  2. What happens if we are wrong? High-consequence, hard-to-reverse errors favour more specification and review before building.
  3. Can stakeholders engage often? Adaptive delivery needs frequent access to someone who can decide. Without it, adaptivity becomes guesswork.
  4. Is there a fixed external date or contract? Fixed dates and fixed-price contracts constrain how much scope can flex, which limits how adaptive you can be.

4. Hybrid delivery

Real projects usually combine the two. Common and legitimate patterns:

  • Predictive framing, adaptive delivery — fixed scope and price externally, iterative work internally.
  • Adaptive product, predictive platform — iterative features on a carefully engineered, rarely-changing foundation.
  • Phased conversion — predictive for a regulated subsystem, adaptive for everything around it.

Hybrid is often described as a compromise. It is better understood as matching each part of the work to the uncertainty it actually has.

Key terms

Term Meaning
Agile An umbrella of approaches emphasising short feedback cycles, working software, and responding to change
Predictive delivery Defining requirements and the plan fully before building
Adaptive delivery Planning in short cycles and absorbing change continuously
Iteration A short, repeating cycle of planning, building, and review
Feedback cycle The loop from delivering something to learning from the reaction
Hybrid delivery Deliberately combining predictive and adaptive practices

Worked example

Task: choose a delivery approach for two projects and justify it from the criteria.

Step 1 — Ask question 1: can requirements be known now? For a mortgage-application workflow, the rules are externally defined and must be met exactly. Requirements are knowable. For an internal reporting dashboard, they are not.

Step 2 — Ask question 2: what happens if we are wrong? In the mortgage workflow, an error can be a regulatory breach — hard to reverse and expensive. In the dashboard, a wrong measure is corrected by changing the measure.

Step 3 — Ask question 3: can stakeholders engage often? The mortgage compliance officers review formally and infrequently. The dashboard's users are available weekly and are eager to comment.

Step 4 — Ask question 4: fixed date or contract? The mortgage workflow must meet a regulatory deadline. The dashboard faces no fixed date.

Step 5 — Decide. Mortgage workflow: predictive, with formal verification gates, because stability and consequence dominate. Dashboard: adaptive, in short iterations, because the dominant problem is that nobody knows what they want yet.

Step 6 — State the weakness of each choice. The predictive workflow will handle a change in the regulations badly; mitigation is to isolate the rules in one place. The adaptive dashboard may drift without a clear product goal; mitigation is to name that goal explicitly.

Common misconceptions

“Agile means no planning”

Agile plans more often, in more detail about the near term. What it avoids is a detailed commitment to a distant, uncertain future.

“Agile is always better, or always worse”

Both statements are unfalsifiable. The approach should follow from the project's conditions — requirement stability, consequence of error, stakeholder access, and fixed constraints.

“Doing stand-ups makes us agile”

Ceremonies without short feedback cycles, working software, and the authority to change the plan are administration in agile vocabulary. The values are the substance.

Practical activity

Justify a delivery approach. Choose one of the example projects.

  1. Answer the four criteria questions in writing, one sentence each.
  2. State your chosen approach and the single condition that most drove the choice.
  3. Name one part of the project that should be handled the opposite way, and say why.
  4. Write two sentences on how you would know, six weeks in, that your choice was wrong.

What "good" looks like: a specific condition driving the decision, and a genuine hybrid answer for part of the project. "Agile, because it is modern" is not a justification.

Self-assessment

  1. The manifesto values working software over comprehensive documentation. Does that mean documentation is unnecessary?
  2. Under what conditions does a fixed-price contract limit adaptive delivery, and what can be done about it?

  3. Give a project characteristic that argues strongly for predictive planning, and explain why.

  4. Apply it — analytics dashboard. The planning office wants “a dashboard of the things that matter”, cannot say which measures those are, and admits the underlying data sits in four systems with different definitions of the same terms. They can meet weekly and are willing to look at a rough prototype early.

    Hint: A strong answer names the criteria behind the choice and the condition that would make it switch.

Show answers
  1. No. It states a preference when the two conflict, and says explicitly that the right-hand items still have value. Documentation that helps someone build, operate, or change the software is not in conflict with working software. Documentation written to satisfy a process, and never read, is.
  2. A fixed price with fixed scope leaves no room to vary scope as learning accumulates, which is the mechanism adaptive delivery depends on. Options include negotiating a scope-flexibility clause or a period-and-materials component, running an adaptive internal process behind a stable contractual boundary, or accepting formal change control and pricing each change.
  3. Any of: externally defined regulatory rules; safety-critical behaviour; a contractual acceptance test; or a fixed date where late discovery is catastrophic. The common feature is that the cost of an error discovered late is high and the requirements are knowable in advance — so specifying them before building is genuinely cheaper than discovering them after.
  4. Iterative and adaptive. The requirements are genuinely not knowable in advance — the stakeholders will recognise what they want only when they see something — change is cheap because a dashboard measure is easy to alter, and the stakeholders are accessible weekly. The criteria that would flip the choice are consequence of error and knowability: if those measures became externally reportable or a downstream system depended on a frozen data model, you would move to a predictive approach for the data model while keeping the presentation iterative. That hybrid is legitimate provided the seam between the two is designed and owned rather than left to whoever is arguing that day.

Summary

  • Agile states four preferences and twelve principles; the "than" items retain their value.
  • Predictive and adaptive delivery rest on different assumptions about requirements, change cost, and stakeholder access; failures usually trace to an assumption that did not hold.
  • Choose using the conditions — knowability, consequence of error, stakeholder access, and fixed constraints — not the label.
  • Hybrid delivery matches each part of the work to its own uncertainty, and is usually the honest answer.

Further learning

Next

Continue to Lesson 2 — Scrum Roles, Events, and Artefacts.