The Daily Scrum is a vital part of the agile framework. It is an opportunity for the development team to review progress and highlight issues or impediments that are preventing them from progressing effectively.
Who attends the Daily Scrum?
The only mandatory attendees are the development team; this is important to remember as it helps enforce that team autonomy and self-managing mentality it needs. The Scrum Master’s role is to ensure that the ceremony happens and that the team know what needs to happen but their attendance is not essential. It can be useful to have the Product Owner present if there are queries about the stories the team are working on.
What happens in the Daily Scrum?
The Daily Scrum is a key ceremony to share information about progress on the current sprint. It is important that it doesn’t turn into a major time-sink for the team and for that reason member’s updates should be concise and not verbose and the whole ceremony should be time-boxed to 15 minutes.
Generally, in order to give member’s a prompt, there are three key questions that each member can answer:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments or obstacles in your way?
This gives the rest of the team a clear update on progress. It’s where potential clashes can be identified and resolved and also provides a platform where risks can be raised within the team or to the Scrum Master for resolution.
In my Experience
When first implementing Scrum it can be difficult for the team to understand the purpose of the Daily Scrum, however it’s one of the ceremonies that is so important. One of Scrum’s core values is transparency, not just outside but inside the team. A symptom of smaller, non-agile teams is that team members are often siloed into verticals – areas of expertise within technology or functionality and this ultimately causes bottlenecks in the development cycle. If the team has a detailed view and understanding of their colleague’s workloads and issues then they should feel more inclined to assist in offering a solution, this can lead to a smooth organic adoption of pair programming.
Managers and Scrum Masters should continuously enforce the principal that the team are responsible for the success or failure of the sprint; it should not fall onto one individual within the team. We succeed as a team and we fail as a team. I’ll go into developing a team mindset in a later blog post.
Some team members will obviously be more outspoken than others so as a Scrum Master try and encourage each team member to give a useful update. Keep an eye on the current sprint and if someone is still on the same story as they were yesterday then gently nudge them to explain why; it could be they need assistance but are too insecure to ask for it.
Conversely if some discussions are beginning to become too verbose then introduce a method of timeboxing updates. I’ve used tactics such as a red card – if team members feel that one or more members are discussing an item in too much detail then they can hold up the red card to stop the discussion and encourage it to be taken out of the Daily Scrum to be discussed later.