As a reader of my newsletter, you know how I highlight the importance of trust. I have written many articles about this topic. Organizations may use all the bells and whistles of the latest and greatest approaches to create wonderful products. But, if trust is lacking, organizations will not get the best out of their potential.
To show this in a slightly different way, I will highlight 10 elements of Scrum that will fail without trust. By the end of the article, I hope you have gained a better understanding of why it is not about following the Scrum rules by the book. It is about working with Scrum on the foundations of trust.
1. Empiricism
Empiricism is a fundamental element of Scrum. It has the pillars of Transparency, Inspection and Adaptation. Here’s how empiricism suffers from an absence of trust:
Transparency will be insufficient. People will not want to show things that could harm them or their team. They may not mention a delay in progress or unexpected negative feedback from the users. Their stakeholders may also want to paint a rosier picture of how they view the product the team created. People are incentivized to paint a rosy picture.
With incomplete Transparency, Inspection will be harmed because people may not view all important factors to form an opinion. They will base their conclusion on incomplete or incorrect information.
Based upon a broken Inspection, Adaptation will be subpar because teams will not make the correct course corrections. On top of that, teams may not feel empowered to change course without approval from someone higher up the ranks.
2. Scrum Values
Scrum has the Scrum Values of Commitment, Focus, Openness, Respect, and Courage. According to the creators of Scrum, these values are essential to working as a Scrum Team and their stakeholders.
I think it is easy to see how three of the 5 Scrum Values are heavily impacted by a lack of trust. How can you be courageous in an environment where trust is lacking? Few people will be courageous when their job is in danger. The same can be said about Openness. A lack of trust is already showing signs of Disrespect.
3. Scrum Team cohesion
The Scrum Team should be a cohesive unit of professionals. Cohesion is important to collaborate and commit to their goals. When trust is fading, teams will disintegrate instead. You should expect sub-teams, a lack of collaboration and opposing goals. The Scrum Team will be a team in name only. A group of individuals that doesn’t trust their teammates to work together.
4. Product Owner owns Value Maximization
The Product Owner decides what is in the Product Backlog and how it is ordered. They determine the Product Goal and what should be a top priority for the Scrum Team. The Product Owner decides the WHAT and the Developers the HOW.
When the organization doesn’t trust the Product Owner, others may step in, to call the shots. This will disrupt the cohesion of the team. It will also complicate empiricism. Scrum Teams work closely together to learn from what they created so they can build upon that. People outside of the team most probably don’t have these insights.
When people outside of the team are going to overrule the Product Owner because of a lack of trust, they will partly or largely ignore the learnings, allowing politics - and not the learnings - to rule the prioritization.
5. Developers own the How
The Developers determine how they create a product Increment and they plan their work. They decide how they will reach the Sprint Goal. After all, their work is complex and they will learn how to reach the Sprint Goal during the Sprint. After all, a Sprint is not about finishing all selected items as planned. It is to achieve a goal and they will gradually learn how.
When people don’t trust the Developers to find the best way to achieve the Scrum Team’s goals, they may interfere with the way the Developers build the product. They may enforce tooling and protocols that don’t suit the Developers at all and make it more difficult to reach their goals.
Without proper trust in the skills and knowledge of the Developers, they will have a hard time being flexible and adapting based on their learnings working in the Sprint.
6. Sprint Length
The length of the Sprint is highly contextual. Depending on the complexity of the product and the product environment, this can vary from shorter than a week to a month. The Scrum Team has the best view on a good Sprint length.
But, when trust is lacking, teams may be allowed to determine the length of their Sprint. They then need to conform to organizational standards, often to control them and check if they produce as consistently as the other teams.
7. Sprint Goal
The Sprint Goal is instrumental in managing complexity. In complex environments, the Scrum Team may not exactly know how to build the next increment. They may have a rough idea but need to work it out during the Sprint. So they determine what they wish to achieve and formulate a Sprint Goal. This Sprint Goal guides the Developers to maximize the chances of being successful.
But in an environment of mistrust, teams may need to show their productivity in a different way. They need to show they can finish all planned items and also achieve a predetermined velocity. The organization doesn’t trust the team to focus on outcomes and value, so they need to focus on activities and outputs instead. With this, product creation is reduced to working at a conveyor belt, churning out features.
8. Definition of Done
Scrum Teams aim to maximize the work not done, which is an important Agile principle. Simplicity should be paramount. It is all about reaching the goal, not about adding fancy stuff no one might need.
The same is true for organizationally imposed approval steps and other kinds of procedures to jump through hoops. Sure, it is important to create and deliver quality products that don’t break production. However, organizations that trust their developers will work with them to find efficient ways to meet the quality and security needs.
But in an environment of mistrust, where Scrum Teams have no say in the matter, chances are that the hoops will only be more difficult to jump through. All of this makes it all the more difficult to get an Increment to the status “Done”.
9. Sprint Review
The Sprint Review is the event to collaborate with the stakeholders. They reflect on what the team has created and what they learned. Stakeholders will also share their insights which can impact the decision of what to do next.
Without trust, stakeholders will not show up as they don’t see how the Review will be beneficial to them. They will find other means to get their way. Like overruling the Product Owner.
When stakeholders do show up, Sprint Reviews without trust may end up being status updates only, to check if the team is sticking to their plan. In a complex environment, this is nonsensical because you simply don’t know what will happen.
10. Sprint Retrospective
Sprint Retrospectives without trust can be a closed affair where only superficial topics are discussed. The Scrum Team isn’t willing to discuss important but perhaps painful topics because these require courage and respect.
Whenever the organization doesn’t trust the Scrum Team, the team can only address issues they control. They will not be able to bring forward organizational impediments that grind them to a halt.
End Note
With this article, I aim to show how important trust is in the context of Scrum. I could have gone on and on, but decided to stick to 10 to make my point.
What do you think? Did I highlight the most pressing issues? Or do you have others? Please let me know in the comments!
I agree that trust is important, but often, it is either:
A - Reduce to its most nocive form, blind trust
B - Weaponized against accountability or for power control
C - Use as a magic bullet to exhonerated our responsibility in the problems we have
Also, I think that the purpose of Scrum is to build trust rather than needing it. How else could we interpret this sentence in the Scrum Guide:
"When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust."
For me, all elements of Scrum are there as requirements to build trust, rather than the reverse. So, I tend to approach your points differently:
- How can you have trust if the team is not transparent? Doesn't inspect their increment honestly nor adapt to what they discover?
- The DoD defined the expectations in quality of the increments of the team: it helps aligned the team and the stakeholders, and that's why the DoD is the only part of Scrum that can be an organization standards rather than solely a team owned artifact.
- etc.
I often explain the Empiricism this way to my team: the iterative loop is a generator of trust. We start with the default values of courage, commitment, openness, respect and focus, and through the cycle of transparency, inspection and adaptation, with the goal of delivering value:
- we learn to trust our stakeholders to give us fair feedbacks allowing us to deliver better value next increment
- we earn the trust of our stakeholders in our ability to deliver value and improve regularly
- we learn to trust our teammates to work together toward a common goal
- we learn to trust the system to empower us to deliver value in a sustainable manner
- we learn to trust our own ability to deliver high value increment within a volatile, uncertain, complex and ambiguous environment.
I believe so strongly in that I consider an environment that don't practice such values and methods, which aren't unique to Scrum but to any enquiring endeavour, trust cannot exist and it is replaced with just a spectacle of false trusts, one of the sad masks I cited at the beginning.