Part 1: Different approaches to software development
As a ‘nerdy’ techie lawyer, agile software development fascinates me; I love the idea of it. It appeals to my pragmatic side, but I wonder if I can adapt myself to the collaborative and trusting approach it requires?
Maybe it is the recollection of time spent outdoors and the wondrous summer we’ve had, or maybe it is the promise of harvest, but my mind wanders to the garden and our vegetable patch. One proverb in particular springs to mind: ‘A man must put grain in the ground before he can cut the harvest‘.
Why is this relevant? Well, many software developments fail; the more complex they are the more likely they will fail and, in my view, that is because businesses often decide they want a new piece of software/technology to fix a perceived problem without fully understanding what the problem is, whether it needs fixing and, if so, how to fix it. They don’t ‘put grain in the ground’.
Project Failures
But is it realistic to expect such input (grain, if you will) at the outset, as is expected when drafting the technical specifications to a traditional ‘waterfall’ contract? Is a bespoke solution the answer, or is there an alternative which involves less/different stakeholder input?
Often, the real reason software development projects fail is because of a lack of proper customer input (or dialogue with the software developer) from the outset. If a customer is truly involved in the solution, the solution will meet the customer’s requirements. Following failure, contract litigation lawyers for each party confidently turn to the specification/description of the goods or services to assess if the party ‘got what they paid for’, only to discover it is ambiguous or doesn’t adequately explain each party’s expectations.
Putting Grain in the Ground
Agile software development originated as an internal project management method. It provided a flexible intuitive way to work collaboratively with the rest of the business (who ‘invested’ in the solution) and find new solutions. So how does this concept translate from internal project management to contracting parties?
Agile requires trust and collaboration. In a purely agile approach, there isn’t a full plan. It is like Gaudi’s cathedral in Barcelona – we’ve got a rough idea of what it will look like but, until it is finished, we will not be able to fully understand and appreciate the detail.
The agile approach acknowledges from the start that software development is a fluid (ie agile) process. Accordingly, the four key values of the ‘agile manifesto’ are:
1 Individuals and interactions over processes and tools
2 Working software over comprehensive documentation
3 Customer collaboration over contract negotiation
4 Responding to change over following a plan.
It is important to note, however, that the agile manifesto does not ignore the items on the right (eg processes and tools). They have a value, they are just not seen as valuable as the items on the left (eg individuals and interactions).
I sometimes think this point gets lost in translation. Agile does not ignore processes, documentation, contracts or plans and nor, as lawyers/customers/developers, should we.
Agile can be achieved through a contractual framework, but this framework has to be one that recognises the true nature of software development. I suggest the same can be said of all projects for new development, not just software.
Collaboration and Trust
The key thing about an agile approach is that, for it to work, it requires true collaboration and trust between the parties – on both sides.
The customer must be prepared to invest time in the process and the developer (not just the ‘scrum master’) needs to invest effort to ensure it fully understands the customer’s business and ‘vision’ for the output from the (software) development.
Agile works only when the parties have confidence in each other, which can sometimes only be demonstrated through experience. The customer needs to feel confident in the developer. The developer needs to trust the customer and to do this they should have someone within the developer’s team who understands (and promotes) the customer’s view.
The customer needs to have someone who understands the agile process; but they don’t need to be ‘techie’. There does, however, need to be a close relationship between contract negotiation team and agile development/implementation team. To work, this has to be a two-way process – true collaboration.
Agile v Contractual
There is, of course, a tension between the agile approach and the client/lawyer’s desire for clarity and certainty.
As lawyers, we tend to be risk averse and analytical. We like our documents! Our clients (developers and customers alike) want us to minimise (or even exclude) their risk.
But agile (indeed any project involving change) is risky! By its very nature, neither customer nor developer will know what the end result will look like until it has been completed. Advocates of agile will (rightly) point out that this is also the risk of taking the waterfall approach to software development; because the investment required by both parties at the outset is not achieved. Often this is because it is unrealistic to expect such investment at that stage, rather than the waterfall approach being flawed, per se.
So, how can we bridge the gap caused by this apparent tension?
Fixed Price v Fixed Solution?
As mentioned above, the two key elements to any contract are the price and the solution/product/service – what the customer is getting for their money. As such, the agile approach appears unsettling. Why would someone sign up to a contract when the outcome (price and/or solution) is unknown?
But are we really asking a customer and developer to sign up to an open-ended contract with no known outcome (price and/or solution)? On the other hand, does a fixed price solution realistically provide the customer with what they want/need? Has the customer truly invested the grain that will produce the harvest needed?
There are a number of options for software development (and, I would suggest, other projects) depending upon the customer’s needs.
Pure Agile
To use my garden analogy, this is like appointing an expert – a landscaper – to design the customer’s garden and handing over the entire project to that expert. In a pure agile process, the customer pays on a time and materials (T&M) basis and appoints (and trusts) the expert to design the garden. They would have free choice over the content (eg type of fruit, vegetables, water features). The customer might have a price/budget in mind or a specific acreage to cover – they may indicate that they want a place of tranquillity or that it needs to produce food throughout the four seasons of the year – but its input and control would otherwise be limited.
The designer will ask key questions to ascertain what’s most important to the customer – the size of the garden or a preference for fruit over vegetables – and then design something which takes that into account. The customer will see the garden as it develops and can influence future changes, but is paying for the plants and time taken in digging and planting, as it goes along.
They won’t fully appreciate the end result (or know the total cost) until the garden is finished.
Agi-fall
What I term ‘purists’ (developers and customers alike) believe that you either have a waterfall contract (with a fixed solution, fixed price, fixed delivery date) or you have a T&M agile arrangement.
My view is that it is possible to work in an agile manner and still have a fixed price and a fixed solution (and even a fixed end delivery date). My colleagues and I have termed this ‘agi-fall‘. I’m not saying this is new, it’s just what we call it.
The key thing to understand is when we refer to a fixed solution in agi-fall, we mean just that – a solution, not a detailed (waterfall-type) technical specification.
An agi-fall contract is essentially a framework contract setting out the overall ‘Vision’ or solution of the customer, with a series of fixed contracts delivering a number of ‘Stories’ (each element of the vision) and mini-waterfalls (Scope; Plan; Execute; Integrate; Test and Accept) for each iteration and a final acceptance for the entire solution at the end.
In the garden analogy, the customer sets the Vision (a place of tranquillity/fruit allotment). The designer works very closely with the customer to build up a picture of how the garden will look to meet that Vision. By getting feedback at key stages, the customer can see the water feature, smell the herbs, taste the tomatoes and identify any particular colour/plant they dislike. The designer can tweak the design to take into account this feedback and ultimately deliver a garden that meets ‘the Vision’.
This can be done as a T&M contract or for a fixed price – see below.
Waterfall (software development methodology)
This is the traditional contract model approach. In my garden, the customer (perhaps with the help of a modern day Lancelot ‘Capability’ Brown) sits down and draws a sketch of the garden, specifying in precise detail the plants needed, how many, their colour, where they will go, etc. The price is fixed. The garden is built and only at the end does the customer walk around and say whether he/she feels tranquil or if it brings the desired harvest throughout the year.
This approach can work with simple projects delivered in a short time frame and where the customer has properly invested in the solution – ie where they know from the outset exactly what they want to achieve.
Off-the-shelf
I include this option for completeness and because, often, the simplest solution is best. Why reinvent the wheel? Returning to my garden theme, someone else has created a beautiful garden. The customer loves it! They enjoy the sensation of peace and calm that it creates. The customer has a plot of land available on which a copy of this garden can be recreated.
Both parties know exactly what is to be delivered and whether it will meet the customer’s requirements. It comes pre-tested/vetted! This option is also likely to be less expensive than a bespoke solution; the developer can confidently price for the work – they’ve done it many times before and know exactly what is involved, the pitfalls to watch out for, how long it will take (and any contingencies eg risk of overnight frost, slugs or virus).
The only downside is it won’t be unique – in commercial terms, it will not put the customer ahead of the competition, if that is the aim.
Choose the Right Approach
Which of the above approaches is best depends on where the customer and developer relationship sit on the spectrum of attitude to risk (and risk sharing) and partnership (ie their ability to collaborate with, and trust, each other). It also depends on the nature of the solution. Is it important for the customer to steal a march on its competitors or are they simply looking for a solution that’s tried and tested for a back-office function?
This requires an honest assessment from both parties. Can you really accept a garden designed by someone else? Can you (should you) let go of control? Again, be honest – note and reflect on the difference between what we say and what we do. And remember that you need to put grain in the ground to yield a good harvest.
PART II: How to create an agile contract
Let’s now look at how to reflect the agile approach contractually and question whether a new approach is required to all contracts, not just software development.
Fixed Price in an Agi-Fall Contract?
One potentially tricky point is agreeing the price.
A developer may feel more comfortable with a T&M approach (whether hourly or daily rates). This might include an element of ‘slice & price’ – where the developer gives a fixed price for each sprint – at the start of that sprint.
Alternatively, if the customer insists on a ‘fixed price’, something other than time must be delivered – both parties need to be able to clearly define measurable outputs. This is when it gets difficult and it is at this point that a lot of customers, lawyers and developers say ‘it’s too hard‘, ‘let’s just shake hands on it‘ and ‘I’m sure it will be all right in the end‘!
But with the right degree of trust and collaboration on the part of customer and developer, I believe you can have a successful fixed price agi-fall contract.
Defining the Solution
In a Waterfall contract, the parties feel comfortable producing very lengthy business requirements, functional and non-functional specifications (even when they know that there will be a number of Change Control Notes – written or verbal – changing this specification as the true nature of the requirements are discovered).
In an agi-fall or pure agile contract, we don’t (and perhaps shouldn’t) go into that kind of detail but should instead look at a different way to describe the output.
The Solution/Requirements Schedule needs to describe the output, the ‘Vision’ for the customer (eg a place of tranquillity) – some parameters, clearly defined, of what the solution must achieve. Ask ‘what is the problem we are trying to solve?’
The Solution Schedule:
1. shouldn’t be technical;
2. shouldn’t try to explain ‘how’ we are going to solve the problem;
3. should set out what we are going to achieve; not how we are going to achieve it;
4. should set out a clearly understood Solution that is measurable;
5. should form part of the contract from the outset;
Both customer and developer therefore need to invest properly in this – ie collaboration (‘planting the grain’) is needed from the outset.
The beauty of agile is that if you get it wrong (ie you don’t invest or you don’t invest properly) at this stage, it is not too late (or too costly) for either side to put things right.
The agi-fall contract would also contain a framework setting out how the agile software development process would work and what involvement was required from both customer and developer to make it work.
Now we get into the domain of ‘sprints’ and ‘iterations’. The framework (rather than the Solution Schedule) will deal with how sprints work and set out a process to agree what will be in each sprint. Each iteration needs to produce something meaningful/useful; something that contributes to the customer’s Vision (ie the required Solution).
Throughout the agile process, the ‘how’ part of delivering the Solution is refined and detailed. The Solution or Vision does not change. The customer still wants a tranquil garden.
An end delivery date (and key milestones – eg fitting the water feature) can even be set out.
Only if the Vision changes would the price change; and the way agile works, you’ll know very early on if there is a clear understanding of the Vision/Scope/Solution and if it is the right Solution for the customer. This limits costs for developer and customer. In fact, in some cases, if there is a change in Vision early on, the price may not change because the developer can probably re-use what it has learnt later on in the project or on other projects.
Science Fiction?
Sound impossible? Not so. We know of at least one software developer who is doing this already! Their view is that for this to work there has to be trust on both sides; the developer has to take some risk that they’ve understood the requirements/Vision from the outset. There is a recognition that the developer (as much as the customer) has to ‘put some grain in the ground’.
The collaborative approach (and requirement to check and recheck each party’s understanding) demanded by the agile approach means there is less likelihood of work being undertaken that is not used/useful. There is always something for the developer to learn from the process – a piece of software code or know-how developed on one project will probably be useful later (whether on this project or another one).
Besides which, the developer is the expert; it knows what is involved in order to deliver the solution. It is investing, collaborating and trusting too. Fresh thinking, heh?!
Other ‘Contractual’ Issues
One question I can hear the lawyers asking is: What exactly is the developer warranting (or promising to deliver)? My answer: the Solution (or Vision)!
Another issue to consider (which will be reflected in the price) is the risk of the project being suspended or even abandoned part way through. This could be for any reason – as the garden is being built, outside factors may mean the customer is now looking for a place of stimulation not tranquillity.
What happens then? Who owns the software/garden? Can you call in a new developer/designer to finish the job? Do you have to dig up the garden and start again? Do you even own the patch of land in which raspberries have been planted? Have you got to go back to the estate agents as well as the drawing board?
So many questions!
Conclusion
With the right approach and by putting grain in the ground from the outset, it is possible to work in an agile way, have a fixed solution and a fixed price.
Every contract (whether software development or provision of other goods/services) should:
- be realistic and reflect what is going to happen in practice
- be flexible enough to accommodate and deal with change (taking into account the likely duration and nature of the project)
- include a clear scope (but this does not need to/should not be technical)
- be invested in by the right people at both parties
- have a clear way to calculate the price (whether fixed or T&M)
- be truly collaborative.
And the contract should work as a living document. It should not be something that is stuck in a drawer and only looked at when a problem arises. It should be updated to reflect the changing nature of the project and the relationship between the parties as it develops over time.
So, I guess my real question is: shouldn’t all contracts be agile? Now, back to picking those raspberries …
Michelle Sherwood is a Partner and IT Contracts specialist at Shoosmiths LLP.
