Daily Standup Tips - a Roundup

Posted by Mark Levison on Jan 30, 2010

Sections

Process & Practices

Topics

Adopting Agile ,

Agile ,

Agile Techniques

Tags

Adoption ,

Self-organizing Team ,

Daily Stand-ups

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:

1. Low code quality resulting in QA finding a trickling but steady stream of bugs
2. 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?

1. Back to top

   Daily Walkabouts

   by C Curl

   I think the role of daily standups have outplayed their role. They were good for getting rid of the weekly status meeting, now it's time to move on. As someone once remarked, "Imagine having the same meeting, early morning, every day, with the same people, with the same questions, year after year..." - the perfect motiviation killer.
   
   What I propose is the Daily Walkabout. Take timeout from your desktop and have a walkabout. Scrum teams are normally quite small, take a few minutes to catch up with everyone, but please don't queue up and make it a formal practice. Doesn't have to be around the desk, but you could tag along to the coffee machine, lunch, or the local pub after work, whatever. The key is not Communication - but to communicate (the verb).

   Reply

2. Back to top

   Re: Daily Walkabouts

   by jason ray

   @Curl: is your thought that the Scrum Master is doing the walkabout, or that each team member is doing their own walkabout?

   Reply

3. Back to top

   Focus on accomplishment

   by J. B. Rainsberger

   If you only take away one thing from this article, let it be this:
   
   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.”
   
   I ask these three questions:
   
   1. What did you achieve yesterday?
   2. What do you plan to achieve today?
   3. What is stopping you from achieving everything in your plan?
   
   I find that works wonders.

   Reply

4. Back to top

   Re: Focus on accomplishment

   by Mark Levison

   JB thanks for the comment, I agree as do a growing number of coaches/trainers. Mishkin gets people to say what they 'completed' and what they 'will complete'. Again a positive focus and form of public commitment.
   
   Cheers
   Mark Levison
   Agile Pain Relief Consulting

   Reply

5. Back to top

   Via LinkedIn some more suggestions

   by Mark Levison

   One of the practices that has worked for us is to pass a "token" that indicates speaking privileges. Generally, this is passed around the stand-up circle and changes, depending on what is easily available. A very heavy token has proved useful in keeping the token moving and keeping stand-up to 10 or 15 minutes. Also, we encourage small groups to meet after the full stand-up for topics that are important, but may require focused attention by a subset of the larger group. - Holly Bielawa
   
   Start the meeting on-time, even if "key" people (who *isn't* key on your team?!) are not yet there. If they miss something important a few times, maybe they'll practice being on-time. And if they just have to skip it, there will be another one tomorrow.
   My recent blog post on being late for stand-ups: powersoftwo.agileinstitute.com/2009/08/charging... - Rob Myers
   
   Have a meeting moderator and a timekeeper. A stand up is just like any other meeting. I needs to be kept on time and its discussion framed. A moderator should prevent participants brainstorm and keep the purpose of the meetings present at all times (we should only talk about things done, things to do and problems encountered).
   
   The time keeper will make sure no one consumes a more meeting slot than it needs to.
   If anyone goes out of this trend, the moderator can ask the team if they need to schedule a full blown meeting to discuss a particular issue. I say that U should have a moderator and a timekeeper (not both in one person) for the simple reason that eventually the moderator will have to talk and the time keeper will serve as moderator at that time.
   
   If you follow this advise please let me know how it worked - Higino Silva

   Reply

6. Back to top

   Information sharing and problem-solving

   by Olivier Gourment

   I must confess our daily standups are getting less and less formal; but it looks like everybody still enjoys it very much (because of this?). When it doesn't start at the usual time (period), a team member usually requests it.
   
   The reaction of a good (French) friend comes to mind when he first heard of the practice: "they have invented... coffee break!?" (it is very common for people working together to come to the coffee machine and chat. Work topics invariably pop up and problems get solved!)
   
   My "formal" tips would be the following:
   

   
   
   • Take the opportunity to share news that give some context to what the team is working on. Developers have to make many decisions in a day, and if they have the right information, they will make the right decisions.
   
   
   • I agree with Jason Yip, these days I see the daily meeting as a way to get more problems solved, faster. This is really the goal of that meeting, and maybe that's what contributes to its success.
   
   
   • Our product owner is pretty much a permanent fixture; I also think it helps tremendously in having the right information conveyed to the right people at the right time
   
   

   Reply

7. Back to top

   Task Board on a Projector

   by Joe Parks

   Our scrum room has an overhead projector and large screen. We put the task board from VersionOne up on the screen and usually just go down the list of what's "In Progress". We also glance at some of the tool's charts to see if anything jumps out as a red flag.
   
   Joe Parks
   HyperProductive, LLC

   Reply

8. Back to top

   Re: Task Board on a Projector

   by Mark Levison

   Elegant - you've solved one of my bigger objections about "web based tools" for teams. My other objection to these tools is that they're not always visible. Do you leave it on all day? So that people are always aware of what's going on.
   
   Cheers
   Mark Levison
   Agile Pain Relief Consulting

   Reply

9. Back to top

   Re: Task Board on a Projector

   by Scott Dunn

   Great timing, and thanks, Joe, for your suggestion. I was prepared to cutout the printouts of stories and tasks for next sprint and put them on the wall. In my experience, nothing beats a daily stand-up around the task board, but the reality is all other reporting is more difficult without a tool.
   
   Cheers,
   Scott
   
   Software Development and Human Capital - Leadership, Agile and Strengths

   Reply

10. Back to top

    Re: Task Board on a Projector

    by Joe Parks

    The story board is up on the screen most of the day, when not using the projector for other stuff. The firefox add-on, "ReloadEvery", keeps it up-to-date as people update the backlog from their own machines.
    
    Joe Parks
    HyperProductive, LLC

    Reply

11. Back to top

    Re: Focus on accomplishment

    by Joakim Karlsson

    You might also try asking the three questions to the team as a whole, in addition to asking it to each member individually:
    
    What is the goal we as a team have for today?
    How did we as a team do on our goal for yesterday?
    What, if anything, hindered us as a team from reaching that goal?
    
    That can help us team members see the common goals and impediments, and how our individual contributions affect those.
    
    I wrote a small piece about that here.

    Reply

• Older >