What are the best tips and techniques for running a good daily stand-up? Most Agile teams run Daily Standups – but according to Joakim Karlsson "most of the daily stand-ups out there are, quite frankly, pretty uninspiring things." They turn into just another meeting that everyone is forced to attend, even worse a meeting they must attend daily vs. the traditional weekly.
Paul Wynia provides the example of a project where the project lead had no Agile training or experience and treated the Daily Standup as a daily status meeting:
She would have each person give a detailed description of each feature, bug, and interaction they had had in the previous day and all their work, including estimates, for the upcoming day. She would then get into a discussions with each person on almost every item. It got to the point where people would bring in notepads filled with work details and to capture the new assignments she would give out. With a team of only 5 people, she somehow managed to stretch the Daily Stand-up into 30-45 minutes a day of excruciating boredom.
Paul goes on to recommend that meeting be limited to 10 or at most 15 minutes. He then gives teams he’s coaching permission to walk away if the time limit is breached, sending the Scrum Master a signal about a problem with the way meeting is being run.
Joakim recommends:
- Focus on the goal – sharing information with fellow team members that will help the whole team get to done in the iteration
- Focus on the team – sharing information with everyone and not just a single manager.
- Discuss Elsewhere – don’t to solve problems in the standup instead schedule the time to solve later, when anyone who is interested may join.
- Come Prepared – to keep the standup short team members need to know what you’ve accomplished and what is left.
- Focus on Accomplishments – Joakim found that: "talking about accomplishments made provides a more positive attitude than just providing information on what parts of the system was worked on."
- Make Commitments – instead of mechanical saying what they will work in the next 24 hrs, he gets people to commit to the rest of the team what they will achieve.
- Raise Impediments – did you have to touch 60 files to make small change?
Mike Cohn recommends that teams conduct their daily standups in front of their task boards, asking the speaker to point at the story they’re working on. In addition, Mike notes that as team size grows past 9 people that its easy for team members to lose track of what other people are working on.
Drew Stephens reports that his team uses “User Story Focused Daily Standups”. Like most Agile teams, Drew’s started with a fairly traditional standup but struggled as the team grew in size:
There was no longer enough work on a single story to occupy the entire team and thus we began to parallelize. We also noticed that many stories were staying active for longer periods of time and developing what we began calling “task tails” (where a story stagnates with the number of unvalidated tasks remaining consistently low for many days). We identified two primary reasons for the occurrence of task tails:
- Low code quality resulting in QA finding a trickling but steady stream of bugs
- Developers moving onto other stories when a story appeared to be close to done but was not actually done
As a result of these factors, our standups became confusing; a person often talked about a different story than the previous person and this ascertaining the current status of an individual story became difficult. Instead of focusing on what was needed to finish the active stories, the focus was on what each person was doing or about to do. A subtle distinction but one that was increasingly problematic.
Their solution – walk through the stories in progress, each person who worked on that story answers the three questions for that story. If the person has worked on more than one story then they speak to all of them (a potential smell). The Scrum Master keeps track of who has spoken and if by the end someone has spoken then there is probably an impediment.
Artem Marchenko, has several suggestions:
- No typing – if someone is taking notes on a laptop (or otherwise), they hold the power as they reinterpret what the team members said.
- If the team is reporting to the Scrum Master, then the SM should look away or in extreme cases turn their back.
In an interview with Henrik Larsson, Jason Yip (author of It's Not Just Standing Up: Patterns of Daily Stand-up Meetings) notes how is view of standups has changed:
I used to see it more about status. Then I shifted to see it more about commitment, mainly due to Mike Cohn’s writings. These days, I see it as more about problem-solving. My current preference is much more strongly toward a “walk-the-board” style of stand-up when a task / story board is available. I tend to emphasise much more the importance of focusing on completing work versus just people trying to be busy.
Having said that, there are still some aspects that haven’t changed over the years, such as the importance of keeping the ritual high-energy and being about sharing with the team versus reporting to
a leader.
What has worked for your team?
Previously on InfoQ: What makes a Good Standup?
