This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
Making Daily Scrum Meetings Really Effective & Efficient (Part 2 of 5)
In the first post of this series, I defined the Agile Scrum Framework and introduced the importance of conducting “High Effectiveness, High Efficiency” daily Scrums. Today I want to give you 6 key steps to make your Scrum team’s Daily Scrums more effective and efficient, and illustrate an example. The 6 steps to a more effective, more efficient standup are:
- Adopt and strictly follow the practice of conducting daily Scrums at the same time and same place each day. Early morning or end/of/day meetings are better than holding them in the middle of the workday. Each team should choose a time that is most convenient to most of its members, considering their other routine commitments, time zone differences for distributed teams, etc., and stick with that time.
- Use a good/quality audio conferencing facility and shared Web/based meeting medium (such as Citrix GoToMeeting or Cisco WebEx) for distributed teams, preferably supported by video conferencing.
- All team members prepare for the meeting beforehand. It is not very effective to think in real time what each member should do for the day (or until the next daily Scrum). Serious individual thinking and planning should happen ahead of time, and the daily Scrum meeting time should be used to inform team members and to recognize any dependency, coordination or synchronization issues.
- The ScrumMaster should only capture the issues recognized in a daily Scrum, and not use the meeting time to discuss or resolve them.
- The ScrumMaster should project all the important data (such as burn/charts, cumulative flow, Kanban storyboard and taskboard) on a screen to engage the team members. Members should not bring their own laptops, tablets or smartphones; these are often distractions.
- Most importantly, a team should have full engagement with their daily Scrums and commitment to the team’s goals and successes. This is a question of attitude and team spirit, and cannot be solved by any tool. It is not a tool issue, but people issue.
At this early stage, the team should first focus on making the daily Scrums really effective so they get full benefits from it, with ability to inspect and adapt on a daily basis. Remember that the daily Scrums are for the self/organized Scrum team, and not for the advantage of the ScrumMaster or management. As I said earlier, each team member presents his/her work plan until the next daily Scrum, and also reports on what was done since the last daily Scrum. I’ll give an example of how to make this discussion highly effective as well as efficient... In the very first daily Scrum of a sprint (let us say it’s on June 4, 2012), team member Andre Agile says he will work on the following two tasks. He has taken into consideration that he will have only 5 hours available to do sprint work on June 4 as he has to prepare for, plan and attend the daily Scrum, attend a company meeting, and also has a dentist appointment:
- Design Object X of the Payroll module design task (T/1702) for Payroll calculation story (B/189)
- Work on “Fix defect 369 (system crash) task” in “FICA tax deduction calculation story” (B/81)
Note that both tasks are very specific and result/oriented, with references to task number and story number in an agile project management tool that Andre’s organization is using. In the daily Scrum meeting on June 5, 2012, Andre will need to report whether the above two tasks were DONE or NOT DONE. If a task is DONE as planned, Andre should not spend a single second on it; only when a task is NOT DONE should Andre state the reason for it, and tell the team when the task will be completed at a specific future date. In addition, of course, Andre will also present to the team his plan for June 5, 2012. In this example, Andre’s update might look something like this, considering that he has 7.5 hours of work time available on June 5: Work done on June 4, since the last Scrum meeting:
- Design of Object X of the Payroll module design task (T/1702) for Payroll calculation story (B/189): DONE.
- Work on “Fix defect 369 (system crash) task” (T/183) in “FICA tax deduction calculation story” (B/81): NOT DONE. Reason: defect is only partially fixed due to its unexpected complexity. It will be fixed on June 5.
Work plan for June 5, until the next Scrum meeting:
- Complete “Fix defect 369 (system crash) task” (T/183) in “FICA tax deduction calculation story” (B/81).
- “Review test case” task (T/499) for State/level tax calculation story (B/66).
- Offer training help on Flash UI technology topic to Ken Coder: Unplanned (no story or task number).
Now this pattern of presenting the information on successive days of daily Scrums continues, day after day, throughout the entire sprint for Andre Agile. Exactly the same pattern is used by each member. On some days, a member may even report that he has brought forward a task from his sprint backlog and completed it as he had some extra time available as other planned tasks completed sooner than he thought. Check out my third post, where we discuss the advantages of this method. Part 1 Part 2 Part 3 Part 4 Part 5