The Boring Daily Status Update

Do you feel like you’re stuck in a rut facilitating a boring standup meeting? Every day, one by one, engineers flatly read their status off a task board. “Yesterday I coded, today I will code, no blockers.” Sounds like you’re stuck in what I think of as the standup status update trap.

By now, most software engineering teams have adopted some form of Agile software development, and one of the ceremonies of this process is the humble standup. What should be a quick, light, synchronous meeting can devolve to a rote recitation of the tasks in progress.

Here’s how to fix it by injecting dialogue into the process rather than reading off a task board.

Start with Why

Standups should provide context, direction, and a forum to quickly course-correct on the question of “why are we here?” The dialogues held during standups are discussions on the tangible steps needed to complete team goals. It’s never too early to demonstrate that outcomes matter by inspecting the progress of the team against those commitments.

Try this: to review the team goals/commitments at standup, ask, “When are we releasing X?” or “When will X task be ready for our stakeholders to review?” or even simply “What do we need to complete to accomplish X goal?”.

Build Accountability into the Process

Every task should have a single owner. Successfully completing a task might require multiple engineers or even multiple teams over a period of time. But one person should understand they are directly accountable for the successful outcome within a sprint.

Try this: ask the person accountable to provide a summary of the tasks in flight, who is currently working on which items, and what is needed to ensure completion within the committed timeframe. Bonus: this is a great leadership-building activity for senior engineers on the team.

Mix It Up and Dive Deeper on Next Steps

The mind quickly adapts to patterns and routines. Make sure as facilitator that you’re keeping the meeting fresh by mixing up the process of reviewing tasks. Work your way through the meeting by project, person, domain, or even simply “top-up” and “top-down.” Remember that some tasks will have hard deadlines and should be reviewed first, but everything else is up for grabs.

Try this: ask open-ended questions that connect an individual task to the owner’s next steps. “Is that where you expected to be today?” “When will your contribution be ready for the next person/step?” Anyone can read the task board; the conversation we’re trying to facilitate is commitment to completion, not the current status of an item.

Let Go

There is no law that says standups have to be held every workday or that you have to be present at every meeting. Part of mixing it up is learning to let go and let others facilitate. Be at peace with missing this synchronous update from time to time.

Try this: set up an async team reminder in your team channel for team members to post updates as they come online. Cancel the ceremony on days when the team is together for other Agile ceremonies. Check in via other asynchronous forums, like a simple memo: “Any action items for me?” Letting go shows your team, “I trust you to manage without me.”

Blockers

But how will you know if there are impediments? Parking lot items? My opinion is that relying on a once-daily synchronous meeting to bring these items to your attention is a symptom of under-communication within the team and something to work on independent of standups.

Try this easy way to check with your team on how they feel about standups: ask if they’re OK with canceling one or two standups a week. If there’s positive response, then you’re leaving a lot of value on the table.

#agile #scrum #kanban #standup #sprintceremonies #scrummaster #engineeringmanager #meeting #timemanagement

Author’s Note

Written as a corporate LinkedIn piece.

Significant revisions

tags: 2024, management, agile

  • Jul 7th, 2024 Originally published on https://www.jsrowe.com with uid E3C2DF76-E36B-4BBB-8834-349C4B365D26 cross published on LinkedIn
  • Jun 26th, 2024 First draft

EOF/Footnotes

Start With Why