01 · 1980s–2000
Iterative and lightweight precedents
Software practitioners developed Scrum, XP, DSDM, Crystal and other approaches in response to long feedback delays and heavyweight delivery.
ASSURANCE DNA · ADAPTIVE DELIVERY PRACTICE
Agile
A family of adaptive approaches informed by four value preferences and twelve principles first written for software development: deliver value early, collaborate, learn and respond to change.
What is the smallest working evidence that can test the buyer’s assumption before it becomes an expensive commitment?
REFERENCEManifesto for Agile Software Development and 12 principles, 2001CURRENT STATE · 26 JUL 2026A foundational declaration and principles, not a certifiable standard or one prescribed delivery method.BID ENTRYCapture · Map · Assemble · Model · Story · Mobilise · Measure · Learn · Adapt
Agile is not one proprietary method, a synonym for speed or permission to abandon evidence, architecture, governance, documentation or contractual control. Source-bounded interpretation: no certification, protected text reproduction or award prediction.
LIVING EXPERIMENT · REACTOR
The Learning Reactor
Requirements enter as hypotheses, increments as reactions and feedback as control rods. Ceremony without working evidence produces no energy.
MODEL STATESME · SENSE · APPLYDeterministic teaching model · no award prediction
ORIGIN × EVOLUTION × CURRENT PRACTICE
Why this reference exists—and what changed.
Software, digital, product and adaptive delivery teams; selected principles also inform discovery and iterative service or solution design.
02 · February 2001
Manifesto at Snowbird
Seventeen practitioners agreed four values and later twelve principles for Agile Software Development.
03 · 2000s–2010s
Methods spread and diversify
Agile practices expanded across product, service and organisational contexts, often with inconsistent meanings.
04 · Today
Return to evidence and purpose
Mature use distinguishes the Manifesto’s software roots from method-specific practice and combines adaptation with engineering, governance and service obligations.
“Agile” must not excuse missing governance, architecture, security, evidence, commitments or pricing discipline.
OFFICIAL SOURCE FRESHNESS MONITOR
SOURCE CHECK PENDING
Monthly official-source reachability and change review.
LAST SOURCE CHECKloading…
What this date means
The check records source reachability and a content fingerprint. It does not silently change the page or claim that an edition changed.
PUBLICLY DESCRIBABLE ANATOMY
Every domain gets a specific bid-management translation.
These are navigational interpretations, not substitute clauses. Use the official publication for normative wording.
- 01
Four value preferences
Use the four values to challenge process weight while retaining necessary control and evidence.
- Evidence object
- Agile value trade-off record
- Decision test
- Which interaction or working outcome is being improved—and what control still matters?
- 02
Twelve supporting principles
Translate the twelve principles into observable team and delivery behaviours.
- Evidence object
- Principle-to-operating-practice map
- Decision test
- Can a claimed agile practice be linked to a principle and outcome?
- 03
Early and continuous value
Plan early, frequent increments that test the most important value and uncertainty.
- Evidence object
- Outcome roadmap and increment hypotheses
- Decision test
- What will the buyer or user learn from the first increment?
- 04
Welcoming bounded change
Welcome bounded change through prioritisation, architecture and commercial mechanisms.
- Evidence object
- Change and prioritisation protocol
- Decision test
- Can change enter without destroying accountability, security or price integrity?
- 05
Business and delivery collaboration
Create daily collaboration between business, users, delivery and operational owners.
- Evidence object
- Team topology and decision cadence
- Decision test
- Can the person with outcome authority reach the team when a trade-off emerges?
- 06
Working outcomes and sustainable pace
Measure progress through working, accepted outcomes and a sustainable pace.
- Evidence object
- Definition of done and outcome evidence
- Decision test
- Is “done” usable, secure, supportable and accepted?
- 07
Reflection, technical excellence and adaptation
Use reflection and technical excellence to adapt the product and the system of work.
- Evidence object
- Retrospective decision and engineering improvement
- Decision test
- Which retrospective action changed observable performance?
BEFORE × INTERVENTION × AFTER
Worked case · digital service under fixed procurement controls
A fictional buyer requires fixed outcomes and regulatory milestones while user needs and detailed features will evolve.
A worked adaptive contract design, not evidence that “agile” guarantees speed.
What the team can observe
The bid promises “two-week sprints” but fixes 220 features, centralises decisions and postpones security and operations.
What changes in the operating system
The team separates outcome, constraint and feature; designs empowered product decisions, continuous assurance and contract change rules.
The offer commits to 12 measurable outcomes, a rolling evidence-led roadmap and release gates that include security, accessibility and operability.
PROPORTIONATE IMPLEMENTATION
Scale the control—not the integrity of the decision.
Agile is not one proprietary method, a synonym for speed or permission to abandon evidence, architecture, governance, documentation or contractual control.
WORKED CASEAGILE–01Teaching scenario · no claimed outcome
Use a short outcome backlog, weekly usable increment and explicit review.
Priorities, accepted increment, learning decision
Explain product, commercial and governance mechanisms for bounded adaptation.
Roadmap, team, decision and change rules
Protect team autonomy inside clear architecture, assurance and portfolio boundaries.
Outcome measures, flow data, governance decisions
SOURCE TRAIL · REVIEWED 26 JUL 2026
Trace each interpretation to its authority.
Publication status can change. Exact conformity questions belong with the current licensed publication and competent assurance.
Original authors
Manifesto for Agile Software Development
The four original value preferences
Open primary source ↗Original authorsPrinciples behind the Manifesto
The twelve supporting principles
Open primary source ↗Original author accountHistory of the Agile Manifesto
Snowbird meeting and method context
Open primary source ↗