Daily Scrum- Tools and tips

One of the agile principles highlights the significance of the face to face communication between the team members of a team and between the teams in general. To encourage and empower face to face communication we need to provide solid examples supporting the value that we can have from a 15 minutes meeting. It is really amazing how much we can learn, identify, realize and also pro-act that could save the day or even better, make our life easier and more effective.

One of the first questions you usually receive as a Coach or a Scrum Master, is the following "Do we have to wait for the Stand Up to share my updates or communicate any issues or impediments?" The answer of course is no. You have a full day to act and align and as a self-managed team you are encouraged to do so. In this case, why do we really need the stand up?

The answer I usually give is simple, the real value is hidden in the details and those details are shared between all the team members at a specific time on daily basis. The daily Scrum is the time where all the team members talk to each other and update each other. The element of transparency increases the value given to the Scrum team and builds more trust.

The Stand Up is the Dev team's time to share their progress and impediments and align with each other. Each team conducts the ritual in different ways and as long as the team is aligned, it means that mission has been accomplished. On the other hand, there are some behaviors and patterns that help you identify that Stand Up ritual is not conducted in such a way that returns the expected value to the team.

Let's see a few cases that helps us identify this:

Behaviors that reduce the Stand Up value

  • Low interest in joining the Stand Up
  • Too many technical discussions
  • Team is not standing close to the kanban board
  • Team is not updating the stories/tasks on the kanban board
  • No proper updates and in many cases no updates from team members
  • Change of the time or delay because "we are too busy to join"
  • No focus on the Sprint backlog
  • Unable to identify or raise impediments that fail the team at the end of the Sprint
  • Dev team joins the Stand Up and reports to Product Owner or Scrum Master or Management

These are some Stand Up behaviors that a Scrum Master should know that if he or she observes that happen in his or her team, should raise flags and take actions. One of the approaches to support the Dev team to be agile and not do agile, is to design such a Retrospective at the end of the Sprint and reflect back to the Dev team, why is important NOT to do conduct the Stand Up in any of the ways mentioned above and highlight with solid examples why is important to turn a 15 minutes meeting into a proper team alignment meeting based on transparency. If you run after the Dev team on daily basis asking them not to do that or to start doing ABC, you are sliding from the pull to push approach and at the end of the day, the Dev team will hate the ceremony and never understand the value of it.

How to "fix" the Stand Up

One of the first things you need to understand as a Scrum Master, is to be able to identify if for any reason there is a lack of trust between the Product Owner or Management and the Dev team. An indication to this is the fact that the team is standing up for 15 minutes and instead of synchronizing, they report to someone. In this case we might need a root cause analysis to find the real reason and take action items.

As a Scrum Master you can provide tools to the team to use that will help them synchronize. For example visualize an impediment log which each of the team members can add his or her impediment either during the Stand up or during the day. Another tool, is the Stand Up parking lot. In case you observe technical discussions, or any other discussions that have nothing to do with the synchronization of the progress and status, you simply add it on the parking lot and take it offline. A burn-down chart could also help the team to get the big picture of the Sprint, and by visualizing and updating it on daily basis in the team room, we can see the trend on daily basis and take actions how to approach the stories and deliver them on time. Having also the Sprint goal visualized is a good opportunity to link the Stand up questions to it, by simply asking "What did I do yesterday and what will I do today that will help the team meet the Sprint goal".

The most important thing for a Scrum Team is to be able to understand who has the ownership of the Stand Up ceremony and it needs to be clear that the Dev team owns it, is conducted from them for them, and the Scrum Master should make sure that the team is getting all the value that will lead eventually to a successful delivery of the Sprint backlog.

Konstantinos Kareklas