Trust: The Basic Ingredient for making Agile work

A lot has been written about the pitfalls of Agile, and the “secret ingredients” needed for Agile to work (a high-seniority team, mature engineering practices, frequent communication, psychological safety, a Product Owner included in the team, etc.).

Each of these angles are true, to a certain extent. But I think that they miss (or underestimate) an essential aspect of communication that makes or breaks a good team: trust.

Low-trust contexts are slow

The importance of trust goes beyond what is usually understood as Agile (Scrum, SAFe, etc.), you can observe how trust smooth interactions out in every single relationship or organization. A spouse can sense, almost immediately, that their significant other is upset, mad, or even happy, by just observing their facial expressions for a few seconds. A group of tight-knit friends can coordinate an activity by just exchanging a couple of messages or words. These are everyday examples of high-trust relationships.

On the other hand, we can easily see how the efficiency in communication dips when people move in a low-trust context: applying for a loan at a bank, buying a house, acquiring a software license in a big corporation, passing a law in congress. Every one of these operations are slow, and require a lot of documentation, coordination and auditing to get anything done. The reason why these kind of interactions are so bureaucratic is because all parties involved do not trust each other enough to proceed without sufficient control on their side (for good or bad reasons).

We can draw the same conclusion even if we take people out of the equation. TLS is inherently slower than raw TCP and it requires a significant amount of machinery around it (the concept of PKI exists for a reason). Trust’s direct correlation holds even without humans involved.

Low-trust Agile teams

We can easily apply this framework to agile teams, a common complaint of engineers who work on Agile teams are that Standup meetings, retrospectives, Sprint Demos, etc. are nothing but control mechanisms excercised by managers. In low-trust teams, this complaint is perfectly valid.

From the managerial perspective, what usually happens is that they don’t see the progress that they’d like and they attempt to solve that by increasing communication. But doing so without increasing trust is just adding inefficiency and making the team feel micromanaged, which tanks performance, motivation and commitment.

Even worse is when remarks about tech debt or code quality are disregarded by management, this stems directly from the fact that management does not trust those aspects of software development to be important enough. The lack of trust in something so fundamental to a big portion of the team is a huge demotivator.

The same might happen in the engineering side of things. Low-quality deliverables due to lack of trust in the fact that the POs know what they’re doing, or failing to buy into the mission of whatever software is being built.

It also happens internally in the engineering team, when a tech lead forces code-review to go through a single person because they don’t trust their colleagues enough to be able to review each other’s code. This is just another coordination step that adds inefficiency to the process.

This is also why I don’t believe that a high-seniority team or world-class engineering practices are the silver bullet for making Agile work. I’m sure every engineer can remember at least one project where things seemed to flow even though the team was not that experienced, or they weren’t using the latest tools/practices. You can have the most fanciest tech stack, architecture, proceses and a bunch of seniors on your team, but that is certainly not a guarantee that things are going to go the way you expect them to.

Probably the attribute that comes closest to addressing trust within a team is psychological safety. The thing is focuses on a single aspect of trust: trust that one can express or act without being punished, marginalized or bullied. This is obviously incredily important, but it doesn’t necessarily address all the other faces of trust. Trusting others and being trusted by others.

Lack of trust in delegation

Not all distrust is bad, in many cases (like the bureaucratic examples discussed earlier) it’s something benefitial. Another instance when not trusting is good is when it comes to delegation.

Delegating a task requires control and assurance, at least in the beginning. It is good to followup regularly and thouroughly when a team member is learning to perform a task for the first few times.

That said, if a given individual has demostrated proficiency at a task and they continued to be micro-managed, performance will most likely drop.

Lack of trust in team-building

The same lack of trust is to be expected at early stages of team building (forming, storming, even norming to some degree).

But again, after a certain period of time, continued lack of trust should be viewed as a team dysfunction.

Building trust

So how do we build trust if it’s so important? After dismissing communication for most of the article, I’m going to try to vindicate it now.

Communication is the main tool for building trust, but not communication for communication’s sake (which in low-trust environments most likely leads to it being used for control and assurance). Communication for trust-building must be intentional and assertive.

The intention must be to lift the veil of distrust and expose all parties needs, concerns, obstacles, expectations, limits and goals. When all the real “drivers” of decision/action are on the table is much easier to see, respect and trust others.

This must be done without violence or it will cause the opposite effect, nothing makes a person more defensive than snarky comments, blaming, or bullying (this is where psychological safety comes into play). Non Violent Communication and Getting To Yes are two outstanding books on the subject, that should be required reading for all leadership positions.

Ask that the other parties try to communicate in the same manner, ask questions and listen intently, leading by example is a good way for others to see that you mean what you say and trust that enough to take it seriously.

And finally, follow through and make others follow through. Trust quickly fades away when a person says something and oes the opposite. Action is fundamental to make words worth something.

Final considerations

Trust is extremely hard to build and very easy to destroy, so work with intention, dilligence and intelligence to build it. It’s a long process but most people will respond extremely positively and quickly to these techniques.