Applying QA to Waterfall Development: Wait, what?

Agile is getting all the spotlight lately as the new dawn of software development

This is 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.

Complete requirements for one bucket before passing to the nextAnatomy of the Waterfall SDLC

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.

The rules of waterfall development can be perplexingWaterfall’s Complications

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.

All hands on deck for testing!Best QA Approach for Waterfall

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.)

Cast and Characters of Waterfall

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.

Good QA people pull like a freight train, babies

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.

3 comments

  1. Mr Mumford,
    It is true you are a wierdo for those who have had the pleasure!! I can almost taste your distain for waterfall type problems… :-)

    However, I don’t believe that selecting waterfall is as outdated an option as you present here. Good old fashioned business problems that need software solutions are much more common than “a new customer learning and purchase prediction model with multiple A/B tests across a variable semantic customer preference grouping algorithm”.

    A CIO’s preference for waterfall (side note: Should CIO’s really be dictating project methodologies?) is understandable. Boring, consistent, predictable controlled delivery, with appropriate stage gates – while doesn’t light your fire, is not a bad thing.

    Badly managed projects are just that – irrespective of the methodolgy chosen. 10 years from now Agile will have had the same experiences. It’s just catching up…

    • Good to see you around this part of town, Mr. Farnan!

      You’re right, I think that what you describe as my “[disdain] for waterfall type problems” is more a disdain for the disdain itself. I agree with your suggestion that waterfall is not outdated; I am in sync with the spirit of “just because it’s old doesn’t mean it’s necessarily bad.” Take all of the mainframe re-engineering work going on today — racing to replace FORTRAN code with Java architected apps can provide some relief from (note: not necessarily a pure solution *to*) scalability/supportability issues, right, but what other problems come with Java architected apps created from the user requirement of “make it work like it does today”? Very often a hairball is replaced with… a new hairball. Meet the new boss, same as the old boss.

      Some CIOs dictate software methodologies indirectly by first stating that it is not their job to dictate how software is created but then hammering down ideas that don’t fit with their pre-conceived notions. Sure, they’re not dictating the process, but the process that ends up being implemented is the one they were just happening to prefer because they made it too difficult to implement the alternatives. How many times have Agile Scrum projects failed not because Scrum failed, but because you implemented a nasty monstrosity that you called Scrum and looked like Scrum but was really just a set of actions without an exhaustively understood set of principles behind it that mapped to both your corporate culture and your technical ability to execute? Good CIOs think of these things, and they look to their direct reports to audit them and question their assumptions.

      In complete agreement on badly managed projects. I don’t know if your prediction about Agile will come true: I do think we can help to prevent that version of the future by standing up for principled, smart software development outside of our expertise, whether we are a Project Manager, Developer, Architect, or QA guy.

  2. It’s nice to see that Waterfall still has a role. In fact we talk to IT executives in many different industries working on many different types of projects and whether they use agile or waterfall development (and I agree, labels are misleading), the one constant is a never-ending search for efficiency. CIO’s don’t have time to make friends—the pace of new business requirements continues to accelerate and that is pushing IT organizations to look for process improvements across the application lifecycle.

    One focus we are seeing is a quest to compress the defect management process. Whenever a bug shows up between sprints or at the end of a dedicated test cycle—there is typically a mad scramble to document, replicate and troubleshoot the problem. These steps are complicated by a geographic dispersion of development and test resources, some or all of which may be outsourced. The stakes are high. Many industry experts put the time developers spend on bugs at 35% or higher.

    So, whether a project is using Agile or Waterfall development, successful CIO’s are indemnifying their schedules and improving MTTR by: 1) better documenting and communicating defects for teams located across many time zones, 2) reducing the amount of time and capital required to replicate the test environment to reproduce a bug, and 3) accelerating the identification of root cause.
    Given that over a third of development time is spent on bugs, lets’ add one more to the “Rules of the Road”: any improvement in defect resolution saves time, money and improves quality. That’s not smoke and mirrors.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>