The birth and death of a Scrum of Scrums — the triumph of silos

My friend asked me to write her story about the scrum of scrums (SoS) she started, kept alive and killed after a few months. The story has provided her several lessons learned that were used to resurrect the SoS in a new form. To protect the innocent, let’s call my friend


She joined the project 5 months earlier as a software architect and her boss asked her to coordinate the work of the product owners. She was surprised by the request since she was not a PO, and in the organization she was below the POs which could have been counterbalanced with her several years long contribution to the product, but she was also new in the company. When she told her concerns to her boss assured her that he would support her and he referred her proven track record as successful product owner.

The Project

The project was admittedly non-agile, although they used agile role names. They had scrum teams, scrum masters, product owners, however they did not work in scrum, but in a “loose waterfall”. The organization was heavily siloed: they had 6 component development teams, a separate integration testing organization with 2 teams, and a release team; the communication and coordination between teams often needed the involvement of the development managers. Unsurprisingly the project suffered from integration and quality issues.

The Inception of a Scrum of Scrums

In her previous project they solved lots of coordination and communication issues with scrum of scrums, so she believed that it would also be a successful tool in her current project. She knew that she needed to create a customized version of SoS. She wanted to see the activities in every development team, and she introduced phases for the backlog items: backlog, study, design, development, test backlog, integration testing. The development phase included unit and some function testing, but the integration testing was a separate activity, since her assignment did not involve the teams of the integration testing organization. Similarly, the release team was also under a separate management, and consequently outside her assignment.

She presented her proposal of daily scrum of scrums to the product owners, and she got mixed responses. On the plus side they gave some improvement ideas and some of the POs welcomed the idea, but on the minus side most of the POs regarded it yet another useless meeting which would keep them away from their teams and real tasks, and consequently slow down the development. She turned down their proposal that it should be held only once a week as a status review meeting, but she felt that she need to compromise to start the series, and they decided to schedule it to every Monday, Wednesday, and Friday.

The Birth of a Scrum of Scrums

The first scrum of scrums was a great success. All POs were present, and they collected all major backlog items for each team; they have written them on sticky notes and put them on a whiteboard. For the first time in the history of the project they had a unified view of the things they were working on (minus release). She got praised for her idea and efforts by the product owners and the management team, everyone looked satisfied.

Scrum of Scrums board v1.0

The POs identified gaps in their (separate) development plans, discrepancies with the communication with the product management, but apart from these, according to their reports, things went well.

The Agony of a Scrum of Scrums

Over the coming weeks attendance has steadily declined. The members of management team have never participated in the meeting, and the POs also tended to skip the event due to another meeting or an urgent task. The management team expected the POs to deliver their pieces of a feature on time and make timely progress, while solving the integration issues was chiefly left to the integration test teams (scheduled months from that point).

Sarah was not granted authority over the POs, so she could not make the SoS mandatory. As a matter of fact, she did not even wanted to force the POs to attend. She wanted to change the culture: she wanted them to feel and understand the importance of breaking down the silos. She tried to balance her lack of authority with enthusiasm, and her experience on the field. She explained the importance of end-to-end feature-oriented view, early testing, and the negative consequences of late integration.

Although the POs seemingly accepted her arguments, they acted differently. The culture of silos prevailed.

Killing a Scrum of Scrums

Despite all her efforts she had to accept that the scrum of scrums is doomed to fail. Roughly two months after starting the SoS Sarah already knew that she made several huge mistakes, and she had no other option left but to cancel the series. For that she needed a good reason: the complete lack of attendance. During the next 1–2 weeks there was always at least 1–2 POs who came to SoS, until on a Friday morning she was the only one standing in front of the SoS table. At last, she thought, and sent out the cancellation message.

Everybody seemed to be relieved, and no one wanted she to reverse her decision. She knew she failed.

Lessons Learned

The main mistakes Sarah made:

  • There was no sense of urgency in the organization.
  • She had neither power nor status in the organization.
  • She had no real management support.
  • Key stakeholders were missing from the SoS, such as the members of the management team, the integration test team, and the release team.
  • She could not sell the importance of end-to-end view.
  • The development managers pushed the POs to make progress and finish their components on time, as opposed to deliver working, releasable features with the shortest lead time.

The Aftermath of the Cancellation

To Be Continued…