UK: Agile Contracting - Thinkhouse (Video)

Over the last twenty to thirty years the use of agile software development frameworks and practices have become commonplace. However, the term agile often means different things to different people and approaches to agile contracting in the marketplace remain diverse. To help demystify this tricky topic, we share best practice and highlight some of the pitfalls to look out for when negotiating these contracts.

Transcript

Helen Davenport: Hello everyone. My name is Helen Davenport. I am a commercial litigation partner at Gowling WLG and today we are going to be talking about some issues around Agile contracting that we are frequently asked by clients. I am joined by Matt Harris, a principal associate in our commercial IT and outsourcing team, so today you are going to get the perspective of both a non-contentious lawyer and a litigator as well.

So without further ado, let's get into some of those questions. So what if a customer is thinking about entering into an agile contract Matt, but they have got a fixed budget. What sort of things should they think about I am sure that happens or mitigate the risks arising?

Matt Harris: Thanks Helen. The obvious place to start really is to look at the extent to which the price can be fixed. There are lots of ways to do this for example the customer could be looking at fixed pricing for a particular iteration or development cycle or set of development cycles. They could also be looking at fixing the price for outcomes in the project. So this might be achieving a particular functionality so, for example, the app must do X and you will pay Y for it, but as with any kind of fixed pricing, there is obviously a benefit to the customer but that is likely resisted by a supplier. Some of these activities might be difficult to price up front and will likely meet some kind of supplier resistance or be subject to caveats.

One other tactic for fixed pricing especially in an agile content is to look at whether you can agree a fixed price for the must haves in a project and maybe rely on a time and materials based charging structure for the should haves. That is obviously going to rely on the customer having some strong product management and the product owner having absolute control over the prioritisation of must haves and should haves.

Helen: and it might Matt be possible to fixed price in terms of specific increments in terms of the activity as well.

Matt: Certainly. One of the challenges of agile is perhaps how many increments you are going to need so certainly some room for commercial discussion up front around how many you think you are going to need and what each of them are going to have to achieve.

Helen: And perhaps in a scenario actually the supplier might be resistant to enter into a fixed price at all even for those increments so if you are looking at a time in a materials arrangement what steps can the customer take in that scenario potentially to incentivise the developer?

Matt: Yes the natural inclination to think about time and materials is always in the customer's favour. That is not quite right. You get a continuous workflow. It is less likely that you are going to have stop start conversations around costs and scope but you are not going to be getting the price certainty so how do you control that? Well you as a customer are going to need to be pretty involved with the project to monitor the progress and spend and also rely on your team to help you achieve that so product owner.

You can also be looking at perhaps considering enhanced discovery phases not necessarily to negate the creative nature of an agile development but more to kind of line the parties as to where they are going to be going and get an idea of how many sprints are going to be required and then manage the delivery against that. I mean obviously there is always going to be some incentive for a supplier to be slower and require more sprints, but that is something that maybe perhaps you can manage though other areas of the contract.

Helen: I think for me and that is sort of the range of scenarios where you might get to but for me it is really important that whatever arrangement you reach is really documented and particularly if you are a customer and you think you have got a fixed price for the project then that is actually what is reflected in the documents as it can be a really common area of dispute. Issues for example can arise where the work started before the contract is signed so perhaps the proposal might reflect a fixed price per project arrangement but the draft contract under negotiation does not or says something different so we have seen disputes arising in that situation and seen disputes arise where work has been undertaken under a framework agreement with a number of work packages underneath it and if in that scenario the customer wants fixed price for the project, it is important to make sure that those work packages when taken together as a whole, do achieve that outcome. And also whilst you might have fixed price per project as a starting point obviously as the project progresses there can be a risk that if the parties can try to depart from the key contractual machinery around the pricing arrangements that that can cause ambiguity as well so really important to be clear in the contract and to follow the contract as it continues.

Shall we move on to another one Matt having discussed that one? What if the customer is in the position that they have not documented their requirements yet but within the customer team there is a belief that they can if required? What should they do in an agile contracting scenario?

