As an Agile coach and a trainer I often compare Agile methods to “Waterfall”. Waterfall is a bad thing. We all do it. When we are assessing a team, sometimes I hear people say in a desultory tone, “They’re just doing mini-waterfalls.” Typically when I think of waterfall processes I think of a project that is organized as follows:
Or something close to this (you may use different terms). Basically, we do this, then this, then this… and repeat. Typically this method is criticized as creating too much specialization, not enough collaboration, too many hand-offs, and so on. So far, none of this should be a surprise to anybody. I can slap this sort of project together in MS Project in my sleep.
Now, let’s take a look at our Scrum task board. Here we see something similar to the following:
ToDo, Test Complete, In Progress, In review, Done
Interesting. In a typical case, can we do any of these steps out of order? No. Can we skip steps? No. Hmmm…let me show you those terms one more time:
ToDo->Test Complete->In Progress->In review->Done
Oh, now that’s kind of interesting. It seems that the Agile process that we are using to track our tasks looks remarkably similar to the Waterfall process. But that can’t be right! Let’s put them side by side and see if we can find a difference:
AGILE: ToDo->Test Complete->In Progress->In review->Done
WATERFALL: Analysis ->Design->Implementation->Test->Release
Oh nuts! Now I’ve really done it. Perhaps its a matter of scale. Perhaps its a matter of the order of magnitude difference in the activities. Or…perhaps using the “Waterfall process” is a straw man that we shouldn’t really be using when we talk about the benefits of Agile. Perhaps the greatest difference between how things are done on an Agile project, and whatever folks have done in the past is not in the order that the tasks are completed in. You can rename the tasks, reorder them all you want. But you still end up with the same thing. Call it something different, “a mini Waterfall.” If it makes you feel better, great. But my argument is that this is not the key difference between Agile and other methods. The difference lies someplace else, not in the ordering of the tasks – because, if we just compare the ordering of the tasks, guess what? Agile and Waterfall look the same.
Maybe I’ll sleep on this tonight and look back on this tomorrow and regret it. After all, I’m a good little ‘Agilista’ and I don’t want somebody to stamp my meal card “No desert”. Perhaps I’ll go back on my medication tomorrow and realize that this was all a hallucination. But somehow I doubt it. If we are looking to explain to others how doing an Agile project is different than others, perhaps we should avoid this comparison and focus on other differences.