Agile or Waterfall development: It's the modern religious war of the information technology realm, leaving dead, bloody projects in its wake.
While each model has its strengths and shortcomings, misconceptions reign over both. In practice, organizations with successful development cycles appear to employ a hybrid approach, taking a little bit from each methodology.
For the uninitiated, Agile and Waterfall are two approaches for managing the project and development lifecycle processes. Agile, as the name implies, is touted by its supporters as being more flexible, collaborative, often suited for smaller projects. Waterfall, by contrast, is more regimented, with progress measured by clearly defined and sequential goals and yardsticks.
Agile is a sprinter, while Waterfall is a marathon runner.
During my tenure in IT, I've worked in organizations that fervently declared their intention to adhere to one of these particular methods, much like a religious zealot during the Reformation. Indoctrination of staff through professional training classes soon followed, with varying degrees of effectiveness. On paper, the Waterfall method seems organized and clear because of its linear nature. It's the way we wish our minds worked, precise and clean. In practice, it often becomes cumbersome and sluggish, bogged down by its need for dotting I's and crossing T's: the necessity to document everything in nauseating, soul-sucking detail.
I still recall working at an organization where you actually had to write an "idea document" to discuss a potential solution for the enterprise. Only then could a proposed concept be introduced to the project review board and then it had to be circulated to stakeholders for sign-off. That kind of bureaucracy (and paperwork) can drain all the motivation from a workforce and cause processes to take an eternity.
Agile appears more natural, but has challenges, too
By comparison, Agile seems more natural. It's adaptive, flexible and responsive, and you don't have to go back to the beginning if you encounter a problem. Do not pass "Go," do not collect $200. Scope creep isn't a problem, because Agile is about getting something out the door. It is the opposite of the Waterfall method, which can be like a Pekingese in need of a haircut when it hits a wall -- unable to maneuver quickly around new obstacles or requirements. But in practice, Agile can become disjointed and rudderless, an excuse for organizational chaos and an absence of internal processes. It's a sprinter, while Waterfall is a marathon runner. It doesn't always communicate the big picture because it doesn't seem to need a strategic view.
Efficient and mature enterprises understand when to apply each of these methods. Agile is better suited to application development with rapidly shifting requirements or with projects that can be modularized. Otherwise it becomes mired in constant reactivity, a bit like a children's soccer game: swarm left-swarm right. Waterfall is more appropriate for something that can't afford mistakes, like a data center move or building an incident response plan. Each can be applied for maximum benefit, but only if the organization approaches its development process thoughtfully. Otherwise, each method is simply confirmation bias: It's either disorganization due to a lack of discipline or unnecessary complexity rooted in an irrational belief that one can eliminate risk.
About the author:
Michele Chubirka, aka "Mrs. Y," is a recovering Unix engineer with a focus on network security. She likes long walks in hubsites, traveling to security conferences and spending extended hours in the Bat Cave. She believes that every problem can be solved with a "for" loop. She also hosts a podcast called Healthy Paranoia, a security feed of Packetpushers. Feel free to explore her blogs and podcasts. When not blogging or podcasting, she can be found in the Twittersphere or Google+ as @MrsYisWhy.
This was first published in August 2013