Stand-ups are best on your feet!

Stand-ups are best on your feet!

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively are the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective making daily stand-ups work for distributed teams include:

  1. Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One usable solution that can be tried when distributed teams can’t overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  2. Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might just be starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  3. Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  4. Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. For example ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get competed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams as well as distributed teams.

  1. Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  2. Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  3. Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that EVERYONE has access to. Keep tools as simple as possible.
  4. Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they CAN’T communicate.

Stand-ups are nearly ubiquitous in Agile. I would do stand-ups even if I were not doing Agile. However, despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the Scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.

UntitledWhen it comes to the daily stand-up meeting, one of the process “improvements” I occasionally see is changing them to periodic stand-up meetings.  Generally teams do this when 1) non-Agile projects use the stand-up meeting technique to share statuses, 2) they are doing large tasks that do not require coordination, or 3) when an Agile team misunderstands the purpose of the stand-up meeting.

Project plans and schedules are an important tool to coordinate and direct team members in non-Agile projects. The intent of project plans and schedules is to provide team members with a sequential list of to-do items.  The schedule is to a non-Agile project what sprint planning and the daily stand-up meeting is to an Agile project.  Where work is highly deterministic, nothing goes wrong or nothing new is discovered the process works great.  Non-Agile project managers often leverage the stand-up meeting technique to gather status and feedback to help them control and tune their project schedule. These stand-up/status meetings are not typically needed on a daily basis given the belief in the pre-planned schedule and a project manager, rather than the team, who is responsible for adjusting the plan.

During sprint planning, Agile teams break work down into more granular chunks.  This process serves multiple purposes including helping team think through the process of delivering the work, generating milestones to show progress and to evoke additional feedback. The level of granularity that work is broken into varies from team to team and from function to function.  For example, installing a new server might be broken down into more granular task such as, installing a new rack, running power to the rack, mounting and hooking up the server (teams will add more or less detail depending on their needs). The more granular tasks would be completed individually more accurately showing progress. Some teams decide to hold their stand-up meetings on a less frequent basis to reflect the lack of change on a day-to-day basis. Assuming that the team has a common goal and that team members are working on stories related to that goal or tasks that are part of the same story a better solution would be to break the work down in to smaller components.

A related reason teams give for not needing to do daily stand-up meetings is that work they are doing is not related, and therefore hearing about what someone else is doing is only of tangential interest.  Actually words like ‘boring’ or ‘overhead’ might be used.  I tend to agree with this rational, if team members are not working on tasks that are related to a common goal or story or they are working on items where inter-team coordination and communication won’t add value, then don’t do daily stand-up (perhaps don’t do them at all). HOWEVER I am unsure whether I would call this assembly a single project or the group of people doing the work a team.

Every once in a while I find a team that has truly embraced the Agile principles, but have misunderstood the rational for doing stand-ups. Most the teams in this category are highly cohesive and expend a significant amount of energy communicating and coordinating between members.  Many times groups in this category see the formal stand-up as a ritual that they found other, informal means to address. Daily stand-up meetings are a time for the whole team to gather, interact, coordinate work and offer advice.  If an Agile team has found another means get the whole team together to interact, coordinate and communicate, the formal daily stand-up is not needed.  Generally, however, what I have observed is serial one-on-one conversations rather than true group interaction. There are much more prone to imperfect communication (see telephone game), and lacks the diversity of opinion group interactions can give.

Sometime daily stand-up meetings don’t make sense. However I typically find that when that is true the real issue is that the either the team has not really embraced Agile or are not working towards the same goal.  Every once in a while a small, very tightly knit team finds a way to continuously interact and coordinate at a group level. They do not need to do a formal daily stand-up – they are doing a stand-up continuously.  Most (99.9%) Agile teams need to do a daily stand-up.  Stand-ups not only reinforce team membership, but more importantly, stand-up meetings are often only time the whole team gathers to share and interact during the day.

Stay focused!

Stay focused!


There are very few add-ons that can make a daily stand-up meeting better. In fact most add-ons shift the focus of the meeting and could easily be classified as process problems. However, there are two add-ons that can add value to the stand-up meeting process: trolling for risks and hand-offs.

