The Daily Scrum — Dos and Don’ts – Part 1

In Project Management by Prabhu Missier

Over the next few posts I will be presenting my observations and recommendations for the successful conduct of a Daily Scrum meeting. The opinions expressed are mine, formed and shaped by my experience working in and with Software Engineering teams.

1. Do – Start the Daily Scrum on time
As much as we would all like to revel in the camaraderie which exists in our teams, it is best not to let it interfere to the detriment of the Daily Scrum.
This is not the time to discuss the stock of coffee in the cupboard or continue the chat that started at the water-cooler. In other words let nothing delay the start of the Daily Scrum.

I have seen instances of folks gathering for the Daily Scrum and then getting side-tracked into a separate private Scrum of their own. Yes we do know you were not discussing last night’s game but that failed suite of Regression tests which ran against the latest build but let’s pause there for a second.


You are now wasting the minutes spent talking times the number of people waiting for you to wrap up your private conversation so that the Scrum can truly begin.

Well if it’s so important, then why not bring it up at the Scrum or schedule a meeting with all concerned to happen immediately after the Scrum. That’s a more professional way of doing it rather than resorting to a private Scrum.


So whether it be a project related discussion or comparing notes about your teens’ escapades, or you just can’t make it on time, when it comes to the Daily Scrum remember, remember that you should respect the team’s commitment to conducting it and respect and commitment are two of the fundamental values of Scrum.
If you can’t make it on time, just let someone in the team know and send out a note beforehand if possible so that the team knows what you are working on.

An occasional blip on the radar is fine but repeated delays to the start of the Daily Scrum are sufficient reasons for the Scrum Master to take notice and resolve professionally since it is in many ways an impediment.

Remember the old adage “A stitch in time saves nine”. Also making a habit of being punctual cannot in any way derail the project.

What might be even better is to try and start the Daily Scrum at the same time every day and in the same place whenever possible.
We do know that efficiency kicks in once anything becomes second nature. In other words once you condition your brain through repeated practice it shifts into cruise mode thereby increasing overall efficiency.
As a team, efficiency increases could be exponential and this would be manifest in the health of the team and the eventual business value getting delivered by the team.

2. Don’t – Launch into a lengthy discourse
This may sound ridiculous to seasoned Scrum practitioners given that every Scrum practitioner should know the time limits of various Scrum events but I have seen this happen many a time where someone in the team decides it’s their turn to bask in the spotlight.

Well yes, the whole team needs to know that you have saved it from near disaster but they also do not want to know how you decompiled the implementation of an Android API on Oreo and found that it used a zero based indexing scheme whereas Nougat used the same scheme but in an entirely different manner which turned out to be against the design criteria which has been set for the API when it was first introduced in Level 5 of the Android Platform and later revised in Level 6 but with a whole lot of bugs which were eventually fixed in Level 7.

Get my point. Yes I’ve seen this happen.

If you want to do some grandstanding, then the Daily Scrum is not where you do it. Of course you need to impress your manager and ensure that you get that high rating at the next performance appraisal or perhaps you sincerely want your team colleagues to know the real technical issues behind the problem.


Either way, the Daily Scrum is not where you will launch into a lengthy discourse and it is best conducted with everyone standing which gives everyone access to a natural indicator of the length of time they have been standing. Not everyone wants to break the world records for physical endurance.
It is no secret why the Daily Scrum is also popularly called the Standup meeting.


On the other hand you could indeed have something important which requires a lengthy explanation. You could then perhaps write a blog post on your technical contribution which is a much more professional way of documenting your contribution and expertise or have a one to one discussion with your manager periodically to discuss your contributions to the team.

At the end of the day, remember actions speak louder than words so follow the “KISS principle” at the Daily Scrum.

3. Don’t – Maintain a pecking order
Do not make it obvious who’s who in your team. They already know it and you don’t have to rub it in.

I have witnessed this in many teams I have had the good (mis)fortune to work with. For that matter I would recommend not even following the same speaking order every day.


One team I worked with got this right but, then messed things up by forcing the last person to join the Scrum to always be the first person to speak. Apart from being absurd, it was not very intelligent since the meeting always started on a punitive note. Hardly conducive to the long term health of a team.

So what’s it to be?

Nope. As the Scrum Master do not be the first one to speak up. Leading doesn’t always mean you have to be the first to speak up. As Scrum Master you are there to facilitate, so set up the agenda beforehand and set the table for the Daily Scrum. Let the team see what they are working on.

In other words, let the stories or features or whatever your team is working on, be listed clearly somewhere for the entire team to see along with the latest status of each of these items. Co-located teams could use a physical dashboard or something akin to a Kanban board and virtual teams can always use a web based tool to achieve the same result. You really don’t need to tie yourself up in knots getting familiar with a tool dripping with feature bloat just because it’s the de-facto standard.

Update your backlog daily and make it obvious to the team, what they should be focusing their time on and spend time talking about during the Daily Scrum. As a Scrum Master you facilitate the meeting and ensure that everything that has to be discussed is discussed but that’s it. You are metaphorically speaking — the teleprompter.

Let there be a natural flow to the whole Scrum meeting where all the pieces in the puzzle come together.

Of course this will not happen overnight but it is something a Scrum team should definitely aspire to.

I hope you liked reading this. Leave me a comment with what your experiences have been. More to come. Stay tuned…