Questioning Stand-ups

When thinking about minimal agile always look for ways to remove process. One daily ceremony that might seem vital to your success is the daily stand-up. Most agile teams have some sort of stand-up and it’s a common delusion that this is critical to your success. We are collectively suffering from a bit of stockholm syndrome and that’s OK. Stand-ups are a band-aid to a deeper problem that is: poor team comms and isolation culture.

This stand-up could have been a slack thread

Do we really need to turn on our cameras and fire up zoom to tell each other that we are “not blocked”? If the purpose of the agile standup ceremony is to increase communication, visibility, transparency, and collaboration is a meeting really the best tool? The main benefit I see from zoom stand-ups is empathy building and helping folks feel less isolated. My main gripe with stand-ups is that folks gather up and bring blockers to standup rather than getting un-blocked in real-time. I have a few other gripes with standups, but lets focus on blockers for this post.

How-to: Ask for help

One of my favorite checklists is the how to ask for and provide help checklist. It looks like this:

  • Push your feature branch in it’s broken state as a draft pull-request
  • Add reviewers that you think can help
  • Comment on the exact line of code that is giving you trouble
  • Start a thread in the project channel mentioning the folks you think can help and a link to the PR
  • Move on to another problem

If your team is not code-first, replace the above branch and pull request language with tickets and documents most modern document apps have line-level comments and ways to mention people.

Fostering Kindness

For this checklist to work, we need to foster a culture of kindness. We use the 70/20/10 rule where most of your day is dedicated to working on tasks, 20% of your time is learning from others, and 10% is learning from outside resources. That 20% is where you need to be asking for help as part of your job. That could be getting a 2nd set of eyes on a problem, or getting clarification on requirements. If you are the one helping, then you are in your 70% work-doing part of your day. Setting this expectation can help remove the notion that you are bothering someone or taking them away from real work by asking for help. The reverse is try as well asking for help is your job.

Co-authoring in your network

To remove the structure of mentor/student from asking for help, lead with the word co-authoring. “Hey @Joan, can I get some co-authoring time on [link to PR]?” is a great way to keep thinking about your team as a network and less of a hierarchy. Sure, there are junior and senior people on the team, but we don’t need everyone reminded of that all the time. We all bring various talents to the team and I learn more from folks who are new to the industry more than I do from seasoned engineers.

Finding other ways to build empathy

Removing stand-ups from your process might lead to isolation for you team members. Folks like to see each other and co-authoring might lead to cliques forming. Look for other ways to build empathy into your process. I’ve been starting book clubs where we have a weekly 1-2 hour learning assignment that is on a general topic and a weekly meeting to hang-out and talk about the topic. If your team is on-site maybe a weekly team lunch is good. I’ve never tried an all-remote team lunch, but that might be something to consider.