What Is Adaptive Software Development? A Practitioner's Honest Take

Here’s a claim that annoys a lot of Agile purists: the methodology that best describes how modern AI and R&D teams actually work was written down in 2000, and almost nobody runs it by the book.

That methodology is Adaptive Software Development, or ASD for short. It came out of Jim Highsmith and Sam Bayer’s frustration with rigid, plan-everything-upfront project management, and it predates the Agile Manifesto that made “responding to change” a household phrase. I’ve spent years building software in the exact conditions ASD was designed for (projects where the requirements genuinely aren’t knowable at the start), and I keep coming back to it, even when the sprint board says Scrum.

This article is the version I wish I’d read years ago. What ASD actually is, where the Speculate-Collaborate-Learn cycle comes from, an example that isn’t hand-wavy, and where it quietly falls apart in practice (the part most write-ups skip).

What is adaptive software development?

Adaptive software development is a software development methodology built for projects where requirements change constantly and can’t be fully defined in advance. Instead of a fixed plan, it uses a repeating cycle of Speculate, Collaborate, and Learn to steer a project through uncertainty, treating change as expected rather than as a failure of planning.

That’s the whole idea in one breath. But the reason it matters is the assumption underneath it: ASD treats a software project as a complex adaptive system, the same lens biologists use for ecosystems and economists use for markets. In a complex system you can’t predict the exact outcome, so you stop pretending you can. You set a direction, you run short cycles, and you let what you learn reshape the plan. Highsmith’s original title says it plainly: Adaptive Software Development: A Collaborative Approach to Managing Complex Systems.

The name of the game is right there. It’s about managing complex systems, not executing a blueprint.

Where ASD actually came from (and why that history matters)

ASD didn’t appear out of nowhere. Jim Highsmith and Sam Bayer built it in the mid-1990s directly on top of Rapid Application Development (RAD), the fast, iterative, prototype-heavy approach that was popular at the time. RAD had the speed but not the discipline for genuinely complex, high-uncertainty work. ASD kept the iterative cadence and added a mindset: uncertainty is the normal condition, so plan for adaptation, not for control.

Then in 2001, Highsmith walked into the meeting that produced the Agile Manifesto and signed it as one of the original seventeen. That’s the part people miss. ASD isn’t a competitor to Agile. It’s one of Agile’s parents. A lot of what feels obvious in Agile today (“welcome changing requirements,” “the best architectures emerge from self-organizing teams”) reads like ASD’s thesis restated.

Why does the lineage matter? Because it tells you what ASD is for. It was never meant to be a lightweight framework for shipping a CRUD app on a predictable timeline. It was built for the messy, exploratory projects where the honest answer to “what are we building?” is “we’ll know more in three weeks.”

The Speculate-Collaborate-Learn cycle explained

The core of ASD is a three-phase cycle that deliberately replaces the old Plan → Design → Build sequence. Each word was chosen to break a bad assumption baked into traditional project management.

Speculate: because “plan” is a lie you tell your stakeholders

In Waterfall, you plan. The word implies you know the destination and the route. ASD swaps in Speculate, and that’s not just a vibe. It’s an honesty mechanism. When you tell a team “we’re speculating about the next iteration,” you give everyone permission to be wrong. You define a mission and a direction (Highsmith leans hard on the idea of a customer mission statement), set a rough set of features and timeboxes, and openly accept that the details will shift.

I’ve watched this single reframe change how teams behave. Call it a “plan” and a missed estimate becomes a failure someone has to defend. Call it “speculation” and a missed estimate becomes information. Same reality, completely different politics.

Collaborate: managing the parts you can’t predict

Collaboration is where the unpredictable work actually gets done. The premise is that no individual can hold a complex system in their head, so the work has to flow through tight, high-trust teamwork: developers, testers, and customers exchanging information constantly. This is where self-organizing teams, decentralized decision-making, and real interpersonal collaboration come in.

Here’s the nuance the textbooks gloss over: Collaborate isn’t “have more meetings.” It’s about maintaining a collaborative environment where information moves faster than the requirements change. If your feedback loop is slower than your rate of change, you’re always building yesterday’s product. ASD’s whole bet is compressing that loop.

Learn: the phase everyone underinvests in

