“Iterative Enhancement” is a model for iterative development, from Basili & Turner, described in 1975 (!). We’ll look at it, and compare it to XP’s approach.
I’ve seen occasional mention of this paper in people writing about evolutionary design or Agile, but as far as I know it was not a direct influence in the Agile processes that emerged in the late 1990s to early 2000s.
In discussing process, I have to omit some aspects. Sometimes this is pure ignorance, e.g., I don’t have enough information to fill in the whole process for Iterative Design. Sometimes this is just to keep descriptions focused on the core ideas, or this would be a book:) But I hope I’ve captured enough of the essence that you can see the key similarities and differences.
I understand “Iterative Enhancement” to be a descriptive phrase, not a process name such as Scrum or XP, so I’ll frequently refer to it as “Basili & Turner”.
Iterative Enhancement
Basili and Turner say that the approach is basically “… start with a simple initial implementation of a subset of the problem and iteratively enhance existing versions until the full system is implemented.” Their steps may be extension (new capabilities) or design modification.
To manage the project, they use a project control list (PCL) – a list of all the tasks needed to move from that initial implementation to the final version.
The overall process looks like this:
Design and Code
They favor design in advance of coding, and generally use “top-down stepwise refinement techniques” to create “modular, well-structured components”. Since that can be challenging to do all at once for a large system, they favor doing it at the task level. They recognize that redesign or reimplementation may become necessary as they learn more.
Analysis
When the team analyzes the resulting implementation, it considers the quality of the code, non-functional aspects, and how well project goals were met. They use automated analysis tools if available, and seek user feedback as well.
The Skeletal Initial Implementation
The initial implementation:
- Samples the key aspects
- Is simple to understand, implement, and modify
- Results in a usable and useful product available to the user
Their project was a compiler, and their skeletal program was a compiler for a minimal subset of the language – but a big enough subset for them to write a bootstrapping compiler. They note that the skeleton would have been smaller without the requirement to self-compile.
Size
They describe the project as 10 person-months of effort, spread across 16 months. The result is about 6400 statements in 17K lines, plus 3500 assembly language instructions – not very large by today’s standards.
The paper gives no indication of the size of the PCL or the size of the tasks it contains.
They analyzed 5 different versions in more detail: SIMPL-X 2.0, 3.1, and 4.0, and SIMPL-T 1.0 and 1.6. Unfortunately, they don’t indicate how many versions they had in total. Filling in the obvious SIMPL-X 1.0 and 3.0, and SIMPL-T 1.1 through 1.5 suggests at least 12 versions. If you assume that each version got up to x.6, that suggests about 30 versions.
Comparison to XP
The original XP process looks something like this:
XP’s approach is cyclical, built around nested iterations. Its focus is stories, scenario-style descriptions of features or capabilities that users care about.
XP plans are built via negotiation among the whole team, at the release and the story level. The team chooses a subset of stories to be done in a (timeboxed) iteration, and developers identify tasks needed to implement selected stories. (Tasks are small steps that don’t create value to a customer by themselves.)
XP’s plans are “progressive disclosure”, fleshing out stories and tasks as it’s closer to time to implement them.
Comparison / Critique
XP plans at the release (story) and iteration (task) levels, where the PCL treats everything as a task. As far as I can tell, Iterative Enhancement’s project control list does not have the notion of near-term items being in more detail than those further out. I don’t think it would be incompatible, however.
The cited paper doesn’t give examples of PCL tasks, so it’s hard to know how big they are compared to XP’s tasks, stories, or “epics”.
Iterative Enhancement works one task at a time. This is a lot closer to lean’s single-piece flow than it is to XP’s nested loops.
The Basili & Turner approach uses top-down, stepwise refinement techniques. XP uses TDD, which doesn’t require that approach but often uses it (sometimes called “programming by intention”). TDD also emphasizes (unit-level) testing and refactoring. Basili and Turner describe testing as “done by the usual method of using test data”, suggestive of XP’s customer tests. TDD generally uses pay-as-you-go design, not requiring much design in advance.
Iterative Enhancement and XP have similar notions of an initial skeletal implementation. XP suggests starting with basic stories chosen to span the whole architecture, and implementing them in the simplest way. I’ve heard Mike Hill describe a skeleton as a “Zero-Feature Release”. Compared to what Basili and Turner describe, XP teams try for a notably smaller first version.
Modern XP
There’s no explicit consensus about it, but I’ve seen several XP teams that have evolved to a simpler approach than that of original XP. By breaking free from iterations, and just focusing on the next story or two, it becomes much more similar to the Basili/Turner approach.
As far as I know, these changes weren’t inspired by that article. Rather:
- Customers and the business wanted more frequent releases.
- The Agile community became more familiar with Toyota’s lean practices.
- Teams increased their technical ability to go from continuous integration to frequent delivery to continuous deployment/delivery.
Let me highlight some differences compared to Basili & Turner’s approach:
- XP’s orients around user stories rather than tasks, so the team focuses on something valuable to end users and the business.
- XP is clearly a team approach; it’s not clear how much team was involved in Basili & Turner.
- XP’s design and testing approach is TDD-based, to keep quality high enough to support continuous release.
- Refactoring builds in more continuous design, rather than managing it as rewrite or redesign tasks on the PCL.
- Although I showed a reflection step, some teams use a more continuous reflection approach and others hold periodic retrospectives. In any case, reflection may look at stories, the system, and the team’s process.
Conclusion
I wish I had known and applied the Iterative Design approach all along, instead of fumbling around the edges of it. Even if it was not the basis of XP’s approach, it added to the zeitgeist around evolutionary design over the last 50 years.
Modern XP teams have more or less caught up to the approach, and driven it further by adding in pairing / ensemble programming, incremental design via TDD, and continuous deployment.
Bibliography
“Iterative Enhancement: A Practical Technique for Software Development”, by Victor R. Basili and Albert J. Turner. IEEE Transactions on Software Engineering, Vol. SE-1, No. 4, December, 1975.