Team Dysfunctions and Scrum

13 October 2008

Plamen Balkanski
Agile Catalyst

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 realise 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 organising 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 behaviour 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 organisation’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 behaviour. 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

The Five Dysfunctions of a Team -http://www.amazon.co.uk/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756/ref=sr_1_1?ie=UTF8&s=books&qid=1215814459&sr=8-1

Various ideas generated by reading posts on http://groups.yahoo.com/group/scrumdevelopment


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Peter Janssens, CSM, 10/14/2008 7:56:54 PM
Hi Plamen,
nice article. I added a link to it in my blog: maybe that will encourage more people to read it!

One small question: when you talk about accountability ("avoidance of accountability", "When a team fails to hold one another accountable") do you distinguish "being hold accountable" and team members being "responsible"? Christopher Avery is a pro in this matter: http://www.christopheravery.com .

Regards,
Peter
http://pjnowhow.blogspot.com/2008/10/bad-smells-when-implementing-scrum.html
Plamen Balkanski, CSM, 10/15/2008 7:34:40 AM
Hi Peter, thanks for your comment and the links. It is a good question and I'm glad you asked as your question helped me learn to distinguish something which I failed to notice previously. I found this (http://www.evancarmichael.com/Business-Coach/112/Responsibility-vs-Accountability.html) and now I understand what you're asking. The answer is no. What I want to express with "being accountable" seems to be covered by either both or in full by "being responsible". And yet again this highlights something I need to improve - being so focused on achieving the goal I often fail to clarify the details. Thanks again for this!
Michael de la Maza, CSP,CSM, 10/15/2008 12:54:44 PM
Fantastic article!

In the article you focus on how to address commitment, communication, and coordination problems once they arise. My personal view, based on observing several dozen Scrum launches, is that the vast majority of Scrum teams launch far too early. They have not had nearly enough training and coaching prior to the launch and, as a result, they sign up for something that they do not fully understand and are not fully committed to.

Before I launch a team, I ask each team member the following questions:
1. Do you understand Scrum?
2. Is Scrum better than the current software development approach?
3. Can the team transition to Scrum?

If any team member answers any question in the negative, then the team is not ready to launch. [Warning: If you feel that you need to have this discussion individually with each team member because (1) the team is afraid of conflict or (2) you believe that the team members will fall in line with the highest person's opinion then the team is not ready to launch!]

My view on this issue has changed dramatically since I started coaching. Initially, I thought that Scrum launch problems could be solved within Scrum, and I encouraged teams to launch even when they were not able to answer all three questions in the affirmative. However, I have since discovered that bad launches are extremely costly and doing more preparatory work is a wise investment.
Julya van Berkel, CSP,CSM,CSPO, 10/23/2008 4:32:47 AM
Plamen, also from me, kudo's for this great article. Almost any new implementation of Scrum is done in a traditional organised environment. You describe here the trouble a new Scrum Master can have within a team. I expect this to be common in a company that wants to shift to Scrum and sends a teamleader to get certified as Scrum Master but does not involve the team, the people who are going to be influenced most, in the change. Every change will be faced with resistance and Scrum seriously changes the environment of a development team. A team will still be thinking withing the traditional frame and not want to think out of scope. The team here seems to be in need of some pairing to understand the work of the other. A tester paired with a developer, just letting them get acquainted with what each of them does.
The first team that I got to work with had the biggest trouble with accepting the daily standup meetings. They thought it was a waste of time to be interrupted every day when they were in the middle of work. And before they only had meetings every two weeks. Durin the second sprint I suddenly was called away, and my impromtu meeting lasted past the standupmeeting. When I came back, the team had held the standup meeting on their own. Imagine my pride :)
Solving the issues and undercurrents within a team requires tenacity, human understanding, empathy and a lot of improvisation. Isn't being a Scrum Master wonderful?
Nathan Carpenter, CSM,CSPO, 10/28/2008 12:16:14 PM
Thanks for the great article -- it's very well written and covers a lot of ground, and situations I've seen many many times.

One approach I've taken in situations like this, though, is not to go off and try to solve the problem as ScrumMaster, or escalate it to management -- rather, I escalate it to the team themselves. It's my job to lay out what I see happening and engage the team to figure out how to work together. When it works (and it sometimes doesn't) the team is fully committed to fixing themselves.

I think this article would be an excellent read-ahead for such a "team, heal thyself" activity.
Manoel Pimentel Medeiros, CSP,CSM,REP, 11/4/2008 11:46:02 AM
Hi Plamen,

Great article, because it provokes a deep reflection on the way to implementation of Scrum at several companies.

Thank you.
Gillian Clark, CSM,CSPO, 11/6/2008 5:16:57 PM
Excellent article which clearly highlights the way Scrum highlights dysfunctions within a team. This to me is one of the key benefits of Scrum and one which needs to be considered prior to launching a Scrum project. However, once the dysfunctions are highlighted I firmly believe that the team can (with the right guidance) fix the dysfunctions at the team level.
David Hainlin, CSM, 12/11/2008 8:08:00 AM
Well done, Palmen. I also like Nathan's suggestion to encourage the team to participate in the healing of such common dysfunctions. The SM's role in working this impediment may well be best served by prompting and encouraging the team to address this head on and openly.

You must Login or Signup to comment.