The Apoptosis of a Waterfall Approach
Upon its birth it was already destined to die. Much like every other living creature on this planet, there was only a finite amount of time this being would be allowed to create its imprint upon the world. Some like him are blessed with longer lives, while others are condemned from birth to have even shorter lives than his own. Although seemingly dismal, it is all part of the plan. It is part of life’s grand scheme to allow for this death in an effort to spawn rebirth. Each of us are comprised with billions of these single minded mission suicide operatives that seek a solitary purpose before experiencing a pre-programmed death. These creatures are inhabitants within each of us, they are our cells, and each of our cells live a life pre-programmed for death. This design, this beautiful design, is called cell apoptosis. It is nature’s plan to allow for functioning cells to serve a purpose before allowing younger cells to take their place. It is the cycle of natural life. And it seems many things imitate this natural cycle.
In the 1970′s, as projects grew larger and larger in scope, there was a concerted push to ensure that costly changes late in a project cycle were avoided at all costs. These “defects” of process were identified as common enemies to a successful project lifecycle, and were one of the primary motivations to move to a more structured approach of project and product management. Out of this effort grew what would become known as the “Waterfall Model” of product development. This approach called for all planning, extremely detailed planning, to be conducted up-front, before any actual development work was started. The thought, very rational at the time, was that any time spent up-front in initial planning was an investment that would pay dividends compared to a lack of detailed initial planning that could ultimately yield many costly changes late in the cycle.
Times were different then. At that time there was a need to ensure that every last detail was known before beginning an expensive development effort. Most of the projects that employed this methodology during this period were of a non-complex nature. In simpler terms, they were more closely aligned with construction types of efforts as opposed to the complex nature of software development, especially considering the software development done today. Why would I refer to construction efforts/projects on a non-complex nature? Because back then success was generally a product of how closely the execution of the plan matched the plan. It was thought that the final product of these efforts should match the original plan precisely, and any major deviations from the plan were categorized simply as defects. And rightly so. Construction can take this approach. In fact, construction types of projects should take this approach. These types of projects should not evolve over their construction efforts, as this may yield a poorly delivered product or a deliverable that does not match the expectations that were set during the planning efforts.
Software is different. Software is knowledge work. What we are building is generally based on a description from our customer of a product that does not exist. When utilizing a waterfall approach to project management, our attempt to capture this description of an imagined product from our customer takes the form of a detailed specification. And in our effort to reduce the perceived risk of change, we capture that all important signature to ensure that we discourage change along the way. Even for software, this approach once worked, and worked well. But as software became more complex, more innovative, and as product refresh cycles shrank, the need to be increasingly more responsive was seen as a compelling competing force working against efforts to guard against mid-stream product specification change. As markets shifted, as companies competed, the waterfall model was quickly becoming a dinosaur in a world that no longer favored the large, lumbering behemoth that waterfall represented. The pre-programmed death of a once useful approach was being triggered.
Waterfall, although not dead, is laboring through what seems to me to be a labored death march. And although this is an agile blog, you are not going to hear me herald agile as the final, ultimate victor. Perhaps if it were only a match between the two development approaches, but it is not. The lifespan of the development lifecycle will go on and new players will emerge based our learning and understanding that has evolved along the way. And as waterfall dwindles in effectiveness when applied to software development projects, agile is gaining a foothold. Agile exploits today’s realities, just as waterfall did when it was king. Waterfall is a victim of its own apoptosis. It was destined, although not designed, to be obsolete, preordained to die the moment Winston Royce inadvertently wrote it into being. Agile’s birth benefits from the pain that has been caused by utilizing waterfall in world that cannot wait for the long cycles that waterfall requires. Death is always spurned by, and simultaneously allows for, rebirth.
Welcome to the world Agile. You have been around for awhile now. You are becoming more and more well known. You success has been widely documented. You are past the dreaded chasm that many new beings are never able to cross. You are now mainstream. You are in your prime. It is possible that your best years lie ahead of you. It is possible that your best years are behind you. But make no mistake, your own clock is ticking. But that is the beauty of nature, every apoptotic cycle not involves the death of one being, it provides the energy for the creation of another.
I make my living providing agile training and coaching. I am extremely passionate about the type of change that an agile transformation can mean to a company. I have seen incredible results from the principled based approach that agile represents. I hope that agile stays around for a long time. But not longer than its usefulness. And that is one of the great tenets of agile. In the DNA of these agile principles is the idea that our organisms, our teams, our approach, our methodology, our framework, our everything should always be evolving as we learn more, as we experience more, as we become more.
It is truly a beautiful aspect of agile that from it’s own birth it recognizes that in its current form it had already predicted its own death. But this is what makes agile a distinguished and impressive approach to product development and delivery. Agile, I am your biggest fan, but I will not cry when you are gone, for your existence supplied the knowledge and energy for whatever is coming next.