Stakeholder Trust

TL; DR: Stakeholder Trust

Trust According to the Scrum Guide

How Lack of Stakeholder Trust Manifests Itself

Lack of Stakeholder Trust at the Organizational Level

  • Metered funding: The Scrum team is permanently held in limbo by the stakeholders regarding whether they will continue its funding or be disbanded.
  • Internal agency: Stakeholders do not empower Scrum teams to solve customer problems. Instead, stakeholders hand lists of tasks to Scrum teams to accomplish.
  • Stage-Gate® vs. self-management: Stakeholders approve Increments and decide over releases.
  • Reporting-driven culture: Stakeholders demand various reports from Scrum teams but refuse to attend, for example, Sprint Reviews.
  • Using unsuited metrics: OKRs are based on output metrics instead of being determined by the desired outcome.
  • Command & control: Stakeholders create arbitrary deadlines to push Scrum teams to higher performance levels.
  • Lack of commitment: Scrum is abandoned the moment there is a challenge on the horizon.

Lack of Stakeholder Trust at the People Level

  • Team building I: Line managers and HR have the final say over hiring and firing new team members.
  • Team building II: Stakeholders and line managers assign team members to Scrum teams without consulting the team itself.
  • No slack time: Line managers believe in keeping utilization rates of team members high. (An increasing velocity is regarded as a success sign.)
  • Sub-roles within Scrum teams: Line managers insist on creating “lead positions” within the team. There are lead engineers or lead designers.
  • Hierarchies within Scrum teams: Line managers create reporting hierarchies within Scrum teams; for example, junior developers report to senior developers.
  • Resources & FTEs: Line managers move “resources” between teams without consulting the affected teams and individuals.
  • Incentives: The organization grants personal incentives for individual team members instead of incentivizing the whole Scrum team.

Lack of Stakeholder Trust at the Way-of-Working Level

  • No failure culture: “Failure is not an option.” (Solving complex adaptive problems is inherently failure-prone.)
  • Separation by silos: Sales prevents Scrum team members from talking directly to customers.
  • Dependencies I: The Developers do not enjoy the freedom to choose tools.
  • Dependencies II: Developers cannot decide how to turn Product Backlog items into Increments. For example, an outside software architect is pre-defining solutions.
  • Imposing processes: The organization creates detailed processes in Jira or any other project management tool outside the team’s control, thus disempowering the team members. For example, team members are not allowed to delete entries or change processes.
  • Approval gates: Scrum teams cannot decide how to spend their training or book budgets.
Download the 66 Scrum Master Interview Questions to Identify Suitable Candidates

How to Build Trust as a Scrum Team

  • Regularly deliver a valuable Increment every single Sprint and embrace a servant leadership attitude as a Scrum Team: make your stakeholders look good.
  • Educate your stakeholders: organize workshops on how agile product development works. Do not assume that your stakeholders are familiar with the intricacies of “Agile” or Scrum. (Learn more: App Prototyping with Absolute Beginners — Creating a Shared Understanding of How Empiricism Works.)
  • Create an actionable Product Backlog by designing a transparent product discovery system encouraging everyone to contribute. If your Product Backlog process looks arbitrary, every stakeholder will be pushed into a corner and focus on pursuing their (personal) goals over aligning with the big picture.
  • Over-communicate all aspects of your Scrum team’s work; it is okay to sound like a broken record in this regard. (Learn more: 11 Proven Stakeholder Communication Tactics during an Agile Transition.)
  • Practice radical candor: be upfront with issues that impact the scope or delivery dates, and communicate the underlying issues immediately.
  • Run user story mapping workshops to learn from your stakeholders, include them in the discovery process and build rapport with them. Once they are a “part” of the solution, they will become more trusting.
  • Don’t ignore stakeholders’ needs; the “how much is it and when can I have it” question is valid; your stakeholders must also meet objectives.
  • Show empathy; try walking in your stakeholders’ shoes; for example, as someone from sales attempting to meet their quota.
  • Include stakeholders in Sprint Reviews and organize regular meta-retrospectives.
  • If necessary, write reports to satisfy their information needs. At the same time, figure out why they need these reports and support them to come up with something better.

Stakeholder Trust — Conclusion

📖 Stakeholder Trust — Related Posts

📅 Training Classes, Meetups & Events 2022

📺 Join 4,000-plus Agile Peers on Youtube

✋ Do Not Miss Out: Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Community

🎓 Do You Want to Read more like this?



Best posts from last week on agile and lean methodologies, Scrum and product management. Manually curated, no robots involved.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Stefan Wolpers

I have worked for 17-plus years as a Scrum Master, Product Owner, and agile coach. Professional Scrum Trainer (PST) with