Main image
7th February
2022
written by Therese

I have worked in many big companies as a freelancer and as a Scrum Master and one take-away from me has been how often there is mistrust between “the business side” and the “development team”. As a Scrum Master it has been my job to bring the sides together and remind them that we are nothing without each other and hopefully also bring a bit of understanding of all aspects of developing software and doing business with it to all involved.

As a Scrum Master, I have coached or taught many Product Owners and the main lessons have been; Trust the team. Tell them (somewhat clearly) what you need and why and then work with them to get to a good solution. Listen to their concerns – it will help you long term.

I have also had to work with many teams to (re)build trust in the Product Owner – to help them communicate their concerns clearly and help them understand the role and understand why we are not always aligned in our wishes for the product. And hopefully highlight, when the Product Owner listens to the team and help show why the Product Owner makes those product decisions.

What has been true for all the journeys my teams have been through, is that the work has flowed much better with trust and understanding between the people involved.

A trick I use often, is to nudge on the language used. Nudge the Product Owner to always say “we” and the team to include the Product Owner into the “we” that they already have in their head. It is a dirty trick, because it seems like such a small thing, but it has a big effect on the teams self image. Seen over a long period of time, you can really appreciate the difference. No more “us and them”-language. “We” are taking on responsibility for mistakes made and “we” are the actors in the successes achieved.

Talking to all team members, about how we can play different roles with different viewpoints and that these viewpoints needs to be balanced and respected, is key. Maybe a few team members are especially good at remembering the architecture view, the security view, the code quality view, the business view or the user feedback view and all these are important. Probably not equally important, but weighed in a certain way, that is dependent on our situation and that can change over time. We can disagree on the trade-offs we make, but we have to respect that there are trade-offs that have to be made and trust that when we make those decisions, we do it with good intentions and to the best of our knowledge at the time.

There is an excellent way of expressing this trust; The prime directive:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

–Norm Kerth, Project Retrospectives: A Handbook for Team Review

The prime directive is usually mentioned in the context of the retrospective, but they are really words to live by. I say: Hang a poster with it in your workspace and remind everyone about it often. To build software well as a team, we need trust.

2 Comments

  1. 05/02/2022

    I probably should have mentioned the trust equation. Good to consider that when working on building trust.

    It says that:
    Trust = (Credibility+Reliability+Intimacy)/Self-orientation

    If that sounds interesting, read more here:
    https://sketchplanations.com/the-trust-equation

  2. 05/02/2022

    Another thing this makes me think about… I’m not a big fan of metrics but something that would be actionable and reasonable to measure is “How much do different stakeholders agree with the prime directive (with regards to us)?”. Not only would it point to things we can do better in communication and stakeholder care (don’t like the word management), but it would also remind people of a good life rule every time we measured it.

Leave a Reply