Agile

The Daily Stand-Up Meeting - A Core Practice for Self-Managing Teams

Not just a new name for a project status meeting!
Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.         

The transition to becoming a self-managing team involves a fundamental change in how individuals, teams, and management approach their respective responsibilities.  Traditionally managed teams depend upon anointed leaders who give direction, track progress and push the project to completion.  Self-managing teams operate quite differently, and in such a team there is no pre-determined role of “project leader” or “project manager.”  Today's teams operate in a hybrid, nuanced environment in which they are asked to be self-managing yet there are also elements of project management required by the organization. In the context of a self-managing team, this article describes how to implement the daily stand-up meeting.



Replacing 'Status Meetings' with 'Stand-Up Meetings'

Stand-up meetings are most commonly associated with agile development methods (in particular eXtreme Programming and, more recently, Scrum), but these type of meetings are not inherently agile.  Indeed, this type of meeting can prove useful in any environment where teams have some degree of self-management.

When it comes to bringing new practices into a team, old habits die hard.  I know, because I’m still in the process of relying less upon some traditional project techniques (that have helped me lead a few hundred projects) and replacing them with practices that have a good chance of improving project success rates.  One practice in particular has been a struggle to consistently implement successfully: the stand-up meeting.  Repeatedly, across a period of several years, I’ve encouraged project leaders in my organization to adopt stand-up meetings and have coach Scrum Masters on improving the effectiveness of the Daily Scrum.  Yet in far too many cases, these meetings inevitably become a typical status reporting meeting chaired by a project leader.  Those project teams, unfortunately, don’t achieve the benefits that can result from the stand-up meeting; indeed, their performance and potential is somewhat capped by the command and control model of a traditional status reporting meeting.

This article reflects my notes on the daily stand-up.  Daily stand-ups or synchronization meetings are frequently associated with Scrum, but their value and use is applicable in Kanban, DevOps, operations management, and other areas that may have no software or technology elements.  I’ve prepared this information primarily for use in my discussions with project teams who are starting to use stand-up meetings or who might need a refresher because they are struggling with ineffective stand-up meetings.

I’ll recap some of the basics of the daily stand-up (providing you with references to this same, or very similar, information that is widely available elsewhere) and talk about enablers for successful stand-up meetings.

 

Preparing for Successful Stand-Up Meetings

Perhaps you’ve heard about stand-up meetings and want to implement them on your project.  As leader, you may be tempted to initiate regular stand-up meetings by simply putting the meetings on the calendar, introducing the “three questions” and imploring each person to answer each question during the stand-up meeting.  I have used and have seen others use this method and the results are consistently disappointing: dysfunctional stand-up meetings that uniformly frustrate.  The process fails to engage most developers, the potential benefits of exchanging information are rarely achieved, and regular voluntary attendance by developers gradually diminishes.

Instead, consider this approach to introducing stand-up meetings:

  1. Introduce developers to the objectives of a stand-up meeting.
    • Start breaking the mindset of the familiar report-status-to-the-project-manager meeting.
  2. Train developers in the practices of the stand-up meeting. 
    • You’ll want the entire team familiar with the small set of principles that underpin these meetings.  Without this common understanding, you’ll find that your stand-up meetings will soon become unproductive.
  3. Determine the key logistics and specifics of your implementation of stand-up meetings. 
    • In many (perhaps most) cases, these meetings are virtual.  Are cameras on?  Is the meeting recorded?  Will we meet every workday?  Are these synchronous or asynchronous?  Should we have a chat channel for asynchronous updates?  Along with several other start-up choices.
  4. Ensuring an efficient, effective daily stand-up meeting.  
    • After you’ve conducted a few stand-up meetings, go through your first retrospective discussion and repeat that activity in a few weeks, deciding collectively what aspects of your own implementation should be continued, improved or abandoned.

 

1. The Stand-Up Meeting . . . What’s it All About?  The Meeting Objectives.

