By Plamen R. Balkanski
Scrum implementations, especially in their early days, are expected to, and almost always do, reveal hidden problems and issues within the Scrum team. This article explores ways to overcome some of these all-too-common team dysfunctions.
A Beautiful Beginning
Pat is the ScrumMaster on her organization’s first-ever Scrum team. So far, all team members seem to be interested and are attending all the meetings. Pat has managed to secure a regular meeting room with whiteboards for the daily standups and has also been able to book an appropriately equipped room for reviews and planning meetings. Everyone seems to have caught the spirit of index cards and blu-tac. Overall, Pat feels very encouraged by the energetic culture emerging around her.
The only part that seems a bit off is the team retrospective. She can’t put her finger on the problem; things just seem a little weird. No big issues are being raised during retrospectives, but Pat dismisses it as normal.
Another iteration goes by. This iteration was a disappointment. Only 5 of the team’s 12 planned points were achieved. As a result, the review didn’t go too well . It’s now time for another retrospective. Pat is curious as to whether the iteration’s poor outcome will spark some discussion about the sudden slowdown in velocity.
The retrospective seems to be running smoothly when suddenly Tom, a senior developer, speaks up: “Here’s what really happened. Chris [a test engineer] wouldn’t let the rest of the team do any testing. As a result the team ended up with half of the stories in the final stages of testing just because test engineers would not trust the rest of the team members to provide adequate testing.”
Surprised by the fact that he is being blamed, Chris replies, “No one else is qualified to do ‘proper testing.’ Besides that, this whole Scrum process practically ignores testing. It’s no surprise that quality is going down.”
At this point, Pat interjects. She explains that blaming is not allowed. She accentuates the positives of identifying a problem that the team now needs to focus on resolving. She agrees to research solutions to these impediments. The rest of the retrospective is uneventful.
Back at her desk, Pat begins to work on solving this problem. She sees this as a technical issue: testing needs to be automated to reduce the workload of testers. She starts reading about test automation and distributes various useful webcasts and studies about it. She even changes the Scrum training to frame it specifically for test engineers. They seem to understand more and more about cross-functional teams and the need of automation. The problem must be solved, right?
Beneath the Surface
Wrong. Let’s step outside of our scenario and analyze what’s happened so far. Though Pat may have solved some of the surface problems, the real issue probably runs much deeper. She has two likely problems: lack of trust and fear of conflict. The test engineers do not trust the rest of the team; perhaps the developers don’t trust the testers, either. Generally speaking, lack of trust is usually caused by an unwillingness to be vulnerable. In these cases, team members are not open with one another and are afraid to talk about their mistakes and weaknesses. At the same time, the fact that the team’s previous retrospectives seemed to be running a little too well suggests that the team might be afraid of conflict. As a result of these two problems, the team is not engaging in open debates and is instead resorting to indirect discussions and shielded comments. Eventually, though, the issues will reach a point where they bubble out of control, causing far bigger problems than if the conflict had arisen earlier, or even better had been resolved in a team debate.
The Calm Before The Storm
During the next few iterations, things seem to be running more smoothly. The testers are no longer questioning automated testing and seem to be spending time finding an appropriate tool to use. Pat still has slight concerns about the way the team reaches quick agreement during planning, although she can easily justify this with the fact that the team is just getting more and more used to Scrum. The team is edging close to completing the list of stories in the backlog, and Pat is ready to focus on the release.
On what seems certain to be the last planning meeting before the release, Pat asks the team to start discussing final steps to produce a deliverable product. Suddenly, people seem a bit uncomfortable. Most unexpectedly Jane, another test engineer, states out of the blue, “The team may think that this product is ready for release, but I’m not convinced that enough testing has been done.”
Chris quickly concurs, “I agree. I will not accept responsibility for this product. I’ve never done less testing in my career nor have I ever seen such a weird way to develop something.”
Peter, a web developer responds, “Obviously, the test engineers still do not trust the rest of the team. How can more testing be done when only two team members are testing?”
Pat leaves the meeting disappointed and very concerned because what seemed to be a maturing Scrum team suddenly doesn’t act like a team at all. She spends the rest of the day reading about teamwork and various ways to improve it. She is beginning to realize that without sorting out underlying problems it will be difficult to improve practices and productivity.
Let’s step back and look at what’s happening. The Scrum team in our story appears to be functioning smoothly but are really hiding their true concerns from each other. A team that does not engage in debate, or in other words, a team that lacks healthy conflict, often also lacks commitment. Because team members are not airing their opinions in an open discussion, they rarely, if ever, commit to a decision, even though they may demonstrate agreement in meetings. Unfortunately when this is the case, it triggers an even bigger problem: avoidance of accountability. When team members are not committed to a well understood plan of action, they often fail to call their peers on actions and behaviors that seem counterproductive to the good of the team.
Did You See It Coming?
The next morning things seem to become even worse. During the daily standup, Pete, a senior developer, shows obvious impatience while Chris is talking. He even interrupts him to make a point about team members not following practices that he believes are a must. Tom also joins in by ignoring the usual order and stating that he feels it has become more difficult for him to do “proper” development. Being a “jack of all trades” makes it impossible for him to develop expertise. Jane follows to confirm what is obvious to the rest: she doesn’t enjoy working “this way” and she doesn’t see any career progression opportunities with Scrum.
Pat feels betrayed. It seems like the hundreds of hours spent on convincing people and setting up the basics have been for nothing. The team hasn’t been maturing; it hasn’t even formed. Team members were living in artificial harmony by avoiding conflict. Now they feel disengaged and demonstrate no commitment. When a team fails to hold one another accountable, they demonstrate the most damaging dysfunction: inattention to results.
Pat is in an awkward situation because, though she firmly believes Scrum is not the reason for these problems, Scrum has exposed the dysfunctions. Everyone else is convinced that pre-Scrum, no dysfunctions existed. Post-Scrum, the team looks like it’s falling apart. How can Pat change this? How can she resurrect the team and prove to senior management that Scrum is worth the effort?
Can Somebody Please Explain!
I am convinced there is no easy answer to these questions; however I also believe that by following a few simple rules a lot can be done to save a dysfunctional team like Pat’s. While many sources suggest that ScrumMasters always should escalate cases like this to management, I tend to disagree. What if middle management doesn’t want to assist? What if they blame Scrum/you for the problem? What if you don’t want to lose the battle?
I should warn you that this is not something that can change overnight. If your team is experiencing these types of dysfunctions, overcoming them will require patience, good coaching, facilitation skills and then more patience. It will probably be many days, if not weeks, until you see some change. It might take as long as six-to-nine months until you start feeling optimistic about your team.
Are you willing to be vulnerable?
It all starts with trust. Let’s start there. Ask yourself these questions:
- Are you willing to be vulnerable?
- Do you act like you are?
- Are you communicating enough to make the team aware that you are ready to make yourself vulnerable?
Talk to the team as a whole or individually. You can try a group exercise where you ask everyone to share details they otherwise would not want to. Many examples exist, but common starting points include: What is your biggest strength and greatest weakness? What was your biggest challenge in school? You also need to find a way to get the team together outside of normal work environment. This may range from organizing a night out for the whole team or attending an offsite event. Do what is appropriate for your budget. Whatever you choose, try to do the same activity at least once a month.
How will you know if you have succeeded in building trust?
- You start hearing team members answering honestly, “I don’t know.”
- Team members happily share information and offer help
Plain Talking
Politics can keep some teams from ever truly forming. I know that politics are influencing my team when people choose their words and actions based on how they want others to react rather than on what they really think. Another sign that teams are politically motivated is when attention is paid to the speaker’s rank rather than dialogue content. Politics kill progress; therefore, you need to stop political behavior immediately.
Is there a lot of whispering in the team? Do team members who express their opinions met with a negative reaction? If so, you probably have some politics interfering with your progress. Challenge each team member to think and act as if they hold a position two levels higher in the hierarchy. Encourage honest comments regardless of how ruthless they may sound. Print out posters explaining why politics is bad; put them on the walls around your team or, if allowed, around the whole building. Protect and support your people so that they can speak openly with anyone in the company. Encourage healthy debate by asking open questions, such as: What other options do we have? What would happen if we go with this solution?
How will you know if you have succeeded in eliminating politics?
- The whispering is gone
- You can join a team discussion and no one changes the topic
What’s that Smell?
Agreement is good but be careful how you reach it. If you often feel that the team agrees too easily, if decisions are taken too quickly and meetings go too quietly, then perhaps not everything is as good as it looks. Such “easy” decisions are bad for the team because team members who feel they have not been heard will not feel fully involved.
The best thing you can do in this case is to be there as facilitator and ask the questions required to spark a healthy debate. Ask about any weakness you see; question solutions; act as the devil’s advocate. When a debate is going in the wrong direction, try to bring back the business goal and focus the team on the responsibility and effort required to achieve a great solution. Avoid digging into too much detail – this is where you will usually lose most of your time.
How will you know if you have succeeded in eliminating agreements that smell?
- You hear team members say, "I may not agree with your ideas but I understand them and can support them."
Group or Team?
According to a popular definition, a team is a small group of people with complementary skills and abilities who are committed to a common goal and approach for which they hold each other accountable. Presumably if a group of people doesn’t meet these criteria it remains just a group of people.
Do you often notice team members not particularly interested in team decisions? Have you seen team members only interested in their propositions and not willing to discuss or support others’ solutions? Do you often hear, “This is not my area. You need to speak to X”? If so, you might be dealing with a group as opposed to a team.
A friend was telling me a story about his son. One day, after a football game, his father asked him who won. The boy answered, “I scored two goals!” His father asked again, “OK. Who won the game?” The boys then replied, “Well, the team lost 2-7, but I scored two goals. Isn’t that the important bit?”
Are members of your Scrum team more interested in their own results than in the team’s? This problem could be caused by your organization's implementation of traditional performance review process, or it could be because team members fail to see benefits in achieving a team goal.
To counteract this tendency, set team goals and make sure everyone in the team is motivated to meet these goals. Sprint targets are good goals to meet but are not always enough. Think about other goals your team could reach. Set performance objectives and individual goals that are aligned with those team goals. If this seems difficult, begin by reading about the review process for agile teams. Note that making some of these changes may be an uphill battle; you may have to enlist senior management support to win. Fight anyway. It’s the best way to avoid ambiguous goals and the resulting inattention to results behavior. Team members will still have goals to work towards but now these goals will not get in the way of team’s targets.
How will you know if you have succeeded in creating a team?
- When the sprint-targets-met rate increases significantly
- When team members start using “we” more than “I”
Fight the Good Fight
We have looked at a few common scenarios, identified team dysfunctions, and discussed ways to resolve them in a Scrum environment. Naturally, you will need to read a lot more than this one article in order to succeed but I hope I’ve given you some ideas to get you started. Remember that the battle to keep your team functional is one that you will have to keep winning over and over again. In the end, though, it’s worth the fight.
References
