Not sure if this is supposed to be sarcasm, but only from the direction of "lock the developers in a room and look what surfaces after half a year".

Picking what to work on for [time] without external additions is a pretty good improvement over getting new assignments daily.

Or maybe you're just doing it wrong, I'm not here to defend anything codified in Agile, I'm just saying that elements of what most people call scrum has been the best I've seen in over 20 years. Maybe I just missed the days of locking yourself in your single office.

I suspect it's more about the way many people experience "scrum".

The basic building blocks can actually work great, it's often how they are executed and how many places go very much micromanagement wrapped in agile's skin while also instituting lots and lots of meetings - total opposite of what both Agile and XP advocated.

Some of the best agile/scrum I ever worked under came from "Scrum master" who explicitly stated that one of his jobs was to see what approaches work and change what doesn't work for the team.

> see what approaches work and change what doesn't work for the team.

unfortunately from my experience, "what works" can vary wildly from person to person. One person wants to be given a task and left alone to understand it and write some throwaway code as part of the understanding process. another person wants to bikeshed it to death first before letting you touch any code. so the first person has to hide the work on the prototype and pretend to come up with the insights for the first time during the bikeshedding session.

Which is why their job was to figure out a model for the team. This specific team.

Sometimes you can compromise, sometimes you can figure a proper allocation of resources, sometimes you can part amicably instead of murderously.

Scrum is a bit too proscriptive to allow for that. One of the things that "works" is killing sprints, for instance, but scrum isn't scrum without a sprint.

> "Scrum master" who explicitly stated that one of his jobs was to see what approaches work and change what doesn't work for the team.

Ironically, if I were to give one-sentence summary of what the idea behind Agile is, it would be exactly that: "see what approaches work and change what doesn't work for the team". Running through that feedback loop rapidly is the whole point of Agile, and the one thing that actually distinguishes it from typical management methods at the time (as opposed to silly comparisons with "waterfall" boogeyman that never even existed).

Everything else is process - the thing that's supposed to be sculpted. Focusing on that is committing the sin explicitly called out in the Manifesto - putting process over people.

> of what most people call scrum has been the best I've seen in over 20 years

If you're phrasing it like that I've been doing agile since way before anyone invented the term.

But that's only 10% of cult agile, which is what is practiced generally.

Agile seems to be used to refer both to a form of cult and a form of software development interchangeably and I think it's too late to fix that.

I've found that agile works if velocity is static and used for estimates ONLY and is flat over time. Once velocity is measured as an output metric and there is an attempt to improve it, you've just left agile and are now in a morass.

In the end, very simple Kanban is the way to go if your org can handle it.

It’s worth pointing out that the “Agile” philosophy is literally 4-5 lines long:

> Individuals and interactions over processes and tools

> Working software over comprehensive documentation

> Customer collaboration over contract negotiation

> Responding to change over following a plan

> That is, while there is value in the items on the right, we value the items on the left more.

The thing I think everyone has grown to universally despise is the cargo cult of “Scrum” that got bolted onto that.

That's a bit misleading. agilemanifesto.org also hosts a (still short, but way more concrete) Twelve Principles of Agile Software: https://agilemanifesto.org/principles.html

(Also worth noting that scrum and most of the best known agile methodologies predate the manifesto; the manifesto was formed from guiding principles of those methodologies, not the other way around: https://agilemanifesto.org/history.html)

It's not Scrum. Scrum wasn't even the first. (I think it was XP.)

The problem is all the "Agile methodologies". Every single one.

(Also, notice that "Agile methodology" as an idea is already against the first principle there.)

Yes. As soon as you're conducting ritual ceremonies such as daily standups, you're no longer agile.

It is the pseudoscience of Taylorism and 'Scientific management', not the manifesto, which is really just a repackaged form of modern organization theory.

The DOD agile BS PDF covers most of it.

https://media.defense.gov/2018/oct/09/2002049591/-1/-1/0/dib...

Once the consultant forms start to monetize the GAO's agile assessment guide things should get better IMHO.

Unless that gets co-oped somehow, which is possible.

How GM screwed up on the NUMMI plant shows how it is a Taylorism problem if you want something outside of tech.

But even TOGAF and ITIL are adjusting because the feds will require it.

Taylor measured people loading pig iron into train cars, faked a lot of things and the BCG/McKinsey types packaged and solid it.

It has always been BS, is part of why the US manufacturing sector failed as well as why the USSR failed.

Pretty hard to kill but it needs to die.

The problem is that those are a really vague and metaphorical 4-5 lines so it's hard to argue against somebody projecting whatever the hell meaning they want on to it.

I'd argue that "agile" where I have done it and it worked well is at its core about tightening up OODA loops - with code (refactoring+tests+iterative improvements), with customer interaction (frequent interaction/experiment driven tests), with team organization (retros, adapting team processes).

Feedback loops are, however, not mentioned once in the philosophy and neither are any concrete examples of "agile" or "not agile".

Agile as a concept will stop being broken when people stop saying "to me, agile means X". Which will probably never happen - I suspect people will just stop talking about it one day and start using different terms for all the concrete steps that are sometimes filed under "agile" but which actually work.

How unsurprising, than, that every little town and village has their own folk religion built around those 4-5 sentences. No wonder this topic is a holy war.

Dailies have the social contract of "you get to talk to the developers every morning, so shut-up the rest of the day", what on theory should be really great.

The only problem is that all the problem people never take the hint, and the well-behaved people tend to take it to an extreme. So on practice it both doesn't get rid of the interruptions, and delay everybody's work due to the latency you need for avoiding interruptions.

People have complained to my boss when I've said the standup was designed to be as short as possible, maybe 10 minutes max, because it was done standing up. It's not called the sitdown. But ours can run over an hour. It's agonizing sitting there for an hour waiting to hear my name among the 99% of noise entirely irrelevant to me.

> It's agonizing sitting there for an hour waiting to hear my name among the 99% of noise entirely irrelevant to me.

More than once I've been asked discretely by my PM if everything is OK with me, because half an hour down a team meeting whose contents is "99% of noise entirely irrelevant to me", I'm too exhausted trying to control my movements to keep my body from telegraphing the fact I'm bored out of my mind. Turns out, to an outside party, I start looking like I haven't slept the night, or am about to get a stroke, or something.