Successful project teams adopt various methods for keeping team members in sync with one another, identifying problems that others on the team can help resolve, and ensuring that progress is continually made towards achieving the project goal.

Your current projects probably employ some formal methods (generally involving written materials) and informal methods (hallway conversations, project discussion boards, IM chats).  Traditionally, a weekly ‘status meeting’ is the primary vehicle used by a program manager, project manager, product owner, or other leader to drive this type of team activity - I’ll refer to this person as the “driver”; this periodic status meeting is a chance to brief the driver on progress relative to the plan.  Typically, the driver has to listen carefully and ask probing questions with a goal of understanding progress and identifying issues.  The driver has an implicit responsibility of detecting project issues and driving their resolution.  The politics of this interaction can, in some situations, cause developers to report “all is well” when, in fact, a serious problem is preventing progress as expected – such cases introduce risk to the project. (This isn’t necessarily a deliberately misleading report; often a developer has the confidence that they can satisfactorily resolve a difficult or unexpected situation.)

A stand-up meeting is quite different from a weekly status meeting.  The key objective for a stand-up meeting is to ensure that the activities of the developers are aligned in progressing the project towards successful completion of the project goal.  In other words: the stand-up meeting is when each developer re-validates that they are making progress on the most important project activities.

A stand-up meeting is:

  • An explicit reinforcement of the commitment by each developer to accomplish a goal
  • A means of dynamically adjusting the work by each developer to accomplish the goal
  • A daily synchronization between developers, informing team mates of work activities, progress and issues
  • A method of cross-checking progress with team mates
  • An accountability mechanism that has each developer accountable to other developers for their responsibilities
  • A visible demonstration of the ability of developers to self-manage their project responsibilities

A stand-up meeting is not a status report to a driver, a Scrum Master, management or sponsors.  (Please re-read that thought one more time, it is important).  Other status reporting meetings can provide this function of reporting progress outside of the team, but that is not the function of a stand-up meeting.

 

2. The Practices of a Stand-Up Meeting

Stand-up meetings seem to go by two names these days:  A Daily Stand-Up Meeting and Daily Scrum Meeting.  Here's a bit of trivia - the Scrum Guide has always referred to this event as a "Daily Scrum," and the term "Daily Stand-Up" has its 1999 origins in eXtreme programming.  I’m sticking with “Daily Stand-Up” because I see this practice as being applicable to many situations that may or may not be associated with use of Scrum (Kanban comes to mind).  Also, I rarely hear teams use the term "Daily Scrum." Expert materials on the Daily Stand-Up are widely available online and in published books – here are the best starting points:

