Nine women cannot give birth to a baby in one month. – Folk wisdom

Why to Scale Product Teams

Scaling teams often pop up in executive’s plans when they have new opportunities to generate income, make significant investments into upgrading existing IT platforms, deliver a new product on the market faster than competitors.

Ken Schwaber's Prophecy, or Why Most Companies Fail Scaling Product Development Teams 1

But scaling teams is not the same thing as scaling their delivery process. Hiring new people is more straightforward than scaling a methodology, practices, and technologies. Unfortunately, the development cost doesn’t scale linearly with the number of people on the team – doubling human resources would increase overall performance by 50% after several months in the best case. Many factors come into place when the team starts to grow, just a few of them to mention:

Knowledge transfer time can vary from weeks to months, depending on the technical complexity.
Splitting product requirements into independent tasks is much easier for a team of ten engineers than twenty and more specialists.
80% of product requirements can depend on very complex technical tasks, which will create multiple bottlenecks

Ignoring those factors is very expensive, but nonetheless, we continue to evade them. Guided by the preliminary analysis and expert opinions, sweet promises of vendors, the managers conclude that the project requires, relatively speaking, 100 specialists for six months. Frameworks such as Scrum or SAFe create some pressure on IT because business people want to see a product increment every two weeks. After a month of work, if managers don’t see the expected velocity out of 10 teams of 10 people, they start to put even more pressure.

Modern agile frameworks have multiple solutions to the typical scaling challenges, but we cannot entirely rely on them. And none of them will guarantee to fix unsatisfactory progress and align it with original estimates.

Case From Aerospace Industry

Ken Schwaber's Prophecy, or Why Most Companies Fail Scaling Product Development Teams 2

In 2012, I was invited as an Agile Coach to the top software development provider in Eastern Europe, recently committed to delivering an enormous project for a client from the aerospace industry.

The project was gaining momentum. A considerable Product Backlog was formed and estimated (over 1000 user stories!). Preliminary analysis was done, product requirements were written, enough data was collected to estimate the average velocity required to deliver fixed scope by fixed date. For software development vendors, success in such a project means opening the door to many more excellent opportunities.

It was evident that the small scrum team could not cope with a massive and complex project. To determine the budget, we decided to forecast the average velocity required to demonstrate monthly progress, resources needed for one team to be fully cross-functional, and the number of development teams to achieve a monthly burn-down rate. This logic was clear to both parties. The contract was signed. Pretty soon, we started hiring a whole crowd of specialists. 20 people were added every month! Target – 12 teams.

From a rational standpoint, I understood the managers’ logic, but the Agile Coach’s intuition sent me an alarm. I was in Salt Lake City for a conference where I had the honor to meet Ken Schwaber, one of the fathers of Scrum. I confessed to Ken that I was worried about running many scrum teams at the same time. He listened carefully to my case, after which he gave an unpopular answer: “Go to top managers immediately and tell them not to go this way! You’re going to fail, and that’s why….”

Ken’s Advices

Ken continued: “The essence of a complex domain is to manage uncertainty with frequent releases to prove that we have the right people, technology, processes, and tools. It’s not about the team that develops functionality later to demonstrate it to the Product Owner. The difficulty of large-scale development lies in integration. It is a tough task to combine the work of many teams into a single integrated increment!“

– Have you already released anything with your first couple of teams? – asked Ken

– No. So far, we are focusing on the development itself. Delivery to customers was not done yet.

– When do you plan?

– Every quarter.

– Make the first delivery first. Until then, just stop hiring the crowd.

Then Ken issued a sinister prophecy: “You will see. A month will pass. The customer will come to you and say: I don’t want anything anymore. Do something that our users can enjoy.” Ken advised forming one scrum team that integrates all the developments to make the first release. If this can be done, the team capacity can be gradually increased.

I returned to Kyiv and immediately passed Schwaber’s message to my bosses, to which I heard the following answer: “Slava, bite your tongue! Do your job quietly. Millions of dollars in our pocket.” The managers were really optimistic. Then we agreed: if we manage to deliver the project as we promised, we will write the book “Schwaber’s False Prophecy”. We soon realized that we would have to write another book, “Ken was true”. The customer came to us, and word for word passed a message fulfilling Ken’s prophecy.

Reputational Damage

We have just finished hiring the last team as we promised to our customer. However, they all were put on pause for a few months until the core team of best engineers completes the integration of around thirty different increments. The customer went nuts, terminated the project, and finally, more than a hundred specialists remained on the bench. The project was closed as a failure. The company received a negative rating. Several million dollars landed into the vendor’s account, but the vendor struggled to get more projects from the customers in same industry. Suffered irreparable reputational damage in the long run.

