Stand Up Meetings – “Scrums”

One of the first Agile best practices that companies attempt to implement is the stand up meeting, or “Scrum,” as it is often called. More often than not, it fails miserably. When I asked one Director why the scrums had failed, he said that they had lasted too long and brought no useful results. So then I started to dig a little:

Me: How many people attend these scrums?
Client: My teams.
Me: All of them together?
Client: Yes.
Me: How many people?
Client: A few dozen.

This led to a few recommendations:

• One scrum per team – Each project team should have its own stand up meeting. This leads to shorter meetings and more team members willing to raise their issues because they aren’t wasting the time of other project teams.
• Keep teams small – If the team has more than 10-12 people, split into smaller functional teams for the daily scrums, then have a combined scrum with a larger group only as often as it makes sense.
  

We then moved on to the next point:

Me: How are the meetings run?
Client: Well, we have everyone say what they are working on.
Me: Does this help?
Client: Not really.

So then I discussed a few additional recommendations:

• Keep it focused – The purpose of the meeting is to help maintain focus on the iteration plan and to remove any obstacles. To that end, each team member should briefly state what they did yesterday, what they are doing today, and raise any issues or roadblocks.
  
• Keep it short – A stand up meeting shouldn’t take longer than about 15 minutes. If an important issue is raised that affects the whole team, address it. If the issue applies to a few, take it off-line.
• Use a project board – I recommend that you meet around the project board, which tracks progress against the iteration plan, listing the stories and assignees, as well as status. This helps keep the "eyes on the prize." It also helps speed up the meeting by providing a convenient reference ("I resolved story X-35 yesterday, and I'm working on X36 today, which is my last story of the iteration").
  
• Keep it constructive – Don’t turn this into a daily inquisition or it will fail. As a developer hits a roadblock or falls behind, remember that the point is, “We are a team, let’s help each other succeed as a team.” If handled positively, the issues will be raised, and people will pitch in to help. If you'd like more details you can read my blog on Project Boards.
• Share announcements –This is also a good time to share brief, general announcements, e.g. “We’re branching the code at noon today.”
  

The stand up meeting is not the end-all of team communication. Ideally, most roadblocks will be identified and handled as they arise, not just in this meeting. However, if done right (and it may take some tweaking to get there), stand up meetings will improve your team's propensity to be working off of the same page, knocking down the road blocks, and helping each other hit their deliverables on time.