I have worked in small agile teams, and it does indeed work a lot better than the classical waterfall & hierarchic environment. When speaking with other people who have been through the same experience, we started to wonder how could this be scaled to a big organization ?
I read two good books on the subject from Craig Larman and Bas Vodde:
There made a lot of good points and techniques, but it still sounded a bit theorical. Later I read “Producing Open Source Software” from Karl Fogel. At first, it did not seem to have any link with scaling agile, but successfull open source projects have to handle distributed developpment and high turnover, so I thought that maybe large agile organizations have something to learn from open source developpment mechanics. Why wouldn’t these technics that are successful at sharing code between companies be used internaly to share code between teams ?
At the same time, at work, I learnt the hard way that I should avoid to work for a “library, framework, engine …” team. It’s both frustrating and unrewarding :
You never really understand what you are working for, what is the final goal
You are always doing a poor job at priorizing requests from different sponsors
You are doing too much on some areas, but too few on others
Agile & incremental development and architecture solves this the nice way, by extract framework and libraries from running software ! Successful open source projects often start like that (Rails being the cannonical example).
So why couldn’t we just let libraries and framework emerge the same way inside a company ? Why don’t we maintain these projects as we would maintain an open source project : as a side product of our main output ?
Craig Larman and Bas Vodde speak of feature teams, 20% free time, communities : all this fits nicely with this idea. Suppose we could have 20% of our time to work on what we like, any developper could take this time to extract a library from his team’s codebase and promote it as a company library, he could become dictator in chief as long as he wishes to. Other teams could reuse it and submit patches. All of the time proven open source developpment best practices could be used.
Edit: Github builds Github with something a lot like this !