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?
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.
No Comment