Embracing Empathy in Agile Standups: A Path to Effective Team Collaboration

Standups are one of the most misunderstood of Agile practices. On its face, the concept is simple: everyone reports what they’re doing, drilling into blocking issues as appropriate.

Then the questions arise:

Why is our standup so long?

Why does it feel like I’m just trying to show how busy I’ve been?

What should I even talk about?

Why do I care about someone else's work?

Why can’t management just ask me for my status if they want to know?

What’s the point of the standup, anyway?

Then someone with a hardcore Agile background comes along and proposes eliminating standups altogether because they’ve devolved to mere status reporting, and status can be collected asynchronously.

Empathy First

From an empathy lens, you can see how the lack of empathy drives these conversations. A lack of empathy drives a manager to focus standups on status, because they prioritize status over people. A lack of empathy drives your hardcore Agilist to propose abolishing standups, because they prefer efficiency over connection, though Agile is a fundamentally empathic process. (more on that in a future article.)

In this post, I’d like to cover the purpose of standup as I’ve used it on my teams, and how it has evolved over the years. The goal is to show how standups can be used effectively to promote team cohesion and effectively share relevant information amongst the members of the team.

Here’s the first, and most important point to consider:

Here are some examples to illustrate what I mean:

I'll have a code review ready in an hour. If someone could jump on it, we could get it merged by end-of-day.

Can I get another pair of eyes to look at my task with me? I'm not sure what's the optimal way to proceed from here.

I'd love to pair-program with someone on this task.

And so on.

The Standup is for the team's benefit

The “traditional” agenda of a standup – status reporting – should be second priority. As a manager, there are multiple other ways to get status that’s less costly. Leave the standup for the team.

Why is the standup the ideal medium to foster these conversations? Because, as a developer, it's all-too easy to bury your head into the task, trying to tread the path you've laid out before starting it. That path might be the most efficient one. Just as likely, it isn't, but because you're so focused on "what's the next thing I need to do," you never take the time to dive above the waterline and think about alternatives. Which means there's a good chance that you're taking longer at completing the task than you would with the team's help.

We’ll explore additional techniques to foster collaboration in future articles, but for now, just know that pair programming can be another effective tool to that end.

If your team is highly collaborative where you can have less tasks in progress at the same time than the number of people on the team (in other words, team members are collaborating on the same set of tasks) and folks on the team have a pretty good idea of the ongoing work streams, then ICs will tend to be more engaged during standup, and standups can take longer without feeling onerous.

Finally, in a highly collaborative team, individuals feel safer speaking up or even voting with their feet when confronted with an onerous meeting. If you feel bored at a meeting, leave.

If, on the other hand, your team is highly siloed (i.e. everyone working on their own thing), then a standup is just a meeting where each IC is forced to wait for their chance to speak. There’s little to no engagement between team members, and a pervasive feeling of isolation. Every team member is focusing on what they’re going to say when it’s their turn to speak.

Sound familiar?

So, first things first: 

Key standup components

At one point on my current team, our standups shrunk to 3 minutes for 8 ICs. We'd get into the meeting, bring up the board, ask if anyone is blocked on anything, receive the rote "no," and adjourn.

You might think that’s a good thing  —  a quick, minimally-invasive standup leaves more time for "actual work."

But there are two critical things your team misses if you practice standups of this kind:

1. Less-than-blocking issue exposure. The opportunity to engage the team on things that may not be blocking, but nevertheless involve some friction. For example, an engineer might be struggling with a difficult build system issue. They're not blocked–they know what steps to take to diagnose it–but leaving this information offscreen removes the opportunity for another team member to say, "oh yeah, I had that happen to me last week, here's how I resolved it." In other words, there's a huge gray area between "blocked" and "unblocked," and rushing through a standup leaves that gray area unexplored.
2. The social aspect of being on a team. This may not have been as important in the pre-COVID days, when everyone sat together in the same "pod" and went out to lunch as a group, but now that so many of us are remote, it's so frightfully easy to lose touch with your team, to stop thinking of them as human beings first. When things are rote that may not even be so terrible, but when the team hits a pressure point, that social lubricant becomes vitally important. People who don't interact outside of day-to-day work requirements will find it much harder to come together when the situation calls for it, as the foundation of trust required for the give-and-take of a high-pressure situation won't exist.   

A direct brought up this point, and it really resonated with me since. A standup, at its simplest, is a team organizing itself for the day. So, if you're coming out of a standup in the same state as you went in, having learned nothing, changed no plans, then (socialization aside) the meeting hasn't served its full purpose.

One way of fostering change in a standup is to ask a variation of a question like "What can the team do to make this task go faster?" Note that we're not asking, "What would make this task go faster?" because that leads to an instinctual defensive posture on the IC's part: "are you saying I'm slow?" That isn't the point and isn't at all constructive. The point of this question is to help the team organize around the problem and complete it as quickly as possible. There's no room for blame in this environment. Performance issues should be addressed 1:1 anyway, not in front of the entire team.

A Standup, Reimagined

Just as with any recurrent meeting, it's vital that both the manager and the team are clear on the purpose of the standup. Don't make it about pure status reporting. Standups are meant to be for engineers and meant to foster collaboration.

So, I recommend dividing up the meeting into three parts:

1. Quick run-through of tickets in progress. This can even be done offline, e.g. over Slack. The purpose here is communicating current WIP to the rest of the team.
2. Parking lot. Leave this section as optional attendance, for those who want to stick around to drill into some specific issue(s). The standup participants will add items to the parking lot agenda during the first part of the meeting, including communicating who they'd want to be present.
3. Connection. This section is also optional, though I find people tend to stick around for it. This is an opportunity for team members to demo something they’ve been working on, talk about their weekend plans, show off their dog, and so on. The focus here is on team cohesion.

The first part of your standup shouldn't be longer than 5-10 minutes. A parking lot can go for hours... if that's necessary, and only with the people who need to participate in the discussion. Finally, the connection section is volunteer driven. In practice there are days when the team has nothing to demo and nobody volunteers their weekend plans, and that’s fine. The key point is to make space for those conversations, even if it’s just a few minutes at the end of standup.

Together, these three parts will make your standup an instrument to foster team unity and help with communication, rather than a rote meeting your team members sleepwalk through.

A Manager’s Role

So what can you, as the manager / team lead / Scrum Sensei do to foster this? Here are the steps I would suggest, in that order:

1. Create a culture of continuous improvement, via team feedback channels such as retrospectives, 1:1s, parking lot discussions, etc. This is critical before making any changes to your process, no matter how small.
2. Position any changes you are proposing as an experiment for the team to run. Provide metrics for the experiment, e.g. engagement, cycle time, throughput, etc.
3. Propose modifying your current standup agenda to focus on collaboration-related topics, as mentioned above, as an experiment to try for a couple weeks.
4. Suppress rote status reporting in subsequent meetings, keeping the team on track with the experiment.
5. Solicit team member feedback on a regular basis, and feed that feedback into an experiment retrospective where the team decides whether to continue this new process or return to the old one.

If your team is anything like mine, they’ll never look back.