Similar cases

Interestingly, there are many such cases even until these days. Almost ten years have passed. One company has money but scarce of specialists to complete the work on the complex product until promised date. So, the managers decided to hire additional teams provided by the outsourcing vendor.

Once again in my life, I had to repeat Schwaber’s dark prophecy: “I assure you, colleagues, 99% the plan will fail. You will lose time and money.” Managers were surprised: “How do you know that? Do you know anything about that outsourcing company?”

I just didn’t hear that after adding several external teams, even halfway through the project, something good came out in a short time. The prophecy was fulfilled again as the launch of the product’s first release was postponed for 6 months!

Why does top management not listen to the opinion of professionals? Why do managers confidently make decisions that require professional knowledge, keep listening to the experts whose job is to promise golden mountains?

Reliable Path of Scaling

Ken Schwaber's Prophecy, or Why Most Companies Fail Scaling Product Development Teams 3

During the financial crisis of 2008, many banks collapsed. One reason is the lack of regular liquidity stress testing of most of them. The largest investment bank, one of the ten most powerful in the world, asked us to develop an automated liquidity stress testing system.

Our recommendation surprised the managers: “Find the best 10 people, no more. Give them a few months to focus on each iteration, each sprint, to create an integrated product. This will allow us to see how the team works, with all the challenges they will face to make the first release. After that, we can continue our conversation about scaling product development”. Managers had the opposite plan – to launch many teams at once! We firmly replied that we would not commit to their project due to the high risk of failure in this case.

Our opinion was heard. When it became clear that the team’s velocity was twice as low as the managers expected, we felt cold outside the skin. Not surprisingly, some executives were furious and pressured to double the pace. Realistically assessing the situation, we negotiated to do in six months only the most valuable and most necessary while slowly adding more developers to make sure that new people don’t distract the primary team too much.

We have established a clear product goal, removed management pressure, and delivered a new stress testing system that satisfied regulatory requirements. It did not have all the little things and whims, but it was surprisingly high quality, user-friendly and reliable.

Managers praised this new approach and discovered that this was the first case of completing a project “without a headache” in the context of the bank.

Mistakes of Businessmen in Scaling Product Development

Ken Schwaber's Prophecy, or Why Most Companies Fail Scaling Product Development Teams 4

With all the challenges explained, I want to highlight a few common mistakes that should be noted by each manager:

“A Jack of all trades” – the illusion of knowing everything.
Misunderstanding of the complexity in scaling product teams.
Not involving developers to decide how to increase development pace.
Rapid recruiting intellectual professionals.
Ignoring team dynamics and its impact on the performance: Forming → Storming → Norming → Performing.

Recommendations

For successful scaling, you should give more space to one team (no more than 8 developers, one scrum master, and one product owner) to focus on quality Sprints, creating a valuable increment, and doing regular releases.
It is worth talking about successful scaling, having at least one successful scrum team.

The same goes for investment strategies. An effective Scrum team creates the opportunity to naturally and gradually increase capacity in parallel with the same natural and gradual scaling.

The team itself must decide how often, how many and which new people need to be added. For example, one person a month, when a certain number of people on the team is reached, form another team, etc.

Gradual natural development helps eliminate the “dependencies” of teams from each other in a timely and painless manner and quickly achieve the necessary integration in creating a valuable increment. We call this natural scaling.

Scrum Basic Principles in Scaling

According to the Scrum Guide 2020, regardless of the number of teams, in Scrum per product can be only:

One Product Backlog.
One Product Owner.
One Product Goal.
A single ecosystem for all teams
Integrated product increment.

This, in fact, was Ken Schwaber’s advice.

Conclusions

Managers should keep in mind that nine women will not give birth to a baby in one month.
When it comes to big money, big projects, big teams, managers tend to rely on their own competence and not hear the voice of Agile Coaches and software development professionals, which is why they step on the same rake and lose.
Leaders should not attribute to themselves a competence that they do not really have.
Managers desperately need to consult with professionals with professional knowledge.
Managers need to understand the strategy of natural scaling (starting with one scrum team of 5-10 people).
We do not recommend starting the project by running many scrum teams at the same time (except for transformation of the ongoing IT programs using the SAFe approach with Release Trains).
When implementing Scrum in a big project, it is first necessary to create the right environment for the first team to succeed.
Managers should remove bureaucratic and other barriers to the functioning of the scrum team if they seek a true digital transformation of the company and a leading position in the market.

Author: Slava Moskalenko