Written by
Michał Gajowczyk

Michał Gajowczyk

(Fr)agile way of delivering things – a little insight from a lawyer’s perspective

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.


Share this post on

2 thoughts in Comments

  1. Kamil

    Even Waterfall projects finally switch to loops(sprints), however because the switch is done after deadline, when budget is overspent and time is lost, those are “loops of disappointment”.
    So why not start with loops from the beginning and never disappoint our partners?

  2. Peter B-S

    I can really understand the motivation of players on the client side who try to guard against foul play by the supplier.

    Many clients have been bitten or know colleagues who have suffered with delivery contracts that hurt them badly. The response is often to try and block every pathway that the supplier could try to “game” for their own advantage.

    In my view, this is not the optimum route to solving the problem and an equally serious difficulty can occur: unintended consequences.

    Professionals that haven’t worked with the software development process for many years can often be tempted by measures that seem sensible: In the first instance, they may conclude that lines of code per day would be a good measure of progress. If they think longer, they may move to Story Points per sprint. Longer still and they may get to Function Points per sprint. All of them have unintended consequences and to those who have delivered many projects over longer periods, it’s easy to see how those measures can go wrong.

    Professional competence in the supplier should be a hygiene factor and once in place, trust becomes critical for an outstanding client / supplier partnership.

    If you’re interested to explore our ideas in this area further, please let me know and we can use our Contracting Guidelines as a basis for our conversation.


Leave a Reply

Required fields are marked *

Read next

Ten to rule them all

I could write an article on how to perform well in support, but telling an Administrator how to do things doesn’t tend to turn out well (“When is the Administrator right? Always kid, always”).

However, in this business, sticking to a set of rules sounds like a good survival plan. Let me introduce you to mine, distilled from experience […]

Read more