Iterative-Incremental

Another principle of the Agile Alliance is to “deliver working software frequently, from a couple of weeks to a couple of months.”

·         Take advantage of what was learned during earlier development in later iterations. Development is performed in repeated cycles (iterative) and in portions at a time (incremental.) This allows developers to:

·         Focus on short term objectives.

In this approach, development will start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. With each iteration, design modifications are made and new functional capabilities are added. Most value is derived when iterations are designed such that early tasks help resolve uncertainty later in the project. Rather than one big design phase, one big code phase, then one big test phase, here many iterations are performed, with each iteration consisting of a short design-code-test cycle. (Figure 12)

This “Iterative-Incremental” characteristic combines with the afore-mentioned “feature-driven” gene (see section 3.2.4) to allow the software product to continually evolve as a series of product increments, each one adding more features to the existing software product.

The Iterative-Incremental concept is not novel nor unique to Agile methodologies. There is well documented evidence of extensive Incremental Iterative Development (IID) for major software development efforts dating back to the sixties (Larman & Basili 2003). Software historians seem to agree that Royce’s original work on the Waterfall has been misrepresented as calling for a single iteration of the Waterfall, and that he actually proposed several iterations of the process.

In 1994 the DoD’s Defense Science Board Task Force on Acquiring Defense Software Commercially, issued a report that stated, “DoD must manage programs using iterative development. Apply evolutionary development with rapid deployment of initial functional capability.” (Larman & Basili 2003) The result was a new standard for software acquisition introduced that same year, Mil-Std-498, which stated:

If a system is developed in multiple builds, its requirements may not be fully defined until the final build […] If a system is designed in multiple builds, its design may not be fully defined until the final build.

This allowed projects to start while only needing fully-defined requirements for one build at a time, rather than a full requirements specification for the entire project, allowing later requirements analysis efforts to be informed by work and experience from earlier build – a step in the agile direction. This standard, although later replaced by others, was a first attempt to introduce the concept of lifecycle and incremental delivery to government software projects. It is also an acknowledgement of the fact that Waterfall development and acquisition was problematic, and that the previous DoD standards had a “Waterfall bias” (perceived preference towards a single-pass Waterfall model of development.)

Explicit iteration and incremental development is neither new nor unique to Agile. It first came to the fore-front of the software engineering community’s conscience in 1986 with Barry Boehm’s "A Spiral Model of Software Development and Enhancement". The Spiral model, shown in Figure 13, very simply put, calls for repeated waterfall iterations to build and refine a software product. Early spirals can achieve goals of producing quick-to-market prototypes which can be tested or presented to customers for early feedback, which produces valuable information for later spirals. This approach mitigates project risk and allows requirements to be evolved and refined incrementally, keeping the project agile in that software is built incrementally and that the approach caters to the reality of evolving requirements.

In 2002, the DoD declared “Evolutionary acquisition strategies shall be preferred approach to satisfying operational needs” and “Spiral development shall be the preferred process“10

·         Incremental Development: End-state requirement is known, and requirement will be met over time in several increments The following two acquisition models became the official standards:

·         Spiral Development: End-state requirements are not known at Program Initiation. Requirements for future increments dependent upon technology maturation and user feedback from initial increments.