Waterfall vs. Agile
Before reading this you should know what the Agile Manifesto is and the Agile Principles are.
I’ve seen it on more than one project in my career and it always seems to happen. Agile rarely gets credit in this scenario. People rarely learn what was and was not effective on the project in this scenario. Those that are Agile Practitioners that know what a truly fast paced, effective, high quality, and successful software project can be know. What I’d like to know though, especially from those that have successfully dealt with the “Must have big design up front (BDUF) headaches” and transitioned those people to a more Agile style approach.
The scenario generally starts like this…
A project is green-lighted for whatever reason. Often with some high level manager determining that a project will save or make $X amount of money. The project is poorly defined or simply not defined at all. The stakeholders, clients, or others that would prospectively use the software are nowhere to be found and unidentified by management. There are at least a half dozen external dependencies the project must have completed. (Take Note Upper Management & Executives: Six Sigma/Lean Processes can help at this level dramatically)
In a waterfall approach all of these things will have to be documented and nothing initially gets developed. The people writing the documents, often some sort of business analyst, is forced to basically make up whatever they can come up with. In addition to that and hypothesis is derived from thin air and someone starts to come up with a more functional, technical, or even concrete UML design documentation. To summarize, in a waterfall approach a whole bunch of people start documenting all sorts of things about this theoretical application software. A 6th grader would study this and say, “so they write a bunch of lies right?”
When the actual concrete ideas come to fruition, long hours of the famous death march approach usually start. Sometimes more and more people are thrown at the application in hopes that somehow it will speed things up, but in reality as a seasoned software developer knows, it only slows them down. Other issues very common with this approach are horrifying low code quality, a lack of tests, missing ability to regression test, no verification of what done truly means, and a whole host of known issues.
An Agile approach on the other hand would start finding the clients and consumers of the theoretical software. These people would be engaged and some paper prototypes or other initial sketches of what the software might do are created. Maybe sketchflow or some other software is used to create some rapid prototypes to give the clients an idea of what the software would look like and what it might do. The clients start giving feedback and a more concrete idea is formed around this theoretical software upper management has dictated. Initial tests and code are written and put into a continuous integration process, with an end product being dropped every few days or weeks. A 6th grader would study this and say, “you’re building software and having fun?”
What Happens in the End, IF the Waterfall Project is Successful
There seems to be two resolutions that I’ve found that allow Waterfall to actually be successful. The first is that the project forgoes the charade of Waterfall and starts implementation of more Agile ideals and processes immediately. This cleans up things and improves morale, all while getting the project back on track. The second solution is that development/engineering determines they’ll do Agile anyway, and up manage the management. Management thinks they have a successful Waterfall Project when in reality the proactive developers/programmers took it upon themselves to assure success, and thus moved to an Agile ideals, process, and practices among themselves.
In Summary
These two different models are HUGELY disparate, and yet the aforementioned waterfall model approach is still heavily used. I suspect, unfortunately, that it is primarily used at a majority of businesses (and especially Government). Even if the business or Government pretends they’re doing Agile and calls their Waterfall Model Agile something another. This is something else I’ve seen far too often. This is a complete misrepresentation of what Agile Ideals and processes are.
The Questions
I’d like to know, what methods do you use to attack and remove the barriers caused by waterfall at large organizations? Do you subvert the existing management infrastructure and just do things in a more Agile way regardless in order to succeed? Are there any specific practices, techniques, or otherwise that help you align so that one can keep a project moving along quickly, all while avoiding the damage waterfall models do to the actual underpinning project, code quality, and other such items?
Please leave a comment or three. 
At my previous job, we had a fairly loose Agile workflow which was replaced by strict Waterfall with disasterous results (to both morale and projects).
During the transition we routed around Waterfall successfully a number of ways:
1. We lengthened the “requirements” phase to include lots of design/implementation iterations. As we completed user stories we’d go back to the users to get requirements changed to match the new tech design and implementation. By the time users started to complain about requirements taking too long, we could report that the core app was ready for testing.
2. On shorter projects, we took advantage of weak requirements knowing that ill-thought requirement flaws would show up in testing, forcing users to rewrite requirements and extend the project deadline. Obviously, this is kind of sketchy and did sometimes backfire w/ management deciding our code was flawed instead of the requirements and/or the Waterfall process itself.
Ultimately, though, I agree with the author that resorting to “ninja Agile” secretly within a Waterfall environment is doomed to fail. Either it goes undiscovered and props up ineffective Waterfall artificially or is found out and paints a target on the back of the Agile ninjas.
The best tactic is rallying the Agile army and confronting management directly in numbers, getting a pilot Agile project and making it an example success.
I’m with ya S Jones.
Pingback: A Roundup of Popular Agile Articles - WebsitesMadeRight.com