The commonly understood definition of the Daily Stand-Up has evolved over the years.  "Self-organizing" teams are now "self-managing." The Daily Scrum started as a "ceremony," with that terminology abandoned and replaced with "event." (The Scrum Guide doesn't refer to this as a "meeting.") What started as a prescriptive definition in the Scrum Guide (e.g., apply the "three questions") is now more guiding (e.g., developers determine the structure of the meeting.)  "Walk the Board," not mentioned in prior decades, is now a common practice.  The dogmatic perspective of a Scrum Master's responsibilities (e.g., coach, helping remove impediments) is almost always broadened in practice to recognize that in today's teams, there is an organizational need for some project management activities and reporting.

The defined practices for a stand-up meeting are few but are significant.  Don’t get overly enthusiastic and start constructing a plethora of additional practices for your project – too much process will negate the benefits and turn this into just another inefficient use of time.

Using information on the Daily Scrum from the 2020 Scrum Guide, here are key points about the Daily Stand-Up meeting:

  1. The stand-up meeting is conducted daily.
  2. The meeting time-box is 15 minutes.
  3. All developers attend and participate.  (Others may attend, but do not participate.)
  4. The developers are responsible for conducting the Daily Stand-Up (not the Scrum Master)
  5. Same time of day and meeting location for all meetings.
  6. The developers determine the structure and techniques they want for this meeting.
  7. The focus is ensuring progress toward the Sprint Goal.
  8. The meeting produces an actionable plan for the next day of work.

You are no longer relying on a driver to ask a collection of questions so they can discover if there is a problem on the project.  The stand-up meeting places a significant obligation onto each developer to:

  • Be responsible for your work.
  • Concisely present an accurate view of your work.
  • Pay attention to other developers.
  • Avoid digging into solutions and details - note items that you’ll need to cover in follow-up discussions.

Here are a few points of guidance that may help you in understanding and implementing these practices:

  1. The stand-up meeting is conducted daily: Perhaps your first consideration is this - do you even need to meet?  With an online project board and instant messaging tools widely available, you have an option of have an “asynchronous daily stand-up,” with developers checking in with one another via IM messages.  Daily check-ins are important.  Fred Brooks gave us this reminder decades ago: “How does a project get to be a year late? … One day at a time.”  (The Mythical Man-Month: Essays on Software Engineering, 1975 & 1995).   Effective daily team interaction will let you know when the project is even one day behind schedule. 
    • Here’s why you’ll want to communicate daily:  Project teams almost continuously make new discoveries and encounter unexpected situations.  If not properly acknowledged and addressed, this new information can jeopardize the project.   Your daily communication is the time to highlight any relevant new information (perhaps identified as ‘obstacles’) so the team can make a proper response by adapting the project activities with this new information in mind.
    • Is this micromanagement of the project?  It might be, but micromanagement generally refers to overly detailed management by an outside authority.  The daily stand-up is self-management by developers, each with a stake in knowing that the other developers are making sufficient progress on their area of responsibility.
  2. The meeting time-box is 15 minutes: The duration is deliberately short so everyone will be able to accommodate this meeting on their calendar and attend every day. 
    • This is a synchronization and planning meeting, not a time for extended discussion, philosophizing, storytelling or problem solving.  It is far too short to probe into the details of a problem or try to solve that problem – problem solving activities later today are a natural and expected follow-up to today’s stand-up meeting.
    • Don't succumb to any temptations to cover extraneous information as this will only serve to extend the meeting duration without contributing to the stated purpose of the meeting.  Purge any desires you may have to tell a story about how difficult your job is, give a history of how we got into this situation, offer your criticism of other people/organizations or take time on other topics not on the agenda.
  3. All developers attend and participate.  (Others may attend, but do not participate.)  You’ll know if you are on the team if you can answer yes to this simple question: are you performing some activity or producing some deliverable that contributes to the project goal?  If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
    • This is a key synchronization activity for the project team, and will work best when all developers attend.  It’s reasonable to assume that each member might occasionally miss for unavoidable reasons.
    • You’ll want full attendance to be the result of the recognized value of the stand-up, not as a result of penalties assessed for absence or late arrivals.
    • Others may be permitted by the developers to attend the team's daily stand-up as observers. Their interference (no matter how well-intentioned) will probably break the team's 'rhythm' and detract from the value of the daily stand-up.
  4. Same time of day and meeting location for all meetings.  This is probably a good idea in establishing a regular pattern of interaction within the team, (slightly) reducing cognitive load.
    1. The overarching principle is that the stand-up meeting be conducted at a time and location that will allow all developers to participate.  Some teams prefer a start-of-day meeting, others a mid- or end-of day meeting.  Look at the advantages/disadvantages of each and choose whatever works best for your team.
    2. If you are fortunate enough to work within a team that is entirely co-located, then you’ll need a physical room in which to meet.  You'll be occupying that room every day, so try to get a room that is suitable.
    3. My projects for the past decade have had developers on two or three continents; thus, we’ve had to find a workable solution for a team that spans multiple time zones.  Choose a video conferencing system that is easily adopted by everyone on the team and use that same system for all stand-up meetings.
    4. Start and end on time.  Agree on an expectation that everyone is responsible for arriving in time for the start.  Accompany this with the commitment to one another that the meeting will conclude on time.  If you continually start late, it will be easy for everyone to adjust to this and start arriving late.  A late running meeting creates a problem: people who leave at the scheduled end-of-meeting time will miss out on the remainder of the meeting.  If the meetings continually run late, then this will likely become a source of dissatisfaction and complaint – not quite the image you’d want for an important synchronization meeting.
  5. Some options for meeting structure. 
    • Walking the Board.  This is my preferred structure for stand-up meetings.  The team acknowledges completed items and reviews other items right-to-left in priority order, identifying blocked items where assistance may be needed, and for in-progress items "what needs to be done so we can move this to 'closed?'"
    • The Classic Three Questions Pattern. You've probably heard of the "three questions."  These appeared as a suggested pattern in early versions of the Scrum Guide (as an example method for focusing on achieving the sprint goal) and removed in 2020 (giving Developers the responsibility for choosing the meeting structure). While use of the three questions is not my preferred recommendation, I recognize that many organizations adopt this technique. The three questions can be an easy way to introduce the Daily Scrum but recognize the shortcomings of adopting this pattern. Here are those three questions (my wording slightly differs from the 2017 Scrum Guide):
      • What I have accomplished since the last meeting.
      • What I am going to accomplish before the next meeting.
      • What obstacles are preventing progress.
    • If you choose to use the "three questions," here are some pointers: My version implies a focus on accomplishment and a responsibility of each team member to share their information.  Beware of these pitfalls:
      • Reporting on what you are 'doing' rather than what you are 'accomplishing.'  Accomplishments, not just activity, are expected.
      • Treating the topic as an interrogatory (e.g., "What did you accomplish yesterday?") rather than a self-initiated report ("What I have accomplished since the last meeting.").  The former question is phrased as though someone is asking the team member for a report on their progress, thus carrying the implication that someone is pulling information from the presenter.
      • Sometimes the third question is worded "Are there any impediments in your way?"  This yes/no question will always beg a fourth question, asking “What are those obstacles and their impact?”
  6. Each developer contributes to the meeting objective.  This single aspect of the stand-up meeting is the most difficult to implement effectively.
    • Have the output of your planning activities available to all developers during the stand-up meeting.  You'll want to have this information available in an online project board. This is everyone's reference point and is essential for meaningfully representing your progress and obstacles.
    • You are sharing progress information in terms that are meaningful to the other developers. Your audience is everyone else on the team – remember this is not a status report to a Scrum Master.  Don’t let this become a meeting where someone has to ask probing questions in order to get a satisfactory understanding of your true situation.
    • When you are not sharing, you have an explicit responsibility to pay attention as others present. You’re listening for connection points to your own activities and areas where you may be able to help.
  7. Adding, deleting or modifying the sprint backlog - is this permitted? Don't fall into the trap of thinking that the sprint backlog of items is established during sprint planning and cannot be changed during a stand-up meeting.  The prime focus is the sprint goal.  The Stand-Up is intended to inspect progress toward this Sprint Goal and adapt the Sprint Backlog as needed.
  8. More on the Sprint Goal.  More often than not, I see that developers have been unable to construct a single sprint goal.  As a direct result, the focus is on the sprint backlog items instead of on a unifying sprint goal.  My experience suggests that you'll frequently encounter this situation; you'll have developers each working on items prioritized by the customer (via a Product Owner) but this inventory of work cannot be described with a single coherent, focused sprint goal.  As a pragmatic compromise to this situation, I've used two different approaches - neither is perfect and both can be considered an antipattern.  Identify the most important (to the customer) stream of work for this sprint and describe that as a sprint goal; yes, other work is in the sprint backlog, but having a priority clearly identified can aid in decisions made by developers throughout the sprint.  A second option is to form a (perhaps messy) composite sprint goal that lists not just one, but a few deliverables or outcomes resulting from the sprint.  
  9. A trainer/facilitator (in Scrum, this is the Scrum Master) teaches the team about the stand-up and guides the team in adopting the process.
    • Have all team members read some materials (e.g., this article and the expert materials it references) and conduct a training session to reinforce the objectives and practices of the daily stand-up.


3. Determine the key logistics and specifics of your implementation of stand-up meetings

Other stuff for your team to decide so the stand-up meetings work best for you:

  • Remote/Virtual. Some teams have everyone attending in person, others have everyone participating via video call.  Either approach can work well.  However, having some people in person and others remote might isolate the remote participants.
  • Fines for arriving late.  Some teams do this.  I think it's silly - seems like the fine just gives me permission to be late.
  • Expectations on attendance.  “At all costs” or “Attendance is expected, occasional absences are tolerated.”
  • Meeting Purpose/Large Attendance.  Ensure that you really want a “daily stand-up” meeting. I frequently encounter excessively large “stand-up meetings,” with as many as 40 people attending.  Most often these are 60 minutes in duration, up to 5 days per week!  While these are on the calendar as a “Daily Stand-up,” these meeting do not resemble a Stand-up.  I find these to be one of three very different types of meetings: 1) a project status review with the project manager querying each attendee on task completion, 2) a problem solving forum for working through the technical details and actions for a significant project obstacle, or 3) a time where senior leaders or sponsors ask detailed questions of participants on their work - in essence, micromanaging people and the project.  Avoid advertising these as “Stand-Up” meetings, as this appropriates the term “stand-up meeting” for an entirely different purpose.
  • Speaking order.  Define an algorithmic means of choosing the first (and then the next) speaker.  Avoid a facilitated method that has someone (e.g., Scrum Master) who runs the meeting – this method too often becomes a ‘report to the leader’ meeting.
  • Positioning of team members vs. others.  For in person Stand-Ups, it can help reinforce the focus of the meeting if team members are positioned together, with all other attendees on the periphery.
  • Interactions during the meeting.  If a presenter has been unclear on some point, you may want to provide a limited opportunity for clarification questions.  Or, is your daily stand-up meeting just a 'present-only' meeting with no opportunities for questions?
  • Action item recording.  Some teams assume that individual team members record and act on their own actions that emerge from the daily stand-up meeting, others have a designated individual assigned to record action items and track their completion, and many record their meetings and delegate action item recording to an artificial intelligence capability.  Avoid having a separate "action items" list; rather, use your project board of items to record any relevant decisions or actions, maintaining the project board as this single source of truth.
  • Sharing information on obstacles.  When describing obstacles that are preventing progress, you'll want to establish a team norm for what is presented here.  You have two obvious possibilities:
    • Each developer presents only those obstacles for which assistance is needed.
    • Each developer presents all notable obstacles, including those that they can resolve.   Consider sharing this information if it is likely that others would have suggestions that would be helpful.
    • (Sharing obstacles during the Stand-Up is only one communication mechanism; significant obstacles should also be noted in the appropriate item in the Sprint Backlog).


4. Ensuring an efficient, effective daily stand-up meeting

For teams accustomed to traditional project management status meetings, the daily stand-up meeting can be a challenge to implement.  The daily stand-up meeting is far too short for extraneous discussion, and it can seem all but impossible to give an accurate report in just a few minutes.  Yet, with preparation, practice and discipline, the daily stand-up meeting can be one of the more important team interactions.

Prepare the team by going through the first three steps, noted above, and then get started with your daily stand-up meetings.  After you’ve conducted a few stand-up meetings, go through your first retrospective discussion.  Decide collectively what aspects of your own implementation should be continued, improved or abandoned – have a definition of the stand-up meeting practices (section 2, above) available for reference during this retrospective.  Repeat this retrospective activity after about a dozen stand-up meetings; from that point forward, just include the stand-up meeting as a topic covered during your standard iteration retrospective.