FAQ about the Agile Contracts Manifesto

As we start to share the Agile Contract Manifesto (ACM), I get a lot of questions. Why another manifesto? Who Is it for? What can you use it for? So here it is, the first iteration of the ACM FAQ. Here are the questions I will try to answer.

• Why a manifesto about contracts?
• Who created the ACM?
• How did you create the ACM?
• What is an agile contract? What is a non-agile contract?
• Isn’t agility about software development?
• Contracts by their very nature are binding, so how can a contract be agile?
• Is the ACM another example of “Fake Agile?”
• Why a manifesto and not something else? Like an agreement?
• There are already too many “agile manifesto” clones out there. Couldn’t you have picked a better name?
• Why follow the format of the Manifesto for Agile Software Development?
• How is the ACM different than the original manifesto?
• How did you ensure the ACM would be a manifesto that people will care about?
• Who is the ACM written for?
• Why do you not talk about trust in the ACM?
• How can you use the ACM?
• For which domain is the ACM appropriate? Does it apply to the public sector?
• Is the ACM a template? Is it prescriptive?

Why a manifesto about contracts?

“Modern economies are held together by innumerable contracts.” So writes the Nobel Prize commission explaining their selection for the 2016 Nobel Prize in Economics . Contracts are the mechanism through which organizations make binding commitments to each other. When companies collaborate, they use a contract to memorialize what they have agreed to.

“Agile approaches evolved to manage the risks of solving complex problems with high levels of uncertainty.”

– Agile Contract Manifesto

Today, companies around the world are striving meet the challenges of the modern world, which means they are striving to be more agile. This endeavor does not stop at the company entrance. If collaboration across company boundaries is going be more agile, then contracts need to be more agile.

I think the simple answer is simply, its time has come. There was a need; the initiators put out a call for participation, and a diverse and interested group of professionals from around the world responded.

Who created the ACM?

The ACM project was called into life by Meenakshi Sundaram, Pradeep Lawande, Stijn Follet, and Vivek Sinha. They recruited a group that eventually became 13 people from around the globe (full list). The group was the ultimate agile team: we had the obvious gender and geography forms of diversity, but more importantly we had a diversity of backgrounds. Agilist, Vendor, Client, Legal, Procurement, Small company, Large company. I think this is real secret of our success – that all sides of the table were represented in this conversation. This group was complemented by a “Sounding Board” – our informal network of interested parties who gave us feedback on what we were doing.

Early on we agreed that we are contributing as individuals. The ideas is to keep the results of our work as free of encumbrances as possible.

How did you create the ACM?

Iteratively, collaboratively, and virtually. From June to December, 2021 we met online every other Wednesday morning. We started with team building and created working agreements. Our first batch included:

• We participate in our personal name, not as representatives of a brand.
• We co-create the manifesto: we decide as a team and try to be regular participants in the workshops.
• Most of the work is done asynchronously, workshops are mostly there for connection, celebration, and decision-making.
• What happens in Vegas stays in Vegas
• “Elmo” – the sign for Enough Let’s Move On

As we created the actual text, we added

• There is no ‘your text’ or ‘my text’, there is only our text

We had a lot of discussion about the purpose of this manifesto. We eventually settled on “aligning contracts with agile collaboration.” We brain-wrote ideas on what could be addressed by the manifesto, then consolidated them into themes. We then started to create draft text, then eventually split into two groups that iterated on the text. After a series of iterations and consolidations, we ended up with a text everybody could put their name on.

What is an agile contract? What is a non-agile contract?

An example of a non-agile contract is a fixed-price, fixed-scope agreement. This approach works reasonably well for building roads and runways, where the final result is mostly knowable in advance, but is really challenged where complexity dominates. This is however how most of the procurement world currently functions, which is at least a partial explanation of why project disasters are so common in the public sector, where big projects are formally procured.

An agile collaboration strives to learn and adapt during the course of the collaboration. An agile contract would support that process of learning and adaption.

Isn’t agility about software development?

Yes and no. The original “Manifesto for Agile Software Development” was written by software developers about software development. It identified values and principles associated with successful software development and rejected of many of the management principles that were prevalent at the time.

Today “agile” is applied applied to many terms beyond software, e.g. agile leadership, agile marketing, agile hardware development, etc. Since agile is a adjective, anybody can use it, which makes it difficult to pin down, what is agile and what is not.

