DEV Community

Klee Thomas
Klee Thomas

Posted on

Your stand-up is bad, and you should feel bad.

TLDR:

Stop getting status updates from the people in your standup, and start focusing your team on the highest priority so they can deliver value.

Your standup sucks!

… and you know it.

You know your standup sucks because Every day, the team gets together, you go around the room, and the people on your team say yesterday, “I worked on JIRA-123, today I’m going to continue with it, no blockers”. Every now and then, someone bucks the mould and says, “I finished a JIRA-456; I’ll pick up something new today”.

You know your standup sucks because whenever “management is away”, the team will skip the standup or move it to be an async update on Slack.

You know your standup sucks because it blows out from 15 minutes to an hour-long debate.

You know your standup sucks because no one really cares what everyone else is doing.

Standup is important!

The easy next step when you realise that your standup sucks is to cancel it. Don’t do that; standup is essential. You’re just doing it wrong. The good news is that it’s easy to fix. It’s just a matter of moving the focus from the individual to the work and the team.

Standup should not be a status update. If you need a status update, get it from the Jira/Trello/Notion/whiteboard; it will tell you where all the tasks are up to and how your velocity is tracking.

What should you do to fix it?

Standup should be a chance for the team to focus on the next highest priority. Rather than asking people what they did, look at the board, identify the next highest priority, and ask, “What can we, as a team, do to move that task to done today?”

There is a key change in language here. Instead of addressing the individual using terms like “What did you do?” or “What do you need?” the language has changed to address the team: “What can we do?”. This small change reminds the team that they’re not a collection of individuals who code near each other. They’re a team, and teams work together to solve problems.

The impact of this change won’t be immediate, but as you keep using this new question and encouraging the team to work as a team to complete the highest priority items on the board, they will start to default to working as a team. This will mean that they’re more engaged at standup because the team is always talking about the topics relevant to delivering work for that day, not just listening to a status update.

Eventually, you’ll find that working as a team leads to less work being bottled up in your board's “review” column, higher throughput for your team, and lower cycle times.

This approach might raise a few questions for you,

“Does this mean that the team can only have one task in progress at once?” The answer to that is no. You can still have multiple tasks in parallel, but the team needs to assess, every day, what they need to do as a team to get the highest priority item done. Sometimes, that means everyone is working together on a single task. Sometimes, it’s going to mean giving someone space to solve the problem or the team moving on to something else while a blocker is escalated.

Aside: The extreme version of this is Mob/Ensemble Programming, which I’ll argue is the most efficient way to deliver value. I wrote about My Experiences Mob Programming here

“I have too many priorities; how do I know the highest?” Within a sprint, the rule of thumb should be highest priority item is the one that has been on the board the longest. You’ve spent effort on this task and realised no value. Lean tells us that “work in progress is waste”. The longer you’ve let a task sit incomplete, the more it’s costing you.

Top comments (0)