Learn is the phase that separates ASD from teams that just iterate mindlessly. After each cycle, you deliberately extract lessons through technical reviews (much like establishing robust test suites in software testing basics), customer focus groups, retrospectives, and project postmortems (though Highsmith argued you shouldn’t wait until the corpse is cold; review while the project’s alive). The goal is continuous learning: every iteration should make the next round of speculation smarter.

Most teams I’ve seen treat the review as a checkbox. ASD treats it as the engine. If you’re not changing your assumptions based on what shipped, you’re doing iterative development in name only.

And critically, this is a loop, not a line. Learn feeds straight back into the next Speculate. That circularity is the point.

What makes ASD different from a plan-driven mindset?

The short version: ASD assumes change is the default and builds the process around absorbing it, while plan-driven methods assume stability and treat change as a costly exception. That single assumption cascades into a set of characteristics you can actually recognize in a project:

• Mission-driven: activities are justified by the mission, not a frozen requirements doc
• Feature-based, not task-based: progress is measured in working, valuable features
• Iterative: short cycles with real deliverables, not one big-bang delivery
• Timeboxed: fixed time windows force scope decisions instead of endless slippage
• Risk-driven: the riskiest, most uncertain work gets pulled forward on purpose
• Change-tolerant: the process is designed to bend, so change doesn’t break it

That risk-driven habit is underrated. Pulling your scariest unknowns to the front of the schedule (proactive risk management instead of hoping problems surface late) is one of the most practical things you can steal from ASD even if you never adopt the rest of it.

Adaptive software development vs Agile vs Waterfall

People constantly ask how ASD stacks up against Scrum, Kanban, and Waterfall. Short answer: Waterfall and ASD are opposites in philosophy; Scrum and Kanban are frameworks that operationalize the adaptive philosophy ASD helped define. Here’s how I’d lay it out:

Dimension	Waterfall	Scrum / Kanban	Adaptive Software Development (ASD)
Core assumption	Requirements are knowable upfront	Requirements evolve; manage iteratively	Requirements are inherently unpredictable
Planning stance	Fixed, detailed plan	Adaptive backlog	Speculate: direction over destination
What it gives you	Full process + documents	Concrete roles, ceremonies, artifacts	A mindset and a 3-phase cycle
Change	Expensive, resisted	Welcomed within a cadence	Expected; the whole design point
Structure level	Very high	Medium (prescriptive)	Low (philosophical)
Best fit	Stable, well-understood work	Most product teams	High-uncertainty, exploratory work

Notice the “Structure level” row, because that’s the honest heart of it. Scrum tells you exactly what to do: sprints, a product owner, a daily standup, a definition of done. ASD tells you how to think and leaves the ceremonies to you. That difference is why most teams today think in ASD terms while running on Scrum or Kanban. They absorbed the philosophy and adopted a framework that ships with instructions.

An adaptive software development example that isn’t hand-wavy

Picture a team building a fraud-detection feature for a fintech product. Nobody (not the product owner, not the data scientists, not the customer) actually knows upfront which signals will catch fraud without drowning real users in false positives. This is a genuinely complex, adaptive problem. It’s exactly what ASD was built for.

Speculate: The team sets a mission (“cut fraudulent transactions without hurting legit conversion”) and timeboxes a two-week cycle to try a first set of signals. They don’t pretend to know the final model. They commit to a direction and a deadline.

Collaborate: Data engineers, ML engineers, and the risk team work in a tight loop, sharing results daily. When early data shows one signal is useless, that information reaches everyone fast, and nobody spends a week building on a dead assumption.

Learn: At the end of the cycle they review real outcomes with stakeholders in something very close to a focus group: what caught fraud, what annoyed customers, what surprised everyone. Those lessons rewrite the next speculation.

Notice how badly Waterfall fits this. You literally cannot write a complete, correct fraud-detection spec on day one (where documentation and system specs match guidelines like our user manual guide while infrastructure loads fast with warmup cache requests). The system’s behavior only reveals itself once it meets real transactions. That’s the tell that you’re in ASD territory.

Where adaptive software development actually shines in 2026

Here’s my honest, slightly contrarian take: ASD as a named methodology is rarely adopted whole anymore, but its thinking is more relevant now than at any point since it was written, because of AI.

