The trend towards agile project management poses quite some challenges when such practice has to be framed in the context of a contract with a third party.

All in all, remember that the goal of the contract is still to deliver a working product: get rid of all the waste that diverts the focus from delivering real value!

Let’s take scrum as an example (but most of the considerations below are applicable to the rest of agile methods). At first sight, its rules seem to be at odd with the typical situation of a contracted work where, simply speaking, one party defines what it needs, and the other promises to deliver it for a certain price. To some extent, scrum refuses to define beforehand the complete and detailed definition of what has to be done. Instead, it assumes that the scope of the work emerges fully only through the recursive application of a certain set of rules and habits typical of the specific framework applied. The same rules and habits allow to gradually tackle the work and – by frequently delivering and therefore testing on the field the product increments – to ensure alignment between the planned work and the true needs of the customers.

Now, a typical lawyer would probably snigger at the ingenuous agile practitioner who asks him consultation to devise a contract that can support such a situation as I have described above. He might point out that, although in an ideal world things might happen as agile implies, in practice that is not often the case. Therefore, one has to setup a strong focus in the contract on nailing down the key elements of the prospected endeavour, and clearly defining what is the nominal path of the contract execution and all the possible deviations to it. Eventually, this may influence and distort the execution of the work to the point that agility may remain only a statement of good will rather than an actual practice.

Recently, I found a very good resource – agilecontracts.com – that helped me draft my first agile contract in the context of an early study for an hardware (subsystem) development of a mass spectrometer for space exploration. I definitely recommend going through the full material available on this website to anybody seeking practical advice on how to setup a good agile contractual framework. Not only it provides very practical advise on contracts drafting, but also it introduces quite nicely how to deal effectively with lawyers at all stages of the contractual relationship.

From the first part of the Agile Contracts Primer, I have summarized my takeaways on the topic on the little learning journal that follows, either summarizing my own reflections on the topic or extracting the most relevant statements from the text. I will come back on the topic in the future, with some more practical insight on the topic from my work experience. I look forward to hearing your thoughts on the topic in the post comments! 😉

1. Number one priority shall be the delivery of a successful project, NOT of a successful contract.
2. Successful projects are not ultimately born from contracts, but from relationships based on collaboration, transparency, and trust.
3. Law is usually behind the curve and not ahead of it, because of the very nature of how law develops. Expect to find old contract models reused and adapted to new problems.
4. Agile Manifesto‘s third principle “customer collaboration over contract negotiation” is not a dichotomy. The manifesto goes on saying “while there is value in the items on the right, we value the items on the left more”.
5. Collaboration shall be expressed not only in the contractual language, but also in the behaviour of the parties (including lawyers) during project execution.
6. Beware of contract clauses that are inherently incompatible with agility. For instance, those forcing to define and sign-off all requirements before starting implementation.
7. Astoundingly, surveys have shown that “scope and goals” has not been among the major lawyers concern in contract negotiation. Between 2002 and 2011 “scope and goals” did not make the top 10 of IACCM rankings, but it jumped surprisingly on at the 4th place in 2014, perhaps after somebody made them notice there was something wrong with it. Interestingly, “limitation of liability” has been consistently 1st priority in contract negotiation from 2002 to 2014.
8. As a traditional saying goes: “You have a good contract when both parties are unhappy“. Beware of the lawyer that pronounce it.
9. In case of problems, the parties have the tendency to refer to the contract and work towards local optima: in such case, try to think to the larger impacts of your choices and to be guided by the higher-level goals of the system.
10. Measurements and incentives lead to local optimization. For example, if the legal department is rewarded on the basis of legal outcomes, there may be fewer legal issues (local optimization), but not greater project success (global optimization).
11. If you need to refer to the contract during its execution, that is already a sign of failure.
12. “Time spent on any item of an agenda is invesely proportional to the cost of the item – C.N.Parkinson’s Law of Triviality”; and that’s true as well for the terms that are being discussed in a contract negotiation.
13. The frequent delivery of working product increments dramatically reduces the risk in an agile project, and consequently lowers the pressure on negotiation exhaustingly certain contractual terms (while in a traditional waterfall approach, there is usually a long delay before project deliverables, which injects fear and anxiety in the negotiation).
14. The liability to stop the project at any iteration in an agile project (e.g., 1 month-long sprint) should imply less pressure on clauses of liability and indemnification.
15. An agile project DOES NOT aim at building partial components of the product iteratively, bur rather it aims at building a deployable working model (with gradually more functionality) of value to the customers that can be accepted and used  at each iteration.
16. In a sequential-development project the focus is on gathering all requirements upfront, and articulate every possible case and testing to meet the anticipated requirements. Such upfront requirements risks to be ill-conceived or lack effective engagement with real users, and after the delivery of a system that conforms to the contract, one may still need new requirements to meet the true needs.
17. Contracts that promote or mandate sequential life cycle development increase project risk.
18. Agile principles can protect a client from things they may not know.
19. Agile recognizes that money may be better spent for requirements that were not recognized at the beginning.
20. There are three general areas of concerns when drafting a contract, and an agile approach is generally better at avoiding the problems that lawyers are worried about:
    1. Risk and exposure (liability) > Agile reduces the risk because it limits both the scope of the deliverables and the extent of the payment
    2. Flexibility to allow for change > Agile allows for inevitable change
    3. Clarity regarding obligations, deliverables, and expectations > Agile focuses negotiation on the neglected area of the delivery
21. The ongoing collaboration between customers and supplier required for an agile contract shall be enabled by a contractual construct that facilitates it without the need of frequent involvement of a lawyer.
22. Evidence-based management research shows that incentives lead to dysfunctions such as increased gaming, and reduction of transparency and quality (see for example the great Pfeffer and Sutton book Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-Based Management).
23. Penalties connected to performance variation lead to similar problems than incentives.
24. A successful contract models may be “share the pain  or gain” (whatever form this could take in your specific case).
25. In scrum, definition of done obviates for any deliverable list!
26. Involve, seek feedback, and engage early on the legal professional (as well as all other actors and stakeholders) for a true application of Agile Manifesto’s third principle.
27. All in all, remember that the goal of the contract is still to deliver a working product: get rid of all the waste that diverts the focus from delivering real value!