Software development projects delivered using 'Agile' methodology (rather than the more traditional approach) are becoming increasingly mainstream.
But have project management and contract structures kept up with this trjaectory?
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.
Agile versus traditional 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:
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 usable 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 an engage collaboratively throughout the project.
Read on for practical tips on making your supplier partnership watertight in an agile environment...
- 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.
