cloudThing works with many SMEs and Enterprise businesses and, as a result of this, we’ve 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 when working on software development projects.
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:
Since cloudThing now works with many SMEs and Enterprise businesses, we’ve 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’ve 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:
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 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 as cloudThing will be happy to share our experience and help you benefit from Agile product development.