Have you ever attended a Scrum of Scrums?

If you ever worked on a multi-team Scrum project, chances are that the answer is yes. In my case, Scrum of Scrums was a weird-looking daily scrum between Scrum Masters where everyone showed up with a list of things to discuss (usually identified during team-level daily scrums), discussed the issues, and went back to their development teams with answers.

Scrum has been around for more than 20 years, delivering convincing results in many businesses as well as in the public sector. But when it came to scaling it to multiple teams, results were often less impressive. With all the challenges that can occur with multiple teams working on the same product-system-process, many Scrum teams tried various ways of coordinating work to ensure the successful delivery of a working product.

As teams experimented and learned, practices emerged to deal with scaling. Scrum of Scrums was among the first, trying to apply Scrum at scale with the same rules included in the Scrum Guide. However, due to a wide range of interpretations, Scrum of Scrums evolved chaotically, producing inconsistent results. In an effort to help struggling teams and organizations, leading authors defined scaling frameworks, for example, Large Scale Scrum (Craig Larman), Scaled Agile Framework (Dean Leffingwell), and Nexus (Ken Schwaeber).

Before diving into any of these, let’s go back to the basics. The reason for scaling beyond a single Scrum team is often related to a lack of capacity and/or productivity to respond timely to a business need. Regardless of the process though, be it empirical (Scrum) or predictive (stage-gate/waterfall), data-supported experience shows an immediate drop of productivity when adding individuals or teams. Over time, the increased capacity rarely yields a proportional increase in productivity—requiring an overhead of coordination on top of individual teams.

There are alternatives to scaling that are often disregarded despite the empirical evidence of their value:

  • Validated learning loop on a small batch scale—Is your Scrum team delivering a “Done” (i.e. potentially shippable) product increment every sprint? Is this increment shipped on a regular basis to users (external or internal) to verify the value hypothesis without developing the whole scope defined upfront?
  • Cross-functional and autonomous team—Are people on the team encouraged to work cross-functionally on what is the most important item at hand? Does this cross-functionality include business areas on top of the obvious IT roles? Is the team able to completely create the product by itself and validate the value delivered with actionable value metrics? Are people encouraged to grow as professionals within their expertise as well as on a cross-functional level?
  • Automation and tooling—Have your team started to automate as many redundant tasks as possible (test, build, integration, deployment)? Is your team using efficient tools to support engineering practices, learning and communication—even in a distributed mode? Are you using visual practices to radiate the information in a clear and transparent way for people who use it for work?

Agile scaling—Experiment different techniques, methods, and approaches that you will be able to apply in your organizational context.

The best advice about scaling is to do it when your Scrum team delivers a valuable and potentially shippable product increment every sprint. Organic growth (one team at a time) is highly recommended as opposed to “Big Bang” growth (many teams at the same time), mainly to help scaling every aspect in a gentle way, so that the original efficiency and team dynamics are not crushed after this huge change.

As to which model to follow, opinions differ widely. What works in one situation may misfire in another. However, while relying closely on Agile values and on  what made Scrum successful in the first place, which is an empirical approach to incremental product delivery favouring fast learning loops from the final client, it’s important to remain cautious and not to stick blindly to whichever model we decide to use.

Personally, I tend to favour Nexus, a minimal framework built on top of the Scrum Guide that focuses heavily on integration issues—as these are often causing tremendous overhead in scaling initiatives. Like Scrum, Nexus benefits from many complementary practices that have been proven to work well in various contexts. That being said, Agility requires nimbleness and prescribing one approach over the other would be harmful to any organization.

In a scaling approach, a true professional will stay open-minded and reach out for tools and practices within any other scaling method or framework (and even from elsewhere), refusing to blindly follow a prescribed best practice.

Regardless of the number of teams, the ultimate purpose remains the same: engaged cross-functional teams delight clients and users with frequent delivery of highly valuable quality products.

pawel mysliwiec

Pawel graduated in 2004 and is a certified Professional Scrum Master. He has played various roles since the beginning of his career—programmer, analyst, project and product manager, team leader and, more recently, business architect—in projects carried out using whether waterfall or Agile methods. Since 2011, he has been leading Agile initiatives in both IT and business teams.

Strongly believing in the power of Lean and Agile principles, Pawel joined Pyxis in 2015 to keep on helping people and organizations discover a more rewarding, empowering, and efficient way of working that is fully focused on bringing value to the client.

Previous post

Rebalancing society and Agile organizations

Next post

Five easy ways to effectively collaborate with your team

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.