Chris Sterling’s Blog

If you have been through the Certified ScrumMaster training course you may have seen or been involved in an exercise called the “Daily Scrum From H#%&”. In this the participants each take on dysfunctions which a ScrumMaster may see on their team. The ScrumMaster attempts to hold the Daily Scrum full of these dysfunctional team members without knowing the dysfunctions they are exuding. In the last Certified ScrumMaster course that I co-trained with Bryan Stallings had the following dysfunctions in the exercise:

Tardy - arrive late for the meeting; offer a weak excuse
Without focus - give a rambling update and appear lost as to what you will work on next
Interruping individual - ask a clarifying question on someone else’s turn
Hidden impediment - mention an impediment but don’t be obvious about it
Noisy “Chicken” - start your update by saying, “I’m only an observer,” and then proceed to report on things the group wouldn’t care about
Design zealot - focus your update on a design question or issue and attempt to get resolution in the meeting
Poor task communicator - refer to your tasks in the most generic sense, such that your update is vague and without context

At the Scrum Gathering 2006 in Minneapolis I became a cast member in a Dysfunctional Daily Scrum video. The video was posted on YouTube here.

Although teams may find themselves confronted with dysfunctional behavior on their teams, in my experience I have found two particular issues with Daily Scrums more often. The first is the team feeling like they are being micro-managed and the other is the use of task unique identifiers.

When first starting to use Scrum many teams apply the tools, processes, and practices of their current working environment into the Scrum framework. This behavior causes many teams to think that Scrum is making their environment even worse. The adoption of Scrum and doing it effectively most often requires a mindshift change.

A Daily Scrum that feels like micro-management, in my experience, is usually caused by applying the traditional task update status to the 3 questions discussed by each team member in the Daily Scrum:

What did I do since last meeting?
What am I going to do?
What impediments do I have?

The application of the task update status with your traditional Project Manager (not that all PMs were like this ;)) causes the team members to spend much more time on the first question, “What did I do since last meeting?”. This focus leads their conversations into long spirals about detailed information that may be redundant or not valuable for the rest of the team. Also, there tends to be an unwillingness to spend any time on the impediments because this may indicate that we do not know how to do our jobs. This pattern begins to erode the value of the Daily Scrum and the team may move to meeting every 2 days, a week, or not at all over a period of time.

When I am coaching a team and I come across this pattern I start asking the team members why they feel micro-managed. The most common responses that I have gotten are:

Nobody cares about what I am doing
I do not see any value come from this meeting
The ScrumMaster always is checking on what I have done
I already updated my tasks on the Sprint Backlog, why do I have to discuss my progress again
Everybody talks too much and we go over the 15 minute timebox

After investigating further into the root cause the most common suggestion that I give is to focus more on the last 2 questions, “What am I going to do?” and “What impediments do I have?”. I tell the team that the purpose of the Daily Scrum is not to scrutinize their work but to better understand the state of our Sprint and plan accordingly. By discussing what we each are going to work on our team can better understand potential dependencies, issues, and communications which need to be discussed after the meeting. The impediments which are brought up can be assessed to figure out if the team can resolve them internally or if the ScrumMaster will need to find a way to resolve them. The removal of impediments is essential to enabling the execution of successful Sprints and accelerating the team’s velocity.

Another problem that I have commonly seen on Scrum teams is the use of user story and task unique identifiers to indicate what each team member is working on. Be aware that the use of these identifiers to discuss tasks being worked on could lead to a few issues:

Product Owner not understanding team member’s discussions in the Daily Scrum
Team members not re-planning based on information discussed in Daily Scrum
Just communicating each team member’s status and not communicating the right information to the ScrumMaster
Daily Scrums which are too fast and not valuable
Too much focus on the ScrumMaster as status gatherer

Although it may be good for our tools, historical data, and traceability needs, unique identifiers on user stories and tasks are not good communication tools. Depending on the situation, I may suggest that a team start using a task board which is visible during the Daily Scrum or better yet use the human readable description of our user stories and tasks to communicate with team members. This can help to alleviate the overhead of looking up or ignoring what your fellow team members are working on.

In conclusion, the Daily Scrum is an essential practice in the Scrum framework. If the team feels like it is a micro-management tool, are not easily understanding the discussions, or any other bad vibe degrading it’s usefulness then we must conduct root cause analysis to find out what the problem is. Address concerns head on and work as a team to figure out how we can make the Daily Scrum an effective use of our time.

2 Comments »