17   Use Short Iterations, Release in Increments

“We’ve got this beautiful project plan with all the tasks and deliverables scheduled for the next three years. When we release the product then, we’ll capture the market!”

The Unified Process and the agile methodologies both prescribe iterative and incremental development.^[18] With incremental development, you develop application functionality in several small groups at a time. Each new round of development builds on the functionality of the previous one and adds features that enhance the product’s value. You can release or demo the product at that point.

Iterative development is where you carry out the various tasks of development—analysis, design, implementation, testing, and seeking feedback—in small, repetitive cycles, called iterations.

The end of an iteration marks a milestone. However, the product may or may not be available at that time for real use. An increment of the product is complete when, at the end of an iteration, you are ready to release it for real use, along with resources to support, train, and maintain. Each increment generally includes many iterations.

According to Capers Jones, “…Large system development is a very hazardous undertaking.” Large projects are more likely to fail. They generally do not follow an iterative and incremental development plan, or the length of the iterations is too long. (For a good discussion on iterative and evolutionary development, and evidence of its correlation to risk, productivity, and defects, refer to Agile and Iterative Development: A Manager’s Guide [Lar04].) Larman argues that software development is not predictive manufacturing but inventive in nature. A project that is scheduled years before a customer puts the application to real use is most certainly doomed.

The idea of tackling a large project by taking small steps is key to an agile approach. Large leaps increase your risk; small steps help you maintain your balance.

You can find many examples of iterative and incremental development around you. Consider the XML specifications from the World Wide Web Consortium: Document Type Definitions (DTDs), which define the structure and vocabulary of XML documents, were released as part of the original specification. Although DTDs solved the issues at the time of their design, actual usage brought to light a number of limitations and problems. Based on user feedback and further understanding, more effective second-generation solutions for defining document structures, such as Schema, were created. Had they waited to come up with something superior to start with, we might not have seen XML become dominant—we got experience and insight by releasing early.

Most users would rather have good software today than wait for superior software a year later (see “Good Enough Software” in The Pragmatic Programmer: From Journeyman to Master [HT00]). Identify core features that’ll make the product usable, and get them into production—into the hands of the real users—as soon as possible.

Depending on the nature of the product, releasing an increment may take weeks, or perhaps months. But if you’re looking at delivering in a year or two, you should reevaluate and replan. You may argue that building complex software takes time and that you can’t produce a large software application incrementally. If that’s the case, then don’t produce one large application! Build it in smaller, useful pieces—that is, follow incremental development. Even NASA used iterative and incremental development to create the complex software for its space shuttle (See Design, development, integration: space shuttle primary flight software system [MR84]).

Ask the users what features are essential to make the product usable. Don’t be distracted by all the nice features you might possibly have, and don’t aim for the most glamorous user interface you can envision.

You want to get an application into users’ hands quickly for a number of reasons: by getting it into the hands of users, you generate revenue, and it’s easier to legitimize the efforts to continue funding the product. Feedback from the users helps us understand what they really care about and what should be written next. You may learn that some features you thought were important are not anymore—we all know how volatile the marketplace is. Release your application soon, because it might not even be relevant later.

Having short iterations and smaller increments helps developers stay focused. If you are told you have a year to complete a project, in your mind you see something a long time off. It is hard to have the drive needed to focus when something is so far away. Our society prizes instant gratification—we want results quickly, and we like seeing things take shape sooner than later. That isn’t necessarily bad; it is actually good if it can be turned into productivity and positive feedback.

---

Figure 2. Nested agile development cycles

Figure 2, ​Nested agile development cycles​ shows the relationship between the major cycles in an agile project. The ideal duration for each increment is a few weeks to a few months, depending on the size of the project. Within the development cycle for each increment, you should use short iterations (no longer than a couple of weeks). End each iteration with a demo, and place a working copy of the product in the hands of select customers who will provide feedback.

Develop in increments. Release your product with minimal, yet usable, chunks of functionality. Within the development of each increment, use an iterative cycle of one to four weeks or so.

What It Feels Like

A short iteration feels sharply focused and productive. You have a solid, well-defined goal in sight, and you meet it. A firm deadline forces you to make the hard decisions, and no issues are left open or unresolved for very long.

Keeping Your Balance

• Determining an appropriate iteration length is a critical question of balance. Andy had a client who firmly believed that iterations should be exactly four weeks in length, because that’s what they had read. But the team was dying at that pace; they couldn’t develop the code and tend to their ongoing maintenance responsibilities. The solution was to use a four-week iteration separated by one week of maintenance work and then begin the next iteration. There’s no rule that iterations have to be back to back.

• If there’s not enough time in each iteration, then the tasks are too large or the iteration is too short (on average; don’t change just one iteration because of oddball circumstances). Feel the rhythm.

• If there is a disconnect between the users’ needs and the features of the release, then perhaps the iteration was too long. As users’ needs, technology, and our understanding of the requirements change over time, those changes need to be reflected in the release. If you find yourself still working on old notions and stale ideas, then perhaps you waited too long to make adjustments.

• An incremental release must be usable and provide value to customers. How do you know what they’ll find valuable? Ask them.