blogs & Things

Contracting Agile Software Product Development For SME’s & Enterprise Organisations

Written by: Nick Churchill-Evans – Sales Director, cloudThing

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:


  • 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’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:


  • 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 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!

More blogs & Things

More blogs & Things

James Crossland in NonProfit

AI + Automation: Reducing Donor Churn & Maintaining Sponsor Interest

Churn management is a vital element of any marketing strategy, and the NonProfit sector is no exception. Knowing what to track and having a joined up view of all your donations data is vital for getting this right, and also opens the door to building innovative data-driven campaigns.   At our recent DataScience and Transformation in Charities […]

James Crossland in NonProfit

Dynamics 365 In NonProfit’s

Charities have unique funding concerns, and an obligation to spend as much as possible on their chosen cause. However, an investment in technology can offer ROI in the form of more than just improved fundraising. Dynamics 365 can help rework complex business processes, ensure compliance with stringent safeguarding and financial regulations, as well as consolidate […]

James Crossland in Tech

8 Ways Your Business Can Increase Turnover With Big Data

Understand how Big Data and Data Science can transform your business…   Big Data is the phrase that’s used to categorise any data that’s too large, complex, cumbersome or complicated to be managed and processed by conventional technology. To put that into a relatable context; being able to recommend your customers content, products or offers based […]

James Crossland in NonProfit

How To Reduce Donor Churn In NonProfits

Reducing Donor Churn doesn’t have to be a big task but does need to be a fundamental part of a NonProfit’s day to day processes   What Is Donor Churn? Donor Churn is the likelihood of an individual stopping their donations to a charitable cause for a variety of different reasons resulting in the non-profit organisation […]

James Crossland in Tech

Agile: Cutting Costs, Improving Quality & Accessing Talent

After using Agile to develop software products for several years, we thought we’d share the challenges we encountered at the start, what we did to change and the results we saw (which were ultimately uplifts in quality and efficiency)…   My development team has been using Agile to develop software product since 2007. Personally, I’ve seen many […]

James Crossland in Tech


What’s the difference between UI and UX?   Simply put UI (or User Interface) are the pages, screens, buttons, icons and any other visual aspects of a website or App that let you interact with it… or to expand on that into the non-virtual world… UI is how you experience using something – For instance in opening a fridge, […]