Scaling Agile

2 minute read

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 theoretical. Later I read “Producing Open Source Software” from Karl Fogel. At first it did not seem to have any link with scaling agile, but successful open source projects have to handle distributed development and high turnover, so I thought that maybe large agile organizations have something to learn from open source development mechanics. Why wouldn’t these technics that are successful at sharing code between companies be used internally 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 prioritizing 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 canonical 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 development best practices could be used.

Edit: Github builds Github with something a lot like this !

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment