Sourcing For Agile – The Right Way

Introduction

Many years ago, I was a fresh-faced, slightly naïve, and highly optimistic project manager leading a software delivery team, delivering as part of a multi-year waterfall program.  My client counterpart used to keep a copy of the ~90-page contract we were delivering to on his desk, in a big blue binder, the BBB.   The BBB always sat close to him, in arms reach, and usually on top of everything else.  Whenever I swung by for a chat, or discussion on some element of the project, he would often slowly reach for the binder, casually flipping pages, often without even taking his eyes off me while I spoke.  Whether this was a deliberate trick from a war-weary project manager to intimidate his prey, or he genuinely wanted to refresh his memory, for me it summed up one of the key pillars of the agile manifesto: “we value customer collaboration over contract negotiation”.

Today, as agile continues its uptake across Australian businesses, finding the right contract to support and enable agile has remained elusive for many.  For many, old habits die hard: the desire to control through the iron triangle of time, scope and cost leads some to attempt to force fixed price contracts onto suppliers, thus crippling an agile project before it has even begun.   Perhaps in response to this many ICT project managers have let the pendulum swing in the opposite direction, running with pure Time and Materials (T&M) contracts, thereby assuming all risk themselves, and losing incentive for supplier performance.

But does it have to be this way?  Agile principles are based around collaboration and trust, but is collaboration mutually exclusive of a contract?  I don’t believe so, the concept of a contract is in fact an agreement.  In this article I will outline how I look to find the right contract for agile, how it can better set up a project for success, and how the options are far more varied than fixed or T&M.

The problem

It is widely recognised that traditional fixed price contracts are unsuitable for agile delivery.  In 2017 the Australian Government Report of the ICT Procurement Taskforce stated, “It is evident that the way in which government procures ICT is not designed to support agile delivery of digital services meet user needs.”[1]  This is obvious to those working with an agile team, where the principles of innovation, iteration, and an evolving view of the end state are core to the approach.  These key differences mean that the goal of a fixed price contract is to define a ‘thing’ that will be delivered, while a good agile contract will be focused on an outcome.   In other words, the moment you start to define the ‘thing’ in a contract you start limiting the uptake of agile.  Resisting this temptation can be difficult, as can explaining it to that senior executive who just wants to know when ‘the system’ will be delivered!

In leaving fixed price behind, T&M contracts have become a default contract for many agile software delivery projects.  As simple to prepare as a fixed price contract can be complex, a typical T&M will usually have a (non-binding) description of the project outcomes or goal, and at the core will simply define the human resources, rate and volume that is being purchased.

T&M contracts like these are perfect for a number of agile engagements, e.g. where there is a high level of trust and alignment between supplier and customer; for smaller proof-of-concept or project (rather than program) sized engagements; or where risk is lower and rapid engagement is prioritised.

However for large engagements this approach presents risk:  There is no contractual binding of the supplier to the outcome, only to the supply of the resources; no risk is owned by the supplier, and there is a mild disincentive to perform, as the longer the engagement continues the more is paid.  Some will argue that the performance measurement is simply moved from the contract to controls within the project, and to an extent this is true.  However, show me a running race where the prize increases for those who take the longest and tell me it will have no effect on how the runners run…

So as projects scale, how can a project manager better align a contract with the goals of an agile program.   More specifically, how can the contract:

1. Define the outcome(s) that must be achieved
2. Align the project and supplier motivations to enable a collaborative partnership
3. Fix the price without having to fix the scope

Solutions

In experimenting with different approaches as well as researching the efforts of others it is clear there are a number of approaches that sit in the middle ground between fixed price and T&M.  I would rationalise them down to two main groupings, as follows:

1. Shared Risk Approach: Those approaches which seek to align and motivate by sharing the risk between the program and supplier, either through a penalty/incentive payment, or through some form of capping of price based on story points.
2. Incremental Approach: Approaches which seek to break up a program with regular checkpoints to manage performance and progress.  Termination is possible at any checkpoint, along with assessment of mission complete.

In these examples I’m primarily focussed on systems delivery programs, where agile is being applied to the software development cycle, and the supplier is a development and/or testing delivery organisation.

Shared Risk Approach

My favourite amongst these is the shared target model.  In this model, a target price is jointly estimated and agreed between the parties.  If the delivery is completed under target, then both parties equally share the underrun.  Equally if completion is over target then the overrun is also shared.  In this way the risk is shared, but the vendor is also incentivised to complete early (carrot as well as stick!).  In my experience working to implement this model I found that small vendors were nervous to adopt, and a variation to overcome this might be to reflect the proportion of over/underrun based on the relative size of the organisations (e.g. if small supplier to large corporate the weighting might be 20/80 of the over/under).

The disadvantage to this approach is that to successfully work a development firm requires a reasonable understanding of the minimum viable product (MVP), and sufficient detail in the requirements (stories) so that estimation can take place.  This therefore requires an upfront ‘discovery’ phase delivered as T&M to allow the parties to complete their due diligence, itself not a bad thing.

The other variations of the shared risk theme revolve around fixed price per story point, or capping the price per story.  In these models backlogs are converted to price or hours, however the key challenge with this is the need to have established velocity reasonably accurately at the beginning of the project.  This tempts teams to breakdown stories in order to increase accuracy, which is not well aligned with the agile approach.

One note here on capped T&M: Some find the easiest way out is to simply put an upper cap on a T&M engagement as a way of transferring risk to the supplier.  However in my experience the existence of a cap will serve to drive the project towards waterfall tendencies:  Firstly the cap will drive a desire to estimate in detail up front, and secondly will drive the supplier towards enacting change control on any scope variation that risks the cap being breached.

Incremental Approach

The alternative approach is to breakdown the work into increments or packages that are contracted separately.  The way that the work is broken down varies: under the Scaled Agile framework (SAFe) the approach is to breakdown in alignment with program increments (PIs)[2] however epics or time-based increments (e.g. quarterly) could also be used.  The key component here is the focus on defining the outcome, and measuring the result at the end of the increment.  The incentive for performance is supported by the ability to terminate the contract at the end of each increment, thereby motivating the supplier to deliver (something I’m less of a fan of, given it has plenty of penalty but lacks much in the way of reward).

The key benefit here is the ability to scale: by estimating and contracting in increments a project manager can better scale over larger or diverse programs.  It also avoids the temptation to lock down scope at commencement.  On the flipside is the lack of contract for the end-to-end delivery – it leaves a program lead unable to answer the question “how much will it cost”, which takes us back to the heart of the waterfall vs agile approach.

Summary

Setting up an engagement for successful agile software delivery requires thinking about contracts differently.  As I’ve outlined above there are quite a number of approaches, and the right choice will depend on the nature of the delivery that one is considering, particularly size of engagement, clarity of requirements and proportion of solution that is MVP.  In my experience having that up-front conversation with your development firm in an open way, with a goal of defining the outcome, and ensuring both parties are successful is critical, and an important step in building trust and a collaboration culture.  I may still be as optimistic as the version of me that watched the Big Blue Binder be waved in front of me all those years ago, but I’m wise enough to know it’s not the best way.

[1] Report of the ICT Procurement Taskforce, Digital Transformation Agency, 2017

[2] https://www.scaledagileframework.com/agile-contracts/; accessed 10/8/2020