Standup Meeting Playbook

The “Standup meeting” or “Daily Scrum” that everyone does religiously just for the sake of calling themselves “Agile.”

The name does not matter; you can call it anything. I like to call it a “Huddle.”

Intent

If we look at the Agile Manifesto, it does not describe how to manage your project. However, two methodologies come to our mind:

1. Scrum, which is the most popular; The “Daily Scrum” comes from that.
2. Extreme Programming is considered to be the best implementation of Agile.

Although terms like “Standup meeting,” “Daily Sync meeting,” “Daily Scrum,” and others may have distinct definitions, we should focus on the meeting from the Agile perspective instead of religiously following each one’s process and definition.

Over the years, as “conventional” project managers converted to the Agile way, Agile lost its core value, and so did standup meetings. Agile transformed into just another project management process, and developers found themselves increasingly detached from its original essence.

Values

If we look at Agile values, it focuses on “Interactions,” “Collaboration,” “Delivery,” and “Change.” Remember these while creating your own rules for standup meetings.

FAQs

Q: What is the ideal frequency?

Usually, every day. However, if all the stakeholders interact frequently and do not need to know the status, you can meet less.

Q: Where?

Anywhere the whole team is comfortable. Physical or remote, does not matter.

If you are conducting it remotely, always have videos on. You want to talk to humans, not animated figures!

Q: When?

Ideally at the start of the day. However, if everyone is not available or working remotely in different geographies, you can do it anytime.

Q: What content?

• What did I do towards the iteration goal?
• What will I do next?
• What is inhibiting me from achieving my goals?

Q: How granular?

Remember, it is for the team. Your updates should be at the right level, so everyone can understand and contribute to the project goal.

Q: Duration?

Ideally, a maximum of 15 minutes. Every team member should speak for only 2 or 3 minutes. If there are too many participants, and the meeting cannot be concluded in a 15-minute timeframe, it is a different problem. Ideally in such cases, divide the team instead of shortening individuals’ time or increasing the duration of the standup meetings.

Q: Should I be standing up?

Since the goal is to keep the meeting short, adopting a psychological approach, standing up tends to lead to brevity. If your standup meetings consistently exceed the allotted time, you should definitely transition to standing meetings.

Q: Should we hire a scrum master?

If you are married to the process of Scrum, then sure. But, if your focus is on Agile values, you don’t need to.

I disagree with the concept of having a Scrum master. The word master is terrible anyway. It also brings all the micromanagement, like tracking the burndown chart like a hawk. I have seen very bad standups where a “scrum master” will go through all the issues on the board and ask everyone for a status.

People who are going to talk should take charge of their own work, from updating tickets to delivering and updating others in the team about it.

We should rename that to Agile mentor/coach, even if we want someone to teach Agile principles.

Q: Should we hire an Agile coach/mentor?

If you observe that the team is not doing what they need to do or doing what they shouldn’t be doing, then an Agile coach can help streamline that. Also, in this case, don’t make the Agile coach your process.

Q: What should be the Agile coach’s role?

They teach the team to follow the practice and create other Agile coaches. Remember, Agile coaching is not a permanent process. It is just an initial push. These are just the people who know how to conduct the meeting effectively.

Q: What is a facilitator?

After the Agile coach/mentor moves on, one of the team members steps up as the facilitator, playing a role akin to an internal Agile coach/mentor. They kick things off and ensure a smooth exchange of the baton. Avoid sticking with a single facilitator; keep the rotation going among team members.

This goes without saying, but you don’t need a facilitator if you think your team is mature enough to handle things.

Q: What order?

Choose whatever suits you.

Some like the alphabetical order, some like the current position they are sitting in, some like facilitator assigning, some like the last person nominating the next person.

You can be creative as far as meetings are short and effective.

Q: Do I need a burn down chart? Or any chart or board?

That is a great way to visualize the status. However, status is not the goal; action item is the goal. Anything that helps the project. It helps identify whether you need to organize yourself and the team better.

