Decompose products to avoid scaling teams

As a proponent of the lean approach to product development, I have lost count of the number of times I have been asked, “…. but, how do you scale this approach?”. Since completely unrelated people have asked me this question, I have to assume sincerity of the question. I am also beginning to wonder that the existing frameworks to scale (like SAFe or LeSS) haven ‘t worked. However, nothing suggests that scaling lean approach shouldn’t work. Toyota, one of the most quoted companies for lean production has over 300k employees and manufactures of 18 million units a year.

Where are we in the field of software product development getting it wrong? I want to address this without sounding like I had a moment of epiphany. I am going to avoid the issue instead of solving it. Like Kent Beck usually says, “if an idea is good and it turns out to be true someone smart would have done it. If the idea is stupid then you have a chance no one else is dumb enough to try it.” Many people much smarter than me have attempted to solve the scaling issue, so I am just going to eliminate the roots of the issue instead of solving it.

In a nutshell, I want to flush out decompose to avoid scaling instead of scaling for growth. The issue with scaling is it not only assumes the problem of organic growth but assumes the solution to reach there is by scaling team(s).

Let me start by putting forward a couple of questions.

• What does scaling mean?
• How is scaling solved in the traditional software development models? Is it solved at all?

These questions are important as they helped me identify that when people mean scaling, they mean one or more of the below items.

1. I need to develop this product faster.
2. I need to ensure the teams are aligned with the broad vision.
3. I need to ensure that there is coordination within the team and across teams

So, scaling is not an issue. The real issue is why, when and how.

My learning

I want to summarise my learning on this topic through the below points.

1. When in doubt about how to structure a team go back to the first principles on a product.
2. Do not fall in love with the tool
3. Identify if what you are doing should be part of your product or another one which is dependent on yours.
4. Assume you will not be in the product team for long. Make it easy for the other person who might pick it up from where you left.

First Principles

Definition of a product

Kotler, P., Armstrong, G., Brown, L., and Adam, S define a product as “A product is anything that can be offered to a market that might satisfy a want or need.”.  Mike Cohn defines a couple of key constructs of a product.¹

• Products provide benefits to a market
• • A product can exist within another product. A pen, for example, may have replaceable ink cartridges. The pen is a product. But so are the ink cartridges within the pen.
• Products can be defined recursively
• • When we identify subproducts within a larger product, we need to be careful that each subproduct provides benefits to a market.

Attributes of a product

Martin Fowler came to my rescue to give the fundamental principles in his ‘goto conference’ speech on Microservices.

The key attributes of a product are the same as the one Martin Fowler used to describe his microservice.

• Componentization: A component is a unit of software that is independently replaceable and upgradeable.
• Organised around business capability: The microservice approach to division is different, splitting up into services organized around business capability
• Products not projects: a team should own a product over its full lifetime. The product mentality ties in with the linkage to business capabilities. Rather than looking at the software as a set of functionality to be completed, there is an on-going relationship where the question is how can software assist its users to enhance the business capability.
• Decentralised governance: One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Experience shows that this approach is constricting – not every problem is a nail and not every solution a hammer.

So, after looking at the definition of a product and the characteristics of a microservice and with the approach of Lean Startup, I came up with the below understanding of a product.

The answer to ‘Why?’

The answer to why scaling became an issue is because the products were not decomposed properly. The above principles can be decomposed to the below snippet.

A solution can be classified as a product if

• It provides benefit to the market (Problem – Solution Fit)
• It is independently replaceable and upgradable

Even if

• It exists within another product
• If it is part of the same engagement/project

And should

• Be organised around business capability
• Provide decentralized governance

If the product is not decomposed, it will result in

• Loss of context
• Team feeling directionless
• Erosion of practices
• Releases feel bloated
• Tools become roadblocks
• Practices don’t feel like they can scale

The answer to when?

The next question to address is when to begin decomposing so that we avoid the issue of scaling. I want to use the nomenclature of Lean Startup to drive this point. The first point is when you reach the problem – solution fit.

Decision Point#1: Problem – Solution Fit

• Criteria

• • • How many problem – solution sets are there?
• • • Does solution can constitute a separate product?

• Next Steps

• • Prioritise one problem – solution fit
• • If both the problems have to be started and can be started, then start them as two different teams
• • If both the problems have to be started and cannot be started because of dependencies, then identify the right pre-conditions for starting the second product stream

Decision Point#2: After each round of research

• Criteria

• • • Have we validated a new problem altogether?
• • • Do we need to solve this problem now?

• Next Steps

• • Kickstart another stream of work
• • Highlight the reasons to start this as a separate stream

Decision Point#3: Product – Market Fit

• Criteria

• • • Have we validated the product – market fit through our MVP?
• • • Do we need to scale to more problems?

• Next Steps

• • Kickstart another stream of work
• • Run them as separate teams if possible

The answer to ‘How?’

The high-level approach to decomposing a product to form multiple sub-products involves three key components

1. Timeframe or Duration of the activity
2. Structure of the backlog
3. Structure of the team

Here is a simple flow which can be used to determine how to decompose a product.

The idea is to determine the answer to the key questions.

1. Do I create a product?
2. Do I spin off a separate team?
3. What should that team look like?
4. How much coordination is required?

When the product is decomposed this way, it results in multiple small teams. The teams should balance team autonomy and intrateam collaboration. The governance for this will be the minimum needed to keep the balance going.

References

1 https://www.mountaingoatsoftware.com/blog/what-is-a-product