Scrum of scrums can be used to scale the daily stand-up meeting when multiple teams are involved. Its purpose is to support agile teams in collaborating and coordinating their work with other teams. Several authors have shared views on scrum of scrums, with experiences of using them.
Charles Bradley wrote a blog post about resurrecting the much-maligned scrum of scrums where he described how the scrum of scrum can help teams who are working together on the same product to (re-)plan and coordinate development work:
I believe and have experienced that a Development Team-focused approach honors the principles behind Scrum, honors the principles of the Daily Scrum practice at the team level, and results in more value being delivered sooner to customers. In my experience, an effective Scrum of Scrums, for and by the Development Teams, leads to a big boost in the Development Teams’ self-organization skills, impediments being removed quicker, higher quality products, and higher valued products delivered sooner.
In his blog post Charles collected the views on the scrum of scrums from Ken Schwaber, Mike Cohn, Craig Larman and Bas Vodde, and Jesse Houwing. His conclusion is that scrum of scrums should focus on helping the development team members to coordinate and collaborate in self-organized way; it should not become a status meeting of the scrum masters.
When I coach Scrum teams, I put a strong emphasis on honoring the foundational principles of Scrum when scaling. I encourage Scrum Masters, if they attend the Scrum of Scrums at all, to stand "outside the circle" of Development Team members, and to avoid eye contact with Development Team members as they are collaborating. Because I believe in principle based scaling, it’s probably no surprise to you that I coach the same technique for Scrum Masters at the individual Development Teams’ Daily Scrums too. I want the Development Team members to be empowered to truly self-organize in their coordination and collaboration efforts. Yes, of course I coach the Scrum Masters to be servant-leaders and facilitate as wanted or needed -- but I also encourage them to fade to the background as soon as the Development Team can have an effective Scrum of Scrums on their own.
In the blog post effective scrum product organizational patterns part 2 Robert Galen provides a solution for large-scale product development organizations to connect the team’s scrum of scrums to their product organization. He describes three levels where the connection can be made:
- At the lowest level, there is a Product Owner per team; driving their efforts with a Product Backlog that aligns with the teams skills.
- At the Scrum of Scrums level, the Product Owners need to collaborate. Often there is a “Lead PO role”, where one of the Product Owners is guiding the aggregate view across the various Backlogs.
- At the Scrum of Scrums of Scrums level, there is typically a Chief or Uber Product Owner who is connecting higher level business roadmaps and delivery commitments down to the teams’ executing them. They usually track and maintain the balance between perceived commitments and the actually velocity of their Scrum delivery team(s).
Establishing the connecting between the scrum teams and product owners at multiple levels support the adoption of agile in large-scale organizations:
The essence of this pattern though is organizational transformation. Effective Product organizations re-connect their structures to how their technical teams are now delivering products. Along the way, they learn how to compose, decompose, and recompose backlogs that drive work through their Scrum teams.
Giuseppe De Simone wrote about the myth of “scrum of scrums” where he mentioned a myth about scaling agile:
When you scale Scrum to more teams, you handle dependencies and coordination among teams with Scrum of Scrums
He listed things that scrum teams do that should reduce the need for coordination among teams:
Actually dependencies are handled in Scrum by actually eliminating or at least minimizing them. That is done in many dimensions and here are 5 key things you cannot miss:
- First of all development teams must be cross-functional, meaning that they have all needed competencies to transform a product backlog item in a potentially shippable product increment. This is complemented by adopting a collective code ownership, where anybody is allowed to touch any line of code needed to deliver a product increment at the end of the sprint: otherwise you constrain your team with a lot of dependencies from outside
- Backlog items shall be in the form of end-to-end User Stories, cutting the system through all layers from front-end to the back-end to produce a potentially shippable piece of function: a component based development produces instead a hell of dependencies
- User Stories shall be INVEST, where the I stands Independent, so that they are easier to work
- In a scaled Scrum approach the Product Owner Team develops a unique Product Backlog to feed all development teams and ensure that they are as much independent as possible so that they can move fast with little need to coordinate with each other
- Scrum teams plan together so that residual dependencies are detected as early as possible
By have scrum teams doing these things, the need to do a scrum of scrums and its purpose changes:
It’s not a meeting of Scrum Masters to report some kind of status, but a possibility for a person who got a problem to rise up her hand and get fast help and support from other teams.
[The scrum of scrum] is not meant as the umpteenth coordination structure, but more as an emergency procedure to adopt when some team has put or is going to put something on some other team’s feet.
In the blog post scrum of scrums – a communication thermometer Morgan Ahlström shared an experience using the scrum of scrums. The project that he describes consists of seven teams in three countries doing a regular scrum of scrums:
All the ScrumMasters and the project manager would have a teleconference three times a week where the ScrumMasters would take turns giving status reports(!) and complaining about the problems they had. I was approached by some of the ScrumMasters asking me if we shouldn’t have the meeting less frequently since “nothing new is being said. The same problems are being brought up in every meeting.”.
It appeared that teams weren’t able to solve problems between the meetings. Morgan suggested that the scrum masters started to write down issues and start working on them in stead of complaining about them in the scrum of scrums. He also arranged an opportunity for scrum masters to meet in person and get to know each other better:
I managed to get the funding to fly all ScrumMasters to one of our sites and hold a retrospective and some other workshops. It was a great day with people getting to know each other but it still wouldn’t be enough. When, towards the end of that day, I asked if everyone in the room had everyone else on speed dial, the frightening answer was that no-one had anyone else’s phone number in their cells. Getting this problem solved was easy, the problem was to get everyone to use the phone numbers.
After this day together, I began requesting from each ScrumMaster to call all the others’ on a daily basis. Whether they had an issue to talk about or not, they should at least make a social call to see how the others’ were doing. This didn’t happen immediately; most thought that they’d get away without making the calls but I kept asking them about it in our one-on-one’s.
Morgan noticed that more issues were being solved since the scrum masters had established relationships with each other:
(…) fewer and fewer issues were being brought up during the Scrum of Scrums. Instead people were having social discussions and talking about problems in a past tense. (…) there were still a great deal of issues but now they were being solved outside of the Scrum of Scrums. The teams (or at least their ScrumMasters) had begun caring about each other. One team even offered to send some of their developers to another country to help one of the teams there before the other team had worked up the courage to ask for external help.
In a little more than a month we went from having a meeting that didn’t help us coordinate any issues or solve any problems at all, to holding a meeting where there were no issues to coordinate and no problems to solve. This made me realize that the daily stand-up and the Scrum of Scrums might not really be any solutions in themselves, but rather indicators of how well we communicate within our teams – outside of the meetings.
Do you use the scrum of scrums? How does it help your teams to coordinate and collaborate?
