Deep-Dive into the Agile Contract Manifesto (Part 2/4)29-03-2022
Deep-Dive into the Agile Contract Manifesto (Part 4/4)31-03-2022
The Agile Contract Manifesto is a guideline for establishing agile partnerships. It is a simple collection of values and principles that help people and organizations meet their needs for flexibility and responsiveness in the context of a written contract. Why did we choose the values and principles that we did. What do the values and principles really mean? Karsten Eskelund, Mirko Kleiner and I hosted a deep-dive webinar on the Agile Contract Manifesto to explain the thinking of the ACM creators.
This post covers the principles one to five:
- Our highest priority is to create a positive outcome for the ultimate customers and for all contracting parties.
- Collaboration is about more than delivery. The contract is part of the process. Agile collaboration is inclusive, starts before the contract is signed, and extends beyond just the delivery of value.
- Contract, relationship, and governance need to move together. The contract defines the rules of the game. Ensure consistent rules to encourage transparency, integrity, empowerment, autonomy, clarity of purpose, and collaboration.
- A successful partnership learns and adapts throughout the life of the engagement. The challenge of developing governance is creating enough control while enabling effective, results-oriented work.
- Minimize the effort spent on non-value producing work. Ensure effort and time focused on indirect activities are optimized and in proportion to the productive activity.
Principle one: Our highest priority is to create a positive outcome…
I just want to emphasize the positive outcome for all parties. In Agile, we help the companies out there to shift their focus to more customer centricity. But think about also your partners… Do they get to work on a sustainable pace? Do they have sustainable prices and such? I think that’s still in line with all the Agile values we already have in place. Our main goal across companies is to satisfy the customer, the customer or the end user. This should also help to kickstart such a discussion.
We had a big discussion about the term customer. Because from my experience, if we ask the vendors, who is your customer, then they usually point to the people that pay their paycheck. And so that’s something we need to make clear. It’s really the one that flies the rocket, if you will, or if we go back to this example.
I think this is an important course correction to the Agile Manifesto, the original manifesto, because there, you might think that the client Oh, yeah, our main goal is the vendor is to satisfy the client. Okay, and so you get kind of this customer is king mentality. But that’s kind of that can be kind of dysfunctional. Because the client might totally say, be tempted to abuse their power. No, I’ve never met a client who would do that. Giving the overall context here I think is very important.
Principle two: Collaboration is about more than delivery.
The contract is part of the process. Agile collaboration is inclusive, starts before the contract is signed, and extends beyond just the delivery of value
Yeah, this is one that feels close, close to me. I think we have talked a lot about collaboration and partnership already there. And the idea that the collaboration should start also, before the contract is signed, you see this in the Mirko’s work. If you are familiar with his way of doing procurement processes, you will understand what this is about. I think this is an important one, get the agile spirit to start as early as possible.
If I may add, put your focus on the word inclusive. So often the people in delivery or in the business think are these guys from the legal department or compliance or governance, ah, let’s, let’s bypass them that they are terrible, they slow us down. We do the opposite. We invite them from start. And we make it a team effort to co-create the proposals first, but then also the contract. We move away from thinking we have a template, a take it or leave it situation, to a new co-creation. Maybe over time, we will find some templates as starting points. But it’s important that everyone who will be involved in the business are part of that co-creation. That includes people in procurement, in delivery, and even the vendors.
There’s a great story here! The first the first iteration of this text was, “The contract is just part of the process.” The legal people in our team really hated that text, so we had to change it. This is where we realized how important it was that we were an Agile team. We needed to be a cross-functional team to for this to succeed.
Principle three: Contract, relationship and governance need to move together.
The contract defines the rules of the game. Ensure consistent rules to encourage transparency, integrity, empowerment, autonomy, clarity of purpose, and collaboration.
This is also where the principle three started to arise. The contract is part of something bigger. There is the relationship, which is very intangible. And there is the governance, which, depending on the project can be very formal. Somehow all these things need to move together.
We had a lot of different perspectives on governance. Some felt a project needs strong governance; others felt governance just gets in the way. The notion that the contract defines the rules of the game was for me very important.
I discovered the notion of emergence as I was writing Ten Agile Contracts. Emergence is individual things interacting with each other to form bigger entities. How these individuals interact with each other determines the characteristics of our project or company. In the manifesto, we call guidance on the interactions between the parties “the rules of the game.” The right rules of the game encourage behaviors that lead to successful results. The principle includes a short list of such behaviors.
Principle four: A successful partnership learns and adapts throughout the life of the engagement.
The challenge of developing governance is creating enough control while enabling effective, results-oriented work.
I think this this one goes a little bit hand in hand with the previous one. Here, we also talk about developing governance. And the more I think about that, the more I think this is a crucial part. So many contracts I have written, and these so-called administrative processes MSA that the vendor should follow. Ideal or something like that, but the governance does evolve over time. And I think that that is something that is important to take into consideration. You can write down perfect appendix on how the government should look like when you start the agreement. But that is not how it will look like a little bit later. Don’t lie!
Principle five: Minimize the effort spent on non-value producing work.
Ensure effort and time focused on indirect activities are optimized and in proportion to the productive activity.
This is one of my favorite principles. If you think about the non-value-add work that we often spend around contracts… This is not just the first initial creation and negotiation that sometimes might even be seen as non-value-add. But even if the contract is in place, change management escalations, opening a case, penalties and all this stuff… We are not saying that this is not needed. But we are making a big question mark, what is the what’s the outcome for the end customer?
There are other ways that we can minimize risks. One of the main drivers for contracts is reducing the risks for both parties. For example, we successfully introduced a clause for the case when things go really wrong, which still can happen in an agile cooperation, then we said, both parties could stop the collaboration and the partnership at any time, at no costs. You don’t need to do that. But the outcome was interesting to observe because both parties started to care about their relationship.
Next up: Principles six to ten.
Free gift: Transcript: Exploring the Agile Contracts Manifesto
Get the entire transcript mailed to you!