Adaptive software development suits work where the outcome is understood but important assumptions still need testing. Evaluate it through 5 controls: mission, uncertainty, collaboration, evidence and scope decisions. Its speculate, collaborate and learn cycle should make change intelligible rather than provide a reason to avoid commitments.
When is adaptive software development a suitable approach?
Begin by distinguishing uncertainty from indecision. A team may know that customers need to submit an application while remaining unsure which evidence they can provide easily. That is a testable uncertainty. A sponsor who has not decided what business problem matters has a different issue. Adaptive delivery still needs a mission so experiments can be judged against something more useful than personal preference.
Jim Highsmith describes the original speculate, collaborate and learn cycle in his first-person account of adaptive planning. The Agile Manifesto principles provide primary support for related practices such as working software, collaboration and reflection. Keep those source roles distinct instead of presenting them as interchangeable authorities.
Compare adaptive work with a sequential delivery plan. If the requirements and approval sequence are genuinely stable, a staged plan may provide sufficient control. If a key workflow must be tried with users before its detail can be decided, explicitly reserve room to learn. A project can contain both situations: an uncertain customer journey and a fixed external submission requirement need not use identical planning tactics.
Write down assumptions in a form that can be challenged. For a fictional customer application, an assumption might be that applicants understand which document to upload. Pair it with a prototype task and the evidence that would change the design. Avoid treating a meeting opinion as equivalent to observing someone complete the task. The value of adaptation lies in changing decisions for an identifiable reason.
Define a small usable increment. It should let a person try a coherent part of the workflow, such as submitting a draft and recovering it later. Completing isolated technical tickets may be necessary, but it does not automatically provide user evidence. The Agile principles identify working software as the main progress measure. Translate that into something demonstrable before deciding the next batch of work.
What controls keep adaptation accountable?
Make collaboration specific. Name the person who understands the business rule, the people who will use the result and the people responsible for implementation and testing. Give them a decision to resolve together. A large standing meeting does not establish collaboration if the authorised business owner never sees the uncertainty that requires their judgement. Record the decision and its reason in the shared project evidence.
Keep acceptance criteria stable during each test. If the purpose is to learn whether applicants can recover an unfinished submission, decide what recovery means before observing the prototype. A team can revise the requirement after learning, but it should not quietly redefine success to match whatever it built. Retain the old assumption, new evidence and resulting decision so the change remains understandable.
Separate a discovered defect from a changed requirement. A button that fails the agreed behaviour is a defect; a new preference for another journey is a scope decision. Both deserve attention, but conflating them makes planning and commercial discussions harder. Classify the change, describe its consequence and identify who is authorised to decide what moves into or out of the next increment.
Protect engineering quality while changing product detail. The Agile principles connect technical excellence and good design with agility. In practical terms, ask how the team retains repeatable checks and readable interfaces while revising the workflow. A prototype may deliberately be disposable; a production component should have an explicit quality standard. Label the distinction so demonstration code is not accidentally accepted as a maintained service.
Close the learning loop. Review what the increment showed, which assumptions survived and which decisions changed. Choose a concrete improvement to the next cycle rather than ending with a list of vague lessons. The Agile principles call for regular reflection and adjustment. This discipline makes adaptation an evidence-based process rather than a permanent state in which nobody can say what has been completed.
Rehearse an assumption that turns out to be correct as well as one that fails. The team should not feel compelled to redesign the workflow merely to demonstrate adaptation. If the evidence supports the current approach, record why continuing is reasonable and move to the next uncertainty. For a failed assumption, ask what changed in the product rather than only what was discussed in a retrospective. Keep the scope consequence visible: a revised journey may displace another planned item. This makes the learning process commercially intelligible and avoids a situation in which every discovery becomes additional work with no clear decision about the overall brief.
A worked speculate, collaborate and learn cycle
The following application example is an original use of Highsmith’s cycle, rather than a prescribed framework template. Its mission is to let an applicant save an unfinished submission and return without repeating completed work.
Speculate: write the hypothesis: applicants will recognise a saved draft and understand how to resume it. Sketch a draft list and a resume action. Retain the mission, assumption and proposed observation together. A delivery estimate remains a planning input; it does not make the hypothesis true.
Collaborate: bring the applicant’s perspective, business rules and implementation constraints into the same decision. Ask someone to attempt the fictional resume task while the team observes where they hesitate. The business owner decides which saved information may be shown; the developer identifies what recovery requires; the tester records expected and observed behaviour. Their output is a shared decision, rather than agreement that the prototype looks convincing.
Learn: compare the observed task with the original expectation. If the applicant opens the wrong draft, change the identifying information and repeat the task. If resuming works but a saved field disappears, record an implementation defect separately. Retain the observation, revised design and displaced scope item. This gives the next cycle a concrete starting point without claiming that the fictional test has actually taken place.
Decision worksheet
Original contribution: an assumption-to-increment decision card. Use a fictional application journey and write the mission, uncertain behaviour, prototype task, acceptance evidence and authorised decision-maker. After the task, classify the finding as a confirmed assumption, a contradicted assumption, an implementation defect or an unresolved question. For a contradicted assumption, record which part of the next increment changes and what is deferred. For an unresolved question, state what additional observation would help. The card makes learning visible without claiming that every experiment has produced a conclusive result.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Mission | Business outcome and decision owner | Reject experiments unrelated to the outcome |
| Uncertainty | Assumption and proposed evidence | Make the unknown testable |
| Collaboration | Required participants and pending decision | Resolve missing authority |
| Acceptance | Expected behaviour and observed result | Separate defects from changed scope |
| Learning | Evidence, decision and next increment | Retain the reason for adaptation |
Use adaptive delivery when the organisation can engage with evidence and make decisions. If business owners cannot review increments or resolve trade-offs, changing the method name will not repair the bottleneck. Likewise, do not promise that adaptation eliminates uncertainty or guarantees a deadline. A useful proposal explains the outcome sought, the learning process and the controls around scope.
For the wider delivery brief, see web development and mission control. To discuss a project, get started with the intended outcome and the assumptions that need testing. Avoid supplying private customer records; a fictional journey is enough to begin.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.