Picture this: you are building your dream house. A typical knee-jerk reaction when entering into legal arrangements with your construction company would be to outline precisely:

  • What you want to build
  • How you want it to be built
  • When will you be able to move in
  • How much is this going to cost you
  • Will you have a warranty period if anything goes wrong with the house when you move in?

Now, let’s turn the whole scenario on its head. Imagine if the construction company approaches you and proposes that:

  • They will build a house for you without detailed design from the outset
  • The house will be built in 1-2 month stages and you will be responsible for providing updated feedback after each iteration is complete. You can tell them what needs to be done differently and if anything needs to be added in comparison to previous phases
  • You won’t be provided with an estimate for the work, instead of an overall project cost you will be charged per hour and for materials used.
  • You will not be entitled to a warranty afterwards.

Sounds like something from a science fiction movie right?? Let’s skip contesting each-and-every aforementioned assumption on the grounds of fiscal, organisational or legal absurdity. Instead, let’s conclude that not every product or service is likely to use the second approach as it is usually the nature of the particular service which makes it more beneficial for both parties to deliver either the first or second approach.

The first approach is often referred to as the Waterfall method of delivery. The reason it is called the Waterfall method is that each stage follows on from the previous one, creating a waterfall style image. When this approach is applied within software delivery you should follow a distinct set of stages in the project life cycle – e.g. (Requirements, Analysis, Design, Implementation, Testing, Installation and Maintenance).

The second method is known as the Agile development methodology. The aim of this approach is to make a software development unit more responsive to changes given how rapidly the Internet software industry is growing, combined with the thriving mobile application environment. It refers to a collaborative approach to projects, where requirements and solutions evolve through co-operation between customers and development teams.

At Objectivity we believe that delivering software through an Agile methodology is the best way to meet client’s business expectations, even if sometimes those expectations are unknown or vague at the beginning of project. We specialise in Agile development so effectively that you could say we have a Ph.D in using it!

Surprisingly, although in principle the Agile approach is very popular among many corporations that procure IT solutions, sometimes contract negotiations become a war of nerves between: client’s procurement & legal team against sales & legal team of a supplier. Having said which, negotiations of an Agile contract can often reflect a tag-of-war exercise where the one line’s end is marked with a “Waterfall” ribbon against the other end with an “Agile” one.

When a lawyer drafts a Waterfall contract it all looks good and a straight forward process. The supplier’s business analysts have pored over the client’s project description and as a result, the supplier has a defined product that needs to be delivered and a fixed budget that will be spent. An exact time of delivery is agreed and an optimal warranty period following the user acceptance testing phase is negotiated. It’s the perfect scenario for a pragmatic legal shark.

Then project kicks-off to be delivered. However if the client starts testing and discovers that nearly half of the functionalities they desired are useless since the business and commercial background has changed in comparison to what was detailed in the original contact, who would be at fault and who would be responsible for fixing it?

If the problem resulted from a supplier’s ‘defective coding’ (generally speaking) the client would have their warranty to fall back on. However, if the issue is a result of a ‘change of client’s business model or background’, which can often be the case, it wouldn’t be perceived as the supplier’s fault, so the only solution would be for the client to extend their original budget and enter a change request procedure. However this can soon transform into an ongoing vicious circle since the change will undergo the same Waterfall and fixed budget cycle, and so on, and so on..

When a lawyer drafts an Agile contract they have been vaguely briefed with the product that needs to be developed and delivered, without providing a binding and detailed specification from the outset.

Throughout the entire project, the activity will not be perfectly defined nor strictly outlined since both parties will both enter into collaborative stages called ‘sprints’. Generally speaking, the brief is broken down into user stories by analysts that will in turn be created into application software by developers. Testers and users will sign off the application software, so the whole process right down to delivery is broken down into ’bite size’ pieces that are quick to digest – i.e understand, test, rectify and move on.

Within this process situations may still arise where users will make assumptions which are later found to be incorrect or during development, it is found that existing code is not consistent with business users’ expectations. Since the client actively participates in the project’s life cycle by providing feedback on a regualr basis and tests the software after the completion of each sprint, it could be considered unnecessary to provide a warranty period following delivery. Any recoding or “bug fixing” will often be a chargeable activity if the client has had ample opportunity to tailor and test the product.

Simply put: „improvised projects” may be perceived as a nightmare for lawyers, however do the client stakeholders have the same view? Contracts drafting is a very (fr)agile process when it comes to agreeing specific Agile contract provisions. Sometimes it requires the lawyer to look at the whole Agile approach from the client’s perspective, understanding all the pros and cons and addressing them appropriately during negotiations for the benefit of both parties.