Trust and shared liability: keystones of agile contracts. Takeaways from the Beltug X-change: 3 May 2018


Agile development needs equally agile contracts. What does this contract approach look like, and how do you go about it? During this session, we found out about the characteristics of agile contracting, and gained insights into the approach in the real world, from Eandis and KU Leuven. Plus, we touched on the question of how to remain agile after signing the contract.


The presentations from the event are available, exclusively for Beltug members (after login):


How agile can you go?


Kim Verlot, ICT Buyer at Eandis, began building her agility and agile contracts experience in 2005. The world of Eandis is a world in motion, both from its customers' perspectives and internally.  That is where the need for agility comes in.


To start off, Kim explained what the term 'agile' does NOT mean: it doesn't equal 'chaos', for instance.  She described the methodology as an umbrella of frame contracts, with an easy philosophy, customer-driven and focused on improvement and learning.


Next, she went over the differences between traditional 'waterfall' projects and 'agile' projects. In the past, projects were started by setting a certain goal, based on elaborate and detailed analyses, cost estimations and plannings.  There were a number of assumptions included, but a clear understanding of what the client wanted and how to realise that.  But moving forward, changes would be requested, and the goal missed – requiring reworking of the analysis and planning.  This created stress and additional costs, and the final result didn't always meet the client's expectations.


Agile projects also start from a clearly defined goal, with plannings and analyses – but in a different way.  Issues that are far down the line are not developed in as much detail.  And it is assumed from the start that changes will be requested, so the scope is delivered gradually, step by step, iteration after iteration.  This means that when changes do occur, the planning and scope can be adapted with much less reworking, and the goal still reached.


In agile contracting, trust is the key word.  You also need a strong relationship with your suppliers for this agile project and involvement from business users and IT operations. Make sure to include the specific project terms and roles in your contract, with a proper definition for each. (See slides 15 and 16 on contracts.)


'Agile' in some ways navigates between Time and Material (T&M) projects on the one hand, and 'fixed price' projects on the other. For Eandis, the responsibility tilts:  the more 'T&M' a project is, the more responsibility the customer has.  With fixed price projects, the supplier has more responsibility, whether shared with Eandis or not. (See slides 20-21 for pricing scenarios and Eandis’ choice.)


To conclude, Kim shared the lessons learned from the agile approach at Eandis:

  • It is key to manage your product backlog from the start - what is your minimal requirement and what is 'surplus'?
  • Work out internal discussions first
  • Work as one team and keep your product owner with the business
  • Have clear agreements for billing, and communicate them to all parties.


Agile contracting: Creating win-win contracts


Bastiaan Bruyndonckx, Partner, Information & Communication Technology at LYDIAN, then took the floor to discuss agile contracting from a more legal angle. We again compared waterfall and agile approaches: waterfall is often a solid yet a long process which gives the customer full control.  The result is clearly defined upfront and is relatively easy to specify in a contract. 

With the agile model, the 'what' element is less important than the 'how' element.  "How will we achieve the product at the end that we had in mind beforehand."  An agile contract also includes who will work at it and what methodology for collaboration will be used. Flexibility often goes hand in hand with uncertainty, which is why agile contracts may be less preferred by legal departments.


For an agile project, set the scene with your product vision and your product backlog.  Don't forget a few essential contract points:


  • Include the product vision in a schedule to the contract (reference point)
  • Develop an initial product backlog (as a schedule to the contract) or specify how to do so (e.g. in a meeting between the product owner and development team)
  • The contract should allow for throw-away development (to allow for change)
  • Read more on slide 7


In agile development, we can see three different roles: the product owner, the scrum master and the development team. (See slide 9 for more details.)  The scrum master can be someone from the customer or the supplier - both can be an option.


Agile is not a 'hippie’ way of working, Bastiaan emphasised, so how do you need to address delivery and pricing in your project and contract?  Define your deliverables at the start of each sprint, he shared. And have your acceptance criteria agreed upon, prior to the start of a sprint. A 'deemed acceptance' system can help make sure the project can continue and that the next sprints aren't jeopardised by discussion on previous sprints.


Bastiaan outlined three challenges in pricing agile projects:

  • It is impossible to define your workload upfront
  • Customers and suppliers have different pricing perspectives
  • The success of the project depends significantly on the involvement of the customer.


For your contract this means a fixed price agreement is difficult to realise.  A hybrid approach may prove a good fit: use T&M to scope your project (creation of user stories, gathering of requirements, etc.), while the Statement of Work (SOW) is divided between T&M (for project management) and fixed fees (for fixed time and resource commitment to complete each sprint).


The classic concepts of warranties, indemnities and liabilities included in waterfall projects are rather difficult to address in an agile contract, not only due to the nature of the agile contract, but also because suppliers find it difficult to pin themselves on these strict responsibilities when the customer is heavily involved in the process. (See slide 20.)


To finish, Bastiaan shared a few elements to consider, regarding the termination clauses in a contract:

  • Customers will want to be able to terminate after each sprint, but will not want to give the supplier this entitlement
  • Standard rights to terminate immediately (e.g. in case of insolvency) should be included
  • The consequences of termination should be set out (e.g. work in progress and compensation)


Don't forget a clause on intellectual property rights (IPR) and a procedure for dispute resolution.


Agile contracting and awareness go hand in hand


The final case on the agenda was KU Leuven.  At this university, agile contracts are often used for research contracts.  A collaboration often can't be set in a fixed contract, explained Ingrid Vanstapel, Legal Counsel at KU Leuven, as it often follows a progressing methodology (see slide 2).


There are several topics that must be covered – at minimum - when preparing for a contract (see slide 5):


  • Who - the initiator will co-sign the agreement
  • What - what you want to do, or what good or service will be delivered
  • Quality - what standards are used
  • Timing - when each milestone must be reached
  • Price - what will be paid for, and how much by when
  • Collaboration - how will it go and how it can be adjusted smoothly
  • Deliberation bodies - how often will deliberations be held and about what
  • Also: academic freedom, liability, intellectual property rights, termination of the collaboration, etc.


Ingrid emphasised that research projects, for example, are always a team effort, with multiple parties, so the liability is shared.


When preparing for an agile project, it is vital to make the proper choice within the 'spectrum of contracts'.  The collaboration doesn't always have to be tied down at the start of the project: a 'Memorandum of Understanding' can already provide a good basis until the real collaboration agreement is ready, complete with SLAs and addenda.


Unlike many waterfall contracts, agile contracts at KU Leuven are true work instruments - not documents that disappears in an archive until someone needs it regarding a dispute.


To achieve success in agile projects, Ingrid concluded, you must apply the principles of agility in the internal organisation: engagement of the supporting services both during and after the contract negotiations, and tuning among the legal advisors and with other supporting services.













Dear visitor,

Access to more information about this topic and/or to download the paper is easy and fast, but exclusively for Beltug members (just login to get access).

Beltug gathers a lot of information. Here you find the advantages of Beltug membership

The Beltug Team

Click here to login

>>> Back to overview