October 7, 2014
Agile is a solution development life cycle (SDLC). So is Waterfall. Agile is trendy – its name has entered the danger zone of buzzwordiness: coworkers the world over are asking and talking about and using it (and not all effectively). There are lots of opinions floating about regarding Agile, none so many as those from Waterfall fans. Waterfall is another SDLC: tried and true, linear and thorough, the old dog. Sure, Agile isn’t just fancy shoes anymore, its solution-delivery methodology is very good at working forward as well as backward, and is viewed by many programmers and dev-type folks as revolutionary. It has also been labeled heir-apparent of the classic Waterfall machinery, but this opinion is not shared by everyone – lots of everyones.
In my opinion, this draconian Agile-or-Waterfall/take it-leave it/us-them mindset limits users of both working methods: let’s open our minds a little. Are you flexible to employ the best of both Agile and Waterfall without your Agilefall turning into an Agilefail?
Agile and Waterfall both do some things well. Both can get you from requisition to solution. Both have been proven in the battlefield. Both have been useful for organizations large and small. The are certainly not the same, however: Waterfall’s SDLC has been used and abused, reviewed, reviewed again, and perfected over 30-plus years of principled industry use. It works – its templates are figured out, the requirements are conspicuous, everyone knows the process, and the delivery team doesn’t need convincing. If you can make large-scale business process design decisions prior to building or implementing a solution, Waterfall can be your huckleberry.
Meanwhile, Agile Development is very Round Table, encouraging creative team dynamics, ready involvement of the client, customer and team leadership, and it’s fast to find solutions. It’s especially good when the end-product is short on details (or indefinable).
Having used both methodologies, I believe that Agile is a better platform for working from inside out – customer-facing – and does a better job than Waterfall of providing products that accurately reflect customer needs (and marketing, feature and research-driven customer demands). That said, Agile can be dangerous for undisciplined or inexperienced team members who may see it as a Get-Out-Of-Documentation-Free Card. Accountability and recording requirements that are built into and automatic for Waterfall users must be formed and enforced for the Agile process. Agile has also come up short for org-wide and enterprise-transformation projects like ERPs, CRMs and sales-management upgrades that affect a large mass of operators and/or large portions of an operational business that necessitate making strategic decisions up front.
Having lived with both methodologies for 17 years, I’ve come to use a flexible combination of Agile and Waterfall that borrows from each as demands warrant, in a fashion I like to call the Iterative Waterfall methodology. This practice is not alien to our business – whether you’ve heard it called Iterative Waterfall, Wagile, Wacky Waterfall or Skating Ice, these and many other names describe the same thing: making use of the most successful functions of each methodology as needs and organizational culture prescribe.