I have trouble finding a key distinction between adaptive model and iterative or incremental model.

According to this definition - https://www.oreilly.com/library/view/effective-project-management/9781118016190/ch011-sec045.html

[...] Each iteration in the Adaptive models must address not only task completion for newly defined functions and features but also further solution definition through function and feature discovery

The discovery part is supposed to be the key difference but is this it? I mean it is pretty natural that when people are working on something they get to know more and more about the product and problem domain so I don't understand how is this a key difference. My point is that I don't see how iterative or incremental models are lacking the discovery part which is supposedly the "new feature" of adaptive model. In my mind, the whole goal of incremental and iterative approach is to repeat all of the project activities multiple times so you can adapt while delivering portion of the product so I don't see any new methodology coming from adaptive model. What am I missing?

  • I believe that to have a sound answer, one needs to understand how this problem is impacting in your work. What's the context where the difference between an adaptive and iterative was raised? Is it related to some practices someone suggested you to follow? Are you trying to understand different working models? The terminology is really useful when it has enough context, otherwise it may only lead to confusion.
    – Tiago Cardoso
    Nov 22, 2021 at 22:31

2 Answers 2



You have mixed some concepts.

As Stanislav has written; there are two approaches.

Predictive and Adaptive

Within Adaptive you may find both incremental and iterative which are distinct from each other.

However, it is highly likely that Incremental is also found within Predictive models.

How Does That Work?

Increments are pre-defined packages of functionality that build on the previous increment. They are planned and part of a larger architecture.

We will add VISA, then Mastercard, then PayPal then...

Ultimately they make something bigger.

So we can have a Predictive Model that has incremental delivery.

An iteration is a defined package of work that is responding to feedback and may take the architecture/organisation/service in completely unknown directions because satisfying a user makes sense.

We will allow users to use one type of payment and then ask users what payment types are missing and analyse that in line with market research...

We can have an Adaptive Model that may have Iteration and in doing so it will also increment the product or service.

Ultimately iteration makes something better, not necessarily bigger. We may change it completely.

Wider Breakdown


As an analogy, we build modern bridges using an Predictive Model in an incremental way.

We conceptualise the bridge for feasibility then we build a model but crucially, once the full delivery begins we add 1 section of a bridge at a time until you have a bridge.

Like this.

enter image description here

An incremental approach in software engineering is the same. You build section by section, or component by component or feature by feature until your vision (largely defined at the start) is complete.


An Adaptive Model using an iterative approach is looking at an obstruction and thinking

how could we get across this?

You might start with a simple path down either bank and wading through the water. Users are unhappy and it does not work in winter. A user may ask to transport goods so you iterate a design that includes a small gondola ferry.

Another user explains they need the ability to go backwards whilst another user goes forward so you replace the ferry with a log bridge.

Automobiles are invented and you need to respond to weight capacity so you strengthen the bridge but sediment flow within the water dictates wood is no longer suitable so you decide to close the bridge and rebuild it with modern techniques.

Financial considerations dictate you have to charge a toll but traffic declines so you respond with toll charges only one-way....

At no point did you start the process deciding a concrete, three-pylon, toll-booth bridge was the solution. You started with solving a customer problem of getting from one side to the other.

You iterated to the most suitable solution that customers, stakeholders, market conditions, technology and your own ingenuity would allow.

Other Considerations

  • Both techniques may or may not have plans and those plans may or not be effective
  • Iteration requires a commitment to responding to change even if that change comes very late in the build (that can be hard to take for developers, it means being happy you did not build it fully rather than being unhappy your work was wasted)
  • Incremental design does not require as much respond to change since you can theoretically plan all of your increments up front depending on how confident you are
  • Late changes to an incremental design can be damaging if the architecture cannot absorb the changes
  • A large product or service may have a mix of incremental AND iterative design (for instance a component or feature may be iterated within a larger incremental design)
  • Iterative ideas are crucial to Agile but you can both increment and iterate without subscribing to the wider Agile Manifesto or any specific framework.

Historical Reasoning

Lastly, to know the genesis of incremental design is to understand computing.

In the 60s-80s, production environments were highly expensive and entry to production was queued. In turn, this meant testing was expensive and also queued.

So, the impact was that a potential mistake in your design was very costly. It made sense to gather as many requirements as possible up front and try and fix (or baseline) those requirements in collaboration with a customer before you ever committed a line of code. The baseline would be communicated and everyone would expect that to be delivered.

The disadvantage was that changing the baseline required approval and not everyone was empowered to do so and governance would be involved...

In the modern era, we can literally spin up testing resources and higher environments for pennies. We can solve problems quickly and there are likely frameworks or packages we can take from the community.

The penalty for a mistake in modern software engineering is much lower so we can allow ourselves the freedom to build things quickly and let the user feedback drive what we do next. Do we fix A or improve B or add C or make D more performance etc.

However, there are still organisations that struggle with that (for a variety of reasons) and the Agile Manifesto was an attempt to encourage greater ability to respond quickly to feedback.

As of 2021 we now have hundreds of documented patterns for how we respond to feedback and incorporate iteration into a workflow.

Some patterns rely on management agreeing to cede power to the development team.

In that regard, iteration may fail based on a variety of creative, cultural, organisational or knowledge barriers.

MVP Addendum

The Minimum Viable Product is closely tied to iteration but it is a widely misunderstood concept in engineering and within Agile. Largely because most Agile practitioners have little experience in startups; most worked in scaled organisations.

It is best to divorce your learnings about iteration from MVP however once you are ready you can understand the MVP concept with a careful reading of the blogs of Marty Cagan.


Hi, seems you are opposing approaches to models.

There is Predictive & Adaptive Approaches.

Predictive e.g. Waterfall and Adaptive is like Agile.

So Adaptive SDLC approaches have a mix of incremental and iterative development.

Here you could find more info.

  • What do you mean by "opposing approaches to models"?
    – Sarov
    Nov 22, 2021 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.