Agile methods are now the norm for many design and/or build technology projects.  However, despite this uptake of agile methods for project delivery, most customers continue to contract with suppliers using a traditional (waterfall) mindset, which can result in the benefits of using agile being eroded. 

From a customer’s perspective, the agile process (which is collaborative and iterative) allows the customer to trial ideas and pivot quickly where those ideas are not fit for purpose. It also means that the customer is only billed for work that is done rather than having contingencies built in to the price paid or paying considerable amounts to change scope. On the flip side, and at least from a legal perspective, agile does not give the customer much certainty as to the ultimate outcome of the process, how long it might take to achieve that outcome or the cost involved – a management team’s nightmare.

So, as a customer, how do you embark on an agile process while maintaining control? First, you must be on the same page as the supplier in terms of what “agile” means in the context of your project. Generally, agile refers to a process that, in the case of software development, is based on iterative development where features, functionality and ultimately the solution evolves through the collaboration of self-organising and multi-disciplinary teams. However, there are many different agile methodologies (e.g. SCRUM, Kanban, Lean etc.) and you need to understand which methodology is proposed for your project and be comfortable with how that methodology works. Second, you need your management, project team and project manager to buy in and commit to the agile process you adopt. Finally, you need to contract for the project using an agile mindset (i.e. focussing on the process rather than the outcome). Many customers try to shoehorn an agile project into a traditional (waterfall) development contract. Doing so only results in open ended time and materials arrangements, where the customer has little power and must continue to pay for a substandard service. To avoid this, customers should enter into agile contracts that: (1) detail the relationship framework and the process to be followed in carrying out the project; (2) include performance monitoring; (3) include pricing that reflects iterative development (which can include a fixed price without a fixed scope); and (4) have exit provisions that allow the customer to end the relationship without additional cost.

The benefits of adopting an agile approach is that it aligns the development of the solution with a customer’s actual needs. The trick is to have sufficient protection and control in the contract while not negating the benefits of the agile process.