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.