I’m here to let you in on a little secret, waterfall isn’t the reason your project failed. Waterfall isn’t the reason you were fired. Waterfall isn’t the epitome of evil in the world of software development.
Blaming waterfall for all of your woes is not unlike blaming the screwdriver you used to paint your wall. It isn’t the screwdriver’s fault you chose the wrong tool for the job.
Waterfall works well when both the problem and the solution are known.
Since I always get chastised for this statement, let me clarify that I’m not the first person to state this and also let me clarify that we never fully know anything.
So if I were to rephrase this for the word police, it would be:
Waterfall works well when both the problem and the solution are mostly known.
Mostly known implies that we know a great deal more than we do not and I believe that is applicable here.
If you are about to kick off your big software project and a stakeholder asks “Do we know the solution for the problem we are trying to solve here?” and you say YES then you should REALLY KNOW THE SOLUTION. Don’t just convince yourself you know the solution, actually back that up with data and information about the solution. (hint: some customer development would come in handy right about now)
Too often we say yes when we should say maybe or I sort of know the solution or I really have no idea what we’re doing.
Herein lies the most common misapplication of waterfall.
If you do not know the solution and you choose a software framework with slow feedback loops, then you are going to fail. Now I’m not against failure, in fact I think it is integral to learning, however by choosing waterfall to paint your wall you are going to fail slowly. You are going to fail at a snail’s pace and worse yet you are going bring everyone else down with you.
The fallout of this approach is illustrated in the Standish Report which is quoted ad nausuem by the anti-waterfall crowd. Although it would be an interesting thought exercise if the Standish survey asked “Did you know the solution?” and if they answered yes, a follow up question that asked “No seriously, did you know the solution?”
Speaking of the anti-waterfall crowd, let us apply the same known vs unknown argument to agile software development.
Agile works well when the problem is mostly known and the solution is mostly known.
You can use agile or waterfall if both the problem and solution are mostly known, it is a matter of taste and not one of success or failure.
Agile works well when the problem is mostly known and the solution is mostly unknown.
I think most of us can agree that agile works well when you are iterating through a solution so that you can learn and adjust quickly. If you attempt to use waterfall for an unknown solution, it will most likely need to be a mini-waterfall-like approach for it to have any value. If you choose to do this, you might as well go with agile and get the added benefits of it in my opinion.
Agile works well when the problem is mostly unknown and the solution is mostly unknown.
You can even use agile if both the solution and problem are mostly unknown. I do not recommend this for the faint of heart and your whole organization better be ready to inspect and adapt if you want to succeed (not just software development). I would not recommend using waterfall for this unless you’ve updated your resume.
The battle of agile vs waterfall is becoming old and tired. Neither one is going away anytime soon and the argument is white noise. It distracts us from the real issue of whether or not we mostly know the problem or solution.
So let’s stop blaming waterfall for all of our woes, and start asking ourselves if we are choosing the right tools for the job at hand.