Scaling scrum is all the rage. People love to debate the merits of the various scaling frameworks: LeSS, SAFe, Nexus, Scrum@Scale, Disciplined Agile, FAST Agile, Spotify’s approach, and others. The underlying assumption is that the way to scale up value production is by increasing the number of people and teams. More people and teams can get more done, right? Perhaps, but there are significant costs to scaling up headcount, and alternative ways to scale up value production.
Org charts by Manu Cornet
More Developers, Exponentially More Management Overhead
Imagine the simplest organization, one person. That person has a need, perhaps they want a bit of software to help them organize their music collection. Luckily, they know how to code. They write a bit of code to catalog their music collection, allowing them to quickly find any album or song that they want to hear. They are the customer, and the developer. If we define ‘management overhead’ as work needed to coordinate and align the people building the solution with each other and the customers, then the management overhead in this scenario is zero.
What happens as we add people to the team? As soon as there is more than one person, there are connections between people that need to be tended. The people need to communicate and coordinate with each other in order to solve a problem together. It’s not so bad with two people. There is only one connection. Still, some time and energy will go into managing this connection.
With ten people, the number of connections is up to 45. Managing those connections is a lot of overhead! It gets even worse as the organization continues to grow.
| People | Connections |
|---|---|
| 1 | 0 |
| 2 | 1 |
| 10 | 45 |
| 100 | 4,950 |
| 1,000 | 499,500 |
| 10,000 | 49,995,000 |
No wonder big companies seem to have more managers than developers!
Note: I’m using the word developer in the way the Scrum Guide does. Developers are the people who do the design, building, testing, and other work of creating the product.
And So We Create Hierarchies
One way to try to wrangle the communication overhead is to create hierarchies and silos so that the developers don’t have to directly communicate with so many people. Alas, this means information has to pass through chains of people. Suddenly, we are playing the telephone game. Take a moment and watch how this works.
According to a study mentioned in this sales training video, the fifth person in the chain is likely to get only 20% of the original information.
Organizational Politics
In The 4 Types of Organizational Politics, Michael Jarrett defines organizational politics as “activities associated with the use of influence tactics to improve personal or organizational interests.” Each person is pursuing their own agenda. Some are well aligned with the company’s goals and others are not. Some people just want to build empires inside the company. Power struggles are inevitable. Factions, alliances, and cliques form. Rumors circulate. It’s all very interesting, but not very productive. Adding more people will tend to lead to more organizational politics.
In their book “Scaling Lean & Agile Development: Thinking Tools For Large-Scale Scrum,” Craig Larman and Bas Vodde start off with this advice:
After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t do it.
There are better ways to build large systems than with many developers in many places. Rather, build a small group of great developers and other talents than can work together in teams, pay them well, and keep them together in one place with the product management or whoever acts as the voice of the customer.
Scale Skills
Grow the people you have by increasing their technical skills, business skills, interpersonal and communication skills. There’s lots of books, videos, and classes that can help with this. Llewellyn Falco and I both recommend scheduling time every week for the team to focus on learning and skill development.
Scale Collaboration
Scrum is a framework that is designed to foster better collaboration. Investing in your company’s scrum practices can yield tremendous improvements. I’ve had the privilege of witnessing this happen at many companies over the past decade.
Scale Engagement And Motivation
In 2018, Gallup excitedly announced that employee engagement was at an all-time high: 34%. That was the good news. The rest of the story is that most employees are not engaged and 13% were ‘actively disengaged.’ If you are a leader looking to scale up value production, there is gold to be mined through understanding what really motivates people.
Scale Tooling
Improving the tools that we use can dramatically increase productivity. I remember the gains in my own productivity as I learned to use a debugger, better editor, and source control. Things got even better when our regression tests moved from documents to code.
Scale Product Discovery
Product discovery is the iterative work learning what will make your product useful, usable, and valuable. Get better at this, and you won’t need to build so much. The 2019 Feature Adoption Report by Pendo determined that 80 percent of features in the average software product are rarely or never used. This means you could get a 5X improvement in productivity by simply not building those features!
Scale Value, Not Headcount
Ultimately, you don’t really want more people. You want to create more value. Perhaps you will need more people to do that. First, I encourage you to pursue the big gains available by investing in your people, your tools, and your practices. You are likely to find that you are able to scale up value production while avoiding the pitfalls that come with scaling up headcount.
Additional Resources
- Scaling Teams by Ron Lichty
- Videos: Spotify Engineering Culture Part 1 & Part 2