Agile vs Waterfall, is Agile a real benefit?

In My Humble Opinion
1

Seems like Agile has been around long enough now, that there should be real metrics to show if it really improves the project over Waterfall. When I read about Agile, people talk more about the philosophy of it. I’m not so sure it has helped every software product development or IT environment. I get the feeling we are expected to believe it will because on the surface of it, it looks like it is better method. But I’m concerned with real metrics on this and if anyone has done this.

I’ve seen people on Linkedin who have obtained every possible Agile related certifications. I’ve also heard a lot of complaining about it that it can take up more staff time. Just wondering if there is any real proof that Agile is really worth all this.

I have seen people complain it wasn’t implemented very well where they work, but they can be done with Waterfall too.

2

The scale of modern software is too great to perform realistic comparisons. Agile has proven itself to be beneficial to management. It provides the means for management to evaluate the progress of software development. That in itself is not really tied to efficiency or quality of outcome, it just helps prevent massive wastes of time and money on attempts that can never succeed in a practical manner.

3

As a peon, if I were ever - God forbid- interviewing for a software development position again, I’d run far away from any company that said they didn’t do any Agile stuff and were still using waterfall. I don’t care too much about the post-it notes and the whiteboard and the stand-ups, though they’re all excellent things. But constant public evaluation of exactly where you are, what your next step is, who’s in charge of it and what might be stopping you? Hell yeah, do that

4

Agile is a many splendoured thing. Which is a good thing. Like any process it can become a straightjacket, and become something that is used inappropriately or inflexibly. Managers that drink the Agile kool aid and don’t understand the underpinning ideas could be a problem, but this is no different to almost any process.

Contrasting it directly with waterfall and asking if it has brought about better outcomes in a quantifiable sense is not an easy thing to do. You need to choose the process that suits the task. There is nothing inherently wrong with waterfall - when used in a project or task for which waterfall is appropriate. In that sort of project Agile would probably be a net drag on productivity.

Agile seeks to address some of the big problems seen in projects that can cause them to go off the rails. But projects differ dramatically in their constraints. However, back when I taught software engineering - in the pre-agile days - I used to warn the students that IMHO the two places where they would fail more often than anywhere else were requirements and integration. I haven’t changed my mind. And Agile is a good way of handling these two. Waterfall fails often because it tries to divine the requirements before anything else. If you have a very well understood problem this can be quite reasonable. But so much software is ill defined. Stakeholders don’t have a full grasp of what they need (as opposed to want) and they can have changing demands. Short cycles with stakeholder involvement helps avoid this. It minimally avoids cries of “this isn’t what I wanted” at the end of the project. Short cycles with some amount of working and tested code helps avoid integration failures, and integration issues can kill a project dead well into its life.

People still underestimate how hard these things are. In addition to the above, Agile style cycles help identify components that are getting out of control early. Waterfall can easily be derailed by the one long pole that was, on paper, progressing fine, but in reality is well behind, or worse, wrong, and incapable of working when integrated into the whole.

All the buzz phrases and things - scrum, stand ups, are just sensible adjuncts to the core problem. You need to always know the answer to one question - are we doing OK? Waterfall makes answering that question very difficult unless you have a comprehensive understanding of every aspect of what you are doing. Which can only come from having done essentially exactly the same thing many times before. Most software projects are not of that ilk.

But back to the OP’s question. Quantifiable metrics? Hard, and IMHO difficult to justify. Unless you run controlled projects with people of much the same skill set and measure the outcomes, you are not going to get proper answers. Companies that have explicitly migrated their practices may report useful thing such as amount projects go over time, over budget or fail to meet the stakeholder expectations. But even these need to be taken carefully.

OTOH, even before Agile became a thing a lot of the ideas were already in use. Just not codified, and often the result of experience by the lead engineers. So, again, direct comparison with pure waterfall may be very hard, simply because the classical waterfall process has been waning for a long time. Some sort of spiral model has perhaps been more common, and you could argue that Agile is (to some extent) a modified spiral with many turns.

5

Very little of Software Engineering has any form of empirical basis which makes answering questions like this one of opinion and gut instinct rather than any sort of scientific consensus.

The reason why is because you almost never are in need of building the same software system twice, because if software is already built, you would just use that rather than building your own. Thus, every software project is unique and every software team is unique, rarely allowing for 1:1 comparisons. The few studies that have been done tend to be on university projects, usually by solo developers or extremely small teams which make it hard to generalize to production software systems at scale.

6

