Trust In An Agile Context
Prefer to watch this as a video? Click here.
There’s a part of the Agile Manifesto that I’ve long had trouble with, and it’s principle five, the part that says:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
It all seems very straightforward, and is a bit ‘motherhood and apple pie’ in a way. That said, I’m sure we’ve all experienced at least once project built around unmotivated individuals who were not given them the support and environment they need. As obvious as the recommendations are, they’re worth specifying clearly.
However, it’s the ‘trust them to get the job done’ part that I’ve found the most difficult to work with over the years. You can see where it comes from. If you’re a software developer, working in an industry that’s not been around all that long, in an environment that’s unpredictable and changing all the time, with people who know far less than you do about building software, you’ll want people to trust that you know what you’re doing.
People mean well, but unpredictable environments that are still being explored are really prone to the Dunning-Kruger effect, the idea that the less you know, the more confident you are about your opinions. If you’re working in a fast-paced, complex and uncertain environment, it’s likely the Dunning-Kruger effect will be running rampant across all sorts of people. So these people will start to suggest all sorts of well meaning but unfeasible things, and even insist that they must be done, even when doing them has a really poor cost / value ratio, or is even impossible.
In these sort of instances, it’s important to trust your developers, or anyone who knows more than you do about something.
There’s also the social effects of not trusting people. I’ve always found trust repays trust, and if you act in a trusting way towards someone, they’ll trust you more in return. Communications between you will improve, the amount of collaboration will go up, and everyone wins. The more you try to micro-manage people, assert your authority over them, or make them follow your opinion even when they know it’s wrong, the worse your outcomes will be.
So far, so good. Trust people to get the job done, and they very likely will.
The part I’ve struggled with though is when I try to trust people, but they don’t act in a way I find trustworthy. When you’re product owning a piece of software, but know far less about the technical details of the build than the developers do, the developers effectively have immense power. The same is true if you’re commissioning an external agency to do some work for you, and they say it’s going to take far longer than you think it should and cost far more. You need to trust them, but it feels difficult. Sometimes people just straight up act in an untrustworthy way. I once freelance Scrum Mastered a project where one morning the developer told me they were just going to spend the day doing their personal tax return, but still bill the company for a day of work. How was I meant to trust that person after that?
I think the answer to this all comes down to the meaning of the word trust. The Internet seems to define the word as:
“The belief in the reliability, truth, or ability of someone or something”.
Which is interesting. Trusting someone doesn’t mean they are reliable, truthful or able, it means that you believe that they are. Once you take this definition of the word trust, then it becomes something that takes two people to be true, the person doing the trusting and the person being trusted.
This may sound obvious, but I think there’s an important point here. If you trust someone all the time, regardless of how their actions affect your belief in their reliability, truthfulness or ability, then you’re actually breaking the spirit of the third part of the Agile Manifesto; ‘collaboration over contract negotiation’.
If you always trust someone, no matter what they do or how they act, then you’re effectively making that trust a matter of contract. It becomes a contractual requirement between each of you that you trust them, and you have to stick to that contract no matter what. What you should actually be doing is making that trust a matter of collaboration. Your default position should be to trust people, and you must never slip into not trusting people as your default position. However, if someone acts in a way that makes it difficult for you to trust them, then you should raise that with them.
Trust is a collaborative thing, a trust that’s assumed as a requirement of agile working will never be as strong or as useful as a trust that’s developed through working together and proving to each other than you are reliable, truthful and able.
On top of this, a big part of collaboration, and the servant leadership that agile recommends, is helping others to develop, serving others and helping them get better every day. In this context, if someone acts in a way that reduces the trust you have in them, it’s your responsibility to bring this up with them, understand whether your interpretation of how they acted is correct, and if it was, help them not to do it again.
Trusting someone is about believing that they’re reliable, truthful and able. As much as your default position in agile should always be to assume that people are trustworthy, it should never be about acting like they are reliable, truthful and able when they clearly are not. If they are not though, then it’s your responsibility to help them become moreso, to help rebuild and reinforce the trust between you.
It’s just as bad to act like someone is not capable of being trusted as it is to act in an untrustworthy manner.