All in this together

Daily Scrums explained

Steffan Surdek
scrum.1

Forget boring, stuffy meetings: this is your team’’s daily synchronization tool.

Before I tell you what the meeting is about, let me begin by
telling you that, contrary to popular belief, the daily scrum
meeting is not a status report meeting. If your team merely stands
around in a circle, each reciting what they did yesterday and what
they will do today while looking straight at the Scrum Master, then
you are the kind of team I am talking about!

The daily scrum is in fact about allowing team
members to synchronize on a daily basis to coordinate their efforts
for a sprint. Notice that when you build a sprint backlog, you
identify the tasks and the number of hours for each of these tasks
but you do not identify target end dates or build Gantt charts for
dependencies. The daily scrum is how teams synchronize and
communicate throughout the sprint.

Why should the meeting occur every day, at the
same time and in the same location? Because sometimes routine can
be your friend. What you really want is for John or Julie to walk
into the office in their zombie-like state, automatically grab
their coffee and find their way to the meeting. You want the
meeting to become a habit for everyone.

Who should attend?

Teams often ask me who should attend the daily
scrum meeting. Team members are mandatory attendees, while the
Scrum Master and Product Owners are optional attendees. Ideally
team members will self-organize and run the meeting on their own,
but initially the Scrum Master facilitates the meeting to make sure
the team gets on track.

One team I collaborated with decided to name a
different meeting facilitator every day of the week. This allowed
the team to take full ownership of the meeting instead of the Scrum
Master.

Focus on synchronization

Sprint backlogs do not contain due dates so
teams need some form of mechanism to work on their dependencies
during a sprint. The most effective and useful way to run your
daily scrum meeting is to focus the team on answering three daily
scrum questions with a goal of synchronizing their efforts and
making sure they will meet their sprint goal.

The not so subtle distinction between the daily
scrum as status report instead of a synchronization meeting begins
with how the team answers the following three questions:

  • What did I do yesterday?

  • What did I do today?

  • What are my blockers?

When team members talk about what they did
yesterday, they provide cues to others with a dependency on their
tasks. For a simple case, a developer pointing out all coding tasks
related to a specific feature are complete signals to the tester
that they can begin testing it.

When a team member talks about what they will do
today, they are essentially making a verbal commitment to the team.
Other team members will know what this person is working on and if
they are focusing on work relevant to meeting the sprint goal.
Similar to the previous example, knowing ahead of time what another
team member is working on may help you better plan your day. For
example, if a developer expects to finish the work on a feature
today, a tester may decide to focus on finishing the relevant test
cases for this feature.

Task boards increase visibility

Just answering the three questions may not be
useful if the team cannot picture their progress during the sprint.
Looking at the sprint task board during the daily scrum meetings is
a simple way to get this visibility.

Some teams manually build and uphold their
sprint task boards (see figure 1 below) using sticky notes and tape
on a wall or a rolling whiteboard they can move around, while other
teams use electronic agile planning tools. Using the task board
view of an agile planning tool may be more suitable for distributed
teams.

Figure 1: Sprint task board.

I find that answering the three questions in
front of a whiteboard while moving tasks and updating hours in real
time helps make the progress come alive. As an alternative, some
teams I know have a rule stating that team members need to update
the task board at least five minutes before the start of the
meeting.

In either case, I usually ask team members to go
up to the task board and point to the tasks they are alluding to so
the team understand what they are discussing. Having people point
also helps the team make sure everyone is focusing on the most
important user stories and shows people are doing work relevant to
the sprint.

Notice the unsaid blockers

When team members are answering the three
questions, it is good practice to listen for the blockers people
arenot directly mentioning. I often see situations where team
members say they have no blockers, but their answers to the two
other questions indirectly mention many blockers.

For example, someone discussing what they did
yesterday may talk about the unexpected support issues that keep
coming up. Unmanaged, these support issues become blockers. Someone
else may talk about a weekly internal committee meeting they need
to attend that is eating away some of their time.

A more subtle form of unsaid blocker occurs when
people keep putting new tasks in progress because they are waiting
for answers on other tasks. To notice these, the team also needs to
pay attention to the work already in progress. These unsaid
blockers should produce questions and become conversation points
for the team.

Getting long Daily Scrums under
control

Effective daily scrum meetings should last no longer than
fifteen minutes. For many teams, respecting this time limit is a
big challenge but it is important to respect the time box or team
members will lose interest in the meeting. Teams larger than five
to nine people may decide that fifteen minutes is not suitable for
them and may opt for a slightly longer time box.

When you see your team having design discussions
or trying to problem solve, the best approach is to call a separate
meeting after the daily meeting. Invite only key people to this
discussion to not waste the time of all team members.

If the meetings are running long because people
are talking too much, one solution is to use a timer. I have two
variants on this technique: the first method is to time the meeting
and stop at fifteen minutes, no matter what. You can be sure the
people who did not have time to speak will get upset and will want
to speak first the next day. The other method is to divide the
meeting time equally between all participants; when I use this, I
interrupt people when their time is up.

