Deliver early; deliver regularly
Deliver the functionality in regular increments, starting early in the project lifecycle. A.k.a. Incremental Development.
Incremental delivery implies IterativeDevelopment, and the two concepts are closely linked, though by no means synonymous. When an increment of functionality is delivered, feedback from the users tells us what we got wrong. The earlier we get this feedback, the greater proportion of the functionality can be considered for similar problems, and the greater the understanding that can be applied when interpreting the requirements. It is necessary to manage expectations; the users should not expect the first increment to be perfect, it is “to see what sort of things we are getting wrong”. This expectation can also help circumvent the developers’ reticence at delivering a product that might undermine the users’ confidence in the developers’ abilities to deliver an adequate solution.
There are, in the main, three forces that determine the cost and benefit of a delivery and thus determine frequency of delivery; risk, team size and agility of approach. Greater risk implies greater benefit from feedback, and more frequent delivery. Larger team sizes and heavyweight processes (usually to support less experienced teams) both increase the cost and imply less frequent delivery. Agile teams deliver in cycles typically of two to four weeks or less. Few heavyweight processes deliver in cycles less than 6 weeks, and the remote end of about 6 months hardly qualifies as ‘early’ delivery, though the feedback still will be of benefit.
If the project does not support ContinuousIntegration, then the cost of regular delivery can be high. Cost of testing per release can also be high; automated AcceptanceTests cut down on the time and cost of pre-release testing.