Applying QA to Waterfall Development: Wait, what?
Agile is getting all the spotlight lately as the new dawn of software development over the old crusty world of waterfall development. How do we know the problem was the waterfall process? How can we be sure the real problem wasn’t our implementation of waterfall? Is it possible waterfall wasn’t to blame?
A waterfall software development process for those of you that are unfamiliar with the phrase simply implies that a collection of a certain kind of software development work, much like a bucket of water, is completed independently until a certain goal is reached. Once that bucket is full, or the work complete, the output of that process is “poured out” or fed into the next bucket, which contains a new kind of software development work. Likely, it contains what we call the next “phase” of development. This next bucket would then begin its work in earnest, do its unique job, and then pour itself into the next bucket. In this way, work can be carefully defined and assigned to certain teams. These teams have official and well-understood hand-offs and it is presumed that the output of this process is quality software. Well… sometimes.
Waterfall development is as old as industrial work itself, at least insofar as the metaphor of accountability for smaller groups of people building a product. Waterfall software development has earned somewhat of a bad rap in recent years not because waterfall itself is necessarily inherently bad, but because, in my opinion, it has been applied as a solution to problems that probably had in its set of possible best solution sets another approach that would have, all other things being equal, solved the problem more effectively and with less capital/human investment.
Waterfall works a little like this: Software is split into a number of buckets (why not call it the Antique Waterwheel approach you say? Or the Spirited Sack Race? I too share your wonder.)
There is a requirements bucket, an implementation bucket, a testing bucket, and a support bucket. Each bucket is well-defined with pre-requisites from the process previous to it and defines exactly the deliverables that it will generate to pour into the inputs of the next bucket.
This approach can work very well for large project teams or large corporations that need a consistent management approach to enable consistent reporting up the management chain. This approach walks a fine line between process for process’ sake and enabling a predictable command-and-control management approach to getting work done. This process works particularly well when the software being developed does not need a deep reinvention of an idea or approach and follows a somewhat well-established solution set.
A web site implementing a catalog inventory and purchase system might, for example, do well with a waterfall managed process, whereas a web site implementing a new customer learning and purchase prediction model with multiple A/B tests across a variable semantic customer preference grouping algorithm will require a more dynamic and flexible software development process. Waterfall would be too hardened to allow deep innovation in this example, where the requirements themselves must be flexible enough to be self-modifying or reinvented entirely based on new discoveries or developer hypothesis.
Complicating the waterfall approach is the sheer number of copycat copycat management and software development approaches that model it or throw a slight variation on the theme in the name of uniqueness. Companies in the business of reinventing their image often reinvent their process so there’s something new to sell prospective clients or there’s a new “innovative effort” that is supposed to attract new talent under the guise of a smoke-and-mirrors investment in IT and delivery excellence.
These reasons for implementing waterfall have given it a bad name — and unfairly so. If you’ve worked with me, you know that it is true that I prefer Agile approaches to waterfall and I feel they are more effective to the projects I tend to be attracted to. Understand: this is not because waterfall is bad, but because the sort of projects that are best solved by waterfall software development just tend to bore me (but not always) and the projects that tend to be best solved by Agile methods tend to excite me (but not always.) No harm no foul, I like strange problems to solve; not everybody likes strange problems to solve. Strange problems often attract strange people, and I’m somewhat of a weirdo anyway.
It is important to understand that by and large, waterfall development itself is one particular solution to software development that requires certain conditions under which to blossom. It is not the fault of a process if its implementers fail to adequately provide for its successful implementation. I place my gaze directly upon the CIOs that dictate waterfall implementations over a more holistic systems approach to solving a technology problem. Yes, it is the CIO’s job to responsibly solve a technology problem or innovate a solution for a company. The way the CIO goes about this, in many cases, has far more to do with ego and less to do with a deep understanding of the problem they are solving with the decision to implement a waterfall software development lifecycle. Or, as is often the case, trusting their team that a waterfall process is the best way to go without fully understanding the problem they are solving with accepting the team’s proposition. An effective CIO is not looking to make friends and does not rule by majority vote; they do what is rational and good for the technology team and the goals of the company by communicating those goals effectively and being transparent in his or her decision making.
So how is QA best applied in waterfall development? The most valuable approach here is to simply learn the rules of the road.
- Get to know what dictums have been handed down from on high upon which the software development process is to proceed.
- Trust the CIO’s judgement (unless something truly nutty and unexplainable seems to be going on that seems harmful to the overall project) and understand exactly what deliverables are expected of QA in terms of testing and requirements audit.
- Build a list of owners to escalate your issues to: know your project manager, product managers, business systems analysts, architects, senior developers, coders, and most of all go out to a few lunches or beers with the team to hear the stories of what’s come before you.
- Lunch and learns, and/or beer: Chances are there are a few choice nuggets of storytelling that outline miserable failures and some rockstar moves that saved the day. These stories will help you determine how to guide your own enthusiasm to do good work and apply your good intention in the most sensible and effective way possible.
- Apply your energy with the long-term in mind: Best intentions in corporate organizations can make you seem like a loose cannon if you go about applying your enthusiasm in a way that suggests a rebel-rousing or aggressive personality. (You may in fact have this personality, and that’s fine, but if you want to be effective you’ll learn how to temper your expression of feeling with effective channeling of your feeling. Don’t mistake your inner feeling itself for being necessarily bad.)
The personality type driving a decision to use waterfall may very well include the sort of person that wants to cover their ass in case of failure. I don’t mean to sound negative here, but I’ve seen this so many times it’s hard to ignore.
Why do I say this? Because waterfall enforces a certain rigor around it, failure in the development process are often redirected toward the project managers or software developers when in fact the issue is the process being used.
On the other hand, great successes have been had with implementing a waterfall process (IBM and NASA are two large organizations that routinely achieve success using waterfall or waterfall-styled procedures.) These organizations tout accountability and traceability of defects in the name of deep quality often at the price of huge headcount. The application of waterfall to projects of this nature makes sense. The rigor of the process forces certain gates to have strict criteria for which the next phase of a project must wait for to begin.
The personality types waterfall is designed for are people who enjoy being told what to do. I’m being serious – there are plenty of people out there who are very smart and successful and have no interest in innovating completely new procedures and methods to get work done – they maintain a certain comfort in having procedures to follow and glean their satisfaction in a job well done by following the rules. Personality types that enjoy invention and questioning classical knowledge would not enjoy waterfall. Students of philosophy and many people with advanced degrees who have been forced to question the origins of their science may become bored with a waterfall styled approach because the root motivations of the CIO are generally not up for discussion in companies that implement waterfall development.
In summary, waterfall development provides structure and predictability to software projects that have little innovation required to implement them. Projects that require deep thought about algorithmic implementation, user behavior, or a new technological approach should reconsider their decision to apply waterfall and deeply question what problems they are looking to solve with their technology team. A train conductor with 35 years at the helm piloting a locomotive may not be the best person to innovate a new kind of diesel engine. The key to success in implementing QA into waterfall development is to understand and manage communication, expectations of testing, and the most effective channels to raise issues to.