The importance of useful answers

Another challenge of daily scrums is when people
provide answers that are useless to the three questions. You can
see one of my favorite examples below. As you can see, the answers
are completely useless to the team. The team would get much more
value if the person would take the time specify which defects he is
talking about.

“Hi Gang… What did I do yesterday? Well, I fixed
some defects… Today, I think I am going to fix more defects… What
is blocking me? Well… If only I did not have so many defects to
fix!”

When team members (not just the Scrum Master)
feel the answers are useless, they should not just let it slide,
but ask more pointed questions. In these situations, I find humor
works well, and I will make a joke such as “Joe, that sounds both
nice and mysterious… Could you please tell us more?” to get more
information.

Peer pressure and visibility are important parts
of the daily scrum. When you tell the team what you will work on
today, you are making a verbal commitment to the team. Team members
that depend on your work expect you to complete what you said you
would do today so their own work can move forward
tomorrow.

Keeping an eye on the goal

Just blindly answering the three questions, even
with the sprint task board in front of you, is rather useless if
the team is not keeping an eye on delivering on their sprint goal.
One of the last questions I like to ask at the end of the meeting
is whether the team feels they will meet their sprint
goal.

When the team does not feel confident, members
may need to reorganize their work to allow them to complete the
high priority pieces while letting others drop to the next sprint.
The team needs to discuss such decisions with the Product
Owner.

Learning in the last days of a sprint that the
team will not deliver the planned work is a powerful sign the team
is not keeping track of the spring goal.

Preserving transparency and focus

One common issue that I see is when certain team
members refuse to update their estimates of time remaining. This
causes situations where someone has an everlasting thirty-hour
task, even though they work on it every day. Ideally, tasks should
be no longer than a day or two to allow the team to see
progress.

In such situations, the best approach is to encourage that
person to break up tasks in smaller blocks at the sprint planning
meeting to allow delegation to others. During a sprint you may want
to ask the person to list the remaining work and create tasks for
each work item. Once you have these tasks work on getting proper
estimates.

Be aware some people refuse to break down their
work into smaller tasks because they are uncomfortable with the
visibility it provides. For example, if they estimate five hours
and it takes seven or eight instead, they may look bad. When facing
these people, you may need to have some separate one-on-one
conversations to hear their concerns and address the
issue.

Another focus-related challenge is of team
members with five tasks already “in progress” on the task board
that feel an overwhelming need to add yet another task in that
column. During the meeting, the team needs to ask this member about
the status of the other tasks currently in progress. Are some of
these blocked? Are some of these done but not yet moved to the
“done” column? If they are still in progress, they need to focus on
completing their work before starting something new.

Making sure everyone pays attention

When many people talk at once or side
conversations occur, it can cause serious communication challenges.
When side conversations occur, my preferred approach is stopping
the person currently speaking to the group so that everyone can
focus on listening to the side conversation. I always find it
interesting how putting people in the spotlight encourages them to
self-discipline and stop their conversation.

For teams where many team members chronically
speak at once, I occasionally use a talking stick, where only the
person holding stick may speak. This forces the team to have only
one speaker at a time. In one company I worked with, I used a
plastic microphone as a talking stick with the teams I coached. I
saw other teams use a ball they toss to one another or a dog
squeaky toy as their preferred speaking permission tool.

Other ways people stop paying attention is by
fiddling around on their cell phones or staring into nothingness.
The best way to get their attention is by calling on them to speak
next or using humor to draw them back in. The most direct way to
address this is literally calling them out for not paying
attention.

Conclusion

Remember the goal of the daily scrum meeting is
to allow the team to coordinate their efforts and ensure they are
on track to meet their sprint goal. The meeting is not meant or
feel like a daily status report meeting.

When team members answer the question “what am I
doing today?” they are implicitly making a verbal commitment to
their team. Peer pressure (i.e. the team asking why someone did not
meet a commitment) is another important aspect of the daily scrum.
Team members should feel comfortable challenging one another in a
healthy way about their deliverables.

The team should be able to do a daily scrum
meeting with or without the Scrum Master present. This is part of
the team taking ownership of their software development process.
The Scrum Master should actively encourage the team to step up and
own this meeting.

Daily scrums are an important part of the sprint cycle
because they help the team collaborate and plan on a daily basis.
Keeping them interesting and effective will enable your team to
stay focused and regularly deliver on their sprint
goals.

Author
Steffan Surdek is a senior consultant and agile coach at Pyxis Technologies. Steffan has worked in IT for over eighteen years in collaboration with many distributed teams around the world. In the last few years, Steffan was an agile trainer and coach in large companies such as IBM and the TD Bank Group. He speaks at many conferences and user groups about agility with distributed teams. Steffan is co-author of the book 'A Practical Guide to Distributed Scrum' written in collaboration with the IBM Scrum Community. He blogs on his websites surdek.ca and provokingleadership.com.
Comments
comments powered by Disqus