“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 iter- ative and incremental development.9 With incremental development, you develop application functionality in several small groups at a time.
Each round of development builds on the functionality of the previ- ous 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, callediterations.
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.
Show me a detailed long-term plan, and I’ll show you a project that’s doomed According to Capers Jones, “...Large system
development is a very hazardous undertak- ing.” 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 dis-
cussion on iterative and evolutionary development, and evidence of its correlation to risk, productivity, and defects, refer toAgile 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.
9But then again,alldiet plans suggest you should eat less and exercise more. But each plan’s advice on how toachievethose goals varies widely.
Report erratum
USESHOR TITERATIONS, RELEASE ININCREMENTS 70
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 limita- tions and problems. Based on user feedback and further understand- ing, 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 supe- rior software a year later (see “Good Enough Software” inThe 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 pro- duce one large application! Build it in smaller, useful pieces—that is, follow incremental development. Even NASA used iterative and incre- mental development to create the complex software for its space shuttle (SeeDesign, Development, Integration: Space Shuttle Primary Flight Soft- ware 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 fea-
USESHOR TITERATIONS, RELEASE ININCREMENTS 71
Increment
1-6 Months
Iteration
1-4 Weeks
Local Build
Release
Demo &
Exercise
Check-in
Multiple times per day
Figure 4.2: Nested agile development cycles
tures 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.
Figure4.2 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
Report erratum
USESHOR TITERATIONS, RELEASE ININCREMENTS 72
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 mini- mal, yet usable, chunks of functionality. Within the devel- opment 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 codeandtend to their ongoing maintenance responsi- bilities. 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 fea- tures of the release, then perhaps the iteration was too long. As users’ needs, technology, and our understanding of the require- ments 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 cus- tomers. How do you know what they’ll find valuable? Ask them.
FIXEDPRICESAREBROKENPROMISES 73