See my slide deck that I usually use when giving a talk on this topic.
Among the many practices that people start to follow when they decide to “go agile”, is the daily standup.
Jason Yip’s article on standups is often considered the reference article (that’s me in the red t-shirt in that pic).
Over the years, various organisations and teams have adopted the practice of a standup along with many other practices in the hopes of being Agile. As an outside observer, I often get to spot various anti-patterns in standup practices.
Here are some standup anti-patterns to identify and address:
1 Having a person “run” the standup
It is best that people volunteer information turn by turn, rather than be asked to. This way, people learn how to discuss during ad-hoc standups.
2 Reporting to an authority figure
People tend to naturally “report to the Natural Leader(s)”. Such leaders may be one or more persons who make things happen, or set direction or solve problems. This reporting is often by way of looking at the leader(s) when speaking.
Ideally, a team should be used to functioning in the absence of the leader. This helps keep the show running, and the team or smaller focused groups within the team gain the confidence and experience to call for an ad-hoc standup to discuss matters.
It is, therefore, best that a person giving a standup update look at everyone in the team. Likewise, it is important that the team actively ask the speaker to address everyone in the group and not just the leader. Depending upon the team dynamics, you could choose between calling this out as it is happening, or taking the person aside and giving them feedback, or announcing at the start of the standup.
3 Treating the standup as a “reporting mechanism”
A common technique used to get someone to become subservient to you is to ask them about six questions. The act of replying consecutively (especially over a period of time and/or in others’ presence), makes people start to “report to you”.
This is both mean as well as an inefficient use of the team’s time. It is better that story and issue tracking systems and CI dashboards provide the project’s state, while the standup focus on blockers, emergency items, stuck items, other priority items
This also requires that people come to the standup prepared on these four items.
4 Sharing updates only at the standup and not earlier
It may happen that a team member may notice something, and decide to share this at the next standup - which may very well be the next day! This wastes time.
It is instead better to share one’s observation (“right now” is often the right time to share), and seek help. One can also call for “huddles”, where devs who have context or can provide advice gather together for a quick discussion on the finding or the query, and step away once they are no longer useful. This helps ensure that queries are addressed as early as possible. This saves time and money for the team and for the client.
5 Limiting the team to just one standup a day
Word “daily” in “daily standup” leads one to believe that there can be just one standup a day. Further, treating the standup as a reporting mechanism further conditions the team to “follow the leader/facilitator”.
We should bear in mind that one can have as many or as few standups as one wants. For e.g. during a production issue, one might have a standup every hour as a checkpoint. This could be an ad-hoc standup amongst the problem solvers without any facilitator necessarily needed.
6 Using standup time to signify the start of the day
If a team follows the concept of “core working hours” - a 6-hour window during which everyone is present together, this enables different people to have different timings. Once we add multiple-standups-a-day to the mix, we can no longer “start the day” with a standup. It is better to focus on the outcome of the day and the progress made, rather than trying to “discipline the team” by starting the day with a standup.
7 Missing the standup
Once the team decides on a standup time, it is best to respect the team decision and make it to the standup on time. Not doing so is a disrespect to the team, one misses out on receiving and providing information, and this starts off a culture of not caring. While one can provide standup updates via phone call and chat, it is best to not miss the standup itself. One could also have a standup a time convenient to all.
But do bear in mind maker schedule, manager schedule
8 Others not respecting that a standup is in progress
If you see another standup in progress, pause your chatter while they finish. Otherwise, you’ll just add to the general noise, everyone would increase their volume, and the place becomes noisy.
9 Detailed discussions at the standup
A standup is for quickly stating blockers, emergency items, stuck items, other priority items. If something needs to be discussed at further depth, then finish the standup and have that discussion.
10 Bringing offtopic items during the standup
It is best to finish the standup and to then share non-standup information, make announcements, etc. This helps the team finish the standup.
11 Expecting (Or Requiring!) that everyone provides a standup update
A common social engineering approach to expose those who are not working, is to demand a standup update from them. While this approach has it’s use and place, embarrassing someone at a standup is not the way to go about. There can be various reasons a person may either not be working at all, or may be perceived to not be working. Standups should be efficient, focusing on blockers, calls for help and other priority items. All other agenda should be executed in other ways.
12 A standup that takes longer than 10 minutes
Remember, it is not wrong to have discussions. It is more efficient to first gather the summarised points, and to then break off into smaller discussion groups.
I’ve been part of teams of 40 where there is a general standup that gets over within 10 minutes, followed by tech, BA , infra and other focused groups standups and discussions.