In any discussion on this site or others about Agile, you will find a flurry of PM's rigorously defending it with the typical line of reasoning -
If you tried agile and it failed, it wasn't actually agile.
When you show how it was actually agile, you didn't do it right.
When you show you did it right - go back to argument 1. It's a really circular no true scotsman style of argument.
Obviously this "study" is not good or even really a study, but I think the general arguments it makes aren't tremendously out of line. I have been an IC on agile teams, an IC on more traditional teams that I guess would be called "waterfall," and I've been tasked with implementing a scrum process both as a team leader and as a PM in my career - I've personally never seen it work on Ops/Infrastructure teams. In fact, I'm convinced it can't. It's far too difficult to determine the scope of work, far too interrupt driven, far too difficult to measure actual velocity, way too easy for engineers and managers to bullshit the system.
All the arguments I see in favor of it over the years strike me as pretty dogmatic. The way I like to manage projects these days is a kind of kanban system with a task queue, and 1-2x a week brief cadence meetings to discuss priority/alignment and any blockers.
edit: should probably clarify I'm using agile == scrum here, which I know isn't technically correct, but that's how I've seen it implemented in 99% of cases so far in my career.
> The way I like to manage projects these days is a kind of kanban system with a task queue, and 1-2x a week brief cadence meetings to discuss priority/alignment and any blockers.
To me, distilled down to its core, agile is all about faster feedback loops and course corrections.
If you’re regularly getting good, actionable feedback on your work, and maintaining alignment, I think you’re living up the spirit of agile.
There are plenty of “agile” teams going through the motions, doing the ceremonies, but not actually reaping what the real benefit is supposed to be: frequent, actionable feedback that helps guide and align the next phase of work.
I agree with you completely and what you said brings to mind something I wrote on my blog a few days ago:
> I posit that if I showed the Agile Manifesto bullet points (without the title) to a group of people with cringe-worthy titles like Scrum Master, Agile Delivery Manager, Agile Coach, or Head of Agile Delivery, and asked them “Is this agile?” almost all of them would say it isn’t. I can only imagine the effect that revealing the title and explaining that, actually, this really is the agile, would have on their Jira-addled brains.
>If you tried agile and it failed, it wasn't actually agile. When you show how it was actually agile, you didn't do it right. When you show you did it right - go back to argument 1. It's a really circular no true scotsman style of argument.
It'd be interested in seeing that argument in the wild. Mostly I see complaints like yours when people point out that an hour-long daily that the manager uses to harangue the developers isn't actually agile, and that is perfectly true. Or that a blame-assigning retro or measuring dev productivity using story points is not actually agile, which is at least true insofar that it clearly is forbidden in Scrum, and stupid in any case.
Though I find it interesting that you end with kanban -- an agile methodology. It seems you do like to use agile after all, just not scrum.
I agree, and I guess it should be clarified I'm mostly criticizing the "traditional" implementation of agile as I have seen it which is scrum with sprints, retrospectives, etc. I find it extraordinarily counterproductive, but obviously some have had success with it or it wouldn't be so widespread.
> The way I like to manage projects these days is a kind of kanban system with a task queue, and 1-2x a week brief cadence meetings to discuss priority/alignment and any blockers.
Sounds pretty agile to me.
While the "defenders" of agile might be employing No True Scotsman fallacies, it's detractors (which I personally seem quite a bit more numerous on HN) are often doing the same in reverse: refusing to define what "agile" actually means, and just throwing together a bunch of anecdotes and feelings about excessive meetings and estimates being misused to measure productivity.
> refusing to define what "agile" actually means, and just throwing together a bunch of anecdotes and feelings about excessive meetings and estiybeing misused to measure productivity.
I mean - this seems necessary when the agile manifesto is extremely vague and practitioners can't seem to agree on the One True Way to do agile - and in the absence of formal studies and analysis, what else is there but anecdotes?
If you tried agile and it failed, it wasn't actually agile. When you show how it was actually agile, you didn't do it right. When you show you did it right - go back to argument 1. It's a really circular no true scotsman style of argument.
Obviously this "study" is not good or even really a study, but I think the general arguments it makes aren't tremendously out of line. I have been an IC on agile teams, an IC on more traditional teams that I guess would be called "waterfall," and I've been tasked with implementing a scrum process both as a team leader and as a PM in my career - I've personally never seen it work on Ops/Infrastructure teams. In fact, I'm convinced it can't. It's far too difficult to determine the scope of work, far too interrupt driven, far too difficult to measure actual velocity, way too easy for engineers and managers to bullshit the system.
All the arguments I see in favor of it over the years strike me as pretty dogmatic. The way I like to manage projects these days is a kind of kanban system with a task queue, and 1-2x a week brief cadence meetings to discuss priority/alignment and any blockers.
edit: should probably clarify I'm using agile == scrum here, which I know isn't technically correct, but that's how I've seen it implemented in 99% of cases so far in my career.