Waterfall Zombie vs. Agile Zombie
Back on October 12 (2010), I had the privilege of seeing Michele Sliger do a presentation titled “Hello Agile, Goodbye Scope Creep“. In it, she presented a compelling argument as to why a Waterfall process used to work so well for projects and why Agile is becoming more and more prevalent and successful. You know me by now. I can’t help but draw a parallel between Waterfall versus Agile and old-school-dragging-their-legs zombies and new-school-all-out-sprinting zombies.
Back in the day of Night of the Living Dead, Day of the Dead, and even Dawn of the Dead, zombies were sooooo slooooow. You usually had enough time to time to go to the gun shop and pick up a few cases of ammo, pluck them off one by one, all before they would change course and lumber after you.
Those were the days, when you could actually plan your attack on the zombie populous and carry it out.
Yes, when Waterfall was big, zombies were slow. You actually had a fighting chance to outrun them. That is, until you made some foolish mistake like not rolling up a car window or fumbling with your car keys. Come on, people!
Now, zombies are fast, fast, damn they are so fast! These aren’t zombies like I remember them. These “28 days later” style zombies look you square in the eye and they are sprinting after you. They are quick to react.
Now, I’m just looking for an excuse to put zombies in a post. But, truthfully, something has changed. Why is it, more and more projects are leveraging Agile methods and not using Waterfall? Is it ADD? It is just a bright shiny toy? No, it’s evolution. Things change over time. The one constant that seems to be happening is communications is a lot faster than they used to be. The famous “Midnight Ride” of Paul Revere of 1775, where he road horseback across the countryside would now merely be a 21 character Twitter Tweet British coming! #fail
But, I would be doing you all a disservice if I didn’t let you read what inspired me to write this post.
Fifty years ago, planning out the scope of an entire project and locking it in worked because the pace of change was much slower. Teams had time to analyze, design, code, test, and deploy the product before their customer could change their mind. It was in the late 1980s that all of the inventions that speed thoughts of change started being used by the general marketplace: the personal computer (PC), Internet, email, and cell phones. The speed of communication increased, which increased the speed of knowledge, which drove the speed of change. Teams using the traditional plan-driven approach to product development could not keep pace with this new speed of change…
…A new approach to product delivery was required in order to take advantage of the technological advances and speed value to market. And it had to abolish the philosophy that change was bad, and instead embrace it. It had to give teams the flexibility they needed to react to change, and the framework and discipline to execute change.
Like the images? Find them at Pictofigo
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)