How your product determines your scaling approach

When your product grows, often scaling is the path that we enter. However, does your product need a scaling Scrum approach? Do you even have truly only one product?

Published in

Serious Scrum

13 min readDec 2, 2021

The “Big Fictional Company” teams struggle a lot lately. They have a ton of work to do, but that is nothing new. There are around 200 developers within the organization. Some people spotted some problems with working in such a big group and came up with the idea that they should do a scaled framework. Long story short, management caught up with that, and now here they are. In the land of never-ending meetings, as employees assess it. People are tired and disengaged from constantly having to go from one meeting room to another. Attendants are not engaged and interested to focus on meetings topics. John, one of the involved developers, said lately:

“The only thing we achieved by scaling is we have less time to do our work and understand less about our upcoming work.”

The “Big Fictional Company” hired even some external coaches meant to guide them throughout that scaling journey.

I mainly focus on software development within this article. However, I believe that those concepts are applicable in many other contexts. I need to notice you, that this will be a long read :)

Ok, you have been warned, still here? Great! Let’s dive in.

John’s Scrum Team — the Sailors — are about to start next Sprint Planning. There are 18 Scrum Teams, totaling nearly 200 people. Some people call this gathering a Nexus Sprint Planning. Others call it Big Room Planning. Some even say that it is the Large Scaled Scrum (LeSS) inspired planning event. Whatever is true, those joint planning meetings mostly looks like this one:

Caitlyn, the Product Manager, tries to outline the main theme for the planning session. This time it is to “Increase users happiness”. Some performance issues had an impact on the customer support line and KPIs lately.
Then their two Product Owners (Adam and Greg) share a so-called “vision” for changes in their two products. Adam is accountable for the pre-sale website and pricing plans. Greg, on the other hand, is accountable for the “main app” development, which is an e-commerce suite offered in the SaaS model.
“To impact user happiness, we need to focus mostly on our notifications capabilities. Users and prospects often are not aware of our promotions or new features.” — Adam points.
Greg adds that — “Users highlight a lack of out-of-the-box online payments. Integrating one is unnecessarily overcomplicated. Thus we need to integrate a payment system into our system. Our company has already chosen one. We also need to simplify for the users the process of adding custom integrations of other payment solutions.”
After that, the developers present their Scrum Teams plans. The Sailors share their Sprint Goal. It is: “Enhance the AI model used in recommended products feature”. As there are new data sources available to use.
John noted in his mind four observations that seem for him as the new normal:
(1) “A couple of hours passed and Caitlyn already left the meeting to catch her other duties (…)
(2) Adam is not listening and seems to treat the topic as not his concern (…)
(3) Greg, who looks interested, doesn’t even point that the Sailors do not seem to contribute to what others said before (…)
(4) Other teams also seem to pass by the problems/goals shared at the beginning by Caitlyn, Adam, and Greg.”
A couple of days later John tries to find out who remembers what “business” said during their joint planning session. He can not find any.

I am sure that you already see a lot of pain points in the above story. I focus today on the concept of a product. It may be a root cause of this displayed lack of engagement, focus, and cohesion.

What is a product?

As the axis of our discussion here is Scrum, let's align on how a product is defined in the Scrum Guide:

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
~ the Scrum Guide 2020

So a product may be:

Physical, i.e.: smartphone, notebook, or a car;
A service, i.e.: VOD Streaming, catering, or e-commerce SaaS;
Something more abstract, i.e: Body cryonics, AI afterlife, or recently announced billboard streaming ads from space;

To be honest, this definition is both helpful and not helpful. It means that the product may be everything and anything. Mostly that will depend on the assessor’s point of view, which often leads to not optimal and expensive solutions. It is a hard art to define what is our product. Do we even have only one?

Why we even should bother by defining it? In my honest opinion, a clear definition of what our product is will help us to define a clear vision, strategy, and goals. However, defining it is tricky, as the product is an abstract thing. If we do not pay attention to that concept, we may harm everyone’s ability to focus and be effective.

Same thing, many points of views

Let's look at a car for example. For a customer, the whole car is a product with some variable options to choose from. However, for manufacturers, it is not so straightforward thing. Each major part can (and often is) a separate product:

main platform on which the car is built;
engines to fit in a car;
infotainment system;
cars’ operating software;
driver assistants systems;

Each of these components may have a B2B customer and can be sold as separate products. For example, Fiat and Mazda shared most of such components for 124 Spider and Miata. However, for the end-user, those cars were two separate products to choose from.

