When it comes to supplier-client relationships, many common complaints like the adding or changing of scope, the availability of business people, or the use of the word ‘estimate’ to somehow implicitly mean ‘promise’ comes back to the conditions created at the very start of the relationship. How contracts are agreed can have consequences for the whole of an engagement.
During our travels for our Agile Around The World study, we spoke to many organisations and Agile practitioners on the subject of contracts. It turned out to be an area that many people were looking for explicit guidance on. We were often asked to give our own advise. With no silver bullet to hand, I instead want to share some of the ways that Agile thinkers and organisations that we met are approaching the subject of ‘Agile contracts’.
By far the most common starting point that we saw was the ‘Time and Materials’ approach. Put simply, the supplier provides a fixed number of people for an agreed length of time. Its then up to the client what these people work on. This is a little closer to Agile thinking than traditional contracts where, rightly or wrongly ‘The Iron Triangle’ has been interpreted to fix scope, time and budget. Though Time and Materials contracts do not require full requirements up front, the temptation can be to put more people on the project when it falls behind, despite how counter-productive this can be as summarised by Brook’s law.
From the supplier’s side, Time and Materials manages the risk of the client changing directions and protecting themselves from the associated additional costs that change would incur. This does mean that the risk, control and management responsibility is all placed on the client while the supplier is secure in the knowledge that they will always get paid, whatever the outcome. This balance has never sat well with me; does it really embody the value of customer collaboration over contract negotiation? There must be another way.
We spoke to Martin Kearns, Scrum Alliance CST and one of the first Certified Coaches in the world. Martin is based in Australia where he gave a talk on ‘contracts to enable Agile behaviour’ at the 1st Conference in 2016. Martin said that Time and Materials is a good starting point. It gets agreement in place to run a few iterations, build trust, understand delivery capability, risks and product viability. For him the ‘principles’ – the desired outcomes – emerge and are not something that can be truly discovered at the start. Discovery workshops are great, however the primary objective is to see behaviours, mindset and to understand risks with project scope emerging later. Chief amongst the concerns is understanding the levels of client engagement and availability.
Those early iterations are run on the basis of a cap on Time and Materials and a realistic outcome. Through negotiation and discovery, what Martin terms “work principles” are evolved. This is a focus on the main variables of complexity and risk, with an escalation process driven by clearly visible metrics. An example of a work principle would be expectations around participation in meetings, with metrics of percentage of people attending that were supposed to, and percentage of those that remained for the entire meeting.
Subjects such as governance and constraints are defined, but at a high, overarching level. Progress is based on building a partnership, and Martin pushes the concept of ‘acts of reciprocity’ where success is shared, but so too are set-backs. Clauses may be added which agree to both sides taking a share of the profits generated from the product. If deliveries are faster than expected, the savings are shared between supplier and client. If there is the need for a change in direction, suppliers are not expected to absorb such costs, but are expected to adapt to a change of plan, while the client accepts later delivery or dropped scope elsewhere.
I also spoke to Tushar Somaiya, an experienced Agile coach currently based in Singapore with Palo IT. He has spoken and written extensively on the subject of Agile contracts, and he talked me through some of the approaches that he has used.
Tushar’s starting position is what he terms ‘The Master Contract Agreement’. Here, only high level terms are considered, such as the people that will be involved. There is no mention of scope nor timelines. Tied to this are one or more ‘Individual Statement of Objective’s (StO) written as user stories to be clear on what it is that the client wants to achieve. Implementation is not discussed at this stage. Instead, 3 months of funding, paid in advance by the client, is started for a Proof of Concept based on breaking down the first StOs. At the end of this period, the client can decide to continue with the development, stop, or find another supplier – it is written into the Master Contract Agreement that the client owns all Intellectual Property rights allowing them to easily go elsewhere.
Should the client wish to continue, then a further list of Epics are produced, and the team gives a first high level estimate expressed as a range, e.g. 8-10 months. This is little more than a guess but it is a point to start from. The client and the team work together to divide the Epics into those that are ‘must have’ and ‘good to have’, breaking them down into smaller stories as understanding grows or new ideas come up. A third classification of ‘cannot be delivered’ serves to make visible scope that is completely unrealistic to achieve. The developing backlog is organised into a User Story Roadmap. User journeys based on personas are defined to help define horizontal slices of functionality on the roadmap.
Both parties commit to a period, say 6 months, with a termination clause, for example either side can terminate giving 1 month notice. Tushar walked me through an example of how payments could be agreed. Every month the client pays a flat rate that is a majority of the ongoing client’s running costs, irrespective of what is delivered. The content of each delivery is reviewed and after, say 3 months, the client pays the outstanding running costs plus a weighted percentage depending on features that are delivered in the ‘must have’ or ‘good to have’ categories, e.g. 20% and 10% respectively. This method focuses suppliers on the most valuable features, and demands more money from the client for doing so. This encourages the client to think hard about pushing an item into the ‘must have’ category. Without this clause, clients tend to label more items as ‘must have’ and pressurise suppliers to deliver them.
Agile relationships should be a partnership, and welcome changing requirements for the client’s competitiveness in the market. Tushar said that the contract should always include a clause for the allowance of supplier review and re-estimation at regular points without punishment, while clients should be allowed to change priorities or requirements.
Things get more complicated when multiple suppliers are involved. Tushar told me about some of the clauses that would be written into the Master Agreement to deal with this. All suppliers must keep the main code branch green and that it is their responsibility to ensure all test suites continue to pass after they have merged their own changes into the shared code base. However, the client has overall responsibility for coordinating and ensuring the right supplier takes responsibility for breakages – suppliers should not lose time or money chasing up issues caused by others. Key to success is identifying integration points and resolving dependencies as early as possible.
Another example of handling contracts in Agile environments comes from Continuum, a Software Development company we visited in Chile. Formal signed contracts are unavoidable with very large clients, including the state where their use is part of the client’s pre-defined processes. For smaller clients, especially those that are located in the same region and thus share similar values, the contract is made up of a non-disclosure agreement and the work proposal. Considering a trait of the culture in this part of the world is long term relationship building over short term gain, Continuum’s approach to contracts suggests they place more value in their reputation and building trust with their clients over agreeing formal terms in a traditional contract.
Written into the work proposal is the acknowledgement that the scope of the project is variable, regardless of the number of proposed sprints, and the final implementation will depend on the prioritisation made during the engagement. The document makes it clear that an Agile method is used and that there is an expectation that a client representative has availability in no-uncertain terms. For example, a dedication to be available for 50% of the time during the initial stages of ideation and prioritisation, with a significant amount of that time spent with Continuum’s UX experts for initial designs. They aim to start development as soon as possible, with first sprints happening in parallel to these workshops. Ongoing client availability is written into the agreement, for example, for one day equivalent per week.
These are just some of the perspectives on the issue of Agile contracts that have emerged separately in different parts of the world. While there are differences in terminology and detail, it is interesting to note the commonalities in the approaches; explicit agreement of client involvement, accepting variability of scope, and building trust the goal ahead of agreeing formal contract wording. These principles certainly fit well with the value of customer collaboration over contract negotiation.
Many thanks to Martin Kearns, Tushar Somaiya and Leo Soto of Continuum for sharing their experiences with us.
—
Further Resources;
Agile contracts Primer by Tom Arbogast, Craig Larman, and Bas Vodde
Flexible contracts by Susan Atkinson and Gabrielle Benefield
Agile Contracts: A Template by Allan Kelly