Contracts by their very nature are binding, so how can a contract be agile?

Contracts are how high-level, emergent entities like companies and governments are able to make commitments to each other. Much as the values and elements of the original Agile Manifesto were in tension with each other, so are the needs for commitment and flexibility in tension with each other. The ACM doesn’t tell you how to do it, but it does highlight the importance of doing so.

Has agile contracting produced game-changing results?

Absolutely! Some of the values and principles were inspired by NASA’s successes in rethinking procurement for the Commercial Cargo and Commercial Crew programs, which produced better results for the less money than traditional methods, despite the failure of some of their vendors.

Other values and principles were inspired by Lean-Agile Procurement, which has reinvented the Procurement process by building on agile methods. This approach has achieved order-of-magnitude reductions in the time and cost of procurement while achieving better collaborations post-procurement.

Still others are about simply about recognizing and avoiding common failure patterns.

To sum up, the ACM strives to distill into simple, actionable guidance the approaches that have led to better outcomes at lower cost around the world.

Is the ACM another example of “Fake Agile?”

I often encounter skepticism in the community about the use of the word “Agile.” The ACM is not saying, “do agile right.” The ACM is about affirming the importance of uncovering better ways while sharing patterns that have led to better results.

Are the authors of the ACM “doing it right?” This question reminds me of the following exchange from Doctor Who:

Doctor: Am I good man?
Clara: I don’t know, but I think you’re trying, and that’s the important thing.

We’re trying.

Why a manifesto and not something else? Like an agreement?

A manifesto is defined as, “a written statement declaring publicly the intentions, motives, or views of its issuer.” A manifesto is a call to action and a clear statement that something has changed or needs to change.

In our case, I think we shared a belief that 1) the traditional approaches to contracting were not helpful for complex projects, and 2) together, we have enough understanding about what works that we can formulate succinctly.

Could we have called it something other than a manifesto? I don’t think so. When I was recruited, the high-level concept was “an agile manifesto for contracts”. That is exactly what we produced: a public declaration of our views on good contracts.

There are already too many “agile manifesto” clones out there. Couldn’t you have picked a better name?

Yes, we could have used a different name. Would that have been a good idea?

There have been many manifestos since the “original” Agile Manifesto that follow the same form. Some people think, “oh no, yet another manifesto.” But there have always been manifestos, and only a few follow this combination of values and principles. Some have proven more durable than others.

Imitation is the sincerest form of flattery. I think we picked the name because it both expressed our intent and highlighted that we hope this supports the agile movement as it becomes ever more mainstream.

The resonance we are getting in the marketplace tells us that we made the right choice. Using the name Agile Contract Manifesto connects something people know — “Agile” — to a new domain — “Contracts” — and invites leaders and practitioners in that domain to reflect on what it means for them.

P.S. Some of my favorite agile manifesto clones are satires, like the half-arsed agile manifesto and the waterfall manifesto.

Why follow the format of the Manifesto for Agile Software Development?

The original Agile Manifesto is a hugely influential document. It launched a movement and gave it a name. It rejected 20th century forms of organization and pointed the way to more effective alternatives. Out with old and in with the new.

We stayed with this form. While some reservations were expressed, no alternatives were presented. Once we saw the first drafts of what we later published, there was no further discussion on changing the format.

I think this is a good choice. It expresses clearly what we are trying to say and offers a clear contrast to what we are asking people to let go of.

How is the ACM different than the original manifesto?

First, there are many similarities. Like its inspiration, the ACM values learning, collaboration, and purpose, with essentially the same prologue and a first principle that focuses attention on the top priority.

We discussed how the original manifesto had been misunderstood and tried to avoid those pitfalls.

For example, looking at the original manifesto’s first principle, one might conclude that a vendor’s highest priority is make their client happy, but that client is under no obligation to reciprocate. This is surely not what the authors intended, and this attitude could lead to dysfunctional behavior. Therefore, the corresponding ACM principle takes a broader perspective. This is the only point where we have qualified a statement from the original manifesto.

Like the original (at least, as I have understood the authors intent), the ACM strives to be a practitioner’s summary of what usually works well. The language and formatting have been tweaked to avoid shouting (no big, bold letters) and to emphasize the pragmatic nature of our statements.

