Don’t Scale Up. Scale Your Product Down!
The inherent contradiction of scaling Scrum, and 5 descaling strategies to escape it
At the end of this post (you can also listen to it on our podcast), you will have discovered that:
- There is an inherent contradiction at the heart of scaling Scrum across many teams for the development of a single product;
- There is a way out of this contradiction by not scaling up the number of teams, but by scaling down the complexity of a product;
- Descaling a product is similar to breaking down work on the Product Backlog. Instead of one big product, you have many smaller products around a unifying purpose;
- Descaling a product increases the ability of individual teams to focus on value and become more responsive to their stakeholders. For the organization, it reduces risk and encourages a culture of experimentation and entrepreneurship.
Scaling Scrum is Hard
Scaling Scrum is seriously hard, right? How do you work with many teams on one product? How many Product Owners should you have for one large product? How can many teams deliver a “Done” Increment every Sprint? How do you manage the increasing number of dependencies between teams? Honestly, I believe that — in most cases — scaling Scrum is tantamount to solving the wrong problem. And I say that irrespective of the framework you use, Nexus, LeSS, or SAFe. Let me explain why.
The Scrum Framework essentially exists to refine big things into smaller things, from entire projects to Sprints and from large features to small Product Backlog items. Though often hard, this process of breaking down larger things into smaller things is a great way to reduce risk; smaller is simpler, easier to control, and less wasteful when it doesn’t work out (which happens often in complex work). Simpler is also faster. This sentiment is expressed well in one of my favorite quotes: “What one developer can do in one day, two developers can do in two”. This drive towards simplicity is strong in Scrum, as Gunther Verheyen captures when he states that “in the face of complexity, simplicity is our path”. The simplest solution — in terms of the number of variables — is more effective than a more complicated one.
“The Scrum Framework essentially exists to refine big things into smaller things, from entire projects to Sprints and from large features to small Product Backlog items.”
So how does this relate to the scaling of development on a single product? Scaling inherently increases complexity because it introduces more variables. There are more teams, more people involved in the development, more (potential) technical dependencies, more opportunities for adverse group dynamics, and more potential for politics. I’m sure most of us will accept this too. Why is it that we use a framework that encourages simplicity on the one hand, while also increasing complexity by adding more teams at the same time?
The Mirroring Hypothesis
One reason for this may lie in the seemingly inherent complexity in the product. In this case, the product is deemed so big that it simply requires many teams — there is no other way. Yet, there is logical absurdity going on here. If the product is so big and/or so complex, how is it a good idea to mirror this complexity in the product with complexity in the group of people that develop this product?
“How is it a good idea to mirror this complexity in the product with complexity in the group of people that develop this product?”
One explanation for this is the reverse of Conway’s Law. This law states that “any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure”. Although the effect is the other way around, organizations seem to implicitly mirror the complexity of the product in the complexity of the development organization. McCormack, Ruskan & Baldwin (2011) found evidence of this “mirroring hypothesis” by studying different pairs of development organizations and concluded that “the product developed by loosely-coupled organizations is significantly more modular than the product from the tightly-coupled organization”. Does that mean that complex products always require complex development organizations?
When it comes to scaling, and scaling frameworks like LeSS, SAFe, and Nexus, there seems to be an implicit assumption that only the number of teams is a variable, and not the complexity of the product itself. Behind this assumption lies a very different approach to product development.
Don’t scale up development, descale your product
Instead of dialing up the number of teams, what would happen if we apply a break-down strategy to the product itself to reduce complexity? Just like we break down entire projects into smaller Sprints, and larger Product Backlog items into smaller ones, we can break down large products into smaller products. By doing so, we reduce their complexity and make them simpler, smaller, and their risk more controllable. We can make the products small enough so that a handful of Scrum Teams — preferably even one — can still deliver a useful and valuable increment of that product to its stakeholders.
This approach may appear similar to “feature teams”. The difference is that feature teams (generally) work on end-to-end features from a single, shared Product Backlog. When you descale your product into many smaller products, you effectively end up with separate Product Backlogs and independent Scrum Teams that effectively act as “product teams”.
Potential descaling strategies
How can you break-down a large product into smaller, simpler products? Here are some of the strategies we have worked with. They share two characteristics. The first is that they result in vertical slices of a larger product; each small product remains valuable in its own right to its stakeholders. The second is that Scrum Teams become or remain capable of delivering a working increment of the product to their stakeholders (primarily users and customers) every single Sprint.
1. Break your product down by the groups of stakeholders it serves
One strategy is to break-down a large product into smaller ones based on the groups of stakeholders (users and customers, primarily) they serve. Take accountancy software like QuickBooks, Exact, or Xero. One approach is to consider the entire software package as “the product”. Developing that product can easily take dozens of Scrum Teams. Another approach is to consider various groups of stakeholders; entrepreneurs, small businesses, large corporates, governmental agencies, NGOs. In this case, the products become “accounting for entrepreneurs”, “accounting for NGOs”, and so on. This break-down can go as far as needed to keep the development organization as simple as possible. For example, “accounting for entrepreneurs in the Netherlands” or “accounting for webshops”. The most effective break-down is the one that results in the smallest number of Scrum Teams that can still deliver one cohesive product for a distinguishable set of stakeholders.
2. Break your product down by functional services it fulfills
Another strategy is to break a large product into smaller products based on the functional needs they fulfill. A good example of this is Google, with its wide range of products catered to specific needs; Google Drive for file storage, Google Slides for presentations, Google Docs for documents, and Google Photos for pictures. Each product is small and has a specific purpose, though is used by different groups of stakeholders.
3. Break your product down by creative destruction
Aside from breaking down your product into smaller products, the complexity of your product can also be reduced by removing what isn’t valuable or useful enough anymore. This process of creative destruction removes features and code that needs to be maintained, hosted, and supported, and is no longer capable of introducing bugs.
4. Don’t break-down your product by technical layer
One common strategy is to break-down products based on their application layers. So one team takes responsibility for the database, another for the back-end code, and another one for the front-end. This is a bad idea. Although this strategy results in highly specialized teams, which might seem like an advantage, none of these teams can deliver working software on their own. If a group of stakeholders requires a new feature, chances are that all teams need to perform work (changes to the database, to the back-end, and to the front-end) to deliver that feature.
5. Many products can appear as one
It would be a mistake to assume that breaking down your product into many smaller ones automatically means that you can’t present them as a larger product together. Google is a good example of this, with its rich ecosystem of smaller products that work together. Another approach is a marketplace, where customers can add or remove additional modules to suit their needs. Yet another approach is a screen-in-screen strategy where the interfaces come together in a unified dashboard.
Dealing with commonalities
Whatever strategy you use for vertically breaking down your product into smaller products, they will have much in common. There probably needs to be a uniform branding for the product, as well as a shared security model, storage platform, tax law engine, and business rules. Some of these commonalities might become internal products in their own right; a tax law engine for Germany, a tax law engine for the United States. For other commonalities that are not feasible stand-alone products in their own right, other solutions may emerge. For example, guidelines for branding can be provided through a shared style guide, a shared design framework (e.g. Material Design or Bootstrap), or shared themes. Recurring technical solutions — like a security model or business rules — can be shared with packages and code modules (e.g. NuGet, NPM).
If you look at the advances in software development over the past years, it is obvious that technology is moving in a direction that makes descaling progressively easier. Monolithic products can be broken down into microservices — independent services — that can be maintained and developed by individual Scrum Teams. Development Teams can use strategies like a strangler pattern to perform this breakdown progressively. Containerization like Docker makes it easier to deploy services independently in small virtualized containers that can be moved around hosts easily. Design patterns and architectural concepts like event sourcing and CQRS are created specifically to allow those services to communicate in a robust manner. So in terms of technology and frameworks, there is a lot of help available.
Benefits of descaling your product
- Scrum Teams lose most of their dependencies on other teams. Provided they are cross-functional enough, this makes it easier to deliver a “Done” increment every Sprint. This shortens the feedback-loop, reduces risk, and makes the team more responsive to stakeholder needs.
- Product Ownership is simplified because each small product has its own Product Owner that has a full mandate over that product. There is no need for the complexities of scaling Product Ownership across dozens of teams. Or worse, to create hierarchies of Product Ownership that stifle responsiveness and mandate. Instead, Product Owners work with the stakeholders of their product — users, customers, other teams — to evolve the product to best suit their needs.
- Each product can have its own profit/loss balance, which makes it easier to determine which products are valuable and useful and which are candidates for creative destruction. Individual products can be sold if needed. It encourages a more entrepreneurial approach.
- The modular approach of descaling products means that it is easier to start experiments with potential new products. When experiments fail, the blast radius is limited to just that product.
- This approach encourages antifragility. When a large product fails, the damage is much more significant than when a smaller product fails. When organizations effectively have a swarm of “small products” around a unifying purpose, the swarm evolves as some products make it and others don’t.
Obviously, descaling a product is not a silver bullet solution. It brings its own challenges. For example, what does marketing look like for many smaller products instead of one bigger one? How do you coordinate changes that affect many products? How do you keep the work done by Scrum Teams integrated with the larger purpose of the organization? How do you manage commonalities between the products and reduce duplication of effort? But compared to the challenges of scaling the development of a single product across many teams, it seems to me that overcoming the challenges of descaling a product is more likely to result in an increased focus on value, responsiveness, a culture that encourages experimentation, and a general sense of entrepreneurship among teams.
“When it comes to complexity, the challenge is not to ‘think big’ but to ‘think small’.”
A paradigm shift
When it comes to complexity, the challenge is not to “think big” but to “think small”. This is the paradigm shift that is at the heart of the Scrum Framework. But in product development, we often fall into the trap of “thinking big” and scale Scrum by adding more teams. Inadvertently, we’re adding complexity. This makes it likely that work slows down, becomes fraught with dependencies, and risk increases. In this post, I argued the opposite approach.
Instead of trying to mirror the complexity of your product with complexity in teams, why not break-down your product into smaller, less complex ones? This strategy of reducing risk by breaking-down large chunks into smaller ones should be deeply familiar, as it is an inherent part of the Scrum Framework. Isn’t it interesting that we so often resort to “thinking big” when it comes to scaling, when instead we may be better of “thinking small”?
References
MacCormack, Alan; Rusnak, John; Baldwin, Carliss Y. (2011). “Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis”. SSRN Working Paper Series. doi:10.2139/ssrn.1104745.
