If you've worked on a dev team for any length of time, you're probably familiar with "the standup": that daily, time-boxed, status update by all members of the team where each answers three questions: what was worked on, what will be worked on, and any blockers encountered so far. The emphasis is on keeping the meeting brief and time-boxed (typically 15 minutes or less).
While the basic goal of a brief time-boxed status update meeting are the same across all the teams I've worked on, I've noticed that specific details on the approach used can have a significant impact on how effective these meetings are. Below I briefly discuss 3 different approaches I've experienced, and what I see as the pros/cons of each, using the example of 3 fictitious teams.
Team A: Everyone gathers in the same room, and provides their updates one after another. No meeting notes are typically taken.
Team B: Everyone posts written status updates in a shared chat, followed by a shared call to answer any questions. No meeting notes are typically taken.
Team C: Everyone posts written status updates in a shared chat channel. Everyone signals they read each status update by posting a emojii reaction. Each status update is its own thread, and any questions about the status update are asked and answered in the appropriate thread (which serves as a form of meeting notes).
Team A's primary benefit is probably ease-of-adoption and simplicity. No additional tools are needed, and it can be conducted anywhere. It is probably the approach that teams just getting started with Agile often use. However it comes with some notable cons:
- Temptation to ignore time-boxing constraint, causing meetings to drag on longer than the allotted time. Disclipine must be taken to ensure that each participant sticks to the time-boxed nature of the meeting by answering briefly. Especially when reporting on bugs, conversations have a tendency to derail into a problem-solving brainstorm unless carefully managed by the Scrum Master.
- Since no meeting notes are taken, any decisions that come as a result of the standup are often forgotten soon after. Worse, as there is no written record of decisions and status updates, different team members might leave with contrasting views on what stage a task is in, what decision was reached, etc.
Team B's approach mitigates both issues with Team A's, although it does require all team members to use a shared chat:
- The written nature of status updates helps trend toward brevity, as well as encouraging clarity in writing since each team member has the opportunity to compose and edit their update as much as desired prior to communicating it to the team.
- The status updates themselves form a kind of meeting notes, helping to ensure a shared understanding of what stage a task is in.
However, the follow-up shared call can easily exceed the time-boxed allotment, as well as suffers from the same problems as Team A's approach for the status updates because any discussion that does occur is not recorded.
Team C's approach seems the best to me (and is the one currently employed by my current team). One nice addition is the use of emoji's to indicate that members have read an update as it helps provide visibility that all relevant parties are aware of the status of a task. Further, while standups typically discourage discussion to keep the time-boxed nature of the meeting, the use of threaded chats seems to provide a way to include discussion without it detracting significantly from the ability to quickly digest the status updates of each member. The main potential con I can think of is it might be more difficult for members that don't excel in communicating by writing.
For myself, I can't imagine going back to Team A's approach, and would only reluctantly go back to Team B's, but I'm curious to hear from the wider DEV community: what standup styles have you encountered? Which have you found to be effective (or not effective)? What best practices and anti-patterns have you observed?
Top comments (0)