Dave Thomas, one of the original authors of the Agile Manifesto [1] wrote an article called "Time to Kill Agile" [2] a few years ago (which he subsequently re-titled "Agile is Dead"). He has some good insight on how Agile (the methodology) got to be something very different from what they intended. Originally they were trying to break away from a rigid methodology, not introduce a whole new one. Unfortunately, if you don't codify something into a set of rules, it's pretty hard to get people to follow it, and it wasn't long before "experts" were building formal processes out of it. I've never seen it work well, and the more ardent the adherents are, the worse it seems to get. I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress. In my experience the two most important aspects of moving a project along are simply communicating what needs to be done and recognizing effort.
> I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress.
This is spot on.
And the fact is, this has been known since at least 1980's (!)[0]. I am quite fond of using the version "culture trumps process", because it so well encapsulates the reality. (Also: hits directly against "The Process" ideology.)
It often feels like everyone and their dog within the industry are hell-bent on establishing a Good Development Process. But that's a false premise. You can't just introduce a designed process and expect it to magically fix things. Workflow is everything: motivated and talented people will go to lengths to get their actual work done, process be damned. The best thing you can do is to invest in good tooling and actively encourage sane development practices.
Get the workflow right, and process will follow. Crucially, as you said above, every company will need to find their own flavour.
> I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress.
Couldn't agree more. A development process is like your CI pipeline, there's no one solution for everyone, but there are common patterns you can choose from and build upon to make something that works for you. And it's something that you will want to assess and refine on a pretty constant basis.
I've worked on everything from high-integrity embedded systems to web applications over the years, and what worked for one would be catastrophic (both metaphorically and literally) for the other.
I've dealt with "agile experts" who appear to never have actually read the agile manifesto. For those "experts" is always about following the rules and process of their version of agile.
What gets presented by these "experts" is rarely anything like the original indent if not the anthesis.
"What do you think is the most important principle in the agile manifesto?" is one of my favorite interview questions. I'm yet to interview for a position as "agile developer" and have the interviewer know what the manifesto is.
It's more like a brand vs an idea. The word "Agile" was used (like that, capitalized) mostly as a way to designate adherence to a procedural cult (e.g. the Scrum cult) and usage of specific words looking like newspeak (Sprint, Stories, Epics).
The concept of agility, with the word taken as in its common word meaning, does not actually need all that bullshit. Well, neither does the general concept of being agile in the first place, but it is harder to distinguish from the now tainted one "Agile".
[1] http://agilemanifesto.org/
[2] https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html