Guiding Principles of Iterative Development

These are my rough notes on the principles of iterative software development in an attempt to boil down the complexities of iterative development to a simple working set of guidelines. Any comments, suggestions or resources are certainly welcome.

What is iterative development?

Iterative development is a software development process that supports development of a system incrementally. The process builds in regular and frequent cycles for feedback from stakeholders based on reactions by end users to a working, although incomplete, system. This enables the development team to deepen their learning and understanding of the system as development progresses and to flexibly adapt to changes in requirements as they come up. This process helps ensure that the end result will be a system that best meets the current needs of all stakeholders, yet can change or grow to adjust for new and unforeseen needs.

In this way, the iterative development process reflects what most of us actually experience as the reality of software development, that requirements cannot be frozen and new requirements are frequently discovered once programming is under way. Instead of trying to impose artificial deadlines and milestones on a project, as is common in traditional models of software development, the team can tailor the development process to conform to the situation as it actually exists, and therefore increase the chances for success.

Principles to Follow

• Manage requirements not tasks, based on use cases and nonfunctional requirements.
• Manage to meet business goals, due dates and budgets. Be willing to change requirements to fit these, not the other way around.
• Practice the art of doing only what is necessary and no more. Every requirement should satisfy a user goal.
• Learn as you go; be adaptable to new or changing business needs that become clear only after development begins.
• Analyze existing implementations frequently to determine that they are meeting business goals.
• Begin with a simple implementation of a subset of the requirements that demonstrates key aspects of the system.
• Design around isolated, easy-to-find modules that group small sets of related requirements. Complete or re-code one module per iteration.
• Work in short cycles (1-6 weeks) composed of overlapping phases: requirements, design, programming, testing.
• During the iteration, the external customer or project manager cannot change the scope for that iteration, but the development team may change the scope by dropping features if the end date will not be met.
• Build on what was built before and produce a working product at each stage. Gather customer feedback at the end of each iteration. Plan for a release every 3-4 iterations.
• Any difficulty in design, coding and testing a module should signal the need for redesign or re-coding.
• Modifications should become easier to make as the iterations progress. If not, redesign is needed.