Trust and control - friends or foes?

By Mathias Fuchs

 

Two weeks ago, I was planning to write a post on the subject of "trust". For two main reasons:

  1. "Trust is a central element of all agile approaches and therefore also of agile validation."
  2. Secondly, "trust" is one of the terms that is currently being used almost excessively in the context of implementing agile methods. (I'm sure you've read dozens of articles like: "Command & control was yesterday, trust-based collaboration is the future".

So I sat down and started to sort out my thoughts on the subject. The result astounded me. This word, which is often used quickly and lightly - and I am not excluding myself here - has an incredible depth and impact on very different aspects, both in private and professional life. It's impossible to go into it even remotely enough in a small post. When I thought about it, I came up with questions like:

  • What does the term "trust" actually mean to me?
  • Who do I trust and to what extent, both privately and professionally (are there differences?)?
  • As a Scrum Master, can I demand trust in a team?
  • How do I get a team to trust each other?
  • Who takes the leap of faith and when, and what impact does this have?
  • By consistently trusting, I make myself vulnerable. Is everyone aware of this and how is it dealt with in the team?
  • Is control the death of trust, or the beginning?

Whew! Far too many different topics. I decided to think a little more about the two terms trust and control for myself. For me personally, without researching the literature, without scientific backing.

Let's take the example of Scrum: the word trust appears exactly once in the Scrum Guide. In the Scrum Values section. Remember, the values that Scrum propagates are:

Commitment, Focus, Openness, Respect, and Courage, i.e. self-commitment, focus, respect and courage

The Scrum guidelines state:

"Scrum team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum team and the people they work with, the empirical Scrum pillars of transparency, control and alignment come alive and build trust."

That's it. Sounds good. But what does the reality look like? Especially if the sprint goals are not achieved or the estimates in the sprint planning were once again very optimistic and only some of the stories were completed? - This is supposed to happen in times of Scrum teams that mostly work remotely 🙂

Then I keep catching myself feeling the seeds of mistrust starting to sprout: Did everyone really do their best? One can only guess what the PO, who is supposed to maximize the product value, is thinking. Now it becomes critical, because as soon as this seed starts to sprout, trust is actually long gone. And this germ is quite resistant. It still germinates years later and grows quite quickly.

For me, the whole thing also has something to do with mutual expectations: If I'm not sure that a team member is doing their best, the question quickly arises: What does he/she actually do all day? I could have done it much faster. And that is precisely the wrong question for me. It's more about a specific team with specific skills and experience finding the optimum delivery speed (velocity) for that team. And ideally to increase this over time through process optimization. And not to forget: Velocity is the speed that they can maintain over the long term, regardless of any initial project milestones that were defined at a very early stage of the empirical development process and are typically never adjusted 🙂 .

Back to trust: In my opinion, real trust can only be achieved through the introduction of control mechanisms. But not only through externally imposed controls (sprint burndowns, dailies, sprint reviews), but above all through the introduction of controls that come from within, from the team itself. Ask the question in the Daily: Were you all satisfied with what you did yesterday? If the answer is (hopefully): "No, I wasn't in a good mood yesterday and messed around. I'm not satisfied", then I think you've already taken a good step towards sustainable, trusting teamwork.

Control, or rather self-control, is therefore not the enemy of trust, but a basic prerequisite for trust to exist in the long term.

This is true in many areas, but especially when many different skills work together, such as in agile validation, where business, IT and QA work together on a validated product.

What do you think about it? I am curious.

If you would like to know more about our agile validation approach, please contact us: