Small Releases

There are several reasons to have small releases. In traditional software development approaches it can happen, that a release can take up to several years.

Example: A software system for the police in Germany (INPOL-neu) was approved in 1992 by the secretaries of state of the 16 states of Germany. According to the most recent planning (as of October 23, 2001) the system should have replaced its predecessor as of October 15, 2001. (Sources: Heise, Golem).

A couple of disadvantages are associated with big releases. As an example, it is of increasing importance for customers, that an investment starts to pay off as soon as possible. The earlier a system can be used productively, the earlier it can earn money.

Customer requirements are subject to ongoing changes. The increasing globalisation, but also the increasing worldwide informational integration are leading to requirements changing in increasingly shorter timespans.

A lot of functionality can be delivered with one large release, but typically the requirements are determined at the beginning of the implementation, that is at the beginning of the release cycle. During the release cycle, the requirements may change (and they do!), for example because the market has changed. If ultimately the system is shipped (using large releases), it could well be, that the functionality does not meet the actual requirements.

Small releases, one of the 12 practices of XP, cannot eliminate this risk; due to the timely availability of functionality the customer has at least two advantages:

1. The customer can use the already available functionality in production without waiting a long time.
2. The customer has an additional mechanism for influencing the future direction of the project, for example by changing priorities, or by adding or removing features.

Ad 1: The functionality can be put to production, because the features are tested, both reproducable and automatically. To achieve this, acceptance tests and unit tests are used.

Ad 2: Alway at the beginning of a release cycle a planning game takes place. The customer specifies his requirements by writing user stories. At this point new user stories can be added or existing user stories can be modified or even completely removed, for example if they become obsolete.

Tips

• A small release takes typically three months.
• A small release never takes longer than 4 months.
• An extremely short release takes 1 day.

Example: In a Swiss insurance company a Smalltalk based system is used in customer service. Using XP the release cycle was brought down to one day. In other words: There is a release every single day! (Source: Personal conversation with Kent Beck)