The Hallmarks of Iterative Development

The Hallmarks of Iterative Development

Most people are familiar with the general tenets of Iterative Development techniques - time boxed iterations, demos of
business value at the completion of each iteration, emphasizing high risk / architecturally significant work early in
the project lifecycle but there are also a number of other characteristics that aren't immediately evident that should also be
considered. Below are some general observations that I have made regarding effective iterative development. This is a blend
of different approaches ranging from the Unified Process to elements of XP, SCRUM and Lean Programming.

Rapid Feedback

Many people should be aware of this benefit but the primary goal of an iteration is taking a requirement (which represents
value) and realizing it in working, tested software. This allows a business sponsor to actually see something working and
understand whether what they've asked for is what they actually want. It has a beneficial byproduct of allowing a developer
to stay engaged and actively involved in realizing functionality. In the perfect world this model consists of a requirements
specifier telling a developer what is desired and seeing that provided in small incremental chunks. In the real world, the
two of these roles need to have some ways in which they can communicate requirements and ensure that what is being
asked for is specific and vague. I personally think this can work very well using a Scott Ambler, white board approach but it
can also work equally as well with rich sets of artifacts such as use cases, supplementary specifications, models and
leveraging UML.

Pull vs Push:

While there are different ways in which to achieve the benefits of rapid feedback, I think a true iterative development
approach will always emphasize a pull model for specifying software. By this I mean the idea that information should be
produced that meets the needs of the person consuming it. Why produce a fully dressed, Cockburn style use case if a
developer really only needs a short XP style story. On the other hand if a scenario is sufficiently complex and requires
System Sequence Diagrams and Operation C ontracts the same developer should be able to receive these instead. The
challenge often is that many processes are seen as prescriptive and information ends up being 'pushed' to its recipients
instead of being pulled.

These days I particularly like the idea of 'Executable Requirements' (XR) to capture requirements. This approach has the
benefit of not only enabling the Pull method described above but they also ensure that software developed matches the
specifications provideds. XR bsaically provides a mechanism where a requirement is captured in a 'pass/fail' style using
an Excel or HTML table to define the requirements. The power of this approach is that it not only moves requirements out
of the fuzzy, prose style that can plague use cases (and which is why use cases have so many sections) but also allow a
team to automate a series of tests that demonstrate that a requirement has been 'fulfilled'. For those of us with a testing
orientation we can immediately see the opportunity to regress through all of our tests every iteration and ensure that new
changes don't break old functionality. There's a lot to this subject and something that I'll update on more in the future but
there are some good reference sources for this such as the Fitnesse wiki which leverages Ward Cunningham's Functional
Integration Testing (FIT) framework.

Collaborative Development

This, to some degree, is an enabler of the first two points above but its worth pointing out because too often the creative
process of software development is compartmentalized into distinct disciplines which rely on artifacts as the sole form of
communication. Small teams with a range of skills working on a common problem achieve success. Teams should have a
simple construct of a leader, an analyst, a lead developer or architect, three or four developers and a tester. The
developers will play multiple roles including build management, deployment, persistence etc. but they should all be
somewhat interchangeable if necessary. The goal is to have everyone working together, literally, the entire team should be
sitting close to one another with no impediments to their communication amongst each other. Later I'll discuss how to
scale this into a larger program setting but I think this is ultimately one of the most important hallmarks of iterative
development.

Quality at the Source

The days of having large teams of functional testers who manually execute test scripts and painstakingly document defects
are over. Good software should be written with a net of small unit tests that are automatically and continuously executed
with every build. Validating requirements through tests is important and necessary but these should be automated through
Fit/Fitness tests and the tolerance for discovering software defects (as opposed to requirements defects) after a build has
been completed should be almost zero. Obviously (and my apologies if this isn't completely obvious) continuous
integration and the development of a comprehensive and automated suite of test harnesses is critical to accomplishing
this goal. I've written some piecs on how to manage the test process such as Iterative Development Testing Approaches
and the Top Ten Questions for a Project Test Plan.

Adaptive Planning

A detailed software development plan developed months in advance isn't worth the paper its printed on. Instead a high
level set of Features mapped to timeboxed, iterations with a detailed view of the activities required to support the existing
iteration is the most realistic and effective approach to software development planning. While having an overall plan,
identifying resources requirements, dependencies (particularly with other organizations or areas) and related PMI project
planning components is important it is even more important to have a lightweight and adjustable approach which supports
changes (which after all is most of what a project manager deals with on a software development project). Tools like
XPlanner (an open source iterative development project management tool) or commercial products (like Rally Software)
provide a great mechanism for providing a blend between long term planning and short term execution. I recently wrote a
blog entry on how to select the correct iteration length for your project.

Continuous Improvement

Accepting the fact that you won't get everything right the first time is a critical hallmark of iterative development adoption.
Developing a plan from what you know and then adjusting it based on what you experience is critical. Every member of the
team should be involved in continuous learning and fostering a trusting environment where team members can safely
contribute their observations is the only way in which a true team can learn. One technique frequently used is a
Retrospective at the completion of each iteration where teams share the Plus's and Delta's of the last iteration. It's
important to ensure that these observations are put into practice though, so give some time to thinking how to facilitate
these sessions and ensure that they are useful. The Japanese call this process Kaizen which emphasizes a continuous
improvement process focused on eliminating waste and increasing efficiency.

July 2002

by Bryan Campbell