The job search chronicles
Describe the difference between Agile and Waterfall
About this series: Looking for my next adventure I’m participating in more interviews wherein I get asked questions that cause me to reflect a bit. These are those reflections. Note: These may not be the responses I actually gave.
In interviews, the question of Agile versus Waterfall always hangs me a bit.
I get hung up because, for me, it’s a faulty comparison. Agile is more a mindset (cultural outline) described by the Manifesto for Agile Software Development. Waterfall, on the other hand, is more a methodology, which only implies a mindset. Waterfall was defined, depending on who you ask, by the publishing of a paper by Dr. Winston W. Royce entitled Managing the Development of Large Software Systems. After reading the paper, and using it as the canonical foundation for waterfall, comparing iterative design and development and incremental releases against big design up front and big bang releases would be more fair.
The Manifesto is focused more on human interaction while the Royce paper focuses more on process and documentation. In fact, the Waterfall process as described in the paper might not be what you expect. Instead, I would say the common ground of negativity between things called Agile and things called Waterfall comes from not squashing anti-patterns, which can emerge under either umbrella.
Another more fair comparison, in my opinion, would be between generalization and specialization of teams and individuals (cross-functional versus pure-functional). The Manifesto does not really describe separate phases (again, it’s not a process document) performed by different people; instead, it only really calls out people who want something (customers), people who create something (developers), and people who facilitate that creation (sponsors, which the Manifesto only does once). The Royce paper, on the other hand, repeatedly calls out separate groups doing separate, specialized operations and passing things around.
Ultimately, it’s probably most fair to compare Waterfall to a framework that claims to abide by the mindset laid out in the Manifesto. In most there are some pretty big similarities (I tend to try and find similarity; helps find universal truths).
- Product Backlog — Software Requirements documentation.
- Refinement — Analysis.
- Development Effort — Coding.
- Automated testing up front — testing at the end.
- Some type of mechanism for communicating between the people who want something and the people who make that thing.
- Some type of mechanism for delivering the newly created thing to the people who want the thing.
- Some type of mechanism for consumers of the thing to tell the people making the thing how well they did.
To the best of my knowledge, there is no similar document describing the mindset of Waterfall. In fact, normally when I hear discussion regarding the mindset (culture) of Waterfall it’s usually in reference to what Agile isn’t; in other words, whatever Agile isn’t, is what Waterfall is.
I think that’s what made the Manifesto unique; having said that, it’s not unique in sentiment. That’s why, when it comes to 8fold, we bring the Manifesto into our core values and principles but change “software” to “solution”: The Manifesto for Agile [Solution] Development.
- Working [solutions] over comprehensive documentation: The user manual for your thermostat doesn’t, by itself, help keep you warm.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable [solutions]: My boss needs a presentation deck to get us more funding to stay afloat.
- Deliver working [solutions] frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale: The first iteration of the presentation deck could work, same with the second, same with the third.
- Working [solutions are] the primary measure of progress: Delivering one wheel of a full-sized car to solve the mobility problem of a user is not a working solution.
Out of 16 elements, 4 values and 12 principles, those four above are the only ones that mention software. (I’ve seen some anti-Agilists say, “I don’t do software; so, Agile doesn’t apply to me,” which always confused me since the Manifesto has so little to do with the software.) Some of the elements are also taken from what one might consider traditional project management (or just straight management); face-to-face communication, for example.
What I’m passionate about when it comes to Agile Software Development isn’t the technology piece. It’s not the anti-waterfall thing. It’s that the Manifesto is a good distillation of values and principles recognized in various fields as good things without needing to become an expert in those other fields. Further, I’m a big fan of those values and principles and attempt to embody them whenever I can.
If there were another label that embodied this mindset, I would use it as well. Or, if I could summarize it so eloquently, then I would just use that summary. Until then, even if Agile fades into nothing, I will probably still hold onto the mindset because of the way I was introduced to it, which is literally a talk for a different time.
So, yeah, Agile versus Waterfall is something of a nonstarter for me. It’s an apples and oranges conversation. Well, kind of…remember the anti-patterns mention. Things like stove-piping can occur due to Waterfall process implementation…doesn’t have to, just high probability. Blaming each other, “if the analysts could write better requirements” or “if the developers would write bug-free code, testing would be easier”. Are these the interactions we want people to have? Are we willing to sacrifice possible better interactions in order to say we are doing X process…not according to the Manifesto…we sacrifice the process to improve the interactions; in some cases that might even mean switching to Waterfall, especially if the people creating the things want to.
