Why Your Agile Project Will Fail

If you don’t get your outsourcing agreements right.

Software is eating the world, and if your company is like many a non-tech company, chances are you outsource your software development projects. And chances are that you have or will implement Agile in that context.

Unfortunately, chances also are, that you will fail.

A key reason for that failure is going to be at the very heart of what determines the nature of your relationship with your technology or software development provider: The way companies draft their software development supplier contracts. This has, until recently, often put me at odds with my company’s lawyers.

Firstly, Agile, in its various forms and permutations, came into being as a way to deal with uncertainty. Traditional project management methodologies assumed perfect, or near-perfect planning. They avoided risk by anticipating any eventuality and planned for every such eventuality, which was probably the best way to run the Apollo Space Program, or bring a new drug to market. Unfortunately, not every project has the budget necessary, or would be commercially viable if it followed that approach.

Agile substitutes robustness for planning accuracy and exhaustiveness. Instead of having to predict exactly what will happen, and plan for every eventuality beforehand, Agile focuses on adaptability. A key way to achieve this, is by giving the Product Owner, who usually is on the buy side, a broad mandate to decide on any changes in scope necessary, in order to deliver as much customer value as quickly as possible, shortening time-to-market, and thus enabling that most sought-after of feedback loops, organizational learning.

Now, about those contracts.

Most contracts are drafted in an adversarial setup. The supplier shall, by a certain date, do such and such. Otherwise, penalties ensue.

It is this such and such that is problematic. In most cases, the scope is not very clear at the start of a software development engagement, and either cannot be made clear until midway into the project, or clarifying it would be prohibitively expensive. So, the signatories make assumptions, which are invariably wrong, but end up in the contract anyway, as the binding scope of the project.

As the project progresses, and new information becomes available, the Product Owner will want to exercise his or her mandate to change or re-prioritize things, which by the way, is arguably a Product Owner’s most value-adding function. Then, the supplier’s best course of action is to initially say NO to the Product Owner’s requests. Why? Because the change is out of scope as contractually defined.

This leads to expensive renegotiations and delays, for if the sell side agrees to the change without doing so, it potentially exposes itself to be in breach, because according to the contract, what the Product Owner is asking for actually is out of scope.

The problem is then, that most software development contracts work on outdated assumptions that are the opposite of how most software is actually developed nowadays.

To get around this problem, experienced software development leaders have relied on handshake deals, but this practice doesn’t scale when the value of the contract is high, because lawyers are rightly uncomfortable with such an informal approach.

Relationship Contracts in Practice

Fortunately, I don’t have to upset my company’s lawyers anymore. Research by Nobel Prize-winner Oliver Hart, and others, shows us how to draft legally enforceable Relationship Contracts in which both signatories have a vested interest in the other partner’s success.

First, you lay the foundation to establishing a partnership mentality, by putting together a team of people from both sides, who will have to operate within the terms of the contract, to share their high level aspirations, specific goals and concerns. The objective is to move from just developing a contract, towards building relationships at multiple levels of the organizations.

Second, you co-create a shared vision and objective. This is achieved by explaining the goals, aspirations and concerns in depth, in order to craft the high-level desired outcomes, which then should translate into tactical and measurable objectives.

Third, you write the relationship’s guiding principles. Because there are so many unknowns that will occur after signing the agreement, it is important to have a common view of what the fundamental values and common goals of the agreement are, and of what the basis for dealing with potential misalignments is, with an emphasis to ensure and maintain the fairness of the relationship.

Fourth, you align expectations and interests, by hammering out the deal, with the responsibilities, metrics and prices, in alignment with the guiding principles.

Finally, you need to work to stay aligned. As usual, governance structures are established and embedded in the contract. A key feature of the governance of relationship contracts is the Two-in-a-Box approach, by which each of the governance teams is the co-responsibility of representatives from both signatories. This encourages trust and honesty between the two sides.

Be Involved in the Legal and Contracting Process

If your are like me, and tend to think of yourself as a maker and as a creator, you probably don’t enjoy the process of drafting the legal agreements with your suppliers. And so, you have avoided getting involved in that process, leaving the bulk of the work that, to a large degree, determines the nature of your relationship with your outsourced development team, to the legal and procurement departments.

That would be a mistake. Your hands-on experience in doing the work that the legal agreement intends to govern is crucial to its success, not only during the operational stage, but also when drafting the agreement.

The problem I had, was the lack of a common vocabulary or mental framework with which to discuss with our lawyers, how their drafting of our agreements affected my day-to-day work.

And now, we have found one.

By shifting our focus from immediate first order project deliveries, to higher order, more enduring business and relationship outcomes. Thereby moving us from a transactional contract approach, to one based on relationships.

Article originally published in Medium.