Matt: Yes I think it is good to hear just to look at what you might see in a waterfall contract which would be a detailed spec up front and then your developer or your project team would be building against that spec but obviously in agile that is not going to be the way you are working. You are going to start with a product vision and rely on the agile process to build a product that meets that vision so the natural thing to do is to look to include at least the statements about product vision hopefully that vision will be established by the time you start talking about contracts so perhaps it should be appended to the actual contract. I mean it is a core document so it certainly has a place there. This is the document or description that is going to help to develop other key artefacts involved in the delivery of an agile project starting off really with the product backlog and moving forward and also having the vision on the table in the negotiation process can help kind of focus the parties' minds and give them some context when negotiating individual provisions.

Helen: So this is area in which I am sort of playing devil's advocate a little bit in terms of agile because obviously for agile, the benefits of the agile in terms of potential outcomes but you are accepting risk in terms of the journey as a customer in terms of what you might get as an outcome and if as a customer you are in a position where you can document your requirements then I would say it is important to think about whether you need to enter into an agile contract of other benefits in that scenario worthy of accepting some of the risks, but it may well depend there in terms of actually what is meant by requirements, what actually can you document.

So let's move on to another one then. So what if as another sort of from the customer perspective, if actually the customer thinks well actually I think getting the supplier to use the agile methodology here is what I need for my project is what would suit us best but actually the customer has got limited resources or experience itself ahead of the project what are some of the risk there Mat and how might a customer try and mitigate those issues.

Matt: Yes so once again it is good to go back and look at what we would be seeing in a waterfall agreement so in this waterfall kind of classic scenario there would be a lot investment up front in designing requirements and specs and then the supplier would be charged with getting on with things and building before testing. It is slightly different in the agile context in that what we are actually engaging here is a long term, well a collaborative and iterative project in which the customer is going to be involved and needs to be involved so therefore there is a need to make sure you have got appropriate resource in place to participate properly and also to be aware of the key pinch points where additional resource might be required so I mean your team is going to be extremely important here as a customer, you are going to need to make sure you have got a strong product owner and also think about whether they are suitably experienced and their qualifications for doing the role because it is likely that suppliers are going to want some commitments around this and also in the contract you are going to be looking at ensuring that they have got their responsibilities well defined primarily to help you retain control of the key processes. And then when it comes into the wider development team, I think the customer has really got to look closely here at the competition of that team and think carefully about who or which side is involved at which points and what their roles and responsibilities are. Certainly from the customer's side they are going to want commitments around the supplier's competence and the members of the team and their competence as well to participate on the project and deliver it properly.

And then also as well one of the kind of key challenges around any development team and commitments of suppliers is ensuring that key members of the team and their knowledge stay with the project for the duration so that is something you want to seek guarantees around in the contract.

Helen: So from what you have said Matt, that really demonstrates that if on the customer side you are concerned about a lack of resource or a lack of expertise, then that could impact on what is being proposed whether actually the agile project will be successful so it is really important to bear that in mind from the outset that you can deliver on those commitments and you have got a strong enough project owner to manage the project. That being said of course what you also talked about was the broader term and certainly I think what we are not saying here is that it is all on the customer side. The key point is that it is balance and from a supplier perspective, it will not want the customer to have full control but it is important that it is a mixed team and the individuals within those teams have clearly set out roles and responsibilities to mitigate the risks arising from it not being clear down the line.

Matt: Yes and also just to add to that as well from the customer's perspective it is also worth being aware as to what you are committing to contractual to what extent the processes that you are signing up to, to what extent are they contractually binding and also thinking in terms of that process which bits should and perhaps which bits should not be contractually binding and having a good awareness of those.

Helen: Exactly. So another question or a frequent challenge that we encounter at the outset is where from a customer perspective again the project needs to be completely by a particular date in the future so in that next scenario, Matt let's talk about some mitigations that we might put into the contract to try and prevent issues arising where there is an important deadline to be met.

