Where did we go wrong with Daily Scrum?

Introduction

Based on my understanding of the role of a Scrum Master, among all the key ceremonies in agile development, the Daily Stand-up is one of the most challenging to execute effectively. I have often questioned the necessity of this daily meeting when implementing the agile framework. From my experience, these short sync-ups frequently fail to deliver real value, as the team perceives them as time-consuming within the sprint cycle. Instead of fostering collaboration, they tend to become mere status updates, task assignments, and fail to properly address the intended three key questions.

Although agile principles emphasize that the Daily Stand-up is an essential ritual for successfully managing software development projects, I wonder whether the theoretical framework does not always align with real-world applications or if my team and I have made errors in facilitating these meetings. What factors contribute to inefficiencies when conducting these daily check-ins within an agile workflow?

This article aims to explore the common pitfalls encountered in practical implementations of the Daily Stand-up, analyze potential mistakes from a broader perspective, and clarify the fundamental purpose of this practice—why it is considered indispensable when adhering to agile methodologies.

source : https://age-of-product.com/stand-up-anti-patterns/ 

Arise issues in the Daily Scrum process

Problems that I encountered while implementing Daily Scrum are as follows:

  • It is very difficult to gather everyone to attend on time every day, especially in the case of remote work. The members have to wait for another member’s lateness or unannounced absence. It wastes everyone’s time, and no one wants to look forward to the meeting.
  • During a meeting, which is often like a report session. Scrum Master investigates the Developer members about what they have done in the last 24 hours, everyone feels burdened by having to think of a task that they have done. For them, that is mere dogmatism.
  • The meeting often took longer than the allowed time, the work was estimated but not committed to the time of each item Sprint backlog, followed by the justifications and arguments for the problems they discovered, making the discussion more challenging, boring, and dubious.
  • If team members have more experience or are seniors, they manage their work better, as well as communicate better with the team, so all information during Sprint is constantly updated and self-arranged, thus having a Daily Scrum every day is not really necessary, I think.
  • In the case of Scrum Team has more than 5-6 members, the time will be longer, and people do not see the work connection but only lose their own time, people often feel that if they skip this meeting every day, they will get more tasks done in Sprint.

The issues mentioned above have made our Agile Team’s daily meeting less effective, creating challenges in applying this methodology overall and its five key events in particular.

Purpose of Daily Scrum (Stand-up meeting)

Thus let’s take a look again at the main purposes and the benefits of this event outlined in the Scrum Guide ( Source: Scrum Guide 2020) and analyze deeply why we are having these problems in practice.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Standup is a 15-minute gathering for the Developers within the Agile Team. To minimize complexity, it takes place at a consistent time and location each working day of the Sprint. If the Product Owner or Facilitator is actively contributing to tasks in the Sprint Backlog, they join in as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plans. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of Sprint’s work.”

Listed below are a few benefits of having a Daily Scrum meeting: (source: Daily Scrum: Why is it important?)

  • Let’s the team to be in sync with how things are going
  • Allows for corrections in the sprint.
  • Building trust between team members
  • Improving their communication
  • Encouraging personal planning
  • High visibility of progress
  • Self-organization in team

The Daily Standup is a crucial gathering for assessment and adjustment, led by the Developers, providing direction for the next 24 hours toward accomplishing the Sprint Goal. This brief session serves as the shortest planning window within the framework and plays a vital role in steering the team’s efforts efficiently.

Anti-pattern in the broader viewpoint

