This article was first published by Computerworld UK and the full article can be found online here.
Agile projects need to be flexible through to their termination, in a way that is fair to both supplier and client.
In the last article we considered how customers can achieve a degree of price certainty without losing flexibility under the Agile approach. One of the protections cited for the benefit of Agile is that customers have the right and the ability to end a project as soon as its requirements have been satisfied. Suppliers are willing to accept this principle provided that termination doesn't occur during an iteration. This article looks at why this simple principle is not so easy to put into practice.
One of the big differences between waterfall and Agile is the lack of a detailed specification for the solution at the start of the project. Agile seeks only to establish a vision for the product, leaving details of the functions and features to be identified during the initial discovery phase or even during development. This makes it much harder to predict with any degree of certainty when the project will complete, which gives rise to the concerns about scope creep and uncontrolled or uncontrollable budgets.
It is a basic tenet of Agile that effort should not be expended in the development of features or functionality unless they provide a business benefit. Developing features as a series of iterations allows the customer to identify which features achieve this and also to refine its vision as the solution evolves. It also means that the customer is able to determine when sufficient features or functionality have been delivered to satisfy its requirements, and it should therefore have the right to bring the project to an end once this has been achieved. The contract should mirror this principle by allowing the project to be brought to an end without any financial consequences, provided always that this does not occur in the middle of an iteration.
Flexible termination without penalty - the risk to the supplier
However, the application of this principle generates a risk for the supplier. If termination can occur at any stage of the project without penalty, then the supplier must be concerned whether it will have recovered its committed costs at the point of termination. This is not a problem for waterfall contracts because the solution is normally supplied in a limited series of releases and the customer is not able to terminate except in respect of a specific supplier default, such as the total failure of delivery. However, it is the inherent visibility of progress that gives the customer greater flexibility in Agile.
Initial phasing of the project will allow the supplier to introduce resource in a controlled manner, and the use of a "mixed economy" of pricing models for each phase can be used to protect the competing interests of the parties. However, such approaches are unlikely to provide costs protection for the supplier during the development phase when it is dependent on the completion of a minimum number of iterations in order to cover its overheads.
Define the minimum level of delivery
The conclusion is that for every project there is a minimum level of required functionality that must be delivered and which can be used by the parties to determine when the contract can be brought to an early end. The parties should identify and agree the set of features, which will include both functional and non-functional requirements, as part of a core product set that must be delivered before the project can be brought to an end. The core product should remain flexible, however, with variations permitted provided that the associated commercial model remains aligned to those changes.
In accordance with the "MoSCoW rules", this equates to the "must haves" and may also include some or all of the "should haves". This does not preclude the development of other desirable functionality, which is likely to be developed in any event in conjunction with other features, but that the successful completion of the project should not be dependent on their existence. Consequently, the supplier should have confidence that the customer will not end the project before all of these features have been delivered.
No cheating
However, the supplier should not be permitted to use identification of these core features to "game" the development by giving priority to non-core features in the product backlog. It is unlikely that the supplier could achieve this successfully in practice because of the relative importance of such features, and also because of the greater customer scrutiny of and involvement in the development of deliverables as part of the Agile methodology. In addition, the parties should agree a regime of interactive governance under the contract that will help to prevent it.
Agile is about flexibility and it is right that this also applies as much to the end of the project as it does throughout its life. The supplier need not fear early termination because its costs are met as it delivers each iteration, and the customer is protected because it does not need to pay for functionality it doesn't require.
