Standup: You're Doing it Wrong!

Regardless of the length of your tenure in the software engineering field, you’ve likely encountered the idea of the Daily Scrum event (standup meeting) at some point, especially if you’ve worked on a Scrum team.

I’ve observed six common ways in which Daily Scrum goes wrong on Scrum teams. I’m confident in saying these are the six most common ways I’ve seen things go wrong.

My hope is, by the end of this article, you have a clear understanding of the common ways Daily Scrum can fall apart and you can identify some key concepts to help get things back on track in your own team.

TL;DR

For anyone who wants the short version of how things can go wrong, see below.

1. Terminology matters, It’s called Daily Scrum, not Standup.

2. It’s not 15 minutes.

3. It becomes a regular meeting about reporting out the status of each PBI.

4. The team regularly dives into implementation details.

5. The timing of the event is inconsistent, frequently being cancelled or moved around on the schedule.

6. Management gets involved, replacing the plans of the developers with the plans of management.

Daily Scrum, not “Standup”

Ah, the classic “Standup vs. Daily Scrum” debate! This daily meeting of developers is not called “Standup”, it’s a one of the five Scrum events called Daily Scrum. I can hear the mid-level managers booing me now, “why does it matter?! It’s just a stupid term, it’s all the same!”

In all seriousness, the wording does matter, especially for teams new to Scrum. The name of the event, Daily Scrum, is meant to convey the function of the meeting. Scrum itself is a rugby term used to describe the restarting of play by which players from both teams pack tightly together and strive for possession of the ball.

In Daily Scrum, developers must start their day with a plan. Specifically, their plan should be to gain ground towards the Sprint Goal, which is usually a piece of business functionality in the product. Daily Scrum is about restarting the workday as a team to inspect progress towards the Sprint Goal and adapt a plan that will place the team in an advantageous position to move closer to the goal by the end of the day.

Standup, on the other hand, is a term that comes from another Agile framework, called “XP” (Extreme Programming). Standup doesn’t focus on a single short-term goal, like a Sprint Goal; rather, the focus of Standup is to communicate the status of individual tasks and discuss technical details to help developers accomplish those tasks. This is still a legitimate and effective way to plan work in organizations that use the XP framework. It does not, however, align with the overarching principles of Scrum, especially in its absence of planning towards meeting a concrete Sprint Goal.

It’s not 15 Minutes

This is probably the most common issue across every Scrum organization. Developers spend far longer on Daily Scrum then the time allotted: 15 minutes. Ken Schwaber puts it perfectly: if you’re taking longer than 15 minutes, you’re doing it wrong.

Their are plenty of reasons this happens. Some of these reasons are described in the sections below, such as turning the event into a status reporting meeting and diving into implementation details. But, I think the biggest culprit is lack of a Sprint Goal.

Daily Scrum focuses on making a plan to move towards the Sprint Goal. Without a goal, the team tends to fracture, working on unrelated PBIs. Left unchecked by a Sprint Goal, these PBIs quickly grow out of hand, escaping the timebox of a short, 15-minute discussion. Each Daily Scrum becomes consumed by these discussions and, what’s worse, no real progress is made that aligns with the critical features of the product.

Keep discussion focused on progress towards the Sprint Goal. Make a plan for the day that moves the team towards that goal. By the end of the event, each developer should have a clear understanding of one item they’re going to work on that is reasonable to accomplish during their normal work hours.

Status Report Meeting

I’ve seen multiple teams fall into this trap, Daily Scrum turns into a regular meeting to report out the status of each PBI to management.

Asking for the status of a PBI, letting a PM or engineering manager know, or communicating the status with the team is completely legitimate. The status of work in Scrum should be transparent at all times. If something is preventing the status from being known, then the cause of the issue must be investigated and removed.

Anyone on the Scrum team, any manager in the organization, and just about any other person who wants to know the status of a PBI, should have a central place to view that status in a clear, unambiguous way. Having a well organized Kanban board that indicates the state of a PBI and captures the requirements, technical discussions, and questions about the work is a great way to eliminate the need for status report meetings and get Daily Scrum back on track.

On a related note, I’ve even seen some teams who traverse their board column-by-column, item-by-item and report out the “percentage” of work they think they’ve completed for each item. Because no one wants to seem like they’re under-performing, developers will end up estimating their items are something like “95-percent complete, but I just need to handle a couple more edge cases.” In reality, those “couple more edge cases” are more like a couple more days of work, but no one wants to verbalize this timeline when everyone else is reporting their PBIs are nearly complete. This whole concept is more fantasy than reality because methods for measuring knowledge work are notoriously unreliable.

Daily Scrum has been effective if the outcome of the event is a concrete, reasonable plan for the day that moves the team towards the Sprint Goal. If all the team did was report out the status of each PBI, then they’re only focusing on metrics that indicate past performance, they’re not striving to move forward towards accomplishment of the Sprint Goal, which means they are likely to fail to build new features.

All About Implementation Details

Daily Scrum is for the developers to make a plan for the next 24 hours. Since the event is hosted and facilitated by developers, there’s a tendency for developers to do what developers do… talk about writing code.

A developer zeroes in on a PBI and the rest of the developers chime in with their thoughts on how to write the code to solve the problem. This frequently bleeds over into other issues, like “if we write this method this way, then we should consider going over into features X and Y and apply the same solution there, too.”

Implementation details - how a problem should be solved and how the code should be written - are an important piece of the development process. Discussing these details with the team will help turn an okay solution into a great solution. However, 15-minutes of Daily Scrum is simply too short a window to illuminate great solutions. These details are best left to discussions among developers outside Daily Scrum; white-boarding sessions, pair programming, and even a draft of a pull request are all great approaches to dive into implementation details.

I want to reiterate, Daily Scrum is about making a plan to progress towards the Sprint Goal. Using up all the time to discuss the technical details of one or two PBIs leaves very little room to craft an actionable plan for the day. A small part of the plan for the day can, and should, be about coordinating efforts to discuss technical details through some of the means mentioned above.

Inconsistent Timing

Daily Scrum resets the workday for developers. In order to be effective in this reset, there needs to be a consistent pattern that is reasonable for everyone. If we reset the workday sometimes at 9:00AM, sometimes at 1:00PM, and sometimes we skip it completely, it becomes extremely difficult to create an effective plan for the day.

The reasons for this inconsistency are often well-intentioned. The team wants to accommodate Fred’s doctor appointment or Daphne’s sick day. They move the time of the event or cancel and reschedule it for the next day to ensure everyone can be in attendance. But, this means the rest of the developers are left without a team-oriented plan in the meantime.

A more effective approach is to always schedule Daily Scrum at the same time and place every day, regardless of one-off attendance issues. It’s much better to have three of the five developers make a plan for the day together than it is for them to make different individual plans while they wait for the rest of the team to arrive.

This doesn’t mean that the developers who have to miss Daily Scrum because of a sick day or an appointment must be left out of the loop. When those developers return, they should be given the opportunity to meet with everyone, updated on what was discussed, and included in the plans for the day.

Management Gets Involved

If a manager makes it a requirement that he or she must attend Daily Scrum with the developers, something is fundamentally wrong with how the organization in integrating Scrum. I’ve observed two key reasons for this behavior that recur across organizations: lack of trust and unwillingness to hand over control.

Lack of trust in developers abilities and unwillingness to give up control over planning work go hand in hand, and they stem from organizational behavior where two cultures have formed. In one culture, management clings to command-and-control philosophies of production. In the other culture, knowledge workers implement Scrum into their individual teams, separate from the rest of the organization. The command-and-control managers see Scrum as a tool to increase developer productivity, separate from their managerial responsibilities and the organization’s culture as a whole.

Take into consideration one real, very common example you may have encountered in your own team that highlights two cultures issue. The team’s velocity has been down for a couple Sprints and the engineering manager is getting pressure from above to get more PBIs completed more quickly.

The manager is observing the team’s performance not matching up with some of some of their recent successful Sprints. They think there must be an issue with how the team is planning and managing their work, so they step in to take the wheel for a few Sprints. In line with classic command-and-control style management, they try to timebox PBIs and pack the Sprint Backlog full. They then set the developers to work, telling them to work through each item in the Sprint Backlog, spending only X amount of minutes or hours per item.

In this situation, the team ends up feeling micro-managed, they feel the amount of work that is planned for them is unreasonable, and they feel enormous pressure to complete complex knowledge work in a very short time period. Developers might put up with this for a few weeks, maybe a month, at best. Eventually, the micro-managing, the unreasonable expectations, and the overflowing Sprint Backlog push the team’s motivation to a critically low level. The team’s performance tanks and velocity actually decreases further.

What’s a better way to approach this issue? This is actually one of the harder problems to solve because it’s indicative of a failure to integrate Scrum across the organization as a whole, not just the an issue with Daily Scrum. There are a couple suggestions I have that can remedy things long term.

Scrum teams should work closely with the Scrum Master to help guide them in communicating issues to management. In the previous example, developers and the Scrum Master should work together to identify why velocity went down and communicate their findings to the engineering manager. 9/10 of times I find that a team’s velocity went down because of a lack of planning. The Scrum Master can help guide the team back to a better planning process and help facilitate a better Sprint Planning event in future Sprints.

In addition, Scrum Masters should emphasize educating everyone in an organization to help them understand Scrum, not just the developers and Product Owners on individual teams. This is especially true for company leadership, who are often the ones with the most influence on how to integrate Scrum with their company’s culture.

Wrapping up

I’m sure there are plenty of others ways Daily Scrum can go wrong that I didn’t cover in this article. If you have some observations of your own, please feel free to discuss in the comments.

The important takeaway is that Daily Scrum is a key event in the Scrum framework to ensure developers can successfully build product features every Sprint by making incremental progress towards a Sprint Goal every day. If your team is shifting away from that concept in Daily Scrum, then other parts of the Scrum framework will lose their effectiveness and developers will get stalled.

If you would like to suggest a topic for our next article or you have some ideas of your own you would like featured in an upcoming article, I encourage you to reach out in a response to this newsletter or in the comments section on the website. I’m always happy to collaborate!

Thank you for reading and we will see you in our next article as we continue our voyage.

Code on,
Matt, Editor and Software Engineer