AI and machine-learning projects are complex adaptive systems in the truest sense. You can’t spec a model’s behavior upfront; it emerges from data you’re still discovering. Requirements shift the moment a stakeholder sees the first real output. The riskiest unknowns (does this even work? is the data good enough?) have to be pulled forward, tested early, and learned from fast. That is Speculate-Collaborate-Learn, whether or not anyone on the team has heard of Jim Highsmith.

This is why, when we scope AI software development engagements at SoftbrixAI, we plan in short speculative cycles instead of promising a fixed feature list on day one, because with genuinely novel systems, a fixed feature list is a promise you’ll break. The same logic runs through how we approach AI agent development, where behavior is emergent and has to be shaped iteratively, and predictive analytics work, where the model you ship is rarely the model you sketched. If your team is wrestling with where an adaptive approach fits your roadmap, that’s exactly the kind of thing our AI consulting practice exists to untangle.

If you take one idea from ASD into an AI project, take this: front-load the uncertainty, and treat every iteration as a learning experiment, not a delivery you have to defend.

The honest downsides nobody warns you about

I’m not going to sell you a methodology without the caveats, because the gaps are real.

ASD is vague on purpose, and that’s a problem for a lot of teams. It gives you a philosophy and a cycle, but no roles, no ceremonies, no artifacts. Teams that need scaffolding to function will flounder. Hand a junior team “Speculate, Collaborate, Learn” with no further structure and you’ll often get chaos dressed up as agility.

“Adaptive” can become an excuse for not planning at all. I’ve seen speculation curdle into “we’ll figure it out as we go,” which is not the same thing. ASD demands a real mission and hard timeboxes. Drop those, and you’ve just built a process for perpetual scope creep.

It’s hard to sell to fixed-bid, fixed-scope clients. If someone’s paying for a defined deliverable on a defined date, “we’re speculating” is a tough conversation. ASD works best where the customer accepts uncertainty as part of the deal.

So would I tell you to go run pure ASD tomorrow? Honestly, no, not by the book. I’d tell you to run Scrum or Kanban for the structure, and steal ASD’s mindset: speculate instead of over-planning, compress your feedback loops, pull risk forward, and make learning a real phase instead of a checkbox. That combination, a concrete framework carrying an adaptive philosophy, is what actually works on the ground.

My take: what I’d do if I were you

If you’re building something genuinely uncertain (an AI system, a new product category, an R&D effort), the ASD mindset is one of the most useful things you can internalize. Not the branded methodology. The mindset. Speculate honestly, collaborate faster than your requirements change, and treat every cycle as a learning experiment.

Your next step is small and free: at your next planning session, replace the word “plan” with “speculate” and watch how the conversation changes. Then pull your single riskiest unknown to the front of the schedule and prove or kill it first. That’s ASD in action, and you don’t need to adopt a single new tool to start.

Frequently asked questions

What is adaptive software engineering?

Adaptive software engineering is essentially the engineering application of adaptive software development, building systems through iterative, feedback-driven cycles that expect requirements to change. In practice the terms overlap heavily. “Engineering” tends to emphasize the technical practices (continuous testing, incremental design, refactoring) while “development” emphasizes the overall project approach, but both rest on the same Speculate-Collaborate-Learn foundation.

What is adaptive software used for?

Adaptive software development is used for projects where requirements are unstable or unknowable upfront: complex, high-uncertainty work like AI and machine-learning systems, R&D-heavy products, and new product categories with no clear precedent. It’s a poor fit for stable, well-understood projects where a fixed plan actually works, like a straightforward internal tool with locked requirements.

Is adaptive software development the same as Agile?

No, but they’re closely related. ASD is one of the methodologies that fed into Agile. Jim Highsmith, who created ASD, was an original signatory of the 2001 Agile Manifesto. Agile is the broader umbrella of values; ASD is a specific, philosophy-heavy methodology under it. Scrum and Kanban are the frameworks most teams actually use to put adaptive thinking into practice.

What are the three phases of adaptive software development?

The three phases are Speculate, Collaborate, and Learn, run as a repeating loop. Speculate replaces rigid planning with a mission and direction; Collaborate uses tight, self-organizing teamwork to handle unpredictable work; Learn extracts lessons from each cycle through reviews and feedback, feeding directly back into the next round of speculation.