Monday, July 06, 2009

Agile Exposes Scaling Problems

One of the first questions that seems to come up in any discussion of Agile is "How Well Does Agile Scale?" Sometimes this is asked explicitly, but more often there is an underlying assumption that Agile does not or can not scale very well. When I was first exposed to Agile, my first impression was that Agile didn’t scale beyond a small team, say 1-12 people.

I used to try to tackle the question head on, but then I realized that there's something else going on here. Let’s take a step back. What do we currently assume about traditional development? I think we come to the discussion thinking that just because there are teams of 100 engineers, 500 engineers, and even 2,000 engineers doing traditional development, that traditional development is a proven quantity when it comes to scaling. Let’s first ask the question: “How well does traditional development scale?”

To answer that question we first have to define "scaling." I think a good working definition is that as you add new resources, there is a linear increase in effective output with little or no decrease in efficiency. For software, output and efficiency translate to new functionality and productivity. That would mean that if you have a 50 person engineering team and you add 50 more people you get twice the output. But when was the last time you saw that? Have you ever seen it? In my experience, after talking to hundreds of development organizations doing traditional development, productivity falls and thus output does not increase linearly with additional resources. In many cases, output actually decreases as more resources are added.

What do you actually do to "scale" your development organization? Do you have meticulously updated Gannt charts and estimates? Do you schedule lots of meetings? Do you spend a lot of time making sure that requirements and designs are just right? Do you reserve 30% of the development schedule for testing (and fixing)?

In my experience, after talking to hundreds of development organizations, the answer to the question “How well does traditional development scale” is “not very well.” We've just suffered along with this problem, in large part because while the pain was there, the root causes were difficult to trace, let alone address.

The main point here is that if you are in the process of rolling out Agile to a large organization, don't be discouraged when you run into scaling problems. The problems were always there, they just weren't as obvious. Now, instead of wondering why things aren't coming together as expected at the end of the project, you may find out right away that your organization doesn't really have a good way to coordinate API changes for APIs that are used by multiple teams. As Agile exposes problems like this, you can take steps to solve the problems and thus create a more scaleable development organization that just happens to be doing Agile development.


Ron said...

Excellent thoughts on scaling. My experience is similar to yours. As projects grow larger and larger, productivity decreases. Communication becomes more difficult. Issues, particularly broken builds or critical defects stop a larger number of developers from working and many of these resources can't resolve this problem because they don't know what is going on. Many of the agile practices specifically address issues related to scaling. However, my experience is that when projects exceed a certain size, they are difficult to manage regardless of methodology.

Damon Poole said...

Hi Ron,

Thanks for your comments. Thanks for brining up the "difficult to manage regardless of methodology." I agree. What I like about Agile in this case is that finally we get a chance to learn how to scale better. We have more opportunity to see on a regular basis where the problems are and to look for and try solutions. As more people do this, patterns will emerge and become mainstream. For instance, continuous integration has emerged as a hotbed of new ideas and new solutions.

Rolf said...

Thanks for anexcellent post, Damon.
For me, the faster, more frequent cycles is a major contribution of agile: problems surface more quickly.
So agile seems to be a less risky strategy towards complex problems (scale adds to complexity).
My favourite quote on scalability: 'Engineering is the art of scale.' (Chris Britton)
More on engineering, agile and excellence at
Follow me on Twitter @rolfgoetz

Vanchi said...

Very Nice article.
I'm a pretty new to Agile. We follow Scrum at my workplace. I would like to know what would make me a good agile manager. Suggest me any resources that would make me to utilize agile to the max

Damon Poole said...


Take a look at this post on management in an Agile team:

Agile and management

Ryan said...

Good tact to objection handling around scaling agile. The consultative approach works best and many times I find out that what they are really asking is:
"What does large scale agile look like and what does that mean to me?" (See the comment from Vanchi.)

To answer that question 1:1 is much easier than a large group:) So back full circle to your question, "what works and what does not work about large scale development at your organization?" If they are motivated "away" from things I talk about the fixes agile makes; If they are motivated "toward" things, I talk about the results and opportunities created by large scale, self-managing teams doing agile.

Have you found yourself in these discussions?


KissTheGoat said...

> "Agile Exposes Scaling Problems"

What, no-one's mentioned that this is a commonplace of software development, known at least since "The Mythical Man Month"?

Did you Agilists think a new methodology would give you a total clean slate?

Damon Poole said...

Dear KTG,

There is no getting around "The Mythical Man Month," I agree. The main point I was addressing was that you have more of an opportunity for finding and fixing scaling problems unrelated to TMMM with Agile than with traditional development.