Stand Up for Banality!

 

This isn't a proper modern standup if it doesn't last at least 30 minutes and have one person enraged by the end.

I finish my abuse of everyone's favorite meetings today with some notes on stand-up meetings.  Of my top 3 most reviled meetings, this is the one I'm most ambivalent about.  A stand-up, if run correctly, can actually provide significant value to the team and management.  However, the caveat is if run correctly, which would apply to any meeting, so I guess my statement wades deeply into the redundant.

A proper stand-up has a basic structure:

• A duration of no more than 15 minutes.  No exceptions.
• A max attendance of 10 people to keep communication overhead to a minimum.
• A 3-question format:
• What did you do yesterday?
• What are you doing today?
• Any blockers?
• Some deviation or follow-up on someone's status is permissible, but it shouldn't stretch past 30 seconds.  Anything that begins to wander off-topic or requires additional time is at risk of receiving the "offline" label.
• Anyone has the right to call "offline" to keep the group conversation moving.

That's pretty much it.  Despite the simple structure, the stand-up has become one of the most reviled meetings by software engineers over time.

Why?

First, the meeting often lasts 30 minutes (sometimes more).  As a result, it loses any semantic connection to its name.  A stand-up meeting is so named because standing up for an extended duration is uncomfortable for human beings, so the stand-up portion is intended to limit that duration and keep the meeting from expanding its scope.  Oh well.

Since the meeting is now an extended duration, it's at risk of becoming a standard status meeting, and it usually does.  In theory, according to strict agile practices, anyone not performing the actual engineering work should either not be present (under the guise that engineers will be more honest when free of the watchful eye of management) or should be silent. 

I find such a rule to be overly prescriptive.  If engineers don't feel comfortable talking about their work in front of their manager, there are much larger problems facing the team.  And, if managers can't keep mostly quiet for 15 minutes, they need to reevaluate their management skills.

I do think engineers should drive the meeting, but having a manager present may help short-circuit any blockers and reduces the need for a separate status update at a later point.  I also think, rather than having a rotating scrum master to ask the 3 questions above, the manager should consistently assume the role of moderator.  I never quite understood the rotating scrum master position other than to reduce any documentation burden on one particular individual.  That burden should consistently reside with the manager so they can compile the information and ensure they're digesting it correctly.

With the bloat of a 30-minute meeting, the principal participant is either a manager or a Product specialist.  There also tends to be an increased focus on agile boards, which adds even more overhead.  Now, people can't simply rattle off their status in 3 sentences; they begin to fixate on whether or not the board item is documented correctly, in the right column, and how accurate the estimate of the item is, all of which is extraneous to the day's core conversation.

Answers?

As with the previous two meetings, a little bit of effort can turn things around.  A small part of me laments the traditional daily stand-up.  It was a signal for the day's beginning and a chance for the team to greet each other formally as they shuffled in (ceremony isn't always a bad thing if it adds some basic structure to the work day).  Of course, we had the benefit of having the whole team co-located, which reduces a lot of complexity that otherwise plagues a stand-up.

I was adamant about holding it to 15 minutes (averaging around 10) for a 6 to 8-person team, of which I'd use surplus time to provide relevant team status updates, thus precluding the need for a separate team meeting.  Further in-depth discussions could occur immediately after in pairs or small groups as necessary.

Moving to a more globally dispersed company and the pandemic effectively killed the in-person stand-up and created major hurdles to my cherished little tradition.

For time zones that are near enough, there's always the video conferencing option.  I've heard of several teams that, regardless of where the employees are located, will hold their stand-up at the same time for everyone.  Hooray for consistency!  Boo for any practical considerations and work-life balance you're trying to instill.

[Note: I've always taken issue when someone responds with "we're a global company" any time I've complained about ass-backwards scheduling.  That's neither an excuse nor a reason - it's a mantra people keep chanting to keep the corporate gaslight lit.  There is no particular personal advantage I've ever seen of working for a global company other than to have my schedule distended and my ability to plan my day around core hours completely shot to hell, all so I can be a bit player in corporate community theater.]

Even for those who are in similar time zones (or the same timezone but at extended distances), a Zoom call can have a much higher barrier to participation than its physical counterpart.  A stand-up is intended to be as low maintenance as possible and video conferencing adds the burdens of connectivity, software updates, mute issues, and more connectivity to the problem.

Psychologically speaking, for me at least, 15 minutes of video time seems to drag on way longer than 15 minutes IRL (unless that 15 minutes is me watching Netflix to procrastinate before attending my next scheduled call).

That leaves Slack updates (or something similar) as the best option.  No surprise here - I'm perfectly fine with that.  In fact, I'd prefer that.  Assuming that we keep things distilled to the 3 major questions, the effort shouldn't require more than 1-2 minutes of an employee's composition time.  Because it's in writing, it can (as mentioned before) be viewed asynchronously and heads off the annoying, but inevitable I'm sorry, I zoned out for a minute looking at LOLCatz photos.  Can you repeat your status again? snafus.

Engineers on my team have had mixed responses to the written option in particular, which caught me by surprise.  I found some of the feedback to be reasonable.  Some of it, not so much.

Statements centered around - why do we need to do this every day, especially if no one's reading - typically render me unsympathetic.  There needs to be some sort of status update.  We can't be cogs in these gigantic capitalist machines without indicating to our overlords that we're making some sort of progress to enrich them.  The less ceremony and overhead the better, but in the current system, status is a way of life.

If no one's reading, that's a reasonable gripe, but the entire update requires about 2-5 minutes to read, and you're doing it to help your peers when they're stuck and to see if there are issues you can help out with.  Work at building the habit of reading daily status and helping to improve it if it lacks consistent informational value.

I'm also fine if status is less frequent but on a cadence.  However, realize that will likely require the time needed to summarize several days' worth of work rather than just the previous day's.  Sparsity also causes issues when managers need to report to their own bosses on the team's status if the cadences are mismatched (though if everything were asynchronous, this wouldn't be as big an issue).

I'm more sympathetic over concerns that repetitive reporting of several days' lack of progress can be demoralizing to the individual.  However, I'd also argue (and have) that such a report is a clear signal to a manager or team lead to help understand why the blocker remains in place.  Everyone faces slumps.  They're no fun.  But having a visible support network helps people get through the rough patches and instills them with confidence the next time they face a problem.

Finally, I'd be remiss if I didn't mention the Scrum-of-scrums which is ostensibly a compilation of several teams' stand-ups.  Scrum-of-scrums is just a more circumlocutious phrase for "Status Meeting."  So just don't hold it.

Until next time, my human and robot friends.