The Scrum Standup: Making the Most of a Crucial 15-Minutes

Agile methodology has emerged as the preeminent project management system for software development and is proving useful for managing projects in other industries. At the heart of agile …

Agile methodology has emerged as the preeminent project management system for software development and is proving useful for managing projects in other industries. At the heart of agile methodologies is the Scrum or Standup meeting, and it’s proper execution can make or break an agile system. Nearshore Americas talked with Scrum Master Rubén Lorenzo and Software Engineer Luis Silva of Belatrix Software, and relied on our some of our own staff’s aggregate knowledge to underscore best practices and Do’s and Don’ts regarding this powerful yet delicate lynchpin of agile methodology.

A product owner that intimately knows the customer’s needs and can be just as critical as the customer is essential. Although the Product Owner is part of the team, she/he must be removed from any influence to cut corners or build solutions that are “good enough.”

The Scrum Master is responsible for making daily Standup meetings (yes, it is important to actually remain standing up) productive and concise, this is not easy and we go into the finer points of it below. Under the direction of the Scrum Master, team members must self-organize the scrum meetings rendering the Scrum Master a mere facilitator.  It is advantageous for team members to be generalists that can take on any task.

Quite Simple

A Standup meeting should only last about 15 minutes where each team member speaks to three simple questions.

What obstacles are impeding you?

What are you working on / finishing today?

What did you complete yesterday?

“A team member should not talk longer than two minutes, three at most,” explained Lorenzo.  “If a team member is talking for too long they are usually trying to explain something very specific so we ask them to save it for right after the scrum.”  It is important for the Scrum Master to create the atmosphere that each developer is reporting to his or her peers, not the Scrum Master; it supports the notion of the self-organizing team.

Standup Do’s

Buy a timer or put the smart phone with the timer in the middle of the huddle so it can be seen.  Some Scrum Masters initiate the call to the meeting (which should take place in the same room where the work gets done and at the same time every day) by playing a song – Bob Marley’s “Get Up Stand Up” is an understandable favorite. Energy must be infused into the meeting with an urgency to move work through the system, a burndown chart can show this visually comparing time remaining to tasks left to complete in the 2-4 week sprint.  He who shows up last at the Standup talks first; it is a soft penalty to keep team members punctual. After that team member talks the next person can talk in a circle or a baton can be passed to initiate the next speaker.

Some find that Standup meetings where team members speak in random order do not address tasks coherently, those teams that use a single point of visualization like a Story or Kanban Board can Walk the Board, and thus speak to tasks in a more prioritized way.

Have the Standup within the first two hours of the workday and use it to set the tone for the day, be aware that team members often do not work on tasks until after the Standup, they may fill the pre-Standup time with completing time sheets, coffee breaks, email, etc.

Make Sure that You Stand Up

  • Tell team members to “Take it Offline” when they are telling the whole story and not just the headline regarding an issue.
  • Record the issues raised on an Improvement Board (a.k.a. Issue Board, Blockage Board, or Kaizen Newspaper) to track their resolution, the Scrum Master makes notes during the Standup and updates this public board after the meeting; note that if issues are not resolved team members will stop reporting them.
  •  Have a single point of visualization or Board, not just agile project management software.
  • Indicate the end of the meeting with a “Great, let’s get it done,” or some other phrase, after the last team member finishes others may not realize everyone has spoken and that drift to an unpunctuated conclusion can end the meeting on a low note.

Standup Don’ts

Sign up for our Nearshore Americas newsletter:

Don’t allow team members to run-on about anything unrelated to the work tasks, other team members not directly involved will get disinterested and the Standup will lose focus.

Don’t allow other team members to engage in on-the-spot problem solving that can be done after the Standup; again, team members not directly involved will get disinterested and the Standup will lose focus.

Don’t permit Standup meetings to devolve into a boring weekly status update meeting chopped into 15 minute increments spread across days.

Other co-workers can attend, but should not talk, they are spectators.

Make sure the Improvement Board is not a Complaining Board about which problems are expressed that the developers do not have control over.

Who Sequences the Tasks in a Sprint?

“Most of the time it is the Scum Master [not the Project Manager or Product Owner] that sequences the tickets and user stories,” said Lorenzo.  Silva mentioned that he has seen projects where the Product Owner has some control over the sequencing of feature development as well.  In terms of balancing the ticket load across developers “the project managers can take that role of assigning tickets if they have knowledge of the technology and the team,” commented Silva.  However, as the sprint gets rolling it is the Scrum Master’s job to make necessary adjustments regarding and changes to tasks individual developers are working on.  Lorenzo reiterated that it is ideal to have a team of generalists that can work on any task, which facilitates the reshuffling of tasks as needed among developers.

What if the Requirements are Poorly Written?

“In agile that happens quite a lot, you don’t have all the requirements really well documented so we try to implement different techniques like post-planning product owner review meetings where the team talks about their understanding of the requirements to the Product Owner; this should happen at the very beginning of the sprint,” said Lorenzo.  Silva added “that the QA must be involved from the beginning, testing every requirement from the definition making sure everything is consistent with nothing missing.”

Tags