One of the most underestimated events in Scrum is the Daily Scrum. The Scrum Guide advised us to keep the Daily Scrum at a 15-minute timebox where the team members discuss what they realized yesterday, what are they going to realize today, and which impediments they face to reaching the Sprint goal. Although it seems quite simple, the reality is that we are still seeing teams which are having trouble with the Daily Scrum. I have noticed that ineffective Daily Scrums revealed a lot about the Scrum process itself. In this article, I will elaborate on a few common mistakes in the Daily Scrum which reveal the shortcomings of other Scrum processes and events.
Yes, Scrum Master, of Course, Scrum Master
The first thing that usually catches my attention, and to be honest also makes me laugh, is the fact that the team is not talking to each other. Team members stand in a half circle in front of the Scrum board and one-by-one they look at the Scrum Master and drill out the three stand-up sentences. The positive thing about this is that everybody is at the stand-up and focuses on memorizing the three topics of the stand-up. However, this behavior also tells us a lot about team dynamics. I usually get the following three underlying reasons when I dig deeper:
The Scrum Master is a semi-Product Owner or feels like/is seen as a manager.
-- Adress this and discuss this with the Scrum Master and team members in a retrospective.
Team members already discuss issues a lot with each other outside the stand-up
-- Very good, "interaction and people over processes and tools." Try to figure out if the stand-up is still needed and stay sharp if everybody is still aligned on reaching the Sprint goal.
Team members are not interested in what everybody is saying.
-- What does this say about your Sprint planning? Does the team have a healthy T-Shape?
I Don't Have Anything to Add
The idea during a stand-up is that everybody shares their previous achievements, the achievements for today and impediments. However, I always see teams in which some people have more to say or to add than others within a team. This behavior is definitely worth the investigation to find out if any of these underlying problems are in place.
The hierarchy between senior and junior team member is strong.
-- try to find out if this is the case, and address this situation in relation to being and getting T-Shaped --
User stories and tasks have too many interdependencies.
-- If user stories or tasks have interdependencies, one developer may have the urge to tell the context of their work, and therefore also the achievements of others. In this case, the Scrum Master should investigate if the dependencies happen often and address this within the team. This can be a topic for improvement during the retrospective.
User stories and tasks suddenly have too many dependencies.
-- In this case, the team members find out the dependencies during the Sprint. I have found that the underlying issue is that the Refinement and the Sprint Planning are not effective. I often ask the following questions to get more information:
- Who addresses and logs the dependencies identified during the Refinement sessions?
- Is the DoR being used during Refinement and Sprint Planning sessions?
Flip the Scrum Board
The most common set-up for the Scrum board is to use swim lanes on the board. Each swim lane reflects a story and the tasks are then in the same lane to indicate what needs to be done to finish the story. Some teams, however, have found a set-up to engage every team member and have the swim lanes per team member. It is very useful, because, especially in JIRA, you can then collapse and expand per team member. Additionally, you can then make sure every team member is working on an item and contributes to the stand-up.
Again, a few things which are worth investigating when you see a flipped Scrum board:
The Sprint goal and the goal for stories are not clear, and therefore focusing on working seems reasonable.
-- try to find out if the Sprint goal is clear and if the value which the stories deliver is clearly explained during the Refinement session.
Individual team members are working on multiple items at the same time.
-- Again, this is a focus issue and/or a T-Shape issue. Maybe putting a WIP-limit in place could help to address the areas where knowledge is lacking. Also, the refinement could not be optimal and only one person knows how to realize the story.
These are three major observations I want to highlight. What are your observations and how do these observations relate to the rest of the Scrum process?