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.
“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.
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.
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:
As we created the actual text, we added
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
(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.
|cookielawinfo-checkbox-advertisement||1 year||Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .|
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
|mailchimp_landing_site||1 month||The cookie is set by MailChimp to record which page the user first visited.|
|CONSENT||2 years||YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.|
|_ga||2 years||The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.|
|_gat_gtag_UA_42152348_1||1 minute||Set by Google to distinguish users.|
|_gcl_au||3 months||Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.|
|_gid||1 day||Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.|
|NID||6 months||NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.|
|test_cookie||15 minutes||The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.|
|VISITOR_INFO1_LIVE||5 months 27 days||A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.|
|YSC||session||YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.|
|yt-remote-connected-devices||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|yt-remote-device-id||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|COMPASS||1 hour||No description|
|cookies.js||session||No description available.|
|S||1 hour||No description available.|