Software development projects delivered using 'Agile' methodology (rather than the more traditional 'waterfall' approach) are becoming increasingly mainstream. This article looks at the key differences between Agile and waterfall projects, the benefits and risks of Agile projects and how traditional software development contracts might need to adapt for Agile projects.
What is Agile development?
With a traditional waterfall approach, a development project is divided into a sequence of distinct phases: initial planning, definition of customer requirements, design of the solution to meet those customer requirements, development/build of the software code, testing and deployment of the finished product into the production environment, and a formal procedure for overall customer acceptance at the end of the project. The waterfall approach assumes that each phase of the project can (and should) be completed before starting the next phase, and that the customer will not receive any working deliverables until the project is completed.
By contrast, Agile development projects feature repeated short development cycles (usually referred to as "sprints"), including planning, design, development, testing and deployment activities, each covering a small subset of the overall requirements, and meaning that useable software code can be delivered to the customer more regularly throughout the life of the project.
Differences between Agile and waterfall projects include:
- There are no detailed business requirements, or rather, the methodology allows those requirements to develop as the project progresses towards a high-level project objective. The parties typically work to a "Product Backlog", which lists in order of priority the customer's non-technical requirements for the solution expressed as "user stories" (eg, "As an <analyst>, I want <a live data feed> so that <I can make decisions in real-time>".
- The Product Backlog of requirements is not fixed or subject to a formal change control procedure as is common for waterfall projects. Instead the customer may reprioritise the list of requirements or add or remove requirements at any time between sprints.
- Project management is shared by the customer and supplier through regular planning and review meetings before, during and after each sprint. In a traditional waterfall project, the supplier is usually tasked with the majority of project management activities and must deliver the project according to the agreed project plan. In Agile projects the customer will provide an estimate to the supplier of the overall project duration based on an estimated number of sprints, with each sprint being for a specified duration (often between 2 to 4 weeks), but the actual duration of the project is dependent upon how long it takes to complete all of the items on the Product Backlog. The consequence of this is that the customer needs to be comfortable with the risk of timetable slippage, and the supplier is generally not measured against fixed milestones as they would be for a waterfall project.
- Waterfall projects usually have a formal acceptance procedure at the end of the project, but in an Agile project, testing and acceptance against the shortlisted requirements is carried out during each sprint. Any outputs that fail to achieve acceptance during a sprint go back into the Product Backlog and must be redelivered during a later sprint.
What are the risks of Agile?
The key advantage of the Agile approach is that the software design can remain flexible and adaptable over the life of the project, and reflect any changes to the customer's requirements as they evolve. By contrast, a waterfall project can lead to a system being developed that conforms to the requirements that the customer had in mind at the outset, but which might become less relevant over time (particularly for a lengthy project). Agile will not be appropriate for all development projects, but works particularly well where a customer is looking to rely on the supplier to help define how the final solution should work. It also avoids a common pitfall of traditional development projects, where the supplier is getting stuck on a particular phase can stall the whole project. Agile development allows the supplier to move onto the next phase and deliver useable code to the customer at regular intervals.
That said, Agile projects can pose more commercial and legal risk to the customer than traditional waterfall projects if not managed properly. This makes choosing the right supplier even more important, but also puts more of an onus on the customer to remain involved in the development process and engage collaboratively throughout the project. Even when managed well, risks can remain:
- Having less detailed requirements might encourage supplier innovation, but can equally lead to ambiguity and misinterpretation.
- Evidential issues might arise from the collaborative approach, such as determining which party is responsible for a defect or delay. Was a failure of the supplier to achieve a critical requirement a consequence of the priority given to that requirement by the customer, or if the customer has members of its personnel on the development team, was the defect caused by the customer's or the supplier's personnel?
- Repeatedly adding incomplete or unaccepted items from a sprint back into the Product Backlog for remedial work may result in cost overruns and overall timetable slippage.
For public sector customers such as government departments, a specific concern may arise from the supplier being unable to accurately price Agile projects at the outset. This is due to the flexibility of the approach and not having detailed customer requirements, which in turn means the supplier might only be able to provide a loose estimate. This may make it difficult for the customer to properly form its business case, which is a key requirement for public sector procurement.
What to include in your Agile development contract
A right to terminate the contract early can help in avoiding the potential for increased project costs or delays, and incentivise the supplier to perform properly. For example, the customer should seek to have the right to terminate after every Sprint, but may negotiate this with the supplier so that the customer only exercises this right in respect of critical requirements or due to cost blowout. Any right to terminate should include a right for the customer to take what has been delivered (together with any necessary licences) to a replacement supplier.
Costs for remedial work
Ensure that the supplier bears the cost for any undelivered or unaccepted requirements that go back into the Product Backlog after a Sprint. This will help incentivise the supplier to ensure it delivers successfully under each Sprint.
Performance targets and delivery
While some developers might argue that it's not in the spirit of an Agile project, customers should set clear performance targets and goals for each Sprint, such as the minimum number of requirements that must be successfully delivered. The contract might also link payments to the achievement of these performance targets (eg, by reducing the instalment to be invoiced at the end of each Sprint on a pro rata basis if the supplier fails to deliver all of the requirements, or withholding a certain percentage of the overall project fee until the project as a whole has been successfully completed).
Compensate for the use of non-technical "user stories" to define the requirements by ensuring that the acceptance criteria applying to each Sprint are described in detail.
Project roles and responsibilities
Ensure that the roles and responsibilities of the project team are clearly defined in the contract. Selection of appropriately skilled personnel (on both sides) will be critical to the success of the Agile approach, and the contract should therefore include a process for determining how the development team and other key personnel will be selected and – in the case of the supplier's personnel – retained for the duration of the project. Customers should also be mindful of creating evidential issues in establishing a warranty claim or protection under the supplier's IP indemnity if the customer's own personnel have had a significant role on the development team.