Using Scrum of Scrums with Agile Teams to Coordinate and Collaborate
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?
Scrum of Scrums: to be agile on both tactic and strategic level
For that reason, I have not only an 'ambassador' of every Scrum team (whoever that may be) on board of the SoS, but also other people on 'meta level', such as: a business analist, a system architect, people from marketing/sales/support, a customer respresentative, etc. Based on strategic input such as the roadmap, product portfolio, marketing plan, etc. they make sure the right epics will be part of the product backlogs of the teams. Important information radiators for the SoS team are for instance the project burndown charts, to enable straightforward multi-product release planning.
Strangely enough I miss this aspect completely in the discussion about the Scrum of Scrums. Of course Scrum teams must make sure they collaborate efficiently, but apart from the mutual alignment, their work must be in line with the overall strategic business goal. I know this is the prime responsibility of the Product Owner(s) - but it is my experience that the Scrum of Scrums can effectively facilitate and streamline their work.
Re: Scrum of Scrums: to be agile on both tactic and strategic level
Having stakeholders involved in the Scrum of Scrums can empower that team and make it easie to take things forward as you describe.
I see a risk that such a Scrum of Scrum teams starts to manage all the Scrum teams, maybe even in detail. Which can be conflicting with the teams self-organizing their work and the individual team collaboration with their stakeholders. How do typically handle that?
Re: Scrum of Scrums: to be agile on both tactic and strategic level
Indeed this could be a risk - but I have never seen it happen.
Typically, the Scrum of Scrum team (as I perceive it...) will only deal with Themes and Epics, never with User Stories. In other words: also with respect to the items on the Product Backlog(s), they remain on meta-level. Selected Epics will be groomed by the Scrum Teams, in close collaboration with relevant stakeholders. It is my experience that handling the strategic stuff on a more abstract level will even facilitate the self-organization of the Scrum Teams, by providing them a clear focus, more transparency and less disruption.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015