Matt: Yes so we have already touched on one of these but probably an enhanced DD phase would be a good place to start making sure that the parties have a good idea of what is required in order to meet that product vision even if it is not to certainly tie the hands of the parties and remove the benefits of the collaborative nature of agile but just to get people kind of broadly aligned as to the map and thinking of how they achieve that vision, but then also it is putting incentives in the contract to incentivise the right behaviour between the parties so one of the ways you could do this as a customer is to look at pricing to incentivise your developer, the obvious one that springs to mind would be perhaps bonuses for completing on time or looking at how the payments are going to be made for the development perhaps withholding payments or linking payments to completion milestones could be one way to do that or even looking at the issues of rates swapping between different rate sets pre and after your milestone for completion.

Helen: So I think those all some really helpful steps and worth bearing in mind in things that could be included from a litigator's perspective the additional point that I would say on this one in terms of where there is a target deadline is that obviously we have talked about these additional risks that agile can bring along the journey, and I do get slightly nervous as a litigator if the timescales are too ambitious or the pressure is such on the supplier to achieve a certain date that will you lose out on some of the benefits that you are engaging in an agile project for on the first place so whilst obviously it is important to document what you want the supplier to achieve and by when. I think it is helpful also if you have got some internal contingency beyond that so that you can react to any issues that do arise along the way.

Our next one is a dispute scenario and of course I have started to touch on issues that can arise along the way and answer to that question but a common dispute scenario we often see is actually at the end of project where the supplier may be waiting for payment of the final invoice but the customer may be feeling well actually I do not think I got everything I wanted to be delivered here and they will be looking at the contractual machinery to see if they can withhold payment of that invoice and that there is the potential for a stalemate and a dispute. So in that scenario Matt what things can we look at to put in place in the contract that might try and mitigate a significant dispute arsing in that scenario?

Matt: I think the key one is that your contract really should be trying to identify when the project is going to be deemed to have been completed typically this is when items in the product backlog have been provided in the definition of done. Obviously as a customer you need to bear in mind that the backlog at the start of the project is not likely to look similar to that one at the end because items will have been completed and they will have been a revisions and re-prioritisations throughout the course of the project and you are hoping at this point as well that the items in that backlog has been tested against the definition of done in the relevant cycles and also to kind of provide clarity here as well, it is probably worth including your definition of done as an appendix to the contracts.

Helen: So clarity over what that definition is and also how that will ultimately be measured and what needs to be done during the lifetime of the contract to be clear on what done is at the end.

Matt: Yes exactly and if things do get to the end obviously and there are issues you are going to be falling back on your dispute resolution mechanism so it is worth taking some time in the contract drafting process to make that that mechanism is robust. It is tiered appropriately and involves the right people at the right stages.

Helen: And on our last issue which is relevant to both parties but can often be something that the supplier has in mind is whether actually it will just be possible to manage change through the change process along the way. What are your thoughts on change in an agile contract Matt?

Matt: Well change in an agile world is not or a change process is not a natural mechanism as agile is supposed to process collaboration over negotiation. There should be a sort of ongoing re-prioritisation tasks and focus through the agile methodology so if you are looking for change it probably suggest you have tried to fix scoping for fixed areas of the project along the way.

Helen: I agree. I practically changed control procedures well where obviously we have got functional and technical specifications are agreed up front so you have got a clear baseline but it is much harder to apply against a higher level set of business requirements that will evolve during performance and from a supplier perspective, the case of De Beers and Atos which is a few years old now but it still acts as a warning in this area because amongst other things, that decision covered the issue where Atos sought additional payments where it considered that the solution ultimately was working on and was delivering was more complex than original envisaged. However the judge in that case rejected most of the claims for those additional monies finding that they were not changes in breadth of the scope but in depth of the scope which was covered in the price so although Atos thought that the change mechanism would be helpful, it was not a means in that case to them recovering most of the additional monies that they were seeking through that route.

Matt: Thanks Helen. That brings the end of our discussion. I hope you found it useful and do get in touch if you have got any questions.