Trust in Scrum

Scrum can be a great approach to software development, however the focus of this article will not be on the many benefits of Scrum. Instead, let’s talk about what it takes to get there. Beyond the mechanics of sprints, backlogs, stories, and tasks there is a much harder to account for requirement for Scrum. Trust. Trust between team members is an absolute necessity. Without trust, scrum can quickly turn into one headache after another.

There are many levels of trust that must be developed in order to have a truly effective Scrum team. You must have trust among individual team members, between the scrum master and the team as a whole, and between the product owner and the team as a whole. Scrum may work with some of these elements missing, but it can work so much better with them present.

Trust between Team Members

Individual contributors must be able to trust each other. When individuals do not trust their team mates you can end up with a variety of troubles including:

• Duplicate work – individuals do not trust that the other will complete their work in a timely manner and they may attempt to complete portions of their work in order to allow their own work to continue.
• Micro-managing – individuals may not trust in the quality of the work their team members produce and may spend too much time correcting each other to get their own work done
• Blame passing – rather than working together to resolve problems, individuals who have not built trust in each other will seek to blame others which will further degrade the relationship.
• Lack of communication – team members that don’t trust each other will not be able to communicate openly with each other. They fear being shamed in front of other team members and will struggle with problems that another individual may have a ready answer for.

Even if all of the proper scrum protocol is being observed these issues result in poor quantity and quality of completed work as well as a poor work environment for the entire team. The initial thought may be that it is entirely the individuals involved that cause the problem in this case, but while that can contribute it is often not the whole story. These behaviors can be caused by a variety of external factors.
​

• Emphasis on individual accomplishments rather than team achievements can cause resentment or an overly-competitive team. Concentrating on the team’s progress makes sure that it is in everyone’s best interest to help their team mates succeed.
• Lack of safeguards to ensure quality work can cause uncertainty around the work being produced. Having tools like automated unit tests, code coverage, and code reviews can help the team trust that their team members are creating a quality product. It is, however, important that such tools be applied equally to the team as a whole. Singling out individuals will only increase trust issues.
• Lack of a forum for open communication can cause team members, especially introverts, to feel like they do not have a place where they can express concerns. This should be accomplished with the daily standup, but people often feel constrained to giving a status update and no more. It is important that any possibly relevant issue be given a chance to be aired in standups. It is also important that ideas brought to such a meeting are given true consideration. If people’s ideas or concerns are dismissed too easily, they will stop bringing them up. While it should be the job of all team members to ensure this is happening, the scrum master should be responsible for setting a good example in this arena.

Trust between Team and Scrum Master

A scrum team that does not have bidirectional trust between scrum master and the team of contributors removes all benefits of having a scrum master in the first place. If a scrum master cannot trust the information provided by their team or a team cannot trust a scrum master to do what is best for the team, then this dysfunctional relationship will grow into a much larger issue.

• Padded estimates – if a team does not trust their scrum master to take their estimates in good faith, then they may add additional and unnecessary padding to story/task estimates to guard themselves against being reprimanded. If a scrum master does not trust the estimates provided by the team they may pad or reduce estimates without consulting the team.
• Lack of commitment – if a team feels like there is a chance that their commitment to completing their sprint work will be abused by the scrum master allowing additional work into it without taking proper balancing actions, they will be less inclined to take their commitments seriously. If the scrum master expects the team to not meet their commitments they will be more likely to practice bad sprint hygiene.
• Poor communication – if a team member does not feel that their scrum master has any power to help they may be less willing to go to them with concerns. A scrum master that does not get all the information may communicate poorly with the product owner or other stakeholders.

A team that does not take their commitments seriously will result in disappointing sprints that do not meet the needs of the product owner. It is important to note that this is a two way relationship and changes may need to be made on both sides to gain this trust.

• Team members that feel empowered to reject a change that the scrum master is making will allow the scrum master to learn to make better decisions for their team and will make the team feel like they have a say in how to interpret their commitments.
• Scrum masters that show understanding when an estimate is incorrect are more likely to get truthful and useful estimates from their team.
• Scrum masters and team members need to be honest about what they can accomplish. It is easy to let optimism or ego make you promise things you can’t do.

Trust between Team and Product Owner

The levels of trust required between a product owner and a scrum team are very similar to those between the scrum master and the team and the problems caused are very similar. If a team does not trust their product owner to be fair and considerate then it will be very hard for them to be honest and upfront with estimates and commitments. While the results of this distrust are similar to the scrum master to team relationship, the causes and approaches to resolution are a bit different.

• Product owners who are further removed from the scrum process may not understand or value the iterative process. This can cause the project to revert to a more waterfall approach thereby negating many of scrums benefits. A product owner needs to be onboard with the scrum process and allow it to work.
• Inflexible team members can cause a product owner to lose faith that their changing needs will be met. Ideally every sprint would turn out exactly as it was planned, but not everything works out that way. Team members and scrum masters need to be willing to work with the product owner to get everyone what they need.
• Product owners need to be understanding that sometimes communicated requirements are not sufficient. The team is going to have questions and will need access to someone who can answer them. A lack of availability on the product owner’s part can result in a team that is not confident in their ability to deliver the right product.

Scrum as a whole is all about trust; trust in the team, the leadership and the process. Without this you are fighting an uphill battle. Trust is unfortunately not the easiest thing to build and all the team building activities in the world are not going to fix it, if the team cannot apply it to the day-to-day scrum process. Trust is built over time by making commitments and keeping them and by thinking about the team first.