This is a guest blog post by Jacopo Romei. Author of the Italian version of the book Extreme Contracts, and author of an upcoming book on the same topic in English.

Simple rules frequently assessed are at the core of Extreme Contracts. In my experience, I observed that a contract filled up with rules won’t necessarily be fairer than a simpler agreement in which we pragmatically and iteratively assess the actual behavior of all the parts. Even more crucial: I am not interested in partners respecting the rules in a dull way as much as I want them to act ethically. In this article, I am going to show a key principle of Extreme Contracts, and a core aspect of Agile in general: Ethics over Rules.

It’s not about the law, it’s about trust

Have you ever thought about the difference between “legal” and “ethical”? To help you a bit, I will honor my Italian roots with an example based on football (some call it soccer ;).

When a football player gets seriously injured during a match, football rules don’t force the opponents to stop from exploiting the temporary one player advantage. Despite this, usually at that point, the ball gets kicked over the sideline to allow for the player to be cared for and give the injured player’s team time to re-organize. Football rules alone then dictate that the game is resumed with a throw-in, but again, despite this, usually the favor is returned, the ball is kicked out on the side one more time and the throw-in is reversed. They call it “fair play” and it’s a set of rules narrower and blurrier at the same time.

As Extreme Contracts practitioners, we care more about those unwritten rules than the rules we can capture in a contract. We reject a collaboration style which starts from nasty negotiations and ends up focusing on enforcing a set of rules instead of addressing the real ever-changing needs of all the parties involved.

There may be many ways to follow the rules and still take advantage of a weaker partner, customer or supplier. Especially in knowledge work, where requirements and the value to deliver can be so hard to grasp, it is very easy to end in a bad collaboration even when playing by the rules.

Let me give you an example in the following story.

A (not so) agile retrospective

I was standing in the meeting room. In front of me ten people: six non-developer employees of a bank and four outsourced IT consultants—three developers and a project manager. The developers and the project manager were from the same supplier. We were deep into an agile retrospective, held after the latest release. We had already listed and clustered all the good and bad things that had happened in the previous iteration, and we were about to dot vote those clusters to select and prioritize the following actions.

On the whiteboard, among many other small clusters, a prominent group of post-its was labeled “deployment”. Seven post-its had been written to raise an issue about the broken deployment process used for the last few releases. The deployment process was labeled buggy, unstable, unreliable and slow. Considering the group in the room, despite the anonymous gathering of the post-its, we could say that at least one person from the supplier company had written a post-it about the quality of the deployment process: seven post-its and six bank employees were enough to tell at least one IT consultant raised the issue about the deployment process.

When an agile retrospective goes wrong…

When I asked all the people in the room to vote which cluster to focus on in the remainder of the retrospective, Elena, the IT project manager, burst out. “This retrospective is broken!”, she said.

“Why?” I asked.

“Because this dot voting is useless. It is biased!”

I exchanged a doubtful glance with the two product owners from the bank.

“We wrote all the post-its anonymously, now the dot voting will be very open, so what bias are you afraid of?”, I asked.

“How can you be sure that everybody will tell the truth?”

I was quite surprised. I hadn’t even considered the chance that someone could lie or might not be interested in investigating the flaws in our workflow. The other people listening to the conversation kept silent.

I tried to reboot the conversation from the basics. “We are using this agile retrospective to improve the way we work as a Whole Team, and I am sure everybody here…”

“It’s stupid!”, she interrupted me. I caught sight of interest on the product owners’ face. “We, from the IT (the outside supplier) will never vote for the deployment issues!”

I was concerned. “Why?”

“Because we will never admit that the most critical issue here is due to us!”

One of the two bank’s product owners looked at me with a smile of entertainment and (uttered) “Gotcha!”, apparently enjoying her win on my argument.

Ethicless is pointless

What had just happened? Let’s review the whole sequence:

1. The team was made of 10 people: 4 business experts, 3 IT developers and an IT project manager.
2. At least some of the outsourced IT people were aware there was some problem with a very technical deployment procedure which they were accountable for.
3. All the team members were given space to let issues emerge and be discussed in a non-blaming atmosphere, focusing on the resolution of the problems and not on trying to pass sentence on someone.
4. The project manager said that they would never propose to focus on improving the deployment procedure because that would mean showing their weakness.
5. As if this was not enough, the bank’s product owner—which would be the first one to be harmed by any loss of quality in the process—somehow took her side, celebrating the “strength” of her argument, and obviously shooting himself in the foot when it came to delivering working software…

So we had a customer—the bank—which had hired a supplier—providing the developers—to have a problem solved and its solution automated via some software. The contract, as too often we observe in IT market, was based on a fixed scope of features. The main consequence for the supplier was that they could simply deliver a collection of features—probably planned months before—to claim their money. The main consequence for the customer was that they had no way to compel the supplier to care about improving the whole collaboration. There was no possibility for any of the parties to go “beyond the contract”, and establish a way of working that would ultimately generate more value!

On top of this, as it showed, the rule-based mindset was so entrenched in the customer’s culture—here represented by its product owner—that they could not see how they were being deceived by their supplier: “yeah, they could be performing less than their full potential, but… they can! Cheers!”

This was too absurd. At that point, I realized that it made no sense to talk about improvement with that team. We carried the retrospective on that day, one way or another, but I quit my collaboration with the bank after a few days, because, for me, it doesn’t make sense to work in a place where rules are more relevant than the most basic ethical principles.

Contracts destroy value in the relationship

The paradox of having a supplier admittedly choosing not to create value and a customer taking their side is possible because of the contract/agreement between those parts. The rules laid down by the contract did not help to improve the quality of the collaboration itself while being only focused on an easy-to-measure KPI—the number of implemented features or the number of person-days worked on the project. No clause in the contract would allow for the customer—the bank— to get rid of a supplier that was overtly trying not to contribute in the most honest way.

Most importantly: if an agreement allows the supplier to deliberately ignore improvements just because “I did my job”… well, how can we even think of working an agile way? If the flaws of the collaboration go unnoticed by the customer who seems even to appreciate how smart the supplier is in betraying their trust… well, how can we even think of pursuing the best possible result?

Agile contracts create value and include ethical principles

Instead of contracts like this, I prefer a frequent re-assessment of what’s right and what’s wrong, which is one of the core values of agile: “customer collaboration”. When it comes to contracts and vendor-buyer relationships, if we allow our collaboration to be re-assessed frequently enough, we can create an ad hoc and ever-changing rule set to address the dynamic and complex challenges that normally happen in business.

In the story above, I would have wanted to get rid of the supplier that was not interested in constantly and deliberately improve the ways we worked together. I would have wanted to make them accountable for their attitude in addition to being accountable for the features they were merely delivering, because at that moment, in that context, their attitude was hindering the chances of success of the project we were working on. The supplier was behaving according to the rules, but unethically!

Ethical behavior goes beyond what is legal. We should care a lot about abiding the law, but that’s not enough: we want collaborations to happen in the narrower space of ethics. We need to favor agreements that allow for continuous validation of the quality of the collaboration.

About Jacopo Romei

Jacopo is an independent strategy consultant, with a strong background in Agile product development.

Jacopo is also an entrepreneur & writer. After having founded a couple of IT companies and practiced agile software development, he started as a full-time freelance agile coach, coaching teams in Italy, Germany and UK.

He has worked with eBay Italia team to set their agile process up. Product ownership and agile UX are added skills acquired in the field.

As a writer, Jacopo published a couple of books on agile coding practices and the Italian version of “Extreme Contracts: knowledge work from negotiation to collaboration“.

Jacopo is a frequent public speaker in international conferences and events about how the way of working is changing in the software industry and organizations management.