TL;DR
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
Incremental
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.
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.
Iterative
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.
