Monday, May 4, 2009

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.


Anonymous said...

Really great work. Congrats to everyone who are involved with this project. The website layout and graphics are really cool. Please come visit my site Long Term Care Insurance when you got time.

Anonymous said...

Awesome! I have read a lot on this topic, but you definitely give it a good vibe. This is a great post. Will be back to read more! Please come visit my site Firefighting Training and give me any valuable feedbacks.

Anonymous said...

Scrum Master Stephen Forte Teaches Agile Development, Silverlight and BI at Great Indian Developer Summit 2010 in Bangalore from 20 April to 23 April 2010. Interested people can register at

Gowshika said...

I actually enjoyed reading through this posting.Many thanks.

Unknown said...

ACER Extensa 4630 Series Laptop batteryACER Extensa 4630 Series Laptop battery
DELL Inspiron 500m Series Laptop batteryDELL Inspiron 500m Series Laptop battery
DELL Latitude D500 Series Laptop batteryDELL Latitude D500 Series Laptop battery
DELL Latitude D520 Laptop batteryDELL Latitude D520 Laptop battery
DELL Precision M20 Laptop batteryDELL Precision M20 Laptop battery
DELL Inspiron 510m Laptop batteryDELL Inspiron 510m Laptop battery
DELL Latitude D505 Laptop batteryDELL Latitude D505 Laptop battery
DELL Latitude D600 Series Laptop batteryDELL Latitude D600 Series Laptop battery
DELL Inspiron 600m Series Laptop batteryDELL Inspiron 600m Series Laptop battery

dte said...

The past is gone and static. Nothing we can do will change it.scarlet blade gold, the future is before us and dynamic. Everything we do will affect it rs gold, You laugh at mescarlet blade gold for being different , but I laugh at you for being the same.

Unknown said...

It is the responsibility of the Scrum Master to ensure that the Product Owner does not change requirements or acceptance criteria during the Sprint review and reject a done backlog item because it does not meet the changed requirements. If the requirements have changed, a Product Backlog item needs to be created to address the changed requirements in a future Sprint. If you want to know the difference between Scrumstudy, Scrum Alliance and Scrum org – please visit this blog :

Unknown said...

Hi paulo,
Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time, de-focussed our colleagues and interrupted their workflows). Because of this we developed a SaaS tool to "automate" the daily standup meetings - with just a single email. If you like to take a look:

SBPwindows said...

Nice thanks for sharing this blog, keep update more blogs.
Best UPVC Windows and Doors Manufacturer in Chennai Best Upvc Windows and doors dealers in chennai
Latest Upvc Doors in Chennai

Deva said...

Great, please continue to share your thoughts.

Ui Ux Design Course In Chennai
Ui Ux Online Course
Ui Ux Course Bangalore