Above is ultimately a physical product, but what about software ones? Take a look at an e-commerce SaaS from the story. For a customer it may look like an all-in-one solution, but should it be treated as such by the producer? There are major parts also, for example:

Main shop platform with the ability to manage layout, display products, and place orders. Mostly content management system (CMS) with some simple forms.
Warehouse management system, to manage stock and sending/receiving orders.
Online payments system, to accept and process a variety of payments methods.
Advanced product configurators, to streamline order placement for configurable products.
Analytics tools, to check how our e-shop is performing and where can we improve.
AI-generated recommendations, to boost basket value.
Live-chat, to be in touch with customers that are online at our site.
Etc.

Those things also could be sold as separate products. However, often those products are bundled together. Another example may be office suite software. Which includes at least three components: word processor, spreadsheet, and presentation software.

Anyway, you get the idea. The same thing may be oversimplified as one product, or overcomplicated as a collection of a lot of sub-products.

So, what is a product?

For your customers, it always will be an oversimplified definition. For example “they have produced next smartphone”, or “they have created self landing rocket”. However, for a producer, it never should stop at such definition. It may be the end state for the world. While within the company, it helps outline the context or to share a vision — it is crucial to define “sub-products” boundaries.

You may ask “why it is crucial?”. Well, consider this. If we tell a house developer that the whole house is one product and she is accountable for developing each part of that house. Such as windows, or a heat pump. Will that help or hinder her ability to develop a house? Does she need to focus on the complexity of each part like mentioned above heat pump? Or will it be better that she is aware of such sub-product and what dependencies it creates? Knowing that accountability for developing it lies elsewhere. I would say that thinking about our product from that point of view, may help us to deal with overwhelming complexity. This strategy is also close to the “divide and conquer” approach that proves to be effective in dealing with complexity. An example of that approach in software may be the Quicksort algorithm.

So, a product is an abstract thing that for an outside world looks coherently. Having easily identifiable key features (or value propositions). However, from the inside, it should be clearly and easily divided into sub-products with known dependencies between each one. It should be easy to tell which sub-product does what. How they are glued together, and who is accountable for each sub-product.

Finding boundaries

The hardest part for a producer is to find those boundaries. If car manufacturers would oversimplify that each car is a separate product and did not reflect on that later. Today we could not have a platform-based approach for developing cars.

In Scrum, we recognize only one Product Owner for a product. Therefore if we define product boundaries too loosely, the Product Owner may be overwhelmed by too many areas to focus on. The Product Backlog will suffer and display no cohesion. Goals will be hard to craft for a lot of disjointed work, or if crafted those goals may be too vague to aid the team with the decision-making process.

So how can we find those boundaries? Well, mostly in an empirical way. If you use the Scrum Framework you are on the right track. In each Sprint, with each Sprint Planning, Sprint Review, and Sprint Retrospective you have an opportunity to reflect on that topic.

As a rule of thumb:

If you struggle to define one Sprint Goal for a Sprint Backlog. One Nexus Sprint Goal for a Nexus Sprint Backlog. One Product Goal for a Product Backlog. It may be a clue that you have hidden products to find.
Another clue may be a situation where you have in fact couple of teams in your scaling approach, but they rarely need to cross their paths. They mostly work in isolation. Maybe they are even not too interested in the results and outcomes of each other work.
If the Product Backlog is a mess of a lot of disjointed things, you may also have hidden products there.
Also as one product matures, it often gives birth to other products that may be not defined. Hence they live within the parent Product Backlog. So if your product is mature, and your Product Backlog is huge, there most likely are hidden products there.

Of course, those symptoms are not signs only for hidden products. There may be a lot of other reasons for such situations too. However, if you find such symptoms, it may be good to stop and rethink if it is not a time to redefine what is your product and how many do you have?

Common mistakes

Based on my experience, common mistakes are:

Fixation on the “one Product, one Product Owner, one Product Backlog” rule. Often people shortcut it to a situation where one Product Owner has only one Product Backlog. However, in reality, has more products under her oversight. There is nothing bad to have one Product Owner for multiple products. That situation may be harmful for other reasons. However, it is far better to be honest and maintain separate Product Backlogs for separate products. Even when you have only one Product Owner.
Pursuing a scaled Scrum as an answer for “how to run our business”. Often I talk with people who try scaling not because their product needs more than two teams to develop it. But because their company is big or is in a hiring frenzy, and therefore they “must” scale (product development).
Taking an arbitrary decision to pursue scaling. Without asking the teams that are currently involved about their opinion. Often not including them in the process until it is already too late in that party to easily change the course. Think here about sunk cost fallacy effect for example.

