{{announcement.body}}
{{announcement.title}}

When Daily Scrum Goes Bad

DZone 's Guide to

When Daily Scrum Goes Bad

Is your Daily Scrum no longer providing the benefits it once did? Or did it never work? Read on for some possible solutions.

· Agile Zone ·
Free Resource

Are Your Daily Scrum Neetings Taking More Than 15 Minutes?

In Michael Mankins’s and Eric Garton’s book “Time, Talent, Energy: Overcome Organizational Drag and Unleash Your Team’s Productive Power”, they state that most people spend on average 11 hours per week in meetings. The point of meetings is to communicate. Communication is a common problem in large complex software projects and constant (daily) communication is key to successful project management. This is why the Daily Scrum is so important. Daily Scrum (when done correctly) optimizes team collaboration and performance. The goal is for everyone on the development team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours. According to the Scrum Guide, a Daily Scrum is a 15-minute time-boxed event that is held every day of the Sprint. If you are consistently going over the 15 minutes, your Daily Scrum might be going bad. If that is the case, then one of two things could be happening:

  • Inefficient Scrum

  • Teams are too big

Inefficient Scrum

During the daily scrum, each team member should answer the following three questions:

  • What did you do yesterday?
  • What will you do today?
  • Are there any impediments in your way?

If more detailed discussions needs to happen, individual (or a group) team members should meet immediately after the Daily Scrum to discuss those issues in more depth. This will allow you to adapt or change the rest of the work in the Sprint. One sign of an inefficient Scrum is going into too many details during the Daily Scrum (i.e. a lack of discipline in the the 3 questions above). Another issue is providing updates not related to the Sprint. This can happen if people outside of the development team attend the Daily Scrum. Daily Scrum is designed to be an internal meeting specifically for the Development Team. If other people attend, it is the job of the Scrum Master to ensure that they do not disrupt the meeting. To keep things efficient and productive the goal is to answer the three questions. If developers are not able to answer the question, “What will I do today?” then it could be a problem with the Sprint planning and what needs to be accomplished during the Sprint.

The Team Is too Big

If you are being efficient with your Daily Scrum, and still running over the time then there maybe too many people on your team. If too many people are providing updates (especially updates that are not relevant), people lose interest. Jeff Bezos famously has the two-pizza rule for both meetings and teams. The rule is that each should only have as many people as two pizzas can feed over lunch. The more people in a meeting, the less productive the meeting will likely be for all involved. The Scrum Guide suggests having between three and nine team members who are actually executing the Sprint backlog. One way to think about this is every person is a node and they link to other nodes. Those links are the relationships between the nodes. Each relationship requires energy (time) and communication. As the team grows in size, the relationships do not grow linearly, they grow exponentially. Which requires exponentially more communication and energy (time).

Conclusion

No one likes meetings, but they are necessary on complex projects so that everyone knows what everyone else is doing and how their work is affecting other people. Understanding the dependencies between your different software modules can help you optimize your teams and keep the Daily Scrum from going bad.

Topics:
daily scrum ,agile ,standups ,scrum ,scrum master

Published at DZone with permission of Sean Barow . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}