We have previously discussed agile contracting in a series of articles (here and here) touching on the basics of contracting for an agile IT project and examining this in greater detail from a customer’s perspective. However, there are occasions when it is not appropriate to use a pure agile approach for a project, and the project may be better served by using a hybrid agile approach that combines elements of agile methodology with some of the restrictions of a traditional waterfall contract. In this article, we will examine how you can implement a hybrid agile methodology and what the risks are in taking such an approach.
At a high level, contracts for IT projects consist of three different pillars that bind every agreement: the scope, the schedule, and the budget. Agile methodology is defined by not restricting any of these pillars, whereas waterfall methodology places restrictions on all three pillars. A hybrid agile approach means using elements of agile methodology while placing restrictions on one or more of these pillars. However, there are risks and benefits associated with adopting this approach and the specific risks and benefits depends on which pillar or pillars you are restricting.
In essence, the point of a hybrid agile methodology is to shift some of the liability for the project from the customer to the developer. By restricting one of the pillars of a contract, the customer makes the developer liable for that pillar instead of taking on all the liability themselves. This is beneficial but can come with risks, explained in more detail below, that can undermine any benefit received by a party if not accounted for.
Restricting scope
Scope is, in many ways, the central pillar of any project as it describes what it is the project is going to do. Restricting the scope of a project in a hybrid agile context means limiting the functionality that can be developed. This can be done in two ways.
The first is to adopt the approach to definition of scope used in a waterfall project and have a strict list of functionalities that need to be developed. However, if you are sufficiently clear on project scope, then it is arguably better to use a traditional waterfall contract and just replace the waterfall process with iterative sprints.
The second method is to adopt the MoSCoW method. MoSCoW stands for Must-Have, Should-Have, Could-Have, and Won’t-Have, and is a method used to prioritise functionality during a project. Using the MoSCoW method allows you to identify key functionality that must be developed in order for the project to succeed, while still allowing additional functionality to be developed if the budget and schedule will allow for it. In an agile context, MoSCoW can be even more flexible as additional functionality can be added and characterised during the development process. You could argue that MoSCoW is functionally no different from a well-managed product backlog, but it does reduce the risk in mismanaging the product backlog as priorities can be set at the start of the project. This method is ideal for projects where some scope or requirements are set, and other requirements are uncertain.
Restricting scope by itself does not eliminate all risk associated with adopting an agile project methodology, but it is best suited for mission critical developments where certain requirements are set in stone or when paired with restrictions on budget or schedule. Restricting scope by itself does not alleviate the risks of a project costing too much or going for too long, although these risks can be controlled with a right to terminate for convenience.
There is a further issue around enforcing a restricted scope without restricting other pillars. This is because it would be hard to demonstrate that this obligation is breached if there is no time restriction, as the developer could simply say they will meet the required scope at some point in the future.
Restricting budget
Restricting budget in a hybrid agile context means either putting a fixed fee or a fee cap in place. This is highly beneficial for a customer in all situations, but realistically is better suited to low priority projects which may have limited business outcomes.
Restricting just the budget raises the risk of a project not being completed because the developer runs out of money, being completed poorly because the developer only wants to get sign off so they can be paid, or being either rushed or taking too long depending on the method used to fix the fee. This may be acceptable in some circumstances. For example, if you were to combine time and materials rates with a cap pricing method then it is likely that the developer will use less resources to maximise profitability. This will extend the schedule of the project, but that may be acceptable for projects that are not time sensitive or mission critical.
Restricting the budget is a useful tool for the customer but comes with a practical risk that the developer will run out of money to pay for the required resources and may even become insolvent. In these circumstances there would be substantial pressure for the customer to increase the budget for the project.
Restricting schedule
Restricting schedule in a hybrid agile context means limiting the number of sprints that are performed. This is ideally suited to projects that are time sensitive or as a method of controlling cost without directly controlling the budget.
The risk with restricting the schedule of a project depends on what other pillars, if any, you have fixed. If you have only restricted the schedule, then there is no guarantee that the work will be completed or that the costs will be low as these pillars are unrestricted. This may be appropriate in certain circumstances as you may have a time sensitive project that needs to be completed despite the potential for cost overruns, in which case restricting the scope and allowing the contractor to increase the resources they are using may be the preferred solution.
Restricting the schedule may place liability onto the developer if the project is not completed. However, this may not be overly helpful if the parties contractually exclude liability for consequential loss, in which case the customer may only be able to recoup part of the money spent on the project. This could lead to a long and complicated process to recoup money that would not match the loss associated with the project not being completed and an alternative solution needing to be found and implemented. This risk could be mitigated by introducing liquidated damages.
Next steps
Hybrid agile methodologies are a good intermediary step for a business to take on its journey to becoming agile and may be ideal to some situations. However, you should carefully consider what the risks are when contracting for a hybrid agile approach and which approach best suits your specific situation.
HWL Ebsworth’s IP and IT team has extensive experience in advising businesses regarding arrangements for development, licensing and support of on-prem and cloud software, IT procurement and contracting in the IT industry. If you are concerned about contracting for an agile project, please contact us for further information on how we can assist you.
This article was written by Luke Dale, Partner, Daniel Kiley, Partner, Nikki Macor Heath, Special Counsel, and Max Soulsby, Solicitor.
