What are the difference between Agile and iterative and incremental development? Is Agile considered as iterative and incremental? Some info shown the Agile is the latest of iterative and incremental. I need a clear clarification on this.

4 Answers
4

Iterative - you don't finish a feature in one go. You are in a code >> get feedback >> code >> ... cycle. You keep iterating till done.

Incremental - you build as much as you need right now. You don't over-engineer or add flexibility unless the need is proven. When the need arises, you build on top of whatever already exists. (Note: differs from iterative in that you're adding new things.. vs refining something).

Agile - you are agile if you value the same things as listed in the agile manifesto. It also means that there is no standard template or checklist or procedure to "do agile". It doesn't overspecify.. it just states that you can use whatever practices you need to "be agile". Scrum, XP, Kanban are some of the more prescriptive 'agile' methodologies because they share the same set of values. Continuous and early feedback, frequent releases/demos, evolve design, etc.. hence they can be iterative and incremental.

I recommend reading Karl Scotland's blog on the topic (availagility.co.uk/2009/12/22/…) where he introduces the notion of fidelity to explain further the difference between incremental and iterative development and how being agile means being both incremental + iterative (i.e. the 2 are not incompatible)
–
dm76Oct 19 '12 at 20:20

@dm76 - yeah the terms are (ab)used to different degrees based on who your are talking to. Read the link - I agree with the idea; however I find that people find it difficult to define their minimum expectations (Grade F). Also my version of incremental is not building one feature to full fidelity at a time.. it's rather growing something with time/new needs.
–
GishuOct 20 '12 at 8:25

The key bit here I think is "differs from iterative in that you're adding new things.. vs refining something)."
–
dangerousdaveMar 12 '14 at 11:04

The Apollo program, performed by NASA was a sequence of iterative and incremental missions. Apollo 11 was the first mission to land a human on the Moon in 1969. Each new mission, from 1 to 11, was an incremental process of experimentation and gradual iterative improvement. It is good to see a fine talk given by Dr Jeff Norris, on Mission Critical Agility - youtube.com/watch?v=EfXl7X-0wRI
–
jjpcondorJun 14 '14 at 8:26

Incremental development means that different parts of a software project are continuously integrated into the whole, instead of a monolithic approach where all the different parts are assembled in one or a few milestones of the project.

Iterative means that once a first version of a component is complete it is tested, reviewed and the results are almost immediately transformed into a new version (iteration) of this component.

So as a first result: iterative development doesn't need to be incremental and vice versa, but these methods are a good fit.

Agile development aims to reduce massive planing overhead in software projects to allow fast reactions to change e.g. in customer wishes. Incremental and iterative development are almost always part of an agile development strategy. There are several approaches to Agile development (e.g. scrum).

Iterative development implies revisiting usual waterfall model steps over the course of product lifetime. The stages can even overlap, i.e. while doing end-to-end testing you could already start preparing new requirements.

Incremental development means you roadmap your features and implement them incrementally.

Agile aims at creating "potentially shippable product" after every sprint. How you achieve it is a different story. Agile tries to employ "best" techniques from various fields (e.g. extreme programming). Agile does not exclude running neither incremental nor iterative development.

According to Chrome program manager Anthony Laforge, the increased pace is designed to address three main goals. One is to get new features out to users faster. The second is make the release schedule predictable and therefore easier to plan which features will be included and which features will be targeted for later releases. Third, and most counterintuitive, is to cut the level of stress for Chrome developers.
Laforge explains that the shorter, predictable time periods between releases are more like "trains leaving Grand Central Station." New features that are ready don't have to wait for others that are taking longer to complete—they can just hop on the current release "train." This can in turn take the pressure off developers to rush to get other features done, since another release train will be coming in six weeks. And they can rest easy knowing their work isn't holding the train from leaving the station.<<