At the Influential Agile Leader workshop earlier this year, I led a session about scaling and how you might think about it. I introduced the topic and explained that “scaling” might not be the answer. My experience is that when people use frameworks for larger efforts, they experience these unexpected side effects:
- The framework actions often require more manager-type people to control the actions of others.
- The framework creates less throughput, not more.
One of the participants asked, “But what if we have to scale?”
“Have to?” I asked.
“Our managers think that’s the only way to get out of our current problems.”
Okay. Notice that management defined this one solution to the problem as opposed to considering the entire system. Or, management didn’t consider how they got there.
I asked the participant if the managers had used a retrospective or did any investigation into root causes before they decided on scaling.
He said he wasn’t sure, but he suspected they had not.
I asked if any of the teams succeeded at using an agile approach at the team level. No, none of them had.
My First Scaling Experience
My very first job out of school was a development role on a very large telecommunications system for the Department of Defense. We implemented wireless, broadcast, the equivalent of webinars, all kinds of stuff. Back in 1977.
When I started on the program, we had a couple hundred people on the program. We were only 10-12 person-years behind. At one point, about a month or two into the job, I asked my boss, “Why don’t we hire those people now, and when they’re useful, they can ‘make up’ the time?”
He sighed. “We tried that. That’s why all you new grads are here.”
Six months later, I suggested, “Let’s get 150 people off this program. All I do is undo the work they did because they’re wrong. They don’t have the information they needed when they need it. I would be much faster if I could choose this team (and I named about a dozen people), and we worked alone.”
My boss leaned back in his chair. “What would the other people do?”
“It doesn’t matter. Pay them to not come to work. We would be faster.”
My boss didn’t like that. Even when I showed him some delays, he didn’t like it.
I didn’t have the words for the ideas of Cost of Delay, nor of flow efficiency. I didn’t know how to map our cycle time. I knew that if we didn’t have to hand off, we would be faster.
Even back in 1977, we worked by feature set. Yes, in vertical slices. We integrated as we proceeded. We made progress. And, at the end of the 18 months I was there, we were now 30 person-months behind.
We had the handoff and cycle time delays with scaling. Granted, we used paper back then to manage our requirements, but we still couldn’t keep the information current.
Problems I See Now with Scaling
Often, management decides they need scaling because they want “more with less.” As in less time.
Or, management delayed the start of this project so they want to “make up time.”
There’s an easy way to manage those problems without using scaling: use a small team or two to work off a ranked backlog. Make sure you think about the backlog in “how little” terms, rather than how much.
“Too much time” is often a result of management dithering. Or of not seeing delays.
Then there are the actual large effort problems. We probably could not have developed that telecommunications system with 12 people. Not back then. Maybe not even now. Twelve people didn’t have enough domain expertise. However, we probably could have limited the number of people to between 50-60 and we would have finished faster.
However, I’ve worked on large programs, where the teams were small and we had few controlling people and few control points.
Here are problems I’ve seen with scaling as an answer, agile approach or otherwise:
People on the program can organize themselves under these conditions:
- The teams understand the domain.
- The teams understand the customers’ problems.
- They can deploy/release by themselves.
- They (or someone who understand the customer needs) rank the work.
These teams can use a small-world network approach to managing and delivering the work. (I explained how in Agile and Lean Program Management.)
I suggested these ideas to this colleague. He said, “Management will never go for that. They still want to control things.”
Agile Scaling is the Answer to Whose Problems?
When I hear about scaling frameworks, I wonder who the customers are. I’m pretty sure the frameworks are the answer to managers who want the results of an agile approach. However, these managers often don’t want to change themselves and change the culture for an agile approach.
More controllers and more control points do not create an agile culture. Or, often, the product results the management wants.
When I hear, “We have to scale,” I wonder who the “we” really is. I wonder what they want from scaling.
Agile “scaling” is rarely the answer to the organization’s problems. More often, it’s descaling. Helping managers visualize the cycle time might be a first step.
I wrote a series about agile scaling a while ago. You might want to read it.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: When is “Agile Scaling” the Answer? Opinions expressed by Java Code Geeks contributors are their own. |
