If your daily standup feels like a status report by each team member to the Scrum Master, the Product Owner or both, there is a very successful technique which I have deployed time and again which quickly solves this.
The standup really is a planning meeting for the team. It should be a chance for them to focus on what they are going to do, and how they are going to spend their time during the day ahead. Too often it becomes stale when the three questions suggested in the Scrum Guide (What did you do since the last standup? What are you going to do until the next standup? What if anything is getting in your way?) become rote and robotic responses aimed at keeping the Scrum Master or Product Owner off one’s back, with no valuable information being imparted and no plan for the day being developed.
The fix for this is simple and easy to achieve. Let the delivery team run the standup themselves.
By putting this into effect, you will see an immediate change in behavior as the team learns to share useful information with each other. The format of the standup is very likely to change to one where the team is talking about each story which is underway and who is doing what to complete it along with any questions or problems they may have. This is all great behavior and it leads to a valuable standup.
Here is my technique for making this happen. First off, I make sure that the team gets the message that the standup is their ceremony! It is for them and no one else. The Product Owner is there to listen and answer questions if asked (not to drive their own agenda on stories). The Scrum Master is there to ensure the tight 15 minute time box; that the standup starts on time and ends on time. They are also listening for any impediments that may need action. It is the delivery team who is the primary audience and participant in the standup. It is a planning meeting for them and them only. Once this is known, I set up a speaker rotation schedule, starting with the quietest person on the team as this helps set the tone for the conversation. The quietest is least likely to dominate the conversation and most likely to support actual conversation happening between team members. The most dominant person on the team is last on the list so that by the time it gets to them to facilitate the standup, the culture has been set already. The same team member facilitates the standup for an entire sprint, and then it rotates to the next member and so on. The Product Owner is instructed to speak only if spoken to, and the Scrum Master is instructed to ensure the meeting starts on time (including tracking anyone down who is late or hasn’t shown up) and to call the time once the standup is completed (of course allowing the team to continue any discussion afterwards), and that is it.
There is more than one reason to try this technique as I am sure you will notice; it can solve a number of problems with standups but the status report problem is the most common one.
Happy standups!
Regards,
Armistral