I feel that most people don't understand that larger corporations don't adopt Agile to benefit product teams, but to add a layer of measurability to the process that is only useful for middle and upper management to establish and track OKRs.

Thus Agile may not be a failed idea, but it arguably fails at the implementation.

Agile apologists seem to be disconnected from this reality.

How many people do you think have fallen into this trap?

It seems that every single company out there are trying agile, and almost all of them are doing it wrong. I have yet to be part of an organization that does agile right, or at least the way it was promised to us from the beginning.

Perhaps the whole idea is just another utopia that will never reach its full potential.

I see this over and over again with agile, scrum, basically any framework. If there is ever a failure of the system, it’s never agile or scrum’s fault. You’re just doing it wrong. But also apparently there is no right way to do it either, so if you can’t figure it out that sucks and is also your fault.

I think my main criticisms are 1) that any specific component from agile is consistent in the success of teams who do it and 2) that it’s reproducible across teams. You may be doing something that works well. You may call it agile. It may work. But it’s like saying I’ve had so much success driving because I use Michelin tires. Sure, it’s a core component of the system, but I if I hold all other context the same and use something else, I’m more than likely going to be successful despite it.

If you have a high performing team, it doesn’t matter if you use agile or not. You’re going to find success. If your team is not high performing, it also doesn’t matter, you’re going to be worse off than a high performing one, regardless if you use agile.

I agree. Agile seems to be widely successful, both in practical terms (it's widespread and the dominant methodology in the industry) and in formal terms (it's specified as requirements in institutional organizations in place of waterfall).

Claiming that Agile failed has vibes of Yogi Berra's "nobody goes there anymore, it's too crowded."

Sure, any true Scotsman can see that.

What reason do we have to believe that Agile is so great, if (as you point out) most business aren't actually doing Agile?

No, it is not. It is definitely not for developers benefit. It is sorta kinda good for junior developers I think, but mostly it is for management. It effectively ignores human psychology, treats developers as machines and individual developer is mostly powerless with no responsibility, no accountability and zero autonomy. It effectively amounts to large dose of micromanagement.

It may sound weird given agile rhetoric and some its processes are really good and improvement, but in it is does creates pleasant work environment in practice.

Well, this comes around to a perennial debate about agile methodologies in general. Yes, an argument can be made that the fault isn't the methodology, but the poor implementation of the methodology.

However, the case can also be made that if a methodology is rarely implemented correctly, that's because there's something wrong with the methodology.

Most companies (every single company I've worked for, anyway) implement an agile methodology purely to crank up production speed. No other consideration enters into it.

It was never appropriate. It was created by consultants to sell consulting services. In that way, it's a huge success. As a practical development methodology, it's always been a disaster.

I totally can, and will. It's on them if they popularized slogans that can be too-easily misunderstood. That's meant that agile, in several respects, has been an exercise of throwing the baby out with the bathwater.

> Blame the management that adopted the agile manifesto as "do all the exact same things we used to do that didn't work, but call it 'agile'".

That's clearly not what my employer did.

My main gripe is most organizations I've worked in were usually in the transition between waterfall and some form of agile. The #1 issue was the people who sold the corporate execs on agile being faster and more efficient than waterfall have set unrealistic expectations as to deadlines and release dates.

Suddenly taking 12 months to build that app you were thinking of developing via waterfall, just got cut in half because everybody thought agile is so much faster, when in reality, it really isn't that much faster at all - just a different methodology, which a lot of people forget.

I have yet to work at a place that has released anything any faster than how it could be done using traditional waterfall methodology.

My last point about agile is that I've found it doesn't scale well. When I used agile in smaller teams (10-15 people, 3-5 devs) it was very effective. As you scale up (50+ people, 15+ devs) things slow down, inefficiencies are created because instead of several devs working on larger chunks, you have several dozen devs working on really small parts that get coded completely differently, then sometimes don't work together and it causes multiple iterations of design that wouldn't happen in waterfall. There is an advantage with us devs seeing the larger picture and coding to that, instead of this little component that gets coded 10 different ways.

I think it has a lot to do with how good estimates can be, and how much can be shared between the members of the team. The extreme situation where the tasks are all boring/predictable and everyone in the team can do everything probably works well with Agile (or any estimation-based religion, I suppose).

The problem is that in many situations, many tasks are not very predictable (because they involve novelty, risk, exploration, challenge), and not everyone is capable of doing everything. In that case the estimates are a big joke, and Agile is just bullshit.

This is the problem. This stuff gets cargo culted from one fad to another. I'm curious to see what comes after Agile.

Oh wait! I actually have the answer. It's called GROWS: https://toolshed.com/2015/05/the-failure-of-agile.html

This isn't true though.

No, it's the opposite! Agile is bad news for software developers:

1) hardware developers will insist on having predetermined requirements and will stick to them; at most, they'll throw the mantra: "Software will fix it!";

2) software users will use Agile as an excuse to avoid at all cost deciding what they want and limit themselves to bikeshedding after the release;

3) those idiot project leaders who manage by ticking cases on an Excel printout will explain you how Agile is a wonderful panacea which will solve all your problems: you will "just" have to write the code and you'll have no excuse to miss the arbitrarily imposed deadline.

No no no, not at all! Agile is for those who ponder about developing software, but not for those who do the job!

The points made in the Agile Manifesto having me nodding my head in agreement more often than not. But the implementations, like Scrum, are another matter entirely. It has become a management methodology, further and further removed from the developers. And that comes complete with all of the trappings you'd expect: process for the sake of process, empty metrics (like "velocity") that can be passed up the management chain, and so on.

Agile was created to beat exactly those things that you are mentioning. Then Agile became big, enterprise became aware of it and smothered it with their rituals, processes and bureaucracy. And now we're back where we started again.

I don’t necessarily agree that things were better - but “agile” was supposed to fix the things that were bad back then but has since somehow managed to morph into exactly the same problems that it was originally purported to solve.

s/People/Managers/

In many of the cases I have experienced, agile breaks down into an excuse to not plan ("Requirements just slow things down!"), and the elements of it that would drive success are ignored.

So often business leaders just want shit done, and when the technical types warn about reliability or technical debt, there is a lot handwaving. Thus short attention spans see agile as a way to justify shortcuts. When this happens the result can be worse than a poorly executed waterfall model.

Agile works when all the proper elements are used, just like any other endeavor, and it fails for the same contrary reasons. Developers become frustrated when yet another path to accomplishment is blocked.

Disclaimer - Am technical manager. Have watched business peers shortcut to failure. Have fought the battles and lost. Frustration apparent.

I recently started a role running an Engineering org at a startup. The first two questions I asked everyone are why are they doing scrum and what do they want out of the engineering process. Answers to the first question were all over the map, and answers to the second were almost identical.