What's Probably Missing From Your Team's Standups

Among the various Agile meetings (aka ceremonies) there is one that stands out leaving much to be desired in its' effectiveness. Good ole' standup.

Good ole' standup.

Standups are (typically) performed early in the day to share individual work updates on status and progress. Standard Agile pushes for a short 15-20 minute length, "what I did yesterday, what I'll do today, and impediments/blockers to what I need to do" format, and ends with light discussions (aka parking lot.)

From observation over the years I've seen gaps consistently across many organizations and teams. Some creating extreme negative impact for everyone.

Here are 5 key areas to review with your team + specific improvement suggestions.

Actual Progress Updates

Observation #1: Low quality updates missing the most useful information

This is the biggest miss I've seen time and time again. Updates become a round-robin of saying words without actually absorbing them. It's like show and tell but no one is paying attention.

In the middle of "what I did yesterday" and "what I'll do today" lies the progress being made. Give 2-3 key bullets on what areas you are focused on, how its moving along, and if we are still on track.

Don't wait until it's too late! I cannot stress enough how important it is to communicate if things are slipping.

Engineering managers hold the highest responsibility with setting and managing expectations with product and sometimes direct stakeholders. Imagine a couple days into a piece of work we are falling behind which could break our sprint commitment. Each time we slip farther from the overall project delivery.

We can't get ahead of it if we don't know about it.

If the team is informed we can proactively solve the issue and support you. Another engineer could step in to assist. Or, an engineering manager like myself can get early communication to say a product owner. Tell them about the risk for XYZ and how we are handling the situation or where we need support.

❌ Bad Update

Yesterday I worked on ATL-34 for the signup form, today I'm still working on it, no blockers

✅ Good Update

Yesterday I completed the main functionality for the signup form ATL-34 adding the new components by Stacey and posting it to the API, today I'll be finishing the updates to the endpoint to save to the PSQL database + tests, we are on track to complete and there is no blockers, the API has been slightly unstable though, we may need to talk to DevOps if it keeps happening, two questions for parking lot

Not Digging In

Observation #2: Accepting updates at face value

A good update can help eliminate unnecessary discussions or fill in details quickly to improve efficiency. Often times though you will run into the need for more depth and extended discussions. The way we get there is by asking questions.

If the standup update was weak you shouldn't wait until the end. When they are finished ask something like:

• Can you talk about the progress were making?
• Any issues coming up?
• Are we still on track?"

If an item is in need of discussion you should state it. Bring it to the end of standup but make sure to call it out early. Something like "I implemented your component's John but I have a couple questions for parking lot."

Take Longer Conversations Offline

Observation #3: Discussions going beyond standup's scope

The last observation dives into the value of asking questions. Questions drive discussion. It's too easy to let these discussions slip into breaking standups efficiency goal. 15-20 minutes flys by.

Let's take this offline

It does not dimiss the value of the conversation but someone needs to step up and say "let's take this offline."

That could mean staying on after and releasing the team if the required persons are available. Or, setting up a meeting to discuss later. This is a time to be strategic.

Situations to consider:

• An engineer (or multiple) are working on a priority item that supersedes the need for the discussion. It would be in our best interest to schedule later.
• A product owner who is key to multiple discussions but fights an exceedingly busy schedule. You bombard them multiple times via different mediums vs a singular meeting.
• Not enough information is available to have an effective discussion. It's wasted time to talk about something we can't handle at that time.

Lack of Preparation

Observation #4: Arriving unprepared with your update + not updating tickets

This is for you devs! Standup is a meeting like any other. You need to arrive prepared with your update and that includes updating your tickets. Keep in mind that product, engineering managers, and other engineers are (or should be) leveraging the board to gauge what is happening.

Have you ever been at a place where product owners can't make it? Or, dont even show up at all? There in lies its own problem but this is also how we adapt to issues like this.

We must leverage multiple, consistent mediums that serve each role and their responsibilities. It doesn't tell the full story but we combine it with standup, other meetings, and inference. Leaning into standup entirely for updates is not the right path.

How about forgetting what you did on Friday the following Monday? Take notes. Winging an update leads to missed information and context.

Tip: All team members including product and engineering managers should be providing updates all the same. You're a team working together to deliver even if the responsibilities vary. It creates transparency, trust, insight into your work/progress, and may even expose overlapping connections between our work.

Synchronous Only Processes

Observation #5: Everyday standups and no asynchronous style processes

During COVID while managing multiple fully remote teams this observation popped up frequently.

You don't have to have standup everyday. It is important to stay in sync but work takes time. Not everything moves on a day-to-day basis. Standup can start to feel intrusive and less valuable. A meeting that's a chore will deteriorate. See observation #1 as an example. I've tested multiple styles such as every other day, twice a week, and even once a week.

So far every other day has been the most effective.

The power up we discovered during COVID was introducing async standups. We leveraged Slack in our team channel to provide updates all the same as the "✅ Good Update" described in observation #1. If discussions were needed we'd tag the relevant individuals. If we wanted to build awareness we'd drop a "cc @somePerson @otherPerson" in threads.

As they say, awareness is half the battle.

Async updates improved our overall efficiency and kept regular standups quality high. A great example was my early birds who would grind before 9am. Not breaking their focus kept them moving towards work completion.

Tip: Use threads in whatever messaging tool you use. The co-location of information makes it easier to relate and improves searchability. In Slack we like to rotate who owns standup. The async post format would be something like "@teamName 3/4/24 - Standup". Watch out for conversations getting to lengthy in the thread. Know when it's time to break out a new one.

Conclusion

There's a final point that needs to be said covering each observation holistically. The root of these problems stem from a lack of effective communication, expectation setting, and holding each other to it. Each role needs to align and commit to a process.

It is all of our jobs to stick this. Managers and more senior engineers, this is an explicit responsibility. Product owners that includes you too. 👀

Managers, you are a major key holder here. Set those expectations, provide fast feedback loops, and don't wait until retro! Early and often communication solves so many common issues.

- DD