Daily Stand-up meetings are used by eXtreme Programming (XP) teams as a simple way to support communication and feedback. These daily meetings synchronize development activity with the current plan and can also help team building. Although daily stand-up meetings were held on the C3 project, the Daily Stand-up was not listed as one of the twelve XP practices, stand-ups only gets a passing mention in "XP Explained", with no information on how to run one until "Planning XP". Other agile software development methods have similar meetings: Daily Scrum in Scrum, Morning Roll-call in FDD and Daily Wash-up in DSDM. In the PLoP4 book, SCRUM is presented as a pattern language and emphasis is placed on the role of the SCRUM meeting as a ritual that socializes of status, issues and plans across the team. In "XP Applied" Ken Auer and Roy Miller make the following comment "the need for stand-up meetings is not as explicit as it should be in the XP literature". I have to agree - they are simple to implement and provide a real reflection of how well the team is progressing.
I have no personal experience of DSDM or FDD but I thought it might be interesting to describe how I have seen the practice of holding a daily stand-up meeting evolve as this shows some inter-play between two agile methods, XP and Scrum.
In 2000, I joined my first XP team at Connextra as a Java developer. At Connextra, we held a company stand up meeting every Monday morning - attended by all employees - from support staff to company founders. The meeting was lead by one of the directors with an update on company news followed by a status report from Sales, Dev, Support, etc. If anyone had been on holiday they were obliged to present a "Tacky Gift" at the end of this company meeting.
When I joined the company, there were two development teams and they each held their own daily stand-up meeting at 9:30am. These stand-up meetings were held around a Planning Board where the stories written on index cards for the current iteration were pinned. The structure of the Dev stand-ups was pretty informal, we talked about any stories in progress, checked off any stories that were complete and allocated pairs for the day.
Whilst at Connextra I read "Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle. The tips for running Daily Scrum meetings sounded like they would give our XP stand-up meetings more focus. Also, there is no mention of referring to sprint backlog or burndown chart in the meeting.
During the couple of years I worked at Connextra, the way that we ran the stand-up evolved. Every month we held a retrospective and used this as a mechanism to fine-tune our development process.
Problems that cropped up were time wasted in gaining enough critical mass to start the stand-up, late-comers, poorly presented information radiators, silent lurkers, too much information and central control. Since then, in my work as an independent agile coach, I have seen the same problems and others occur in other teams.
Jason Yip's
paper lists some smells. If you want to see just how out of hand things can get then try out Bill Wake's simulation
Second Agenda!
When you think about it there are several variables.
What gets talked about?
In Scrum, each person is asked three questions:
"What have you done since last meeting?"
"What blocks got in the way since last meeting?"
"What will you do between now and next meeting?"
This format resonated with me because it was similar to the way I had run weekly team meetings on non-XP projects. I found it more productive to ask each person these question in turn and for the whole team to hear the answers rather than collate the answers myself in one to one chats and produce a status report.
This three question format works well for XP stand-ups, the only adjustment required is that developers, who were pair programming together, do not repeat items that have already been covered by their pair. In large teams, exceeding twelve developers it may give the meeting more focus to talk about each story in turn rather than run round-robin around the circle. If you do this then be on the look out for individuals who have not worked on any story.
It can be tough to get the bandwidth right. Some developers have the habit of being too brief and their report says nothing "I was working on story X".; whereas others give too much detail. The team needs to talk about the significant details of their work but sometimes a detail can have significance without the speaker realizing. I think it is important for people around the circle to be allowed to ask clarifying questions during the stand-up rather than postponing all discussion to after the meeting.
Who should attend?
At the Daily Scrum meeting, tasks are scheduled for everyone on the team working towards the Sprint Goal not just developers. Scrum categorizes attendees who are not commited to the Sprint Goal as Chickens. Chickens can attend (standing outside the circle) but not talk.
In XP it is not clear if the On-site Customer should attend these meetings. The XP literature focuses on the software development part of a project and has very little to say about practices for the On-Site Customer.
At Connextra, we had a Customer team rather than a single customer. Each member of this team gave a progress report on their activities every Monday at the company stand-up. Members of the Customer team were welcome to attend the developers standup to get an update on progress of their stories.
Once we had an increasing number of users for our products we introduced a separate Customer team stand-up to set priorities for the day on Support tasks. One smell that I have observed in organizations where customer attends the daily stand-up is that some developers save up questions for their customer until the stand-up.
If a team member (developer, customer, manager) is working at another site or from home they may dial in via a speaker phone. This means there is some setup to do before the meeting and remote team players may not pick up everything that is said. I have occasionally witnessed the team exchanging silent humor (such as eye-rolling and gestures) in these situations.
Who runs the stand-up?
In some teams, stand-ups are run by the team leader or coach. When I am coaching a team, I may run the first couple of stand-ups to demonstrate how but prefer that the team lead or project manager takes on this role, as this reinforces that leadership is bought-in to the new process. In the long term, having a single person who is responsible for running stand-ups can create an unnecessary dependency. If that person is late or out of the office then the responsibility has to be delegated to someone else. At Connextra, we formed a U-shape around the Planning board. The meeting would be run clockwise or anti-clockwise by one of the developers standing at either end of the U.
When does it start?
The meeting should start at strictly the same time every day. Choose a time that works for everyone and start on time without waiting for stragglers. It can help to book a recurring meeting in electronic calendars to avoid people getting double-booked.
Most teams choose to start the day with a stand-up as this means no development is interrupted by the meeting. If people do not work the same core hours then an alternative is running the stand-up after lunch or at the end of the day. This can also be a good way to break pairs up who are used to working late or thru lunch.
Ken Schwaber suggests a that late-comers are fined and money collected goes to charity. I do not think this works, the late-comer can then get a warm charitable feeling each time they are late. If people do not realize the scale of the problem then track lateness on a Big Visible Chart.
Should the plan be visible?
Although a circle is the usual arrangement in Scrum, I prefer a U-shaped huddle around the plan, as this saves some head-scratching as people struggle to remember what story they were working on. It is worth taking care to present your plan so that it can be read from a distance. Use a marker to write story title in block capitals. Use colored stickies to show what stories are in progress or done. Consider information radiators such as burn-down charts for your shared workspace, the stand-up can be a good time to remind the team of their current commitments.
Create a parking lot for issues raised (on a whiteboard or using post-its) and make sure this is reviewed at the end of the stand-up meeting.
Always standing up?
As a coach, I try to set an example by standing up rather than propping myself up against the furniture. Where the space that you hold stand-ups in contains desks/stools/beanbags it's always tempting for the people who show up first to sit down and this can set a precedent for everyone else who enters the room. If this results in a slow running meeting then comment on elapsed time and clear furniture to the side of the room before the meeting. In extreme cases use a kitchen timer.
I have encountered circumstances where sitting down is OK. One such situation is where one team member is uncomfortable standing, maybe suffering from back injury or expecting a baby, in this case I prefer everyone to sit. This also makes sense if the team was out drinking the night before and everyone is hung-over. Another situation where it seemed sensible to sit, was a team with a high number of in-sourced team members and a mountain of legacy issues that needed a half-hour team meeting every day. Scrum was originally described as a sit-down meeting. If you have a distributed team then a Scrum by audio-conference is likely to take longer and it may help to have people seated around a conference phone on a table rather than standing around a phone on the floor.
I have even encountered a team who felt too embarrassed to stand for the meeting as it felt too american. As a coach, I do not play an enforcing role, instead I explain likely effects of their decision and keep giving feedback on ways to improve team dynamics.
I hope these tips are useful to those of you implementing daily stand-up meetings. All too often we concentrate on the differences between agile software development methods rather than the common ground.
