Srum Daily Meeting

|

A core agile practice is the daily meeting, also known as the "stand -up meeting" and as the "daily scrum". Stand-up because one of the original ideas was to make sure the meeting does not last long — fifteen minutes is the standard — by requiring everyone to stand; this requirement is impractical and usually not applied. Scrum because many groups use some approximation of the version fine-tuned by the Scrum method.

The rationale for meeting at the beginning of every workday is the general agile principle that direct contact is critical to project success. It meets here with the just as general agile distrust of heavy processes and such waste-inducing practices (think "lean") as long meetings. Hence the emphasis on both frequency and strict time limits. The method insists in particular on what a daily scrum is not: it is not intended to solve problems or engage in deep technical discussions. Its focus is precisely defined: answering the "three questions". What did you do on the previous working day? What will you do today? Any impediments?

The first two questions give the team the opportunity to catch up with each other on the progress of the project and its immediate future. They also help ensure that team members make realistic commitments and fulfill them, since today's answer to the second question, the promise, will meet tomorrow's answer to the first, the reckoning. As Cohn writes, the exercise is not a status update where a boss finds out who is behind schedule, but an opportunity for team members to make commitments to each other.

In the third question, an impediment is any obstacle that stands between a team member and the realization of his stated goals. There are technical impediments, such as problems with hardware or software products, and organizational impediments, such as the absence of a team member whose input is needed. The meeting should remove the impediments when possible in the short time imparted, and otherwise assign responsibility for removing them. In Scrum, more specifically, removing impediments is one of the key responsibilities of the Scrum Master.

As emphasized by agile authors, one should be on the alert for practices that distort the purpose of the daily meeting and threaten its effectiveness. The two main threats are project members who go off into digressions, and the temptation to engage in deep technical discussions. Once you are aware of these risks, it is relatively easy to fend them off; the person in charge of enforcing good practices — in a traditional approach the project manager, and in Scrum the Scrum Master — can:

- Remind the ramblers to be concise; a more indirect technique is to enforce the time limit even (or especially) if this means that some people do not get to speak. It should not take more than one or two experiences of that kind for those who spoke too long to understand that they are the ones at fault. If it does, the team truly has a problem.

- If a technical discussion takes off on its own, intervene and suggest holding a sepa-rate meeting.

The idea of the daily meeting, with its focus on the three questions and the strict limitation of scope and duration, is brilliant. As with other agile ideas, you can stop listening to the advice when it becomes dogmatic. Some circumstances, such as geographically distributed projects, naturally lead to variations over the basic scheme:

- Setup time. A 15-minute meeting is fine for a resident team but generally not effective for a distributed team. Even with good technology and an experienced group of people, it can take a few minutes ("Can you hear me?", "Let's switch from Skype to WebEx", "The video conference room is still occupied") to get down to business.

- Flexible working schedules. In many organizations, some employees come in at different times or occasionally work at home. Such practices contradict the agile insistence on direct personal communication, but they have other justifications, such as the desirability of a "sustainable pace", and companies may legally be required to allow them.

- Time zones. Consider a group with some members in California and others in Shanghai. 7 AM for the former means (in the winter) 11 PM for the latter. You can ask people to be up late once in a while, but not every day.

- Meeting inflation. While there are good reasons for moving deeper technical discussions to a separate meeting, they should be balanced with the overhead of organizing separate meetings ("Let's discuss this on Tuesday afternoon — Tuesday I am not here, can you make it Wednesday at 10? — Yes, but I think the meeting room is not avail-able" and so on), plus the context-switching time (the time for everyone to remember what it was all about). Sometimes when an issue can be solved by a 20-minute discussion it is just as simple to have that discussion then and there.

- Length variability. There is no reason to use the same limits regardless of team size. 15 minutes may be fine for a group of five people and too short for ten.


A distributed team I know, which works across three continents and has honed its process over several years, has two weekly meetings, Monday and Thursday, at a time that is acceptable in all time zones affected. Both last one hour for the reasons just mentioned. They have complementary goals:

- The Monday meeting is developer- and deadline-based. Its purpose is to check progress towards the next deadline. It is run in the spirit of a Scrum daily meeting: each member of the team presents his or her current status based on the "three questions". Since it uses a full hour, technical discussions are not prohibited as long as they remain short; anything that requires deeper analysis is moved to the Thursday meeting or some other medium (such as an email discussion, or an extraordinary meeting). The team long ago learned to make good use of the available time and never overruns the one-hour limit. There is no agenda for those meetings; they are organized around the task list, a shared document that everyone can consult (through screen sharing) during the meeting.

- In contrast, the Thursday meeting is agenda-based; it is devoted to the discussion of a list of issues collected in advance by the meeting secretary (a task that rotates between members of the group). Its decisions are recorded as "action items" in the minutes (produced in real time during the meeting), and copy-pasted to the agenda of the next meeting so that the first matter of the day is to check what has been promised, just as in a daily meeting.

This particular formula, obtained by trial and error (as well as reading agile and other software books) works well for that particular group. A team subject to different constraints will fine-tune its own variant of the daily meeting idea. Freed of dogmatism — adapted in particular to the multi-site, flexible-personal-schedule working style of modern companies — that idea, particularly its focus on the "three questions", is one of the principal contributions of the agile school. Some day, the whole industry will be practicing it and not even conceive that anyone could ever have been working otherwise.

Taken from : Agile!: The Good, the Hype and the Ugly

0 comments:

Subscribe to Computing Tech

Enter your email address:

Delivered by FeedBurner

Add to Technorati Favorites Top Blogs