Three stages of the Daily Scrum

Lately I have been working in a large Agile program. With large Agile programs, comes common large team challenges, and the need to adapt the Agile development and management practices to better suit the large team challenges.

Currently the program has 180 people distributed over 12 teams. Each team is formed by 15 people (project manager, business analyst, quality assurance and developers; for short: PM, BAs, QAs and Devs). All teams are following agile practices such as 2 week Iterations, Daily Scrums and End of Iteration retrospectives.

In this blog entry I will describe how the daily scrum (or daily stand-up) meeting went through 3 different stages as the program grow from one team to 12 teams (of 15 members), adding up to 180 people on the program.

Stage 1: The Daily Scrum meeting

When the program was small (up to 2 teams of 15 people), each team had a daily scrum. The teams were getting good value out of the daily update. The three questions answered by each team member (what did you work on yesterday, what are you working on today, do you have any blocker?), and some informal catch up by the PMs, BAs, QAs and Devs of the two teams was enough to keep all program members in sync.

Stage 2: Scrum of Scrum with PMs and non-PMs

As the program was growing (consider now 5 teams of 15 people) the teams were still having the daily scrum meeting. However the individual teams started losing context on the status of the program, and important inter-teams updates and communications were not flowing as easily as when the overall program size was smaller.

We started having Scrum of Scrums after the teams’ daily scrum. The Scrum of Scrums (SoS for short) had the same format as the daily scrum: the participants would stand in a circle and would quickly give status update by answering a few questions. The questions were slightly different than the daily scrum questions. The SoS participants would answer the following 4 questions: What did your team do yesterday, What will your team do today, is anything blocking your team, is your team about to put anything in other team’s way?

The participants of the SoS were PMs and non-PMs: team member, such as BA, QA or Dev. The PMs presence was mandatory and they would drive the meeting (answer the 4 questions.) Each team had two representatives: the PM, and the non-PM team member. The PM would daily select the non-PM team member to attend the SoS (this was done in the team daily scrum). At times a team member would volunteer to come, as he/she had to give some important update to the overall program.

The non-PM SoS participants brought very important aspects to the SoS. First they would complement their PM with the extra detail (not too much detail, but enough for spawning the interest for the other program team members.) Second, they were effective radiators of information. They would bring information back from the SoS to their teams (at times the PM was pulled into other meetings prior to returning to their teams.) And last, the non-PM SoS participants made sure that the SoS did not become a PM update meeting.

Stage 3: Scrum of Scrum for PMs

The program was growing in size. Consider the phase where the program reached 12 teams of 15 people. The SoS with PMs and non-PMs became less effective. First, it was taking too long for 24 people to talk. Second, the SoS was becoming a mixed forum of discussion. The PMs wanted to go into further project management details, while the Devs wanted details on the development activities.

We changed the SoS format. At this stage, we broke it into several SoSs: The PM SoS, the Dev SoS and the QA SoS. In fact the PM SoS called was named SoS: Scrum of Scrums. The Devs and QAs meetings had other names such as Dev hurdle and QA catch up. The PMs kept the SoS in a daily basis; the other roles varied the frequency of their catch up meetings.

The SoS became a PM update, but it was an essential (and quick) PM update. Actually, the SoS still kept the stand-up in circle format, which prevented the PMs form giving long updates (specially after standing up in each team stand up, and then in the SoS). Also the PMs were still focusing on answering the original 4 questions of the SoS (described in stage 2).

The art of facilitating the SoS made an enormous difference. It was simple: whenever a PM would go into a detailed update (for example, I found a bug pattern in my team that …), or two or more PMs would repeat the same information (e.g. blocker: my team could not commit because the Continuous Integration server was down) the item would be added to the Parking Lot.

The Parking Lot items would be discussed at the end of the SoS. PMs that were not required could leave the meeting. If other people would be required, they would either be dragged into the meeting room, or a meeting would be scheduled later.

In summary, the described stages of the daily scrum worked for the program in different stages of the program. My main learning from this experience: try what works for your team, but do not hesitate on adapting.