Iterative and Incremental: Part 1 – Definition

There are few people who argue against iterative development. However, it seems that while most of us consider iterative and incremental development to be part and parcel of iterations, not everyone seems to do both — at least not consciously and effectively. In a pair of posts, I will explain why both have more value together than either does separately. This post will build the ground-work, describing what each of these practices is and their separate value. Part 2 will describe how they become more valuable when used together and the pitfalls of doing one without the other.

Iterative development is a means of scheduling time to improve the process and product. Think about retrospectives. An amount of time is spent working on the product. A discussion of strengths and needed improvements is held. Then, an amount of time is spent reworking the product just built and the practices in use. The point is that you spend time working on the same pieces each work period (iteration).

This iteration on the same thing allows considered improvement. It is similar to refactoring. This allows for paying off of technical debt, enhanced security and performance, and improvements in understanding, testing, and implementation. It increases overall quality and efficiency of the system under development and the practices in use.

Incremental development is a means of growing a large product through delivery of a series of smaller pieces. Think about use cases or user stories or features. The overall product is described as a set of discrete pieces, each having value on their own (see INVEST). The pieces are related enough that when put together, they form a larger, cohesive system. In incremental development time is spent working on new pieces each work period (iteration).

This iteration on small pieces allows for each new increment to be considered for deployment to production. A release plan may set goals for timing or scoping of releases, but the actual ability to demonstrate the working portion may lead to a decision that a set of functionality that is delivered earlier may have enough value to warrant an early release. Delivery of properly prioritized increments also helps to avoid getting to the end of a schedule without something valuable to deploy. The most important (and risky) parts of the system are guaranteed to be there early.

While writing this post, I noticed that Alistair Cockburn wrote something similar in August of last year. His ending statement says in part that iterative development improves the product, while incremental improves the process. While Alistair is an authority and my experience and understanding is consistent with everything else he writes on that page, I disagree with this summation. It is more appropriate to say instead that iterative improves both product and process, while incremental builds upon both product and process.

Tags: definitions, incremental, iterative