The theory is now very clear, so mistakes often come from misunderstanding the key principles in this event. Our encountered issues can be attributed to some of the common mistakes which people often call Anti-patterns when implementing this event (according to sharing about anti-patterns in https://age-of-product.com/stand-up-anti-patterns/)

Daily Scrum Anti-Patterns of the Scrum Team

  • Status report: The Daily Scrum seems to be a status report meeting, and Developers are waiting in line to “report” progress to the Scrum Master, the Product Owner, or maybe even a stakeholder. (The “three Daily Scrum questions” often serve as a template for this anti-pattern.)
  • No routine: The Daily Scrum does not keep happening at the same time and the same place every day. It makes this short meeting more complicated because it takes time to think about organizing work every day to prepare for meeting at different times and different places. In addition, If we can skip 1 meeting, why not skip the second or more. Whereas, if Daily Scrum is simple, consistent and becomes routine, we just do it without thinking.
  • Disrespect I: Other team members are talking while someone is sharing their progress with the Developers. That makes the speaker feel disrespected and hurt. Then they will tend to not want to share anymore next time.
  • Disrespect II: Team members are late to the Daily Scrum or do not show up at all. (This failure poses a massive risk for the Developers as they are inspecting and probably adapting their plan to accomplish the Sprint Goal based on incomplete information, thus reducing the probability of achieving the Sprint Goal.)
  • Excessive feedback: Team members criticize other team members right away sparking a discussion instead of taking their critique outside the Daily Scrum.
  • Overcrowded: The Daily Scrum is ineffective due to a large number of active participants. (There is a reason why the Scrum Guide recommends to limit the number of team members to ten. If the number of members is large, we should divide it into sub-teams according to each related department, holding Standup meetings according to each function will make Dev’s work more cohesive and effective.)

Anti-Patterns of the Developers

  • Cluelessness: Developers are not prepared for the Daily Scrum. (“I was doing some stuff, but I cannot remember what. Was important, though.”)
  • Planning meeting: The Developers hijack the Daily Scrum to discuss new requirements, refine user stories, or have a sort of (Sprint) Planning Meeting, probably collaborating with the Product Owner.
  • Problem-solving: Discussions are triggered to solve problems, instead of parking those so they can be addressed after the Daily Scrum.
  • Monologs: Team members violate the timebox, starting monologs. (60 to 90 seconds per team member should be more than enough time on-air.)
  • Statler and Waldorf: A few team members are commenting on every issue. (Usually, this is not just a waste of time, but also patronizing and annoying.)
  • Ticket numbers only: Updates are generic with little or no value to others. (“Yesterday, I worked on X-123. Today, I will work on X-129.”)
  • No impediments: No one reports any obstacles; no one needs any help or support from their teammates. (Congratulations on your seemingly well-oiled machine! However, maybe, Developers do not feel safe to address issues, challenges, or problems?)

Daily Scrum Anti-Patterns of the Product Owner

  • Assignments: The Product Owner assigns tasks directly to team members. (The Developers self-organize their work: “No one else tells them how to turn Product Backlog items into Increments of value.” Source: Scrum Guide 2020.)
  • Additional work: The Product Owner or even other stakeholders attempt to introduce new work to the current Sprint during the Daily Scrum. (This behavior may be acceptable for high-priority bugs, although the Developers should be aware of those before the Daily Scrum. Otherwise, the composition of the Sprint Backlog is the sole responsibility of the Developers: they may accept new work during the Sprint; however, that is their sole decision.)

Anti-Patterns of the Scrum Master

  • Daily Scrum enforcer: The Scrum Master is enforcing the Daily Scrum. (It is the task of the Scrum Master to ensure “[…] that all Scrum events take place and are positive, productive, and kept within the timebox.” (Source.) However, if none of the Developers believes that Daily Scrum is a sound investment, the Scrum Master cannot simply compensate for this lack of intrinsic motivation by using the Scrum Guide as a forcing function. They need to help to create the motivation on the side of the Developers to run the Daily Scrum in the first place. Enforcing the Daily Scrum is a common Taylorism artifact where trust in the Developers’ capability to self-organize is missing.)
  • Not supporting struggling Developers: A Developer experiences difficulties in accomplishing an issue over several consecutive days and nobody is offering help. Moreover, the Scrum Master fails to facilitate the necessary discussion. (Often, this result is a sign that people either may not trust each other or do not care for each other. Alternatively, the workload of the Developers has reached an unproductive level as they no longer can support each other. The use of ‘work item age’ has proven to be a helpful practice.)
  • Not preventing stakeholders from attendance: Although the Developers decided to limit attendance to the Daily Scrum to the Scrum team members, stakeholders show up uninvited, and the Scrum Master is not addressing the issue. (It is the Developers’ prerogative to decide how to run the Daily Scrum. If they choose to keep stakeholders away from it, this decision needs to be respected by everyone else. If stakeholders fail to do so, the Scrum Master needs to step in.)
  • Not enforcing the time-box: The Developers extend the Daily Scrum regularly beyond the 15-minute time-box. (This is unfortunate, as the extension of the time-box invites problem-solving and other activities into the Daily Scrum, thus distracting from answering the critical question: are we still on track to accomplish the Sprint Goal?)

Daily Scrum Anti-Patterns of the Stakeholders

  • Command & control by the management: Line managers attend the Daily Scrum to gather “performance data” on individual team members. (This behavior is defying the very purpose of self-managing Scrum teams.)
  • “A word, please”: Line managers are waiting until the Daily Scrum is over and then reach out to individual Developers for specific reporting from them. (Nice try. However, this hack is also unwanted behavior and distracts the Developers.)
  • Talkative chickens: “Chickens” actively participate in the Daily Scrum. (Stakeholders are supposed to listen in but not distract the Developers members during their inspection.)
  • Communicating via body language: Formally, stakeholders remain silent. However, they participate in the Daily Scrum via their body language. (Again, stakeholders are supposed to listen in but not distract the Developers. Yet rolling eyes and face-palming are as powerful as the spoken word. Moreover, even subtle forms of body language represent communication, as one cannot “not communicate.” Furthermore, some stakeholders may have a naturally intimidating presence that can prove harmful to the communication among the Developers.)”

Contrary to common assumptions, the Daily Scrum’s 15-minute time limit is not meant to resolve every problem. It aims to increase transparency, which will lead to the inspection. The Developers are free to address any issues that arise at any time, even if a change to the plan or the Sprint Backlog is necessary.

Conclusion

In summary, The Daily Scrum is a crucial ceremony in Scrum framework, which is an agile methodology used for software development. Indeed, the importance of Daily Scrum for the success of the Scrum Team’s effort to achieve the Sprint Goal is completely undeniable. Well uunderstanding the purposes and benefits mentioned above, we will find out that this event in theory isn’t far from reality and covers the cases in practice. The challenge is how we recognize the anti-patterns in the process, and fix them together to get this meeting back on track and give us the real value as its own. One way or another, it is a crucial responsibility of the Scrum Master to help all participants overcome typical Daily Scrum anti-patterns, and apply the right spirit of Agile to bring optimal efficiency in the software development process.

References

Would you like to read more articles by Tekos’s Team? Everything’s here.

Author

Hélène Avatar

Leave a comment

Your email address will not be published. Required fields are marked *

Comment
Name
Email
Website

Skip to content