Release Early, Release Often

We want to get a release to the customer as soon as possible. We want this release to be as valuable to the customer as possible. That way the customer will like us and keep feeding us cookies. ^[6]
”Kent Beck/Martin Fowler

The customer will like us and keep feeding us cookies for a while, anyhow. See the section Generate a Quick Illusion of Success in Chapter 2.

 

XP encourages teams to release code into the wild as soon as possible. By getting the product into the hands of the users very quickly (and then every few weeks from then until the project is cancelled), the team can start to get user feedback early in the project life cycle.

Thus, the users will have the latest version of the software installed live the day after it was written, and they ll get to say, I don t like the way this works, can you change that? or This doesn t work the way it needs to. This is rather like crashing cars to work out how to make them safer, except the real users are being used as crash-test dummies.

It might be more sensible to take an interaction design approach (as described by Alan Cooper in The Inmates Are Running the Asylum and About Face 2.0 ). This approach is a very effective way of working out in advance what the users really need. By taking a goal-driven approach to human-computer interaction (HCI) design (rather than a feature-driven approach), the design is much more likely to fall into place early on (a good indication that this has happened is when both the technical design and the user experience design just feel right ).

Getting feedback from the users at this early stage is also vital , but the distinction is that the users are being fed prototypes and drawings, rather than real software that must be tested out on real data in a live environment.

Another point made by Cooper is that paradoxically, the users aren t always the best people to decide what features to include in the product. Of course, their input is essential because they ll be the people using the software ”the software is intended to solve their problems. However, the end users are typically not interaction designers. Users tend to suggest features or changes based on what they believe is reasonable.

The experienced interaction designer is likely to come up with a much better,-more integrated set of features to fulfill the users goals than the users themselves . Thus, while the users feedback is important, they re best suited to contributing the goals of the software, rather than dictating the user interface design. And these goals (typically based on the problems that the users are facing with their current system) are just as easily identified prior to code being written than after.

Note that XP and some interaction design critics counter this by saying that discovering goals is hard, and users sometimes don t know what they want until they re using the software for real. This is precisely why an experienced interaction designer is so important, because she understands how to identify the goals early on and she can help the users understand what they re getting. There s nothing arcane or magical about this approach; it s well documented. ^[7]

Luckily, interaction design and agile development aren t mutually exclusive. We combine them in our refactored process in Chapter 15.

 

Small Releases Can Delay the Minimum Feature Set

One of the purported advantages of small releases is that the software can begin earning its keep by providing business value to the customer straightaway. Although desirable, this isn t always as useful or practical as it sounds. Sometimes, time to market is less important than taking the time to get the product right first. And sometimes the customer needs a certain minimum level of functionality to be achieved before the software is really useful.

If this turns out to be most of the product s functionality, then the team would do better to design and write the software as quickly as possible ”cutting a straight line from A to B.

 

For some reasons why this is a faster approach, see the section Building an Infrastructure with Emergent Design in Chapter 12.

 

Although the small releases approach ( coupled with emergent design) may seem to reduce risk, sometimes it can increase a project s likelihood of early cancellation because it actually delays the first useful release ”when the product has achieved its minimum level of useful functionality.

Sometimes small releases can be useful, though. The point is to appraise the nature of the project at the start and tailor the process accordingly ”and not to simply go for it with frequent small releases whether the customer needs them or not.

SOLUTION  

The benefits of small releases (primarily, early feedback) can still be achieved in a wider range of projects by taking an up-front design approach (as we discuss in Chapter 12). This does, of course, depend on whether the customer is prepared to wait a little longer (say, a month or two) for the first release ”in our experience, we have found that this is almost always the case. In the few cases where the customer needs something working as soon as possible, a smaller interim release will often do. This keeps the customer happy and provides a breathing space to design the main product properly.

An example of this interim release approach is given in the case study in Chapter 15. See also the section The Stopgap in Chapter 15.

 

Another, major problem with releasing the system early is that it puts the software into maintenance mode very early on. This effectively slows development down; in certain circumstances it can slow development to a crawl. From now on, the party s over ”you have real live customers to support. This means no more quick changes to the database or sweeping application programming interface (API) changes. Any such modifications now come at a price ”several prices, in fact: reinstallation of all or part of the product, database update scripts, update scripts testing, user retraining , user manual or help screen rewriting, and regression testing, to name a few.

See Chapter 9 for more detail on the problems of refactoring a system with an installed user base.

 

Remember that live systems must also be supported on a day-to-day operational basis, and this can often involve your programmers, who would otherwise be better spending their time writing the other 90% of the product.

If the benefits outweigh the problems, it s worth doing; otherwise, you should ask yourself whether the project really needs to be in the customer s hands just yet.

^[6] Kent Beck and Martin Fowler, Planning Extreme Programming , op. cit., p. 64.

^[7] For example, read Alan Cooper s books (referenced in Chapter 15). Also see Jennifer Preece, Yvonne Rogers, and Helen Sharp, Interaction Design (New York, NY: John Wiley & Sons, 2002); Hugh Beyer and Karen Holtzblatt, Contextual Design: Defining Customer-Centered Systems (San Francisco, CA: Morgan Kaufmann, 1997); John M. Carroll, Making Use: Scenario-Based Design of Human-Computer Interactions (Cambridge, MA: The MIT Press, 2000).