Yesterday on Twitter, I said:
The only way to “scale” a people-based system is to figure out which people you care least about.
I figure I ought to say some more about that.
My part of the company I work for is currently in the early stages of implementing a variation of the Scaled Agile Framework. Given that, and the fact that I have read Dean Leffingwell's book and have been sort of following the development of the framework for the last year or so, I have been somewhat amused by the online kerfuffle following SAF's (sorry, but the extraneous "e" on the official acronym is ridiculous) big debut at the Agile 2013 conference.
Most of the push-back against SAF seems to be coming from adherents of the various other methodologies–Agile, Scrum, XP, Lean, and the like–and takes the form of "Who do these guys think they are? My methodology already solves this problem!"
I know a little bit about software development and the management thereof. I know a little bit more about the management of people, and the design and building of systems infrastructure. There are similarities between these various areas of practice, and lessons learned in one can certainly be applied to the others. Unfortunately, the lesson most people seem to come away with is that because we have (mostly) learned how to scale infrastructure systems, we can scale people systems in the same way.
Let's think about that a bit, though.
The way you really scale an infrastructure system is by decoupling its component parts. Assume that at any point, any piece of the system could (and probably will) fail, and design each part so that it can still function in some way even if other pieces of this system fail. You design the individual pieces to be throw-away, easy to replace. When parts of the system fail, you don't bother trying to fix them–you throw them away and recreate them from a known-good source.
That works pretty well when we are talking about machines, and I suppose it can work well enough with people, too, as long as you don't care about the costs to any particular individual in the system. Grow the system beyond the point where people within it have the time and space to talk to and understand one another, and you are left with "metrics" to tell you how things are going. If people aren't generating the numbers you want to see, you can no longer go talk to them about it and figure out what might be going on.
In business, we get performance evaluations based on arbitrary target numbers, and we make sure to hire mainly temps and contract workers who can be easily gotten rid of and replaced. In education, we make all the students take standardized tests, we ignore all the non-quantitative impacts of this policy, and we get rid of teachers and schools that don't pass the tests.
And whither software development? The hope with this Scaled Agile Framework stuff seems to be that we can take the tools and processes that work well with a small team of developers/testers and a single product owner, plug them into a huge systems with hundreds of other people, and get roughly the same results. If the stuff they're building is largely de-coupled, then… maybe.
However, the reason those small teams work well is not the tools and processes they use, but rather the fact that they are small. "Scale" that stuff up, and you'll have the same problems you always do with large systems.