There's been a lot of interest in the use of agile methods for developing new applications. When it's promoted under the rhetoric of "faster, better, cheaper, happier", it's easy to see its attraction for businesses.
Agile is well suited to delivering what customers actually want and need, particularly where defining requirements is difficult or when they will be refined during the project. But it is not necessarily the panacea for the problems typically associated with waterfall approaches - there have been some high-profile project failures that have used agile.
Agile is not a new phenomenon. The Agile Manifesto was published in February 2001, and programming methodologies that use the same iterative, outcomes-focused development processes existed long before that. So why has the adoption of agile taken so long?
Could it be because of the time required to implement the cultural changes necessary to adopt agile methodologies? It may be because agile is suited to small teams working on incremental or evolutionary projects, and the methodology doesn't scale up easily or effectively for large schemes or development projects.
However, it is likely that adoption has also been slowed by a lack of contractual models that balance the risks between the parties and because customers like the certainty of outcome and cost that they are offered under waterfall-based contracting.
Customers are used to contracting for waterfall developments, and legal precedent has provided certainty of the suppliers' delivery obligations as part of the bargain. With most software contracts rooted in engineering and building contracts, the parties know and understand how these should be drafted.
Where these contracts and projects fail is in their ability to deal effectively with change. Consequently, costs are bound to increase as the supplier tries to amend the system as requirements are refined, or result in disappointment when the delivered software fails to meet the customers' changing needs.
Agile satisfies these failings by allowing the software to evolve through the iterative development process. Equally, because the supplier is only developing functionality that the customer wants, the development costs reflect the value actually delivered.
However, the cultural change required by this alternative approach needs to be reflected in a different style of contract - one that is more collaborative and that recognises that change is a fundamental part of the project.
Contracts are used to allocate risk between parties. To ensure that the risks are appropriately balanced, the contract for an agile project will need to deal with the following issues:
1. Project outcomes
The contract should still set out a vision for the project outcomes. Importantly, the contract will need to establish a mechanism for identifying how and when the requirement or vision has been satisfied and the project can be closed.
2. Customer input
The agile methodology is heavily dependent on the customer contribution to each iteration, and its employees will need to be closely involved in the development - both in the development of story boards, use cases and product backlogs and in providing feedback before functionality is put into production. The supplier will be dependent on this input and will need protection against the customers' failure to provide employees at the right level.
3. Governance measures
Employees who are embedded into the development team will be expected to have executive authority to take decisions about functionality and requirements. Customers will want strong governance measures to ensure that the project stays on course and that it is not subject to scope creep. This issue is particularly important for projects in the public sector where changes in requirements can cause procurement law problems.
4. Cost control
Customers should not automatically assume that the costs will be less with agile. As well as the developer cost, customers will also need to consider the opportunity cost involved in its contribution to the development cycle.
Also, pricing generally tends to be conducted on the basis of time and materials, and the customer will want to give consideration to some appropriate control measures. While most development activity is conducted in short and controllable sprints, it remains unlikely that the supplier will be able to give an accurate estimate for the total cost of development.
A similar issue applies to the overall time required to deliver the project vision. Agile works best with small, self-instructing and organising development teams. To provide scale to a project, the supplier can use multiple teams developing different aspects of the work.
Control projects are then required to co-ordinate the activities of these teams, which requires specific governance measures and strong project leadership. Consequently, agile does not automatically result in faster projects.
Customers need to understand these cultural challenges and suppliers need to provide the education as part of the engagement process otherwise there will still be a failure of understanding and disappointment. Equally, the legal team needs to understand how the risks can be balanced and to draft accordingly.
There are many evangelists for agile and the methodology has great potential to save cost and time. It does not resolve all the problems for application development but, if used for the right projects and with the benefit of the right protections, agile does provide an alternative approach.
Stewart James is a partner in the technology, media and commercial group at law firm DLA Piper's Leeds, UK, office. His areas of expertise include outsourcing and retendering, business process re-engineering, information assurance, data protection, and intellectual property issues.