6 Simple Rules To Lead a Better Daily Scrum Meeting
Years of experience leading daily meetings have actually made me appreciate them, and today, I’m sharing my recipe.
Scrum daily meeting; that’s a conflicting topic nowadays. I’ve read many articles or heard friends hate on Scrum lately, specifically about the daily.
I’ve been a lead developer for almost five years now and have been running daily stand-ups for even more time than that. During this time, I’ve had to face some of the most redundant issues and what I hear most people complain about:
- There are too many people in the meeting, and everyone wants to give his opinion or share his life story, so the session lasts forever — I’ve done one hour daily at some point; nightmare-inducing, right?
- The manager comes only to micromanage, asking questions like “Why is this taking so long?” making everyone scared to talk.
- Developers are too shy or lazy or think it’s useless, providing zero value to their teammates.
- Developers want to fix their issues live during the meeting, wasting everyone’s time.
- Scrum Master wants to lead everything while being so out of touch that the meeting becomes useless.
Throughout the years, I found a solid formula for daily stand-ups that everyone from my previous teams liked — that I know of. It helps us prevent issues, build team cohesion, and optimize developers' time — yes, you can win time while spending fifteen minutes in a meeting, I promise.
1 — It’s a meeting for developers by developers*
As a lead developer, I’ve already had to tell persons from outside the development team, like managers, that they could be invited to the daily as a guest if they wanted and if all the team agreed, but they were not allowed to talk.
Each meeting should have a purpose — sadly, not always the case — and the daily’s goal is for developers to discuss what they are doing, prevent any roadblocks, and make sure the sprint is going in the right direction; that’s it.
Most developers hate pointless meetings, which plague most IT organizations. The daily should not be considered one of those pointless ones.
*: I’ve actually started to ask the product owner / QA to talk about the tickets they reviewed and say a few words about any QA problem that needs to be addressed by developers. This takes one minute to prevent misunderstandings and back-and-forth questions between developers and product owners in the ticket.
2 — The Scrum master role should be the lead developer.
This might be a controversial take, but one I genuinely believe in.
I haven’t had many dedicated Scrum Masters assigned to my teams throughout the years, but the few times it happened, it did not bring much value.
Sorry for all the potential Scrum masters reading this, but a lead developer with a good knowledge of Scrum will always have the better tools to perform the job.
He has a thorough technical and functional knowledge of all the tickets. He understands other developers' issues and which action to take to resolve them, pairing with the product owner if needed.
3 — Lead by example: be precise, be concise.
You need to tell information your teammate might need or something they might have to say about.
Are you starting a new component? Say it! A teammate can tell you if it already exists or if you might reuse something and adapt it.
Are you changing the behavior of an existing functionality? Say it! A teammate might tell you to change it at a place you wouldn’t have thought to check.
Are you unsure about an architecture or a database schema you are implementing? Say it! It’s better to discuss it before having to redo everything a day later because you got it wrong.
Have you unconventionally fixed a bug? Say it! It might occur again after some time when you’re not there, and everyone should at least have it somewhere in their brain.
And please, please say out loud anything you do that is not in a ticket. It’s even better if you write it in a ticket and talk about it during the daily.
4 — Include all developers as equals.
We’re a team, and not everyone is at ease talking in public; they might not know what to talk about or even think the daily is useless. We’re all made of good and bad experiences; not everyone is alike, and you must consider that.
Make everyone feel included by actively listening, asking questions, or sharing the knowledge they might need for their tasks. It’s a two-way street, and the goal is to bring the team together.
I’ve joined teams where some developers were not saying anything except the infamous sentence: “Still working on ticket X, that’s it”.
After some time spent working their brain during the daily and trying to connect, they eventually started opening up.
This needs critical soft skills to please different personalities; sometimes, you’ll face the kind of person who doesn’t want to change, and that’s life; you do the best with what you have. You need to navigate around them so they impact the team spirit at a minimum.
5 — The daily is a safe place.
We’ve all been there, stuck for days on end on a stupid bug that has nothing to do with the ticket — I hate you, npm! Or that day when your productivity is at its lowest because it’s not your day.
The daily is supposed to be a time of sharing between teammates; it’s perfectly fine to be honest about the issues you faced debugging or your lack of productivity the day before.
I believe that for a productive team, cohesion and trust are the most essential aspects — of course, if every day is not your day, it starts getting an issue, and we need to understand why.
I’ve actually started multiple daily saying that I’ve had a shitty day productivity-wise and did not do much the day before. Still, I will destroy tickets today and actually do so. It builds trust with coworkers; everyone is human, and there is no need to hide it for the corporate facade.
6 — If it’s too long, take it elsewhere.
Is the issue you want to discuss during the daily need more than two minutes to find a solution?
Decide who is available to help you and talk about it after the daily. We’re not here to waste everybody’s time on the technical decision. Having everyone aware of it and finding someone to fix it is more than enough.
If other developers need to know the result of the discussion, you can say a few words during the next day’s daily.
This needs to be enforced by the lead developer. It’s not a problem to cut in the middle of a discussion to ask people to stop talking and start discussing it again once the meeting ends.
The role of a leader in a daily is really important. You’re supposed to be the one that brings liveness and order to the meeting. Please don’t let it be just one developer after another saying they are working on ticket X.
Every person is different, with a wide range of experiences and personalities; you must adapt to everyone with empathy.
It may appear challenging, down-right impossible, to request your boss to stop micromanaging and have faith in the team or to persuade a stubborn developer who refuses to communicate to explain their work in more detail, but it is certainly worth a shot.
Thank you for reading this article until the end. If you liked it, please don’t hesitate to follow me on X (Twitter) or add me on Linkedin.