Another way is to have just sticky notes or cards in a dashboard. Identify how many cards should have been moved and their current status.

Any tool that publishes data is good enough.

Many teams don’t even use any! (These are very mature teams. I would recommend having some visual representation.)

Q: Our team is small. Do we even need a standup meeting?

In theory, if you have a mechanism like a storyboard or sticky notes on the wall that keeps you informed about the project status, a separate meeting may not seem essential.

However, I would still recommend having a standup meeting, even for a two-person team.

Wearing a different hat often leads to remarkable insights. To explain this through an analogy, take the example of the “duck debugging.” When stuck with a problem, a developer tries to explain it to a rubber duck, and surprisingly, a solution often emerges.

Similarly, conducting a standup meeting to share the project status can unexpectedly provide insights or generate solutions. Even if the audience is already informed or not particularly interested, the act of vocalizing the information can trigger valuable discussions.

In essence, the standup meeting becomes a valuable process for problem-solving and maintaining a shared understanding of the project.

What not to do

Too granular

“I worked on the order class and implemented that method”, “I worked on liquibase scripts”, nobody cares and should care about that. Make it abstract enough as if the recipients are non-developers. The meeting is for the project, not yourself. Don’t go too technical.

Focus on the task or story’s completeness or challenge.

This is one of the reasons the meeting becomes boring. Because nobody understands what the other person really means, so they stop paying attention to the other person.

Cutting each other

Only one person speaks!

This is one reason why the meeting continues after the designated time and lasts for even an hour!

Everyone addressing one person

The meeting is not a project status report meeting! It is a sync up call. Everyone should address the team, not the team lead or project manager.

Non-developers or attendees who are not directly working with the team should be quiet or give their updates to everyone like any other person but never be a receiver.

Slip in other things

“Let me show the demo of what I did”, “Hey, if you are facing this issue, then do this to solve it”, “Why don’t you do this?”, “Why don’t we do this?”. None of this should happen. Everyone should focus on only strictly updates. Nothing else.

Did I say nothing else?

If you want another conversation, meet after the meeting and have a separate meeting with a smaller group. Even if the next meeting will have the same participants, don’t do it now—organize a separate session for that purpose.

Now you might have a question-

But we work only remotely, and this is the only time the whole team is together; I would want it to last a little longer and combine other things.

Even in that case, keep the standup time shorter. Do other things after officially concluding standup. You can wear a different hat after that.

Remember, the standup should be completed on time in a short duration. The meeting or call can be extended with the same or different participants.

Too many updates

“I worked on setting up that server then talked to Bob then talked to Yoda about order detail then talked to Groot about invoice preparation” — How does this help the project? Why should anyone care?

Number of updates or time you take to update others is not a measure of success or hard work.

Absence of context

“I worked on ABC-549 and ABC-588 and will keep working on that”. Although this looks good enough, not everyone may have the context for what “ABC-549” represents. Consider saying, “I’ve been working on the order detail screen.” This provides clearer information for everyone involved.

Not using burndown chart or team board because it is not updated

If you have another way to get the project status, then it is okay to not have a board. However, having incorrect status for tasks/stories is not a good reason not to have a board.

Always keep your tasks/stories updated with the latest status as soon as you make progress. Don’t wait for standup to update those.

It is always better to have some visual representation than not having any.

Sticking to one process

Don’t make your standups boring. Standup is a practice; its effectiveness must be questioned, and ways of improving must be part of retro discussions.

Honorary addition

Lately, some teams have started introducing non-project related and team-related talks in the meeting. Those are not bad. Those help team building. Some examples are as follows,

• How was your weekend?
• What did you learn recently?
• What books are you reading?
• How are you feeling?
• Do you want to thank anyone?
• Anything you are excited about this week?

These additions are great at creating a more connected and collaborative work environment.

Photo by Igor Omilaev on Unsplash