Agile Coaching: The daily stand-up meeting

I’m starting a new blog series based on my experiences doing agile coaching at clients.  Along with agile projects in .Net, my company also offers agile coaching and training.  Right now, the agile coaching practice consists of me, but I’m actively working on finding people to expand that practice.  I started doing this March 2007, and since then, I’ve seen some of the same patterns repeated in very different businesses.  In this series of posts, entitled “Agile Coaching”, I’ll talk about some of the common solutions to the common problems I’m finding.  This first installment is about a daily stand-up meeting.

The daily stand-up meeting

At several clients, I’ve seen developers who aren’t co-located.  Many organizations value individual offices, and what I observed is that sometimes developer won’t communicate much day-to-day.  Perhaps there is a weekly development meeting where folks report on status.  I attended one of these, and one developer reported spending the entire last week on a single blocking issue.  A whole week!  I recommended the instituting of a daily stand-up meeting immediately.  This would give a daily sync-up opportunity for the development team.  There are plenty of other things to improve, but a daily stand-up meeting is low-hanging fruit.  It is easy to implement and returns immediate gains.

What is it?

Every morning (I like 0830 or 0900), gather the development team in the same area.  That area could be a hallway, a meeting room or whatever space is available for standing.  No chairs allowed.  The meeting should be over in under 10 minutes.  The agenda:

  • What I accomplished yesterday
  • What I plan to accomplish today
  • What issues are blocking progress

Every person in the development team reports on the three items to the rest of the team.  This is not a report to management or the coach/scrummaster/project manager.  This is so each person has a clear understanding of what is going on.  When issues are exposed early, others can help resolve them quickly.  I recommend this practice be used in every software organization.