The biggest question when Scaling Agile

Pretty much every large company states, "We need an agile scaling framework". 
I do agree that when 50+ developers need to collaborate, then a scaling framework provides massive benefits. There is one question left unanswered. One unspoken, unchallenged assumption looms like a specter over every scaling approach. Before asking this question, I will list out the reasons why it needs to be answered.

Are you asking the right question?

Creating complex products

A complex system has, by definition, a fairly high complexity. A common assumption is that Divide+Conquer (D+C) is a good way to approach complex problems: Split one big problem into many smaller problems, distribute these and bring the solution back together. Sounds promising. 

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

Question 1: How do you define the problem?

When you're starting the development of a large product, you typically have a need - and want some product to meet that need. Due to the very nature of product development, the solution doesn't exist yet. Have you thought about these:

Is your problem even properly defined yet? Is it sufficiently clear where the efforts will really be? Do you know enough about the challenge domain to divide and conquer it?

Question 2: What is really the problem?

When you're setting up a product development organization, you simply assume that the need is clearly defined, and then it's "just work". 

What happens if even the question wasn't the one you should have asked during planning? What happens when the plan turns sour and you're giving the wrong answer to the right question? Does it help you when more people work on the wrong things? 

Question 3: Where is the problem really?

In scaling agile development, you assume that the main problem is that "there is too much work to do"for a limited amount of people. As I wrote elsewhere, the problem with lots of work is that it causes lots of work. And with that, I mean non-value added work like coordination, task switching, meetings etc. 

Have you considered the proportion of value-added work focused on the product versus the amount of non-value added work focused on your own process? Are you aware how much time your developers coordinate thanks to your organizational structure? Is your organization product-focused or process-focused? What happens to coordination overhead when you add complexity to your processes? What happens to development time?

Question 4: Is the problem really that big?

You simply assume that you need a lot of people to create the product you need, then you wonder what is the best way to organize these people. Have you considered that Google was basically developed by two people in the first few years? And Facebook by one?

Is your product really so great that it blows Google and Facebook out of proportion? Why aren't you making trillions yet? Are your understanding and approach optimal?

Question 5: Does much really help much?

The book "The mythical man-month", written a good 40 years ago by Frederick P- Brooks, has long since discredited the idea that "throwing additional people at a product speeds up delivery proportionally". To this day, corporations consider "scaling development" a solution to "The mythical man-month". As mentioned before, great products were built by a handful of people - and more people just add work without value.

Could fewer people doing less work deliver a better solution? Would it really be slower if fewer people participated?

After asking so many questions around the key issue, here is the real question:

Do you really need "scaling up"?

• Do developers have the 100% best possible knowledge to find a solution? 
• Are they using the 100% best possible technology to solve the problem? 
• Is everyone 100% focused on doing the most valuable thing? 
• Is every work item done 100% value-added?
• Is the work done 100% effective?

Remember, when adding additional people, the percentage does not go up. It typically goes down.

If you multiply the real percentages you have, they are often abysmally low. Maybe 10 people work at 20% potential - so 3 people working at 80% potential might make more progress than these!

If you have 100 people working at 5% potential, then a single team might be more effective than they!

Have you exhausted all possible means to do the same thing with fewer people?

Only if the answer to all the questions in this section is "Yes" - then the answer to "The Big Question" is "Yes". Before that: You will be scaling up your organizational problems - not your problem solving.