I'm far from an agile-ista, but.

> The alternative to Agile is Software Engineering, where you do important things like assess your requirements and capabilities, identify how to validate those requirements are functioning properly and support your business requirements, promote testing and QA to a first-class citizen. Most importantly to always have functioning software that is reasonably demonstrated to be correct. That way you release with confidence, people take pride in their work, and the product, team, and schedule all become quite pleasant.

That just sounds like Agile...

Like, legit just sounds like the Agile Manifesto.

Honestly, if anything is likely to be the issue. It's Scrum. Scrum has the cargo cult. Agile just seems to get drug through the mud by everyone that implements some authoritarian variant of Scrum.

But again, not exactly a proponent of Agile here anyway.

    That just sounds like Agile...

Agreed!

    It's Scrum. Scrum has the cargo cult.

What do you see as the problem: Scrum itself, or the cargo cult of folks who do it badly?

Scrum done properly is very low overhead, at least from a developer's standpoint.

At my old job we did fairly strict Scrum and I estimated that it consumed only about 4 (so, 10% of a theoretical 40-hour week) of my hours per week.

I feel that is very low overhead. I don't know of a lot of development scenarios where you don't need to spend at least 10% of your time communicating with management.

I mean, people really have to think about what their actual dream scenario is. Some kind of world where they only have to spend 1% of their time interacting with management? 0%? These people need to get real. Management/stakeholders exist and you are going to need to communicate with them.

I have had jobs where upwards of 50% of my time was spent in seemingly endless meetings, plus "drive-by shootings" where management randomly stopped by and wanted to see progress and dump new shit onto my plate. Scrum is not perfect, but for most workplaces would be an upgrade.

    Agile just seems to get drug through the mud by 
    everyone that implements some authoritarian variant 
    of Scrum.

I feel it is close to the opposite.

"Agile" is a nebulous term that has lost nearly all practical meaning. Bad management does some weird, loose version of "agile" (usually with some trappings of Scrum) and gives both Scrum and "agile" bad names.

> What do you see as the problem: Scrum itself, or the cargo cult of folks who do it badly?

Scrum itself. Sorry, but when you create a list of ScrumButs and indirectly deride everyone for not being able to take "Full Advantage of Scrum" so that your purists can go out and attack it at full force, yeah, that might be the problem.

The idea that different organizations might actually benefit from not adopting a methodology wholesale isn't that farfetched.

You could argue that's part of the cargo cult, I'd agree to some extent. But it becomes difficult to separate the 2 when you're literally derided for not following it to the religious T.

I guess you have had different experiences than me. We did fairly strict Scrum at my old job for a few years.

I never felt "attacked at full force" or "derided" even though we didn't follow Scrum to a T.

Never saw that "ScrumButs" thing until I Googled it just now.

I still don't feel attacked or derided. I've talked to dozens and dozens of developers over the years with various feelings on Scrum and never experienced those feelings.

But, you do, and it is 2020 so all feelings are valid. I'm sorry you've had bad experiences. People should not be jerks to you about Scrum or anything at all.

The Agile you describe is neither the agile I practice nor the one advocated for by sophisticated software development organizations who understand productivity and effectiveness.

The things you describe as “software engineering” are part of any reasonable agile implementation.

Many orgs have done a poor job of implementing agile practices, but throwing the baby out with the bath water seems like a great way to continue repeating the mistakes of those that came before us.

Because, as someone observed in an earlier thread, agile has become a management practice instead of an engineering practice.

Engineering-first culture is almost always the wrong idea. It's product-first or nothing. The entire point of agile is prioritization based on business value. Everything always takes longer than estimated regardless of how you manage your project. That's actually a core tenet of agile and one that stakeholders (and budget holders) have the hardest time accepting. Having worked in this industry before agile was prevalent, I can assure you it was never better than this in the past. QA as first-class is a pretty core principle as well. The point of things like Scrum is meant to be visibility and alignment rather than prediction, but impatient people are guaranteed to ruin your life no matter what.

I too have been around before Agile took off, and I too recall how dysfunctional it was before that. I do, however, attribute the positive development to better tooling: Git (and GitHub) instead of SVN/CVS/Nothing, Cloud computing and containerization rather than dusty-server-in-the-corner-with-curmudgeonly-sysadmin, popularity of safer programming languages rather than dominance of C/C++/early-Java, StackOverflow and full ecosystem of answers to every question you might have, etc.

In general, my experience has been that the most wildly successful projects I have worked on tended to involve the least amount of stress, most amount of personal/professional development, and best relationship with peers. The least successful ones tend to be stressful, frustrating, and destructive. The common denominator is that the most successful ones rely on experience, intuition, and professionalism of your staff, the least successful ones submit to tyranny of agile - and when agile isn't delivering success, to double down on it and all those awful "issues".

I'm sure I don't have the wealth of experience you fine people have. But I've been in enough teams and companies to see that whatever methodology is being embraced, it seemed like the X factor was always what kind of people are practicing it. If someone likes always being in meetings, you're going to be in a lot of meetings. If you're on a team with smart people you enjoy working with, with open lines of communication, then the rest just seems to fall into place as long as everyone is doing their job.

Then again I never worked for Hooli.

Yeah, this is actually my same observation. High-functioning teams were naturally agile even before it was called that. Defining and formalizing agile practices is a way for people who've never experienced it to know what success looks like.

Things were even worse before agile, or at least as bad. The alternative you describe doesn't exist at scale, nor can it, because the same corporate culture that made agile suck and waterfall suck will make every other process approach suck in much the same way. The most that is possible are sporadic individual exceptions.

Without turning this into a No True Scotsman, I don't think the problem is Agile. I think the problem is that most companies have no idea what Agile is, and they just implement a subset of its ceremonies in a highly malignant way and pat themselves on the back.

If you have 10 hours a week of mandatory meetings and are asked to make projections about features and deadlines 6-12-18 months into the future, you are not Agile.