Is Agile vs. Waterfall the Wrong Fight?
In my years in the software industry I’ve found that there are two types of people: process oriented people and result oriented people. The former generally outnumber the latter by ten to one, though I have no reason that the ratio cannot be shifted given the right environmental changes.
Mindset Over Methodology
To me, “Agile vs. Waterfall” seems to be the wrong fight to fight. It is an issue of mindset and discipline, not methodology.
As long as a process oriented mindset prevails, methodology and ceremony will be irrelevant. Process oriented people will just behave in slightly different, but very predictable and unproductive ways depending on the environment, they will jump through the set out hoops, expecting results to magically appear at the end of the rainbow, even if they never understood what the desired outcome was in the first place.
In a waterfall environment, process oriented people will think that as long as the “right” artifacts, documents and approval processes are adhered to, success will inevitably follow as by some magic.
In an Agile environment, they will think that moving around task- and story cards on a board, mindlessly doing whatever has been written down will be the hoops to jump through to somehow achieve success.
A process- and hoop-jumping mentality will only ever achieve one thing: wasted effort and non-delivery.
Agilist Excuses: What Does “Context” Actually Mean?
The stock answer for any disagreement from religious Agilists is “depends on your context”. Context is of course never concretely defined, most likely because it is an abstract term used to excuse failings people do not understand or care much to investigate. Trial and error is preferred over investigating and understanding.
Well, the business is the context, genius! If you do not understand the business, how can you claim to be able to solve its problems? Trying to solve problems you do not understand is a fools errand, yet this is exactly what IT organizations try to do over and over again. No, I’m not advocating analysis paralysis, I’m merely asking for a bit more interest from IT people to actually understand the fundamental problems they are trying to prescribe technical solutions for.
If you do not know what you want to achieve, how can you have any hope of achieving it? If you have no way of telling if you have achieved something, how can you claim to have achieved it? It boggles my mind how many IT projects there are with no clear idea as to what they want to achieve (other than spending money and increasing headcount). If the answer to “what do you want to achieve?” is “we want to build a [some sort of system all the other big boys have]”, run in the other direction.
A clear outcome in mind means no fussy mission statements. You need to have a clear idea of what exactly it is you want to achieve as a very concrete big picture goal. Contained within this may be a fluent number of requirements making up the scope, but hopefully as you test your assumptions and proximity to your goal, these will become fewer and the scope narrower. A lot of the time the bare essentials to achieve something is a lot less than what you originally thought.
As for requirements, these can’t be fussy-wooly blabla statements. They have to be assertable, measurable and testable. An ideal requirement should read almost as a test script (in fact, you could/should write tests as a requirement specification). The shorter the cycle is from formulating a requirement to testing it is, the less effort and time will be wasted (and possibly also less rainforest will be killed). Behavior Driven Development isn’t such a bad idea.
We Have Been Fighting the Wrong War: Methodologies Don’t Matter (Sort of..)
Ok, I’ll admit it: Agile is probably better than Waterfall in so far as there is usually lest effort wasted on jumping through hoops and more effort spent on value adding activities. But if I where to formulate a recipe for software success, it wouldn’t really be a methodology or process, it would be a mindset:
- Understand your business context: Understand the business you are in, how it works, what challenges and problems it may have. Truly understand it.
- Have a clear outcome/goal in mind: What exactly is it that you want to achieve? What tangible business benefits? What actual pains do you want to get rid of?
- Testable functional requirements: Any requirement should support the overarching goal, any requirement should be testable in a binary pass/fail manner.
- Aggressive scope management: Do you need a given requirement to minimally fulfill your overarching goal? Really? Get rid off, cut out and strip down requirements aggressively, get down to the bare essentials. If your big goal is too big, cut it down. If you want to make it nicer, do it later. KISS, less is more and all of that.
- Cut all waste: Perhaps the most important point of all. Anything that is not a net value adding activity should be cut. Do you need that document? Do you really need to do that task? Can people speak directly rather than communicate through layers of middle management? Anything that doesn’t bring you closer to your goal is waste.
Some may point out that Agile projects tend to have a higher level of success than Waterfall projects. It may be true.
But correlation is not causation, nor would I call a 60% success rate a shining beacon of high performance just because you are comparing it with a dysfunctional 40% success rate.
Of course, there could be some causation, after all, Agile has given us a number of good engineering practices, and Agile environment have a lesser emphasize on hoop-jumping than Waterfall, which likely pushes more people into an outcome mindset rather than a process mindset, resulting in higher rates of perceived success.
However, I have slowly come to the conclusion that Agile in itself is not only a sub-optimization as it is often too localised in its approach, it is to a large extent also not about the process or methodology itself. Success in software projects is about the prevailing organizational mindset, both within a software team and outside of it. Mindset trumps methodology and process every day.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)