Danielle Ferguson
April 02, 2015

Trust in Scrum

Danielle Ferguson

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 as a Concept

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.
Poor Evaluation

  • 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.

4 Comments

  1. 4 Donald Bickel 02 Apr
    I love having team members on my Scrum teams (whether I am Product Owner or Scrum Master) that I just KNOW are going to help the team win - and will win as a team.  Other team members trust that kind of player, know what to expect and it makes it much easier for everyone else to grow the trust.  I've seen teams with less experienced members with huge levels of trust knock down way more user stories than teams composed of more senior but non-trusting members.
  2. 3 Brian 10 Apr
    I like love how scrum makes it easy to forecast our commitments each sprint!
  3. 2 Sarah P. 13 Apr
    Trust is absolutely huge in Scrum. Scrum values people, honesty, openness - and you can't have those things without team members who are trusting and trustworthy. I like how you called out all the main players as having a role in developing trust within a scrum team as each one has an impact on establishing, building, and maintaining trust relationships throughout the scrum process.
  4. 1 Susan 13 Apr
    A common thing between each of these levels of trust you have listed is communication, which I would agree is a foundation of trust in any kind of relationship.

Comment

  1. RadEditor - HTML WYSIWYG Editor. MS Word-like content editing experience thanks to a rich set of formatting tools, dropdowns, dialogs, system modules and built-in spell-check.
    RadEditor's components - toolbar, content area, modes and modules
       
    Toolbar's wrapper 
     
    Content area wrapper
    RadEditor's bottom area: Design, Html and Preview modes, Statistics module and resize handle.
    It contains RadEditor's Modes/views (HTML, Design and Preview), Statistics and Resizer
    Editor Mode buttonsStatistics moduleEditor resizer
      
    RadEditor's Modules - special tools used to provide extra information such as Tag Inspector, Real Time HTML Viewer, Tag Properties and other.
       

Subscribe to Our Blog

Get the latest blog posts sent right to your inbox so you never miss an informative post from Mercury.

 

Get Your Share On!

 

Tags

Archived Posts

Go here to find all blog post published before the new year.