Top 5 things NOT to do in your agile daily standup
How (not) to run an Agile standup
I know how to run an agile daily standup, right?
Most people probably think standups are straightforward, and that any idiot can run them. This is not at all the case. A lot of people are doing it wrong – don’t be one of them! This article will describe the top 5 things you should not be doing in your daily standup (I see people doing these things all the time). I have also included some quick tips that I’ve picked up over the years to make sure these things don’t happen, or you can fix them if they do.
Top 5 things to not do in your daily agile standup
Status reports
The daily standup is not a status report meeting. If you see everyone in the standup waiting for their turn to give a report to the “boss” (the scrum-master), this is a bad sign. Everyone should know the status of the work: it is visible on the Visual Management Board and probably exists in one or two bug-tracking or reporting tools. The scrum-master is not the “boss” or the “manager”, it is a servant-leadership role. The scrum-master should generally attend (to make sure they are across any blockers raised, and to pick up the feel for the team and their interactions), but the main purpose of the meeting is for people in the team to coordinate and discuss the work: where they are getting stuck, what problems they might need help with, if they have some spare capacity to help someone else, and so on.
Quick tip: if you notice everyone looking at the scrum-master when they answer their Three Questions, they consciously or sub-consciously feel they need to give a “status report”. They should be looking at the rest of the team or at the board.
Problem solving
The purpose of the standup is for people to give context to the rest of the team as to what they are working and if they are having any problems. It is not for deep dives or problem-solving. For example, if someone says “I’m working on the tests for the Registration feature, but I’m having trouble setting up test data”, that’s fine, and hopefully someone will offer to help. But the details of that conversation should take place after the standup. If two people then start a long discussion on test data setup, you need to park that conversation, because it could take a lot of time and might not be relevant for other people in the team.
Quick tip: If someone asks one question about someone’s update, that’s fine, but if a second question is asked, the conversation should be “parked” (i.e. moved to after the standup).
Sprint planning or backlog refinement
The standup is not the place to plan out the sprint or discuss requirements. The only work on the board should be work that has been clearly defined and moved from the Product Backlog to the Sprint Backlog at the beginning of the sprint (or before it).
Quick tip: make sure you have regular Sprint Planning meetings booked either on the first day of the sprint or the last day of the previous sprint. You might also want to set up regular backlog refinement meetings (Scrum is strangely silent on this matter – I think most teams will need them).
Vague updates
This is a big warning sign: when people answer the first or second question with vague statements or mumbling (“yeah I’ve been getting stuck into some user stories, looking over some code, getting some things done, it’s going pretty well, no blockers”). This is usually a clear sign that the person is working on things not on the board or not related to the project at all. That could be because they’re being pulled onto work from other teams, they are creating their own work for this project that hasn’t been defined or agreed by the product owner, or they are just losing interest and engagement.
Quick tip: get each person to point to a user story or defect on the visual management board when they talk about what they are working on. If they can’t point to anything on the board, they aren’t working on the agreed work for the sprint!
Going over the timebox
The daily standup usually has a timebox of 15 minutes and you should stick to it. Each scrum should have no more than 10 or 11 people and each person should talk for no more than one minute so you should be fine. If a standup is consistently going over the timebox, that is a classic “bad smell” and needs to be investigated. The usual cause is people are doing “deep dives” or problem solving (see above). Another more serious cause is that the team are not communicating or collaborating during the day and this is the only time they feel comfortable talking to one another. That indicates a much deeper problem with team culture.
Quick tip: get someone (it doesn’t have to be the scrum master) to be a timekeeper and use the time on their phone or watch to set off a buzzer when 15 minutes is up. When the buzzer goes off, the person currently talking finishes their update, then the standup is over. People can choose to then hold a specific conversation if they wish, but nobody is obliged to stick around. Be strict with this. If it continues to happen, you need to hold a deep dive or retro on the cause.
