Adaptive software development treats the first plan as a useful hypothesis. The goal stays clear, but working software and real feedback are allowed to improve the route.
01
A complete specification can still be wrong
Imagine a business commissioning a customer onboarding portal. The early requirements look sensible: collect contact details, upload evidence, send the case for approval and notify the customer.
The team could spend months documenting every field and exception before anybody uses the proposed journey. The resulting specification might be detailed, approved and wrong in several important places. Staff may review evidence in a different order. Customers may not understand the requested documents. An integration may impose limits that were invisible during the first workshop.
This does not mean planning failed. It means software work contains uncertainty that conversation alone cannot remove. Some knowledge appears only when people can see a real screen, try a realistic task and notice where the proposed process does not fit.
Adaptive software development, usually shortened to ASD, is a way of organising work around that fact. It replaces the hope of predicting every detail with a repeating cycle of informed planning, close collaboration and deliberate learning.
02
What adaptive software development means
Adaptive software development grew from work by Jim Highsmith and Sam Bayer on rapid application development. It was created for complex software projects where requirements, risks and technical understanding are likely to change while the system is being built.
Its core cycle uses three words: speculate, collaborate and learn. The names are slightly unusual on purpose. Speculate accepts that an early plan contains assumptions. Collaborate recognises that developers cannot discover the right system in isolation. Learn makes review and adjustment part of delivery rather than an apology after it.
The wider approach is mission focused, feature based, iterative, timeboxed, risk driven and tolerant of change. In plain language, the team keeps a clear business goal, builds useful pieces in short periods, tackles important uncertainty early and changes the plan when the evidence supports it.
ASD influenced the wider agile movement and shares its preference for working software, customer collaboration and responding to change. It is less commonly adopted as a named operating system than Scrum or Kanban, but its model remains a useful way to think about uncertain work.
| Stage | Question for the team | Useful output |
|---|---|---|
| Speculate | What do we believe, what must stay fixed and what should we test next? | A short plan, clear constraints, assumptions, risks and a useful feature goal |
| Collaborate | Who needs to solve and review this together? | Working software, shared decisions, resolved blockers and early feedback |
| Learn | What did the result prove, disprove or leave uncertain? | Updated priorities, better requirements and the next delivery decision |
03
Speculate means planning honestly
The word speculate can sound careless, as if the team is guessing what to build before lunch. The opposite is closer to the truth. The team still defines the mission, constraints, success measures, risks and the features that appear most useful. It simply labels uncertain parts as assumptions instead of disguising them as facts.
For the onboarding portal, the mission might be to let customers submit a complete case without staff copying information between email, spreadsheets and another system. Data protection rules, an agreed investment limit and a required launch window may be fixed constraints. The order of the evidence screens, the best review queue and the shape of an external integration may still need testing.
That distinction protects the project. Fixed constraints receive proper attention. Uncertain decisions become candidates for a prototype, technical spike or small working increment. The team does not spend the same amount of money polishing every assumption.
A useful adaptive plan therefore says more than what will be built. It records what the team believes, why it believes it, how soon that belief can be checked and what decision the result will support.
04
Collaboration is part of the design
Once the next feature has been chosen, collaboration does more than keep everybody informed. It combines the knowledge needed to make the feature work.
A developer may understand the integration and data model. An operations manager knows where cases actually stall. A reviewer understands the evidence rules. A customer support colleague knows which wording causes the same question every week. None of them owns the whole answer alone.
In the portal example, a developer could build the upload screen exactly as requested and still create a poor process if the evidence team only sees it at the end. A short review of a realistic version may reveal that files need a product category, expiry date and visible status before they can be handled safely.
Good collaboration is not a calendar packed with meetings. It means the right people can make decisions while the cost of changing the work is still small. A working screen, sample record or prototype usually creates a better conversation than a long status report because everyone is discussing the same visible thing.
05
Learning must change the next decision
A demonstration only becomes useful learning when the team decides what the evidence means. Otherwise feedback collects in a document while the original plan continues untouched.
Suppose customer testing shows that people recognise a document by its purpose, not by the formal category used inside the business. That may justify changing the labels and grouping before the rest of the submission journey is built. Suppose a technical test shows that an external API cannot support the planned real-time check. The team can redesign the hand-off now rather than discover the limit during final integration.
The learning review should ask four simple questions: what did we expect, what happened, what have we learned and what changes next? The answer may update a requirement, remove a feature, split a risk, improve a test or confirm that the current direction is sound.
Not every comment deserves a change. Adaptive delivery is not design by committee. The project mission, evidence and agreed decision-maker still matter. The purpose is to make the next plan better, not to reward the loudest reaction.
06
Adaptive does not mean uncontrolled
The most common objection is understandable: if the plan can change, how can a business control cost, scope and delivery?
The answer is to keep the boundaries firm while allowing choices inside them to improve. A phase can have a fixed timebox, investment, team and outcome. The team then selects the most valuable features and risks that fit inside that boundary. New learning may change priority or design, but it does not quietly create unlimited budget.
Acceptance criteria, security requirements, audit needs, data protection, accessibility and regulatory obligations do not become optional because the work is adaptive. They are constraints against which each increment is reviewed. Automated tests, code review, deployment controls and monitoring still protect quality.
Change should also have a visible consequence. If a new request is more valuable than planned work, the decision-maker can replace or postpone something else. If it expands the agreed outcome, it can become a separately estimated phase. Adaptation without trade-offs is simply scope creep wearing comfortable shoes.
07
Where the approach earns its keep
Adaptive software development is strongest when the business goal is meaningful but the correct route cannot be known in full at the start. New products, unusual operational workflows, integration-heavy systems and software replacing several manual processes often contain this kind of uncertainty.
It also suits projects where users need to see something before they can give useful feedback. A working prototype can expose language, sequence and ownership problems that remain hidden in a list of requirements. A narrow production phase can prove how real data and external systems behave before a wider rollout.
The approach earns less on a tiny, well-understood change with stable acceptance criteria. Replacing a known label, adding an established report or applying a routine framework update may need a clear task and good testing rather than a full adaptive cycle.
A highly prescribed migration can also have little freedom in its final outcome, although an adaptive approach may still help sequence risks and test the move. The sensible question is not whether every project should be adaptive. It is where the project contains enough uncertainty for early learning to save a larger mistake.
08
Use discovery and prototypes to buy evidence
For many business software projects, adaptation begins before production development. Discovery clarifies the business goal, users, current process, constraints, risks and first useful outcome. It turns a broad idea into a set of decisions and visible assumptions.
A working prototype can then test the parts that conversation cannot settle. For the onboarding portal, that might be the customer submission journey, the staff review queue and the hand-off between them. Sample data lets decision-makers judge whether the proposed system makes sense without pretending the prototype is ready for live use.
The first production phase should carry that learning forward. Build a complete useful slice, protect it with appropriate tests and put it in front of the people who can judge the result. Review what changed in the understanding, then choose the next slice.
This creates useful stopping points. A business can decide to continue, adjust, pause or replace an idea before the largest investment has been committed. The learning is part of the deliverable, not a side effect the team hopes to notice.
09
Keep the destination clear and improve the route
Return to the onboarding portal. The first plan was not wasted because staff changed the evidence order or customers needed clearer language. It gave the team a direction, made assumptions visible and created something that could be tested.
The mistake would be treating that first plan as more valuable than the evidence gathered afterwards. A project can be exactly on schedule and still be building the wrong process.
Adaptive software development offers a calmer model. Set a clear mission. Protect the constraints that genuinely matter. Build a useful piece with the people who understand the work. Learn from what happens. Then make the next decision with better information than the last one.
DanJMills helps businesses clarify software ideas, create working prototypes and build focused production phases. If the destination matters but the route still contains important unknowns, discovery is usually the safest place to start.
Useful questions
Before starting an adaptive software phase, agree:
- What business mission or user outcome must stay clear?
- Which constraints are fixed and which decisions remain assumptions?
- What is the smallest working feature that can produce useful evidence?
- Which business users and specialists need to review it?
- How long is the next timebox and what investment does it contain?
- What quality, security and regulatory checks must every increment pass?
- Who decides whether feedback changes the plan?
- What planned work will move if a new priority is accepted?
- How will the team record what was learned and apply it to the next cycle?
- Where is the next useful stopping point for the business?
