Some while back I read a blog entry from Jason Gorman on Wheel-driven reinvention. His core statement is, that there is nothing new in the world of software development. When you start to trace back any common hype in the software industry, you will most likely end up in the 1960s or 1970s finding the core idea raised by that time. When I first read his blog entry, I was going to write a follow-up describing how little the great old ones help us understand their solutions to the problems of the software industry in the last decades or so. Since I know that I had to incorporate Gorman’s thoughts into my models I decided to postpone it a bit, and get some time to think over it.
There are just a few professionals who actually did what I was claiming, but the more striking point for me is how little time we spent listening to them. One excellent example of a great old one is Gerald M. Weinberg, who worked on project Mercury for the NASA, and was part of the first testing teams when the latest hype was to do testing independently back in the 1970s. Recently I came across a paper from Edsger Dijkstra, written by hand. Into that line fits also Brook’s Mythical Man-month or the No Silver Bullet article. And I know that there are other great examples of great old ones, to which we should pay attention, in order to learn something new.
That said, I read a blog entry from James Shore yesterday on Large-scale Agile. He put up a great effort to describe how to combine the ideas from Scrum and the ideas from Kanban together to scale Agile up on a larger basis with sub-dividing teams. His ideas are interesting, and I gave up half-way through trying to understand all of his premises. Remembering back my math teacher in school when I showed him a proof that one equals two, he stated: “When working from a false premise, you can show anything.” This is even true in writing.
How come there is nothing new about large-scale Agile? The textbooks on Scrum just mention the Scrum of Scrums, but not how to apply them. XP and Kanban just work on smaller teams, so he’s actually writing something new. Really? No. Obviously not. the Crystal methodologies, and recommendations for large-scale Agile. Thought, he stated that there is a barrier to Agile and their light-weight methodologies at project size of about 500 persons. Scaling Agile up, though comes with a prize. Larger teams need other communication channels for example. You may put a team of 12 into a single room. The team can work up with osmotic communication. On a 500 person project, you may have difficulty to find a room large enough, and obviously not everyone will be able to overhear the conversations of all colleagues. There are other penalties you have to pay for scaling Agile up. Whole-heartedly I recommend reading his book on Agile Software development.
Additionally, what I learned from Cockburn is the notion of a sweet-spot of Agile methodologies. The lightweight nature of Agile methodologies has a sweet-spot on a lower team-size with fewer effort put into ceremony overhead for hand-offs. When increasing the team size, you automatically get a larger communication-need. There are non-linear increases in the amount of possible communication channels among team members, as well as slower communication channels like informations flowing across different rooms. That said, if you don’t fulfill the need for more communication, you may find yourself set up for Agile failure.
There are many other factors which need to be increased for the larger team-size in a non-linear way. In case you’re searching for an answer on these questions, I recommend to read all of the following book
- The Mythical Man-month from Frederick P. Brooks Jr.
- Quality Software Management Volume 1 – Systems Thinking from Gerald M. Weinberg
- Agile Software Development – The Cooperative Game (2nd edition) from Alistair Cockburn
Listen to the old ones, or re-invent the wheel.
