The daily standup is an indispensable ceremony practiced by countless agile teams because it gives them a regular opportunity to communicate, review progress, and take corrective action. Most standups follow a simple script and include the famous three questions (mentioned below), which make it appear easy to master.
Yet many teams squander standup time by falling prey to common anti-patterns that limit their effectiveness. If you recognize one or more of these in your team, your standups could use a tune-up.
The standup seems easy
Part of the appeal of the standup is its deceptive simplicity. Each day, the team comes together for a short discussion of its progress, plans, and problems, with brevity encouraged by the expectation that participants will remain standing throughout the meeting.
The discussion is typically framed by some version of the following three questions:
- What did you accomplish since our last meeting?
- What do you plan to do accomplish before the next meeting?
- Is there anything impeding your progress?
These questions allow the broader team to understand what you have already done, what you are about to do, and whether you need help with anything.
Many teams miss the point
Because the standup is so simple in concept, it is easy to underestimate the work that should go into it. The three questions often lull teams into a rhythm of mechanical compliance in which they answer the letter of the questions without satisfying the underlying intent.
The standup is not principally a mechanism to demonstrate that you are worth keeping on the payroll because you are doing things, nor is it a place to impress your colleagues. Nonetheless, a large number of teams treat the standup as though the three questions are as follows:
- Have you been doing anything useful?
- Are you going to do anything useful today?
- Are you competent enough to get your work done without help?
These teams approach the standup as though it were a performance review conducted by a shortsighted manager. Participants aim to show that they are pulling their weight. As such, their answers predictably amount to something like the following:
- I was busy yesterday (as evidenced by the fact that I worked on such and such).
- I will be busy today (because I plan to work on this and that).
- I don't need anybody's help to make progress.
Day after day of standups approached this way leave everybody numb. If the outcome of the three questions is to repeatedly establish that people have something to do and that they know how to do it, then participants will start to tune each other out pretty quickly.
Standups will devolve into tedious round-robins in which people spend all of their time thinking about themselves. Before their turn, they will stare at the ground as they internally compose their own updates. After their turn, they will nod politely toward other speakers as they mentally plan their own day.
How to tweak your standups
Standups would be dramatically improved in most teams if participants answered the questions in a way that fostered interactions meant to enrich the participants. Meeting participants should look to expose details that would be meaningful to an attentive listener who could become helpful, or helped, due to the information presented.
They should try to answer the three questions more along these lines:
- What specific things did you complete yesterday, and how would you briefly describe your approach to these things? (This would allow the rest of the team to know how it relates to their own work, and give them a chance to later ask you questions or give you advice about your methods.)
- What specific things do you plan to work on today, and how would you briefly describe the approach you intend to take? (This would allow the rest of the team to later share pointers if they have done something similar, or to approach you about swarming on a task when needed.)
- What would allow you to go faster or do your work better? (This would allow the rest of the team to offer assistance in the form of advice or swarming, even when you are not actually stuck.)
Approaching the questions in this way would help to underscore the real purpose of the standup: to share useful, actionable information with the rest of the team so everyone can collaborate more productively to achieve the sprint goals.
Signs of a troubled standup
A team that approaches the three questions mechanically and treats the standup as an opportunity for self-justification, rather than improved collaboration, will exhibit a number of identifiable problems.
Kym Gilhooly has already noted several of these, such as giving the same report on two consecutive days, in her article on "6 basic things you shouldn't be doing during daily stand-up." Here are some others you should watch out for, and how you can help correct these behaviors if they appear in your team's standups.
1. Same description of previous and planned work
Countless standup contributions would fit neatly into the following template:
"Yesterday, I worked on <Story X>. Today, I plan to continue work on <Story X>. I have no impediments."
This tells us nothing beyond what we already knew after sprint planning—that a certain developer was going to work on a certain user story. The problem here is that there isn't enough detail about the work being done.
If other team members can't discern any difference between the kind of work done yesterday on a given user story and the kind of work being done today, they don't have enough detail to either offer or request advice relative to the work being done. They are also less likely to see an opportunity to assist by swarming.
How to tune: Scrum masters, agile coaches, or other attendees who hear updates such as this can gently probe for more information by asking how the work differs between the two days. If another team member publicly suggests a follow-up discussion with the person giving the update, so that they can exchange ideas on the specific approaches revealed by the probing, the usefulness of the extra level of detail will be immediately reinforced. It will likely only take a handful of probing instances before the whole team is trained to give enough detail to differentiate between work planned and work already completed.
2. Never having an impediment
If we had a collection of standup transcripts compiled from agile teams all around the English-speaking world and we created a phrase cloud from the transcript contents, I can confidently predict the words that would appear in the center of the cloud in an overwhelming font size:
no impediments
Most teams seem to view the mention of an impediment (sometimes called a "blocker") as tantamount to an admission of inadequacy, as if an impediment means that they can't get their work done independently. Given that mindset, they rarely mention an impediment in the standup.
Yet the water-cooler discussions of the average team are also full of complaints about work environment, bureaucratic hurdles, available information, and so on. Many of these water-cooler grievances could translate directly into reported impediments.
Teams need to start thinking of impediments in terms of "what is slowing me down" rather than "what has stopped me." To think or say that something has stopped you feels like failure. But most people are more than willing to talk about the points of friction that are keeping them from going faster.
Teams need to frame impediments in this way—as points of friction—so that they surface more of them. Discussing these points of friction allows for the possibility of others providing near-term help and makes it possible for the team to see patterns that may affect multiple members across multiple sprints.
Some judgment is required here, because not all points of friction are productive to mention in a daily standup setting. Ineffective organizational structures, troublesome individual personalities, and a host of other things that transcend a given iteration are best discussed in retrospectives or other forums.
Still, most people could regularly list impediments if they tried a bit harder. Any of the following could be reasonably cited as an impediment:
- Lack of familiarity with a tool, technique, or technology (e.g., I've never made a REST call to a Jira instance before and need to learn the API structure)
- Lack of connectivity between two systems (e.g., I need to call the preproduction version of the XYZ service, but an internal firewall keeps me from accessing it)
- Lack of access to some internal system (e.g., I need to provision a new virtual machine but don't have the appropriate rights)
- Lack of realistic test data (e.g., I need to understand the typical range of customer balances due so I can format the payment screen appropriately)
- Lack of equipment (e.g., I need a headset for the phone calls I make in our open office environment)
Noting things such as impediments greatly increases the chances that a team member could help you to go faster by pairing with you to teach you something, introducing you to the right people, pointing you to the correct ticket queue, or showing you some kind of workaround.
How to tune: Scrum masters, agile coaches, or the team in general can compile a set of impediment prompts (such as the list above) to help standup attendees understand the meaning of an impediment and surface common impediments in their environment. The most respected and credible members of the team should go out of their way to mention impediments so as to make them culturally normal and remove any stigma associated with raising them.
3. Limited follow-up conversations
Standups are supposed to elicit and distribute information about the team's work. Timely, meaningful information results in some kind of action, and so effective information-sharing sessions will commonly precipitate follow-up activity.
If the standup is achieving its goals, you should expect to see instances of brief back-and-forth during the standup, and follow-up conversations afterward. For example, a person's update might be met with offers of assistance to solve a mentioned impediment or a request to discuss an issue in more detail after the standup has ended.
Once the standup ends, the people involved in these exchanges may come together to confer further, or at least to establish when and how they will pursue the subject later.
If your standup routinely consists of a series of isolated soliloquies without any follow-up conversation afterward, people are just going through the motions and giving an oral version of a written status report. There isn't much value in having a group of people gather in a room to says some things they could have posted to a wiki.
How to tune: Scrum masters, agile coaches, or the team in general can look for connections that start conversations and prompt the team to pursue these. Example prompts might look like this:
- "I think Susan worked on something similar a couple of months back. You two might want to compare notes after the standup is over."
- "Can anybody help Sandeep get access to the cloud management UI?"
Again, having a few influential members of the team go out of their way to have and encourage such exchanges will go a long way toward establishing a healthy team culture. In addition, the previous tune-up suggestions (giving meaningful accounts of work done and surfacing impediments) will naturally lead to more follow-up conversations.
4. Problem solving during the meeting
Some teams have another challenge, with standup participants jumping immediately into problem-solving mode during the standup itself. In many ways, this is a great problem to have, since it reflects a healthy culture of mutual support.
But the standup is intended as a brief, lightweight triage session that helps the team orient to its current situation. Solving problems during the standup draws the meeting out and tends to be inefficient, because most problems require only a subset of the team for resolution. If you problem-solve during the standup, you detain other members of the team needlessly and make the length of the standup unpredictable.
How to tune: Confine any back-and-forth around problem solving to a small window of time, such as 30 seconds. If the discussion goes beyond that, it needs to be curtailed and moved into a follow-on conversation. Scrum masters, agile coaches, or the team in general can be watchful for instances of extended problem solving and can encourage the participants to work things out after the standup.
Even if the problem involves the whole team, moving it into a follow-up session (perhaps right after the standup) is the right thing to do, since this will set useful expectations for how standup time is to be used.
5. Reporting to the 'leader' instead of the team
Agile teams are intended to be self-organizing, with limited hierarchy. While there may be certain central roles (e.g., product owners and Scrum masters) for some functions, the object of the standup is to keep the broader team informed rather than to keep any specific individual informed. This is another way in which a standup differs from a traditional status report given to a manager or project manager.
Nonetheless, even in the absence of an explicit team hierarchy, it is natural for team members to reflexively direct their reports toward certain figures, such as a Scrum master, product owner, or senior developer. So team members might face those persons during their updates, attend mainly to the reactions of them, and tailor both content and presentation toward their presumed preferences.
Obviously, other people on the team can hear what is being said regardless of where it is directed, but the "leader" focus is still undesirable because it tends to cause others to disengage. If I am in a conversation with two other people and they are directly facing each other, I will naturally start to withdraw, either because I feel like a third wheel or because I can see that my attention is not important to them.
When people direct their updates to some specific leader, the rest of the team will inevitably feel as if they are not "on duty" during that update, and their focus will drift elsewhere. This dynamic mitigates against the sort of collaborative and mutually enriching information sharing that is the real goal of the standup and leads the team to devolve into a status-report mentality.
How to tune: When it becomes apparent that participants are directing their updates to a specific leader, the leader should take steps to redirect their focus. For example, the leader may consciously look at the floor during the updates, so that the speaker seeks the positive reinforcement of eye contact from elsewhere within the team circle. The leader may also be strategically absent at times to reinforce the idea that the standup is not for the leader but for the entire team. Such small gestures will help to redistribute the focus of other team members and establish better reporting habits within the team.
Check under your hood
The issues described above are especially problematic because they are often subtle, and it may not be readily apparent to all participants why these behaviors are bad for the team.
Virtually every agile team I have ever observed is afflicted by one or more of these anti-patterns, and there is a good chance that the teams in your organization suffer from them as well. Fortunately, tuning up these limitations in your standups probably won't be difficult, and will likely bring real value to your team.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
