Before starting, I’d like to highlight that I don’t like working with Agile Frameworks™ like Scrum. Like most people in software, I know how to do it. I lead teams working with Scrum and other similar methodologies… there’s a use case, it can work just fine. It’s just not what I personally find the most efficient and pleasant day to day. This being said, I love the concept of a daily standup meeting. That’s even usually the first thing I setup when joining a team if it’s not there already. However I don’t really run standups like daily scrums, so I figured it’d be interesting to share

How I like to run daily standup meetings

If I were to lead a new team today, here is how I would explain my vision for standup meetings:

• The objective of this meeting is to share interesting things relevant to your team and raise blockers. What we find “interesting” will vary depending on context. Use your best judgment and don’t hesitate to ask the group if this is interesting to them.
• To get there, we’ll meet daily at 12:03 before lunch for approximately 15 minutes. Some days it’ll be 10 minutes, others might be 20, but we won’t diverge much more than this. I’ll be the time keeper if need be, but I count on you all to keep things brief enough.
• This is an ephemeral meeting. There are no boards, no notes… if something critical is shared, it must be repeated in writing asynchronously (email, Slack…)
• This is not a reporting meeting. Actually, it is completely fine to not share a thing some days. It’s even encouraged as you most likely don’t do something worth sharing every day. Yes, I mean it, and you’ll see me do it.
• You will hear updates not impacting you directly. Maybe things you don’t understand fully. This is normal and by design. However your goal is to pay attention to everything, be curious and try to understand what everyone is sharing. Don’t hesitate to ask questions after the meeting.
• Every few months, we’ll challenge this format and adjust if needed. This includes cancelling it of course. What I’m proposing here is the result of years of small iterations…. I like it a lot, but it’s not a one size fits all, but we have to start from somewhere!

“Interesting” things ?

This part is voluntarily blurry to leave room for interpretation depending on the team composition and general context. To make it more real, here are topics that I often see shared:

• Discoveries (new tech, new part of the stack, new business opportunity…)
• Feature progress (started, significant milestone reached, release, feedback from data…)
• Upcoming projects (discovery results, feedback from research, business or legal requirements…)
• Reliability problems (bugs, outages, post mortems, performance changes…)
• Changes in organisation (new hire, new team…)
• Personal events (babies, change in apartment…)
• Blockers (need a review, communication issue, lack of clarity…)
• Office related news (new policies, upcoming team building events…)

What this is not about

This is meeting is not about:

• Updating a board (can be done asynchronously)
• Reporting or tracking tasks (same thing, much better asynchronously). This is especially true since not all team members will share an update each day.
• Holding people accountable. People present are professionals and should not need a daily meeting to make sure they are making progress. If someone is struggling with this, it needs to be identified and handled elsewhere.
• Planning the day. This can be done in smaller more focused groups. It also doesn’t need to be done every day and team members should be empowered to manage their projects as autonomously as possible.
• Forcing people to be present early in the morning. Yes, I saw that happen.
• Necessarily reaching a specific goal. Since this is not done in the context of Scrum, there might not be a sprint or a sprint goal. Reaching the goal will be a byproduct of a having cohesive and efficient team.

Main benefits

To me, the main benefits of meeting quickly once a day is:

• Build empathy with others team members. Before you get a big PR to review, you will have heard the engineer in charge talk about it, share technical choices and struggles. You’ll have more context on the code, but also in the mindset of the person. Are they late? Stressed out? You can adjust your communication accordingly. Same thing if the PM shares some pressure from the business or market.
• Discover what others are working on, even if you’re not directly impacted. Through the years I’ve learned so much about the work of engineers in fields I knew less about by listening to them explaining daily what they were going through. It’s even better if product designers and PMs are also present and sharing their work.
• Create opportunities for additional discussions. If you stay locked on your tasks and tickets, you might be more productive short term, but you will have a very narrow focus, limiting your capacity for impact.
• Get a general pulse of the team. Are people feeling good, productive and positive, or is everyone struggling? This is especially important in distributed teams where you can’t count on discussions at the coffee machine.
• Build an intuitive understanding of who works on what. Hearing someone talking about a topic for months will stick with you and help you redirect questions to the right person when needed.
• Improve team dynamics and cohesion. Just like regular weekly 1:1s with your manager is key to build a working relationship with them, having regular interaction with your teammates is much more effective than a once a quarter workshop. Bonus:
• As a side effect for on-site teams with similar food culture, doing it before lunch is a good way to end the morning and help people going to eat at the same time. This is very cheap team building and can help facilitate even more connections between people.

