Five years ago, when I visited Zappos, CEO Tony Hseih pointed out that as organizations grow they become less effective. Each person you add increases productivity by a little less than the previous employee. Eventually, a large organization takes man-years to do what a small one could do in man-weeks. We understand this intuitively. Hseih claimed this was universal to nearly all business – yet it didn’t have to be. He used the example of cities, where more people condensed in a small area actual improves quality of life by creating new small businesses, cultural and social events, things to do and so on. Living with enough people in a small enough area and you will have access to an incredible variety of resources, products and services. Hseih wanted to bring that idea to business. The idea was so radical that employees had to sign a non-disclosure agreement.
In a way, anyone can scale a project, throwing hundreds or thousands of people at it. The challenge of scaling is to do so without massive dilution; without running a project with 1,000 people in two years that could have been done by a hundred people in half the time.
The argument is that agile doesn't scale, that the initial agile methods – Scrum, XP, Crystal and DSDM – don’t work for large groups. It might be more accurate to say that, at the time, we didn’t know how to manage large groups. The creators of the Agile Manifesto gave up, choosing to define a set of methods that could make a small team very productive. After all, as Hseih put so well, large teams are not productive.
You could argue that the creators of the agile methods chose to punt.
"If your find yourself in a hole, your process model isn't going to pick up the shovel."
Ken Schwaber, one of the creators of Scrum, once told me that we never knew how to scale software development in the first place. My own experience is that inside of every huge project with hundreds of people were a dozen or so sound craftspeople, who knew each other by name, who were doing the hard work of delivering the software. Outside those dozen were another dozen who were at least helpful – without them, things would take longer. Outside that group were the ones who at least didn't slow things down any, and provided a layer of protection from management so we could work. Beyond that layer were the people who did one of those two things, then the layer that did neither. Schwaber told me that in the ‘80s and ‘90s, when the crisis hit, the modest teams of heroes would come out and get the project done.
Sign up for CIO Asia eNewsletters.