Yeah, for the kind of projects I work in (multi-module, usually multi-location, SAP implementations or reimplementations), the standard approach includes several things happening at the same time and several cycles of tightening the requirements and the solution. Both of those give people stuck in Waterfall the fits, while the “long” cycles leave Agilers who confuse speed for results saying “but, but, but…”

They’re too big for a truly-Agile approach (which OTOH is fine for doing maintenance or small improvements once The Monster is in place) and too complex for Waterfall. Like any kind of methodology, those two have areas of applicability that one needs to keep in mind.

7

[Moderating]
Since this seems likely to be a matter of opinion, let’s move it over to IMHO.

8

This time ten thousand. I’ve worked in both environments over time and also weird “cowboy coding” or “extreme programming” environments. I’ve seen it all go bad, and I’ve seen it all work well. In my experience the best methodology shouldn’t even be based on the team or project but something even more discrete, like sub-projects. For example, my current workplace is basically Waterfall. We’re supporting a mature software product on a contract basis where our client submits change requests. We choose a collection of change requests to work on for each somewhat bi-annual release. For the most part this works fine. But in the release we’re currently working on one of the change requests was for a brand new, complex report. We’ve been having trouble nailing down the requirements for it because it’s new and the client isn’t sure how they want it to be yet, meanwhile we can’t let the release slide. I commented to one of the developers one day that it’s too bad we can’t do Agile for this one report and Waterfall for the rest of the release.

9

This is so true. In my experience, informal “Agile” was what was going on behind the scenes of every successful Waterfall project long before it had a name. Everyone had to work to express progress updates into some variant of a waterfall framework for reporting to project management. When I first heard of agile, my first thought was “Oh, how clever, they gave a buzzwordy name to what we all do already. Now the management types will be happy that there’s a named formal methodology being applied, and we can stop wasting all of that time on useless management conformance bullshit.”

10

There is Agile-like development, and the Agile the religion. We all used the Agile-like methods where suitable, but the emergence of the cult produced an emphasis on buzzwords and mindless application of technique. Also, the term Waterfall has been applied to anything that is not Agile, and I don’t ever recall anyone saying “Let’s use Waterfall development for this project”, people worked out what was feasible and practical, but all too often the reasoning was too cryptic for management to understand, when it wasn’t downright faulty.

One more reason Agile is popular is that it make software development resemble a video game which helps hold off burnout for the modern code monkey.

11

Programmers who think that they should stop having meetings and just program…
Who’d have thunk it. :slight_smile: Waterfall wasn’t know for being more efficient in that regard.

There is a commercial-membership organisation that has collected data on software projects, but you have to pay to see it.

If you don’t want to pay for it —
https://www.infoq.com/articles/project-metrics/. Of course anybody who has statistics showing that agile is more efficient is going to be an agile supporter, right? So you won’t find ‘independent’ statistics for free.

That said, who believes any of this stuff anyway? When major projects fail, it’s still because the requirements weren’t nailed down, the client kept changing the requirements, and the contractor kept writing software and billing.

12

I’ve worked in both the waterfall and agile eras. Two things:

  1. Nobody does Agile right, or even the same. Between me, my family, and my friends, I’ve heard about five different agile environments. All of them were different, and none of them fully followed the Agile rules. So just being Agile is no guarantee of a given workplace’s policies being good, or even functional, because it’s not a specific guarantee of what you’re getting.

  2. Waterfall is just Agile with a single sprint’s work stretched out to be the entire development cycle. So yeah, it’s basically impossible for it to be better than Agile, all things being equal. You could come up with a terrible Agile workspace that’s worse than a wonderful waterfall one, but it would require the Agile managers and policies to be substantially worse in various other ways than the waterfall ones.

13

IMHO, there is no such thing as doing Agile “right” in the one true way. This is the difference between the religion and actually doing things. The idea that there is a “true” Agile is something for the incompetent obsessive compulsives, and those that make money writing books and giving courses.

Everybody doing it differently is a strength. No doubt there is a room for everyone to improve, but in some sort of magical world where everyone did it exactly as this week’s version of the Agile Truth demanded, there would be less productivity, not more.

14

Let’s talk about the ‘bad old days’ of waterfall and the attendant dysfunction that came with it.

The first problem with waterfall is the conceit that a bunch of smart architects can spend a long time figuring out everything needed to build a system, get all the requirements correct, and then hand over reams of documentation to project managers, who then break it down into modules each team would build from the shared documentation, then all the teams would eventually merge their code, build, test and ship.

