Daily stand-up anti-patterns

I want to talk about some of the anti-patterns I’ve noticed in daily stand-up meetings. These things will mostly apply to remote teams, as that’s where I have the most experience. Full disclosure, I’m not a fan of daily meetings, but I understand that they can be useful in some cases. Especially if you avoid doing some of these things:

Telling everything you did yesterday (absolutely everything)

I think this is pretty common. People feel like they need to justify their existence, so they start listing every single thing they did yesterday. No one flags it as a problem, so it becomes a habit, and later spreads to the previously unaffected team members. Before you know it, you’re spending 30 minutes on a stand-up meeting.

This is a problem because it’s a waste of time. The stand-up meeting is not a status report, you have other tools for that, like Jira or Trello. The main value proposition of the stand-up is to share only the information that is relevant to the team as a whole, and to identify blockers. Most of the things you did yesterday like code reviews, meetings, or interviews are not on that list.

Not prioritizing blockers

There are three types of things you should be talking about in a stand-up meeting: what you did yesterday, what you’re planning to do today, and what blockers you have. Blockers are usually mentioned last, but they are the most important. You can deduce what someone did yesterday by keeping an eye on the Kanban board, and Github PRs. Mentioning what you’re planning to do today is also important, but if nothing is blocking you, it’s not as important as talking about the actual obstacles you’re facing.

The best thing about daily meetings IMO is that they ensure that no one is blocked for too long. It might be scary to admit that you’re blocked, but it’s better to do it sooner rather than later. The longer you wait, the more time you waste, and the more time you waste, the more time you waste. It’s a vicious cycle.

From my experience, not every daily meeting brings actual value. If no one is blocked, and everyone is in sync, there is not much to talk about. You can still have the meeting to keep the habit, but it should be over in like 5 minutes. If it’s not over in 5 minutes, the only good reason for that is that someone is blocked, and you need to help them. I really stand by this.

Side tracking

It’s also very common for the discussion to go off track. Someone mentions a problem, and the team starts discussing it. Before you know it, you’re 20 minutes into the meeting, and you haven’t even finished the first round. This is a problem because it breaks the flow of the meeting, and it’s not very productive to involve the whole team in solving a single person’s problem. It’s better to take it somewhere else, like a separate meeting, or a pair programming session.

Fighting this pattern is hard, because it takes a lot of awareness to notice when the discussion is actually going off track. It’s also hard to stop it, because people are naturally inclined to help each other, and it’s hard to say no when someone asks for help.

Depending on it for all your communication

The number one reason why I’m skeptical about daily meetings is that they can become a crutch. If you know that you have this specific time every day to talk to your team, you might be less inclined to talk to them outside of that time. This is a problem because it creates an unnecessary bottleneck. It’s much more efficient to talk to someone when you need to, rather than at a specific time every day.

But being a realist, I know that not every team has communication figured out. Developers (especially those who choose to work in a remote environment) are often introverted, and fiercely independent, so they might not be inclined to talk to each other unless they absolutely have to. In that case, daily meetings are a good way to force them to communicate. But, you know, it’s still a crutch. I don’t have a solution for this, but I think it’s important to be at least aware of it.