The ScrumMaster Tales is series of stories about ScrumMaster John and his team as they try to work their way through the issues they discover as they first learn to do Scrum. The stories are born of the ideas I wish I had more time to explore in my Certified ScrumMaster classes.
Non sequitur: John and his team are really doing quite well. The problem that I'm throwing at them in this episode seems unlikely and also over the top. In addition, no team ever suffers all of the problems I inflict on John and the gang below.
John and the team are really starting to reduce the rate of production support interruptions, and the team is starting to collaborate more. But John still notices that team members are sometimes surprised by what the others are doing. Isn't that what daily stand-ups are supposed to cure? John goes back and checks his trusty Scrum sources:
- Daily Scrum should happen first thing in the morning.
- Team members answer three questions: What did you do yesterday? What will you do today? What are your obstacles?
- The ScrumMaster runs the meeting.
- Daily Scrum is held with all participants standing.
- Daily Scrum should last no more than 15 minutes.
As far as John can tell, the team is doing all of these things. So he calls his friend Michael, who is ScrumMaster for another team, and asks him to come and watch the team's stand-up. Michael attends stand-up for several days running to get a true sense of what was going on, and here's what he notes:
- James phoned in to the stand-ups every day but couldn't really hear what was going on.
- Doug strolled in ten minutes late two days in a row and didn't seem to see this as an issue.
- Several team members checked in only long enough to give their own reports.
- John directed meetings by asking each team member in turn to give his or her update.
- Fred gave so much technical detail that most of the team nodded off after the first minute, especially Product Owner Sue, who just couldn't understand anything that Fred said.
- The whole event lasted more than 20 minutes every day, due to the lengthy discussion that surrounded each update.
Michael asks the team what they think the purpose of the Daily Scrum is, but there isn't a clear consensus. Some think it's for reporting to management (through the ScrumMaster), and others think it's to help John find resolutions to their impediments.
Michael sits down with John and talks about the things he'd noticed:
- In directing the team, John misses the chance to engender self-organization and instead gives the team permission to disengage.
- In addition, since the team members don't really understand the purpose of the Daily Scrum (which is the coordination among team members versus management reporting), they don't really listen to each other.
- Stuck on the phone, James is never really a participant, since the team makes no effort to ensure that his voice is heard or that he can hear them.
- Discussion around each update isn't part of the Daily Scrum.
- Fred needs to know that most of the audience will get lost if he goes into too much technical detail.
Active listening
The Daily Scrum is really all about active, focused listening — taking the time to understand what your teammates are saying as opposed to focusing on what it is you will say in your own update. Active listening is hard to do well and doesn't come naturally to most of us. Michael suggests to John that he focus his efforts here:
- Explain to the team the purpose of the Daily Scrum: To coordinate among team members, to check progress toward the sprint goal, and to discover obstacles that the team faces.
- Step back from direction and let the Daily Scrum run itself — act as facilitator instead of manager.
- Remind team members that discussion should wait until after the Daily Scrum itself, allowing those who aren't interested or involved to return to their work.
- Improve the Daily Scrum questions by changing them from what team members "did" and "will do" to "what did you complete?" and "what will you complete?" I prefer the word "complete" because it puts the emphasis on completing small pieces of work every day. Clearly, some days you will complete one thing and start another. It helps avoid the problem of a team member saying "I worked on XXX" for three days running. In addition, this "complete" isn't a stay-late commitment but a best-efforts commitment.
- Help team members empty their minds by writing down their reports before the Daily Scrum, which will free their minds to listen instead of worrying about what theyíre going to say when their turn comes.
- Limit note taking to jotting down whom you need to talk to after the Daily Scrum. When we spend time taking notes, we're no longer listening. Instead, just be aware of whom to follow up with. These aren't meeting minutes, just the names or initials of people you want to follow up with.
- Warm up with any activity that forces the team members to focus. It can be as simple as passing a football from person to person (in random order) to more complex ìimprovî activities. The key is to find a variety of activities that require focus and engagement.
- Engage remote team members and ensure that they're kept front and center. This can be as simple as moving the phone to the center of the team or as complex as creating puppets of the absentee people to remind the group of their presence in the discussion.
- Lateness on a regular basis is disrespectful to the team. The ScrumMaster should find out why Doug is late (there may be reasons that we don't perceive). Either we have to find a way to move the Daily Scrum to accommodate Doug's needs, or Doug needs to arrive on time for the meetings.
- Practice privately just before the Daily Scrum with those team members who still need help. For example, Fred might need help to find the right level of detail; another developer may need support to raise his or her voice.
John's team will have much better stand-ups when members understand the real purpose and learn how to listen.
Share on LinkedIn
Share on Twitter
6