I have, for many years, been working in software development and for about 6 years with Agile Software Development adoption. First as a project manager and later driving the adoption of Agile in the organizations where I’ve worked.
One clear characteristic has become clear to me over time. You may not hear about it much today, but some years ago the biggest fault people would point to Agile methods was that they did not scale! (despite some work by Alistair Cockburn to prove them wrong).
Today, it is quite clear that Agile does scale, and scales to very large organization like the one where I’m working right now. This organization is adopting Agile at a scale that is probably unprecedented, a colossal scale.
So, the cat is out of the bag. Agile does scale! But during my years in this industry I’ve started to note another trend: Waterfall-like processes do not scale. Many of the problems that we are now solving with Agile are problems that were originally caused by the ideas developed for larger projects using the waterfall model of software development (I include the V-model in this group).
Take an example: Requirements Engineering. In the waterfall-like models the requirements were collected upfront with considerable efforts to try and be as exhaustive as possible (everybody remembers Boehm’s cost model for late-found requirements). This approach basically created a huge inventory of requirements (overproduction anyone?) that would then require large groups of people to manage (in large organization, remember this post is about scaling).
These large groups of requirements would not deliver any value to the end-customers, and in fact many of them would never be implemented because others would be found later. This inevitable late discovery of requirements in turn created even more requirements that needed more people to manage them.
The end result was that large software organizations ended up with large requirements-related departments (analysts, user-specialists, user-research, product management, product concepts, etc.) and relatively small engineering departments. It is no wonder then that companies that followed that model would end up slow and unadapted to the fast changing world of software development (remember IBM?).
At the end, the conclusion can only be that Waterfall does not scale! But Agile does!
I’ll be exploring this and other topics regarding Agile at scale in my talk at Agile Eastern Europe that will take place on September 18-19 in Kiev.
If you are there or near by don’t miss the conference that promises to have extremely interesting talks!
Photo credit: “It’s this big” by bobu @ flickr
One thought on “Agile scales, Waterfall doesn’t! The myth is busted!”
One point i’d like to add is that generally development organizations get so busy with all the “methodology” of agile development that they forget to employ the “provide a vision/problem, get the best people and let them get it done” method.
You could also ask a question why dev teams tend to get things done a lot faster (and sometimes better) when everybody else in the organization is out on vacation? It seems that the biggest obstacle for getting things done is quite often the organization itself.
Comments are closed.