Trolling for risks. Anyone that has ever felt responsibility for the outcome of a project has had that nagging feeling that something was lurking just over the horizon that could reduce the value you are delivering. Project risks reflect the potential for something to go wrong. No one wants to have a risk that should be seen coming to catch them off guard. Therefore I periodically add a fourth question to the stand-up meeting questions: “Are there any project risks you are more concerned about this sprint than last sprint?” The goal is expose any new risks or any risks that are becoming more risky. At a project level I suggest adding this to the stand-up discussion once per two week sprint and do not let the conversation expand beyond the 15 minute time box. If the project has suddenly become so risky that more time is needed, treat the changed risk status as a blocker and have the scrum master pursue identifying the root cause so that specific action can be taken. Stand-ups for a program (very large project or a related group of projects) may need to monitor risk on a daily basis.

Hand-offs. Project teams are often distributed across continents, which can be used to a team’s advantage so that work begun in one time zone can be handed off and to be continued at the beginning of another team member’s day. This technique is often called “following the sun.” In order for this technique to work, the team members that are involved in the hand-off must understand that the hand-off is occurring, the goal of the shared task and the current status of the work. The daily stand-up meeting plays a critical role in this process. Involved team members can use their update to alert those they are handing work off to about the current status of their shared task or to schedule follow-on discussions if a more in-depth hand-off is needed. One common example of this practice is when developers are in one location and testers in another. The approach is first planned in sprint planning then coordinated during the daily stand-up meeting and other person-to-person interactions. The daily stand-up meeting generally acts as a formal control mechanism while conversation outside the meeting is less formal and more collaborative.

The stand-up meeting serves a very specific set of planning and coordination purposes. Add-ons generally push the daily stand-up meeting away from that purpose therefore become process problems. There are a few add-ons that fit well within the purpose of the meeting and the 15 minute time box. These add-ons focus on planning and coordinating and help the team get their work done rather than reporting on how the work is being done.

Stand-up Meetings are not just a presentations.

Stand-up meetings are not just a set presentations to scrum masters.

A team’s daily stand-up meeting is an execution of a process, a series of steps taken to achieve a purpose.  Stand-up meetings lose effectiveness when they don’t follow a process, when participants try to multi-task during the meeting, treat the scrum master like manager or when stand-up meeting becomes a status meeting. All of these problems are process problems.

Stand-up Meetings Without a Process  Stand-up meetings are daily planning meetings. During the meeting the team sorts out what has been completed, what will be accomplished in the near term and whether there are any “blockers” inhibiting progress.  There are numerous approaches that can be used to do stand-up meetings, including the famous three questions approach and walking the board. The team should leverage more than one technique on a regular basis to keep the meeting fresh.  What should never happen is for a team to abandon structure and just hope team members will share all pertinent planning and problem information.  The job of a scrum master/coach is to ensure the team has a pallet of stand-up techniques and that those techniques are used.

Multi-tasking One of reasons stand-up meetings work efficiently is that they are short and focused.  The meeting should be 15 minutes (or less).  Nearly everyone can focus on one thing for 15 minutes without doing something else (like day trading or checking email on their smart phone).  I strongly urge all teams I work with to ban smart phones or any other electronic tools during the meeting UNLESS absolutely needed to view the team board (video, teleconference or Agile tool).  I have even gone as far to suggest that phones be put on the floor during the stand-up meeting.  Fractured attention reduces interaction. Recently I was walking through Little Italy in New York City after dinner.  As I walked past restaurant after restaurant, I noticed that many diners were sharing their attention between their phones and their dinner party, reducing the conversation at each table.  Stand-up meetings ONLY work when the team is sharing and listening.

Reporting to the Scrum Master  Stand-ups are a team meeting.  The team members talk to and interact with each other.  Occasionally the meeting might require some facilitation, however the communication and interaction needs to be between team members. They are ones writing the code, testing the software, building the hardware or writing documentation.  The scrum master/coach is the facilitator, not the focus of the meeting.  Team members must address each other not the facilitator.  One technique I learned early in my coach career was to stand behind the team rather than in front of the team or in front of the team board.  Team members will tend not turn around to face the coach, so they will make eye contact with their team members instead.

Status Meeting  The single worst process problem is converting the stand-up into a status meeting (or any other kind of meeting).  Just don’t make this mistake.  If a meeting to collect and discuss the status of a project is needed, first do the stand-up meeting, end the stand-up meeting and then convene a separate meeting. The Scrum master/coach should draw a very distinct line between meetings, even if people don’t leave the room so that no one confuses the purpose between the two sessions. For example, in organizations where stand-ups are done standing up, I have had team members sit down to mark the change of meetings.  Another example, when I have done distributed stand-ups, I invite everyone that needs to attend the second meeting to hang up and re-dial.  This clean break makes it easier for people that don’t absolutely need to be involved to get back to work.

The practice of stand-up meetings is one of the first techniques most organizations adopt when they begin to implement Agile.  Because of the simplicity of the technique, organizations forgo coaching or training on how to do stand-up meetings. They rely instead on the best efforts of everyone involved.  Without coaching stand-up meetings can be implemented poorly, robbing the organization of the benefits of the technique.

Bad attitude!

Bad attitude!

The daily stand-up meeting is an easy Agile practice to adopt and an easy process to get wrong.  When stand-up meetings go wrong the problems are either a people or a process problem.  Each category can be broken down into a number of more specific problems, each with different symptoms and solutions. Today we’ll talk about people problems. (more…)

Superman probably does not need a stand-up meeting but Clark Kent is another story!

Superman probably does not need a stand-up meeting but Clark Kent is another story!

The daily stand-up meeting has become a nearly ubiquitous feature of Agile projects, and also can be found in Kanban (lean), support projects and even in some waterfall projects. The proliferation of the stand-up meeting shouldn’t be surprising – the meeting is simple, typically short and easy(ish) to implement.  However, there are a few circumstances where daily stand-up meetings, as we defined them, should not be used.  These circumstances revolve around two general areas: team size (too small and too big) and team/organizational culture. (more…)

Professional Man Preparing for a Daily Stand Up

Preparing for a Daily Stand-Up

The daily stand-up meeting easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple. (more…)

Your Scrum events might be slightly less well attended!

Your Scrum events might be slightly less well attended!

The list of identified events in the Scrum framework, like the number of roles, is highly constrained. Scrum walks the line between identifying a set of events that each follow a typical pattern and prescribing specific activities and tasks.  As a framework, Scrum leaves the control of specific behaviors to the team. Therefore each team has a customized approach to how they implement the events based on organizational culture and need. The events identified in the framework include:

  1. The Sprint: which is the time box for developing potentially implementable functionality.  The sprint generally ranges from 2 – 4 weeks, with the 2 week increment being the most common I see in the industry.  Once your team agrees on the sprint duration for a particular project, it generally does not change.  The standard duration of the sprint is called cadency. Developing a consistent cadence helps the team become predictable.
  2. Sprint Planning: a meeting for the team to plan the work they will commit to during the sprint.  Sprint planning is a two-step process beginning when the product owner identifies the units of work they want included in the sprint using the prioritized backlog and input from the team for guidance.  After the product owner identifies the work he or she wants in the sprint, the development team (I recommend that the whole team participates) estimates the work based on their velocity (how much work they typically get done in a sprint) and the activities needed to complete the work (completion must meet the teams overall definition of done). The team will either increase or decrease the number of work items based on what they can complete.  What the team WILL NEVER do is to change the definition of what done. The planning activity is complete when the team can commit to completing the work they can do during the sprint.
  3. The Daily Scrum: the daily planning session that generally begins the team’s day.  The daily meeting provides the team with a mechanism to plan the day and to ensure that issues blocking work do not fester. Try to keep the scrum meeting at or near the beginning of the day so that team can use it as tool jump start their day.  Team composition and time zone constraints will dictate when the meeting happens.
  4. The Sprint Review: the meeting at the end of a sprint for the product owner and stakeholders to interact with the functionality and provide feedback and acceptance.  The sprint review provides a platform to gather feedback from a broader constituency than the team itself. The whole core team should be interacting on a daily basis; therefore the review should be leveraged to include a wider range of stakeholders.  The product owner should drive the guest list with advice from the entire team.
  5. The Sprint Retrospective: a meeting for the team to review their performance and identify opportunities for improvement. The team should find at least one process improvement that they can make and then commit to making that change.  The change the team commits to should be captured as a unit of work and be incorporated into the next sprint backlog so that it gets done.  Process improvement is the obligation of the WHOLE team, not just the development team.

The five events identified in Scrum are sometimes explained as four meetings and the sprint, which is an intrinsic part of Agile techniques.  All five are important features that interact providing self-reinforcing discipline and feedback.  I usually worry less about how a team is accomplishing the events, rather I make sure they doing something that meets the intent of the events and are in line with the Agile values and principles.

Four meetings and a sprint

Four meetings and a sprint

When most people think of Agile, they really mean Scrum or include Scrum as part of what they envision.  Scrum is a fairly simple framework whose origin is attributed to Jeff Sutherland and Ken Schwaber. There are numerous overviews of the history and evolutions of the framework;  those at and (where my CSM certification comes from) are two good ones.  The framework is simple. In its basic form it is comprised of three roles, five events and four deliverables.

The roles of the core team called out by Scrum are:

  1. The product owner who represents the voice of the business,
  2. The development team that transforms ideas into functionality and
  3. The Scrum Master who facilitates the team and process.

In Scrum there are no other roles identified.

The five events are sometimes explained as four meetings, with the sprint, which is an intrinsic part of Agile techniques. The five events identified in the framework include:

  1. The sprint which is the time box for developing potentially implementable functionality,
  2. Sprint planning which is a meeting for the team to plan the work they will commit to during the sprint,
  3. The daily scrum, the daily planning session that generally begins the team’s day,
  4. The sprint review which is the meeting at the end of a sprint for the product owner and stakeholders to interact with the functionality, provide feedback and acceptance and
  5. The sprint retrospective where the team reviews their performance and identifies opportunities for improvement.

The three deliverables identified in Scrum are:

  1. The product backlog which includes all of the known units of work in priority order,
  2. The sprint backlog is the breakdown of tasks and activities required to deliver the units of work the team committed during the sprint and
  3. The increment is the functionality completed during the sprint.

Putting the pieces together, Scrum follows a consistent pattern beginning with sprint planning where the product owner identifies the priorities for the sprint and the team plans the work they can commit to being able to complete. On a daily basis the team meets in a daily scrum to review progress and re-plan for the day   At the end of the sprint, the team holds a sprint review for all units of work that meet the agreed upon definition of done. The review is to ensure that what was completed meets the expectations of the product owner and other stakeholders. That generally means that they need to interact and exercise the software.  Units of work can be done, not done or spawn new units of work.  New work or units that are not complete are put back on the backlog to be reprioritized.  After the sprint review the team holds a retrospective so they have an opportunity to reflect on how they are working together in order to deliver the maximum value.

Scrum is a simple framework.  This simplicity makes it easy to adopt and adapt and can lead to many different variants to meet organizational needs and constraints.

Add a little sparkle to your routine.

Add a little sparkle to your routine.

What does “walking the board” mean? A team that walks the board focuses discussion on one story at a time.  When walking the board during a daily meeting, team members talk specifically about that story; describing what had been done, what will be done and what was in the way. By focusing on one story at a time the team can really focus holistically on the piece of work.  Why “walk the board” instead of the standard daily meeting format? There are generally two reasons.  The first is that even the best techniques get stale without variety. The second, walking the board promotes team-level coordination.

Daily meetings, whether Scrum or stand-up, follow the same basic form. Generally each person answers three questions: what did I do, what am I going to do and what is blocking my progress. After several months of doing your daily meeting the same way, regardless of how quick and focused it is, they can get stale. Stale techniques lose their effectiveness. Team members just go through the motions without really communicating with each other.  If a Scrum Master should have at least nine techniques for retrospectives, why would only having a single technique for the daily meeting make sense?

When a team walks the board, the discussion begins with a story.  When I am facilitating a daily meeting I usually randomly select the first story and then let the team direct the flow.  I have seen others select the story at the bottom of their list or board.  Everyone currently working on the story answers the standard questions as they relate to that specific story. The difference in the process is subtle if only one person is working on that particular story, however if multiple people are actively working on the story you will see the difference.  It will shift the focus to the story and promote coordination.

Walking the board addresses the age of problem of process boredom by providing the team with a second technique for their daily meetings because daily meetings are necessary for the team to plan.  Planning only happens with communication and coordination.  Process boredom is the natural enemy of communicating.