The art of simplicity

One of the principles crafted to complement the Agile manifesto focus on that topic a bit:

“Simplicity — the art of maximizing the amount of work not done — is essential.”

When we try to scale, in most cases, aren’t we pursuing the opposite — the art of maximizing the amount of work done?

As much as people solve problems, they also create them. Each new team in a scaling approach introduces new lines of communication, collaboration, and dependencies. Each context is different, but consider below pieces of information for inspiration:

React, a popular and widely used JS library is developed by a small team of 9 developers.
SpaceX had only 50 developers building their software for their 9 vehicles.
Tesla autopilot is developed by 300 developers (200 on the software side, 100 on the hardware side)
Comma.ai — an open-source autopilot solution that has only ~24 contributors on GitHub — However, it does not mean that there aren’t more people involved.
Excel — around 40 developers.

When do you need scaling?

In short, if you deal with an endeavor so complex that requires more knowledge than a group of 10 — 20 people can possess. Then you most likely need to figure out your unique way of scaling. However, the task is not about how to orchestrate a large group of people. Scaling should serve mainly three things:

An environment that helps a large group align around a common goal. If you can not craft such, scaling is most likely not the way to go.
Incorporate practices that help teams with identifying, limiting, eliminating, or effectively managing dependencies between them. While pursuing a common goal. If you rarely need to go hand in hand with other teams, scaling is most likely not the way to go.
Enables teams to effectively integrate their results of work. As often as possible, or it is necessary. If you can move forward without bothering about others to release your results and put them to use, scaling is most likely not the way to go.

The most crucial factor is the first one. If you don't have a common goal, then the other points highlight some sort of technical debt, rather than a need for scaling. In such a situation, you may be better off by finding the right borders and engineering practices that help you descale your situation and increase each team's autonomy.

Summary

I hope that you did not lose in the above flood of thoughts and navigated throughout them as well as the Sailors did. If you wonder how are they now, here is a summary:

The “Big Fictional Company” abandoned their one-size-fits-all scaled approach as means to run business. Today the Sailors don’t need to gather with others at the joint big planning sessions. After redrawing boundaries the closest metaphor would be that this group of people are a business cluster. A network of interconnected products. For example, the Sailors define their product as “AI-enhanced recommendation solutions”. John takes over the accountability of the Product Owner for it. Treating Adam, Greg, Caitlyn, and others as stakeholders. We may say that they are John’s product customers, but their customers are also indirect users of John’s solutions. Therefore he also treats them as stakeholders. Not to mention other developers that use John’s product via APIs. He strives to balance everyone's needs and maximize the possible value offered by “AI-enhanced recommendation solutions”.

However, that does not mean that in the “Big Fictional Company” we can not find scaled approaches. In fact, John’s product is developed by 3 Scrum Teams — the Sailors, the Wikings, and the Hokey-lovers. As they move forward, their framework of choice to address and minimize dependencies is Nexus. One of their Nexus Sprint Goals is to “Streamline machine learning process so that even Adam can teach the network something :)”. Around that Nexus Goal, each of the Scrum Teams can form their Sprint Goals:

The Sailors: “Enable non-tech users to teach and tweak network with an ease of a click”. We could say that their primary focus is directed into GUI for non-tech users
The Wikings: “Allow trusted apps to access and allocate ML AWS resources”. Here the Wikings try to focus mainly on effective and secure resources management allocated for ML.
The Hokey-lovers: “Ensure that users such as Adam will not harm themselves”. Our winter sports enthusiasts focus on how to help their customers remain confident about what they are doing. For example, when Adam will set sail to use this new feature, he could learn it by doing. Without a high risk of harming business or setting an unwanted fire.

If you are still with me, we could try to grasp one thought out of all the above, I propose to consider this one:

We too often shortcut our situation and treat scaling as an answer for how to run a business, rather than for how to develop products. Because of that, we end up with an overhead of synchronization and planning events. Which brings little to no value and increases our frustration. That results in a cargo cult. In contrast, if we find the right boundaries with proper balance. We could avoid that by simply treating our situation as a network of independent Scrums — aka micro-companies. That operates in a market regulated by a common entity — Our organization, that sets the basic rules.

Here is also a TLDR version: The first rule of scaling — Don’t! You most likely do not need that, and if you think you need it, it is probably a bad solution to your problems, think again.