Software Development Runs on Trust

Trust is the bedrock of civilization.

What does trust have to do with software development?

Trust is involved in the smallest details of life. If you approach an intersection with your turn signal on, other drivers trust you're going to turn. When you set your alarm clock, you are trusting the manufacturer to have made a reliable piece of equipment. When you brush your teeth, you are trusting a store to have sold you untainted toothpaste--actually, you're trusting a whole supply chain.

Any activity involving more than one person relies on cooperation, which is a process of working together to the same end. Trust is a prerequisite of cooperation. There has to be confidence that collaborators share the goal, are capable of carrying out their role, can be relied on to do so, and will not take other actions to undermine the enterprise.

What would life be like if you couldn't count on other drivers to share the goal of keeping the roads safe, or on manufacturers to share a goal of trading a product with certain stipulated qualities?

For software development, just think of the team dysfunctions that result when trust isn't there:

• The project sponsor doesn't trust the team to deliver on time, so she micromanages the schedule.
• The developers don't trust the business to value quality work, so they cut corners.
• The project manager doesn't trust the team's estimates, so he pads them by a factor of three.
• The lead developer doesn't trust the rest of the team to produce quality code, so she exhaustively reviews each commit personally.

You can probably think of many more examples. The level of trust on a project has a measurable impact on productivity. Abstractions like "trust" can sound vague and meaningless, but they identify something specific with practical consequences.

However, if people don't trust each other, just decreeing "Let's everybody trust everybody" doesn't resolve matters. Trust can't be wished into existence; it has to be earned and maintained. Individuals may have good reasons to be mistrustful:

• The project sponsor may see a team history of not delivering reliably.
• The developers may have been told by the project sponsor not to spend so much time writing tests and refactoring.
• The variance between estimates and actual delivery time may differ significantly from one story to the next, making it impossible for the project manager to work with a stable velocity.
• The team may spend a lot of its time fixing bugs, resulting in the lead developer feeling the need to take a more supervisory role.

The effects of a lack of trust can often be more obvious than the causes. This can lead to team members harping on the theme: "If only [name of person here] would just trust us!" Without understanding and addressing underlying sources of distrust, the team stays suspended in an unproductive state of hand-wringing.

My next post will look at some ways to re-establish trust within a team where it has eroded.