A Practical Guide to Distributed Scrum: Distributed Daily Scrum Meetings
This chapter is from the book
This chapter is from the book
This chapter is from the book
- Many attempts to communicate are nullified by saying too much.
- —Servant Leadership, Robert Greenleaf
Once the Scrum Team has completed Sprint Planning, they will begin working together to complete user stories and meet the Sprint Goal. The Daily Scrum, shown in Figure 6.1, provides just-in-time planning and serves as a heartbeat for the Sprint. It is the time each day when the Scrum Team gets together for just 15 minutes and each team member responds to three simple questions (Schwaber 2002):
- What did you do yesterday?
- What are you going to do today?
- Do you have any blockers?
)
Figure 6.1 The Daily Scrum meeting
Although the idea is simple, keeping everyone focused on just the three questions can be a Distributed Daily Scrum Meetings significant challenge. Humorous videos on YouTube show just how bad a collocated Daily Scrum can be (ScrumMasters 2, 2006). Distributed communication makes the Daily Scrum even more challenging because communication through teleconference or some other channel is not as effective as being face-to-face. Many of subtleties of facial expression and body language are missing when holding meetings through teleconferences and to a lesser degree with video conferencing.
The combination of inefficient communication channels coupled with a meeting of team members located in different countries can cause the Daily Scrum heartbeat to become irregular and impact the health of the team.
Ming Zhi Xie, an agile testing specialist with IBM Software Group's lab in Beijing, China, shared the early experience of his team with Scrum:
- We would have liked to take part in the Daily Scrums, but with our teams 12 hours apart, it was difficult to schedule. It would have meant team members in China would be on the phone at 10 o'clock at night or team members in North Carolina would be on the phone at 3 o'clock in the morning. Neither was a good long-term solution. Separating into two local teams was unrealistic because of skills. We clearly needed an alternative.
This chapter talks about how to answer the three questions and provides some tested techniques for conducting effective Daily Scrum meetings with distributed teams (Schwaber 2002).
Using the Three Questions Effectively
To make the Daily Scrum useful to everyone, it is important that team members understand the purpose behind the three questions they need to answer in the meeting. It is also important they provide responses that bring value to the rest of the team.
Answering the Three Questions
Here is an example where John, a fictional team member, answers the three questions of the Daily Scrum meeting:
- Yesterday: I started writing the code to load information into the database.
- Today: I'm going to handle some of the data issues that cropped up yesterday.
- Blockers: I have no blockers.
On the surface, it appears John is answering the Daily Scrum questions, but how much value are these answers providing to the rest of the team. His responses are brief and resemble someone providing a status report, but the Daily Scrum meeting is not a status meeting. It is an opportunity for a team to get together to find ways to help one another and to make sure the team as a whole is able to continue making progress.
Before the Daily Scrum meeting, everyone needs to examine how their current work impacts other team members or identify who can help them resolve an issue. During the meeting, they need to communicate any relevant information to the rest of the team.
Here is a better response where John provides the same basic information but adds some more information to provide added value to the team:
- Yesterday: I started writing the code to load user information into the database. I've discovered that some of the international addresses in the sample data provided by Company ABC do not meet the format we had expected. Mary, I think you are going to run into the same problem with the code to import the data into the label printing module. We can get together offline to discuss.
- Today: I'm going to rewrite the module based on the sample data.
- Blockers: It looks like there is a problem with the constraints we put on the tables, and we may need to update the design.
The greatest value of the Daily Scrum meeting is the communication between team members.
Coordinating the Team on a Daily Basis
The Daily Scrum meeting allows team members to communicate, coordinate their efforts, and possibly revise their plans daily based on the answers of the others. Using our preceding example, John clearly states Mary may run into the same problem that he faced when working with the sample data. This may change Mary's plans for the day, because now she needs to get with John to discuss this. The plans of another team member may also change to address the blocker that he identified.
Committing to the Team
The Daily Scrum meeting is where team members make a verbal commitment to the team. When they state what they are going to do today, they are making a verbal commitment to the rest of the team. The next day, when they state what they did yesterday, it is an opportunity for the rest of the team to confirm they met their commitments.
The Daily Scrum creates peer pressure on two fronts, as follows:
- To complete work that is blocking the progress of other team members.
- To create a sense of accountability within the team, in the case where team members do not deliver on the tasks they committed to the previous day.
The Daily Scrum keeps team members accountable as they will eventually need to justify themselves to the rest of the team if they continually do not deliver on their commitments.
Verifying Progress
The two first questions allow the ScrumMaster to test the focus of the team. The team always needs to be working on stories coming out of the product backlog.
The ScrumMaster also wants to know if the team is completing the work they planned to complete during the Sprint. If estimates are expanding or new tasks come up, there will be an impact on the burndown chart. The ScrumMaster should question team members that are doing work that is not helping the team make progress toward the Sprint goals.
When team members are not showing regular progress on their tasks for the Sprint, it can be a sign of outside distractions having an impact on their work for the Sprint. These may be meetings, task assignments for work outside the Sprint, or requests from others. It is important for team members to identify these distractions in the Daily Scrum so the ScrumMaster can help reduce or remove them. Steffan Surdek shares this story:
- Once, I was working on a team with tight deadlines, and some of the team members that were on the critical path were regularly getting requests from another group to provide them with information. When I learned of these interruptions, I directed these team members to redirect the next question my way before taking any action on it. After they forwarded me the next question, I replied to the other team and let them know they were interfering with the deliverables of these team members. I also told them they should come through me in the future for such requests and I would redirect their queries to someone who would be available to help them.
There is also the possibility that team tmembers who are new to Scrum are not used to depending on their team to help them resolve problems. Smart technical people can feel intense pressure to solve problems on their own and not to depend on others. Admitting any kind of difficulty can make them very uncomfortable. When the Scrum Team notices that a member is experiencing problems, they can encourage that person to work with others to get the help needed.
Resolving Blockers
The Daily Scrum allows team members to identify blockers they are facing that are preventing them from making progress on their work for the Sprint. Sutherland states there are different kinds of blockers a team may face (Sutherland 2006), as follows:
- Software or technology not showing tup at the right time. These may be dependencies across teams or groups. The ScrumMaster or the team may not be able to resolve this. The management team may need to step in.
- Meetings irrelevant to the Scrum Team. Here again, the ScrumMaster may not be able to fix this, but it is the ScrumMaster's role to recognize it and bring it to the attention of the management team.
- Hard technical problems often slow things down. The team can often fix this, but at times, management must bring in other resources.
Blockers may create new issues that may in turn become new tasks or user stories in the backlog. These may force the team to change the current plan.
Sutherland also states that it is important for the ScrumMaster to create a list of blockers and assign them to the team or to managers. A major responsibility of the ScrumMaster is to manage, prioritize, and assure this impediment backlog is burning down. The Scrum Team should expect management to help work the impediment backlog. Removing bottlenecks is the fastest way to improve productivity.