Waterfall image

Waterfall Is the Wrong Enemy

I was reading The Inmates are Running the Asylum by Alan Cooper when I came across this passage in chapter 8:

“Some of their previous products were successes and some were failure, but the process they used to create them was the same. From this they deduced that the success or failure of a software product is due only to chance; software success is simply a crapshoot. The problem is reminiscent of physicians in the nineteenth century, before it was discovered that the anopheles mosquito carried malaria, who were unsure of the disease’s source. It was thought to float on the evening air, striking randomly, and one’s only defense against the often-deadly fever was luck. After the cause-and-effect relationship was discovered, the disease was quickly brought to heel.”

And reading this, I thought “That’s us! We have looked at our randomness and declared Waterfall to be the culprit. Agile is the cure!”

Only, I’m not sure we yet understand the problem. I have little faith agile alone can save us. I fear we have become students of nineteenth century doctors.

The Manifesto signers were right, but all too often we have looked beyond the principals they espoused and cried for process and tools. And in our search for what’s easy to digest, we have missed what is most important.

Waterfall image

The problem with waterfall was not too much documentation, but documentation over conversation and understanding. The problem was not in developing plans, but in blindly following plans that were developed with too little information. The problem is we like simple tools and easy-to-use processes, and we are following them without understanding when they work best.

It is difficult to look at ourselves, our skills and shortcomings, to honestly evaluate a team, and then to cast the same critical eye over our technical environment, our business partners, our corporate culture, a nascent understanding of the marketplace, and more to develop the right version of a process. It is easy to say “I will follow Scrum (or any version of Agile)” and fight for meeting the version you were taught in class. And because you still have to fight for your version against the reticent and resistant, it feels like a good fight.

But it is the wrong fight.

Let us commit to reviewing both the manifesto and the principles. Then let us commit to working on the foundations, rather than just a new process. Because if you’re only changing the process without understanding what you are changing and why, I’d rather you change the lighting and humidity.