Frequently Asked Questions

I’ve set this up in many teams over the years, and I think the overall result was positive. I don’t think 100% of the people got 100% of the value, but the ROI was good enough for me to keep doing it. This being said, here are the questions / comments / problems that are often raised. This is disruptive, I’m better left focused on my coding task. Since this is every day, you can plan your day accordingly to limit this impact. Even though, I agree that this is disruptive. However, just like regular 1:1s, this is an investment. It might not feel worth doing today, but the value is visible after regular practice. You might think that your role is purely [writing code / creating figma designs / setting up PRDs / …], but it goes further than that. Understanding your team is more important than you’d expect, and investing this time will help you smooth future interactions and save time and avoid headaches down the line. We should do it asynchronously to save time. Since the goal is to build empathy, increase connection between team members and cultivate curiosity, doing it in writing feels unproductive. I’m yet to be convinced that reading a Slack message has the same impact than seeing someone share the same information verbally. This will also leave a written trace and will, after a while, lead to people feel like this is just reporting. No one will understand what I’m working on. It’s true that sometimes you will work on something tricky that only you will perfectly understand. If that’s the case, it’s completely fine to spend a bit more time to explain what this is all about. You might need to repeat more often the context which is a bit more work. However it will have the double benefit of onboarding more people on your topic and force you to learn how to make your deep projects more understandable. I’m a designer, I am not interested in what developers are doing. Sorry, but I think that this is not a good way of looking at things. Understanding engineers and having engineers understand you is key in your success if you are in the field of building software. Thinking that development is just implementation details will limit what designs you’ll be able to get in front of users… and unless you see your work as only producing mockups and static assets, you probably don’t want that. I’m an engineer, I am not interested in what non-engineer are doing. Sorry, I also think that this is not the right approach. It’s insanely helpful to understand more than just tech when building products. It might not be your cup of tea, but it feels reasonable to hear about design a couple of minutes a day. This will help you identify shortcuts, make design debates smoother and give you keys to challenge proposed solutions that are too complex. I would encourage you to see your job as more than just writing code, and opening up to new fields is a great way to get there. You don’t need to be an expert, but here you have the opportunity to learn by just paying attention a few minutes every day… seems like a good deal! This is yet another meeting, we already have too many meetings. If you have many other meetings, I’d rather review and cancel those. Just like weekly 1:1s with your manager, I think the daily standup is helping reducing the amount of meetings by preventing problems and misunderstandings… so removing it, while freeing up 15 minutes, will cost many more hours down the line. This is not a Scrum-compliant meeting. We need to be in front of a board and move tickets. This is indeed not a daily scrum, it doesn’t have the same objectives. You say that this is not reporting, but it really is. I agree that you will share things that you are doing and it can feel like reporting. However we will not be tracking this, share it outside the team and so on… so this feels far from a progress report. Also, you are encouraged to share what is interesting, and sometimes this won’t be direct progress on your tasks. This means that this would be an imprecise reporting tool and I really much rather use our normal ticket tracker to see what is going on instead of counting on this meeting. I don’t feel confident sharing nothing at the standup. If you are new to the team, this is normal. Don’t worry, you’ll see me and others do it and it should make it less intimidating. Can you really share nothing? Yes. If nothing happened you can just say “nothing really interesting since last time”. If you just kept working on exactly the same thing, you can share “I’m still on [task], nothing new to share”. Of course if someone has absolutely nothing to share for multiple days in a row, this might be a signal that something is wrong. It doesn’t happen often, but from experience this can be the reason:

• The person doesn’t think their topics are interesting. In this case it’s worth taking a minute to highlight why people might want to hear about a specific part of their work.
• The person has a deeper problem. This can be with the process, the work, the team, the company, the task, life in general… this one should be handled on a case by case basis and is usually visible outside of the standup.
• The person is stuck and doesn’t feel safe to share it. Usually this goes away after seeing others sharing blockers.