Contracting Agile Software Product Development for SMEs and Enterprise OrganisationsNick Churchill-EvansJanuary 25th 2019
cloudThing works with many SMEs and Enterprise businesses and as a result of this, we have been required to provide suitable contracting frameworks to support our delivery process. This has presented us with excellent opportunities in which to create an Agile contract that enshrines a mode of working that is beneficial for cloudThing and our customers...
After working under an Agile development methodology for several years and having evolved a mature set off tools and processes to support it, the one thing that we have really struggled to get right has been a suitable contract framework to support it. In the early days working with Public Sector bodies this was not really a problem. Not because we had otherwise solved it, but because the Public Sector approach to contracting was to tender for Agile development, issue the provider with the OGC model contract as a 'fait accompli' and let their project board work it all out on the job… That contract was the antithesis of Agile so it took quite some working out. We made this work by paying close attention to ‘Change Control’ and then varying the outcomes of the Agile aspects of the project into the contract as we progressed. There were two main problems with this however;
- It demands close attention to vary trivial items in and out of scope, creating additional, inefficient layers of overhead for provider and client alike
- It causes issues with payment milestones for both parties as deliverables tend to move around a project. For the client invoicing can trigger too early, causing cash flow surprises; for the provider invoicing milestones can trigger too late, causing cash flow challenges
Since cloudThing now works with many SMEs and Enterprise businesses, we have been required to provide suitable contracting frameworks to support our delivery process. This has presented us with an excellent opportunity to create an Agile contract that enshrines a mode of working that is beneficial for cloudThing and our customers. Over the last three years we have had three different drafts of our Agile contract. The first iteration took a relatively standard software development contract and evolved it to include a mechanism to support changes under Agile, the focus being to negate the need for Change Control where the overall effort required to complete the project did not change. This worked relatively well but we omitted to include a means to deal with the payment milestone problem I eluded to earlier. The second iteration corrected some broader frustrations in the earlier version but also added a mechanism for managing payments.
In spite of our efforts to the contrary, our ‘Agile Contract’ was not as supportive as it could be. Whilst this was not a particular problem during the pragmatic ebb and flow of a development project, it was certainly felt during contractual negotiations and had the capacity to bite somebody if a project ran into difficulty. When we reviewed it against the actual way in which we governed our development programmes and the way our customers liked to work, most of the issues appeared to be a result of mixing the Agile approach with the bones of the standard template. So, we finally took the plunge and redeveloped the contract from scratch. Enter version three…
Version three is refreshing to work with, if a contract can ever be described as such! That said, whilst we have used some contract iterations that were suboptimal, it is fair to say that we needed to go through the process of living and breathing those versions to be able to learn enough to draft a suitable template. This refers not only to learning on the part of cloudThing’s commercial staff but for our firm of solicitors also. The result is an uncomplicated, equitable and comprehensive contract that works on some key mechanics. This redeveloped version has been used to run seven significant developments over the last nine months. In each instance it has been easy to negotiate, has required little change through negotiation and has provided a helpful reference on the odd occasion when neither cloudThing nor the customer were 100% sure how to enact or consider a key point during a development project, and required a glance at the contract to answer a shared question.
So what are the key components of a supportive Agile contract? In no particular order and picking a few highlights that we are using:
- Baseline, baseline & baseline: In other words; baseline requirements; baseline the solution and baseline the effort points for each requirement or story. This provides the foundation from which to work ‘on project’. Capture these in the contract schedules
- Include a mechanism in your contract to allow requirements to be swapped in and out of scope whereby, so long as the overall points for the project do are within a +/- tolerance percentage of the baseline, changes can be made by designated project staff
- To govern activity, deliverables and billing, use a suitable Agile project management tool to capture the baseline deliverables and allows the team to manipulate / track them as they progress, marking requirements/stories as complete/delivered at appropriate intervals
- Include a point to pounds billing regime to allow periodic invoicing to be calculated by delivered points (on a monthly basis for example). This allows deliverables to be moved around without penalising the provider, whilst simultaneously tracking cash burn and giving the client tangible project deliverables that then can see and sign off.
- Include Change Control provision, but reserve it for major changes that breach the tolerance threshold noted above
- Include a top level project governance approach to wrap around Agile, to ensure that the project is not left exclusively to the day to day project team. We use a lightweight PRINCE2 wrapper to convene and report to a project board made up of senior staff from provider and client, this body having ultimate responsibility for the project outcomes.
- Include a robust ‘definition of done’ in the contract to ensure that tasks marked by the project team as completed have gone through the appropriate quality checks to give all parties confidence that when a feature is done, it really is done.
This is a dry subject so if you’ve read this far… well done! However, if you persist and embrace Agile, it will pay you back quickly and generously. The world has woken up to the benefit of Agile development for internal products and is waking up to the benefits of procuring / supplying Agile development for software outsource/co-source. In the case of the latter of these, outsource/co-source, cloudThing’s experience it can be daunting for both client and provider to make the leap but when it is done well the benefits far outweigh the risks and cultural difficulties it presents. Over the last ten years cloudThing’s management team has delivered over £100m of projects with Waterfall in in 2005/2006 and Agile from 2007 onwards. The difference in outcome and benefits is akin to a night and day experience. Moving from a mature Waterfall methodology to our first Agile project yielded in excess of 30% efficiency benefits – mainly as a result of efficiency and quality gains produced by working with Continuous Integration under an Agile approach. More importantly staff satisfaction made similar gains. The customer satisfaction improvements were also interesting: Whilst customers had previously been generally very satisfied and improvements were therefore modest, the outcome of their downstream user surveys made marked gains. Agile has allowed us to collaboratively deliver better software product for our customer’s customers. Everybody has won and we simply wouldn’t go back!
If you’re interested in learning more please get in touch and I would be happy to share our experience and help you benefit from Agile product development.