How did you ensure the ACM would be a manifesto that people will care about?

Ultimately, people will care about the ACM if the topic is important and if it provides useful guidance. To ensure that the ACM is a document worth reading, we had a few constraints:

• No straw-man arguments. The beauty of the original manifesto is that honest people could argue for the things on the right. We wanted to maintain that standard.
• No tribal language. This is not the agile guys telling the legal guys what to do. We tried to avoid language that could cause one group to cheer and another to disengage.
• No appeals to being Agile. As the ACM is striving to define and explain agility in the context of contracts, we wrote down what we really meant using clear language.

Finally, the values and principles are based on experience. For each one, there are stories of actual projects where the value or principle came into question. We are not writing down what we think you should do, but rather distilling what’s worked for us in the past.

Who is the ACM written for?

Everybody. Contracts commit organizations. The whole organization commits to whatever is in the contract. By embracing agility in the contract, the whole organization is embracing agility, from top to bottom.

My hope is that the ACM will inspire closer collaboration between those asking for work, those doing the work, and those governing the work.

Why do you not talk about trust in the ACM?

Some people have asked why we don’t talk about trust or why we don’t talk about the whole organization’s commitment to agility in the ACM. There are surely other things we could have included.

Our process focused on identifying consensus. We did not have a hard limit on the number of values and principles. We considered adding additional sections. As we generated ideas, we focused on those that had strong support. We filtered out things that were redundant or lacked support. It just happened to come out as 4 values plus 10 principles. As a happy side effect, the whole ACM fits on a page, which hopefully will enable people to understand it better.

The ACM is about what’s different in the new approach. Trust is not a recent invention. It has been essential to business since forever. So why include it? Agilists often emphasize trust in their work, and there was concern that it might be considered tribal language. So rather than talk about trust explicitly, the ACM talks about partnership, ownership, and continuity, none of which can be achieved without trust.

Have we forgotten something important? It would not surprise me. Will something emerge in 20 years that we will wish we had written differently? That wouldn’t surprise me either. That uncovering of better ways never stops.

How can you use the ACM?

In my opinion, the ACM is an invitation to think: To think about the goals of your collaboration, to think about the terms you are putting into the contract, and to think about what impact they will likely have on the success of the collaboration. Hopefully the ACM will guide organizations as they design collaboration with their partners. Hear are some ideas on how to use the ACM:

• A checklist to validate that your contract is suitable for the task at hand
• Inspiration to reflect on the level of complexity in your endeavor
• Justification for reducing or removing activities that are counterproductive
• An outline for a retrospective or workshop to improve your collaboration
• Design principles for creating effective collaboration
• Inspiration to reflect on what you really need or really can produce
• A lens to view even internal collaboration more clearly

For which domain is the ACM appropriate? Does it apply to the public sector?

The ACM was created with complex challenges in mind. “Agile approaches evolved to manage the risks of solving complex problems with high levels of uncertainty.” Projects in the public sector are often among the largest, most complex, and therefore riskiest projects attempted anywhere. Where complexity and uncertainty dominate, an agile approach is likely to be more successful, because it is better suited to managing the risks involved.

If your organization has a history of project delays, cost overruns or outright failures, than an agile approach will likely be helpful. The ACM was written to give guidance to organizations like yours.

Is the ACM a template? Is it prescriptive?

No. The ACM is not a template for writing contracts nor does it try to say what you should put into your contract. You can use the ACM as checklist. For each value and principle, how does your proposed agreement address the topic or apply that item? If your engagement is challenged, what pains are you currently experiencing? Identifying divergences between your engagement and the values and principles of the ACM could lead you to the root causes and possible solutions.

Updates

13-Mar-2022 Added:

• What is an agile contract? What is a non-agile contract?
• Isn’t agility about software development?
• Contracts by their very nature are binding, so how can a contract be agile?
• Has agile contracting produced game-changing results?
• Is the ACM another example of “Fake Agile?”
• There are already too many “agile manifesto” clones out there. Couldn’t you have picked a better name?

(c) 2022 Peter Stevens. Licensed under Creative Commons CC BY-NC-ND 3.0
Opinions expressed on this page are my own, not of the ACM Working Group.