Articles

Scrum projects, especially in the early Sprints, reveal hidden problems and issues within the Scrum team. Imagine a Scrum Master on her first Scrum project just days after obtaining her Scrum Master Certification. All team members seem to be interested in her words of advice and are attending all the meetings she asks them to. One of the retrospective meetings appears to be running effortlessly when unexpectedly a senior developer complains about test engineers who would not trust the rest of the team members to provide adequate testing. He claims that more than two thirds of the User stories are therefore in the final stages of testing .The Test engineers retort that no one other than them is qualified to do proper testing and complain that Scrum ignores testing. Our Scrum Master sees this as a technical issue: testing needs to be automated to reduce the workload of testers. She even organizes the Scrum training adapted specifically for test engineers. As a result, the Scrum team seems to buy in into cross-functional teams and the need of automation.

Though the surface problem may have been solved, the actual issue is lack of trust. What her Scrum master training has not taught her is that when test engineers do not trust the rest of the team; maybe the reverse is also true. Team members are not honest and are afraid to talk about their mistakes and weaknesses. Consequently, the team engages in closed debates and resorts to indirect deliberations and shielded remarks. Eventually the problems bubble out of control, causing far bigger issues. In most organizations, before Scrum implementation, teams usually appear to be working smoothly while hiding their true anxieties from each other. A team that does not debate and engage in healthy conflict also lacks commitment.  Since team members are not expressing their views in open dialogue, they seldom commit to a resolution, although they may show agreement. Unfortunately, it starts a bigger problem: evasion of accountability. This allows the bullies to bulldoze their way through and leads to dissent and team members become more interested in their own results than in the project. When team members are uncommitted to and uninvolved in a well understood roadmap, they fail to confront fellow team members on activities and behaviors that are counterproductive to the project.

Before confronting team members and their lack of Trust, a Scrum master has to first ask himself/herself: Am I willing to be vulnerable? Lack of trust is usually caused by reluctance to be weak. When Scrum Masters fight the urge to constantly advertise how awesome they are and behave honestly, the team sees a leader they can relate to. Then Scrum Master can talk to the members and they will listen as a whole team. Next, a Scrum master can try group exercises where everyone shares details they otherwise would not. E.g. what was your worst moment in high-school? Scrum masters can also try to get the team together outside the normal work environment for this exercise. They should set objectives for the whole team and verify every team member is driven to achieve these objectives. There can be behavioral goals and individual objectives aligned with those team objectives. Making some of these changes may be a battle; Scrum masters may have to enlist senior management support to win. It’s the best way to avoid Trust deficit and the resulting breakdown in behaviour.