The reality: Complex designed architectures never survive contact with the real world. Requirements are never correct right out of the gate. So within a short period of time, all that design documentation would be horribly out of date. And if the requirements are wrong, that whole year of design may have been for nothing. Letting teams go off for weeks or months before integrating their code was a recipe for disaster at integration time. And of course, in internet time a long development cycle can see a project be obsolete before it ships. It was possible to think you were ‘almost finished’, only to find so many bugs and other issues when integrating that the project schedule could get blown completely to hell.

I once worked on a project where integration and testing were supposed to take two months, but attempts at integration uncovered so many issues it took a year and a half and a redesign of the architecture to fix them. Integration time is the second- worst time to find bugs and performance problems - the worst being when the customer finds them.

So agile says build only what you need right now, constantly integrate and test, design as you go when possible, design your code for easy refactoring, and then get the software out to the customer fast, find out what they don’t like, and iterate.

One of the lessons of Waterfall is that when projects get to a certain level of complexity, top-down design and control just doesn’t work. Better to do a bit at a time, test it against the real world, and refactor/build some more.

Of course, none of these ideas are unique to Agile. And some things about Agile I really dislike, but the increasingly interdependent, distributed, fast-changing and complex world of modern software is not generally compatible with waterfall or centralized, top-down planning and control of large multi-year projects.

15

I’ve posted my thoughts Agile before: basically it combines the worst parts of pseudoscience, astrology, and religion and producing evidence that it is beneficial in any way involves Trumpian levels of cherry-picking and delusion. Agile exists only to give agile consultants a job, and the sooner it joins six-sigma, ISO-whatever thousand, Xtreme programming, read sea/blue sea, and all of it’s other business-fad ilk on the trashheap of history, the better. (Come for the kool-aid, stay for the No True Scotsman statements that if agile doesn’t work for you, your company, or anybody you know…then you’re doing it wrong.)

But if I had to pick one thing that drives me the most nuts about it? The freakin’ excluded middle belief of agile fetishists everywhere that anything not agile is waterfall. There are hundreds of lifecycle models–many with actual evidence of effectiveness–that are neither agile nor waterfall, and the focus on these two extremes is of detriment to our entire profession.

16

All I can say is that my experience with Agile is nothing like yours. We have had significantly better measured results since moving to Agile from waterfall. While it’s certainly possible to implement Agile is an extremely bad way, that is true of any methodology, there are tangible benefits to be had.

No, it’s not for everyone, but there are only a few constraints that make Agile a non-starter. If you don’t want to use it there are plenty of other methodologies that can work. But each of them can fail spectacularly as well.

17

Just about any method can be turned into a cult and the answer for everything, along with putting people in or out of “the camp”. What concerns me is how something which can be very good becomes corrupted by people who don’t actually understand it and never practiced it correctly in the first place.

18

This. There are a lot of people who are evangelical about Agile who overstate its value and there are a lot of companies that describe what they do as “agile” because it sounds trendy and efficient. But they aren’t really running their projects in an agile manner.
There are some very basic tenets of Agile projects, such as a small, self organizing team, work being broken down into “epics”, “stories”, and “tasks” that then go through iterations of self-contained “sprints” of work, daily short “scrum” or “standup” meetings and so on. If you aren’t doing most of that, or you just have a daily team meeting and call it a “standup”, you aren’t really doing Agile in any meaningful way.

19

I’m trained in Six-Sigma. It’s a fine collection tools - for the types of thing it was designed for. In process control and other areas where processes are highly defined and have high quality metrics, Six Sigma tools can be of great benefit.

The problem is that business types took the tools designed hy engineers for specific engineering work and started applying them to everything. Running six-sigma projects against survey data or human relations makes no sense, but there’s a big market for ‘tools’ that businesspeople can use to show that they are ‘improving’ things. And there is huge money in training and consultancy.

That’s how useful tools and concepts get turned into a giant waste of everyone’s time. tools that work well in the specialized domain for which they were developed get popularized, then over-used in inappropriate ways because consultants and corporate trainers will always give you a good answer when you ask, “Why should my company give your consulting firm a million dollars to help us apply Six-Sigma in our management office?”

20

Given that Waterfall is older, wouldn’t it make more sense to say “Agile is just speeded-up Waterfall”?

Ask me what I think about people referring to “kanban” in software design or of “kanbanning quality assurance”. Well, if you want to improve your Spanish cussing, that is: my English simply isn’t wide enough.