The most important question about Agile Scaling

We hear from almost every major company we work with: “We need an agile scaling framework.” When 50 or more developers need to collaborate, using a scaling framework is actually beneficial. But one question remains unanswered. An unspoken, unchallenged assumption hovers like a spectre over any scaling approach. But before we ask this question, let’s take a look at the reasons why this question needs to be answered.

Develop a complex product

Complex systems are complex – if only by definition. A common assumption is that Divide+Conquer (D+C) is a good approach to solve complex problems: We divide a big problem into many small ones, distribute them and reassemble the solutions. This also sounds promising.

A scaling framework can then be used to maximize the effectiveness of D+C.

Let us start with the peripheral questions in order to get closer to the core question:

How to define the problem?

When you start developing a big product, you first have a need – and you want to build a product that satisfies that need. The nature of product development is that the need-based solution does not yet exist.

Is the problem even described correctly? Is it already sufficiently clear where the effort goes into? Is the domain of the challenge already so clear that D+C can be applied sensibly?

What is the real problem?

When you organize product development, you simply assume that the need is clearly defined and the rest is “just work”.

But what happens if even the question on the basis of which planning was made was already wrong? What happens if the plan fails and you pursue the wrong answer? Does it help if more people work on the wrong things?

Where is the real problem?

The basic assumption of agile scaling: “The main problem is more work than few people can do. As also described in another article, the main problem with a lot of work is that a lot of work causes a lot of work! This is about non-value-adding work like coordination, task switching, meetings and the like.

Have you ever thought about how big the share of value-adding work on the product is compared to the share of non-value-adding work on processes in your organization? How much time do your developers need for coordination due to the complexity of your structures? Is your focus on delivering products or following processes? What happens to the overhead when you extend your processes? What happens to value-added development time?

Is the problem really that big?

With agile scaling, you simply assume that you need many people to build the product you are planning. The next question is then how to organize these people in the best way.

Did you know that Google was developed by two people in its early years? And Facebook by one?

Is your product really so big that it outshines Google and Facebook? Are you really going to make billions? Is your understanding and approach really optimal?

Does much really help much?

The book “The mythical man-month”, written about 40 years ago by Frederick P- Brooks, has long since refuted the idea that “the more people work on a product, the faster it is finished”. But even today, many companies still believe that “Agile Scaling” is the solution of the “mythical man-month”. As mentioned before, great products were developed by just a few people – and more people create more work, but not more value!

Couldn’t you find a better solution with fewer developers with less work? Would it really be slower if fewer people were involved?

After so many questions we come to the critical core question:

Is “agile scaling” really necessary?

Consider the following points:

• Do the developers have 100% best knowledge to provide a solution?

• Do they have the 100% best possible technology to solve problems?

• Are the developers 100% focused on delivering the maximum value?

• Is every activity 100% value adding?

• Is the work done 100% effective?

If more people are added, these percentages tend not to go up. They decrease.

When these percentages are added up, the results are often frightening. Maybe you have ten people who can only use 20% of their potential – so that three people who can use 80% of their potential would progress faster!
If 100 developers are limited to 5% of their potential, perhaps a single team would be more effective than all of them!

Have you explored all the possibilities to do more with less?

Only if all these questions have already been answered with “Yes” – then the answer to the core question is also “Yes”. Before that, you will scale your problems – and not your problem solution!