This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy.
Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier.
Standups can take different shapes, the 'V' in MVP differs wildly by industries, and the cycle time that a product needs to have can be determined by external market forces (e.g. the school year).
Agile is meant to adapt to the characteristics of the business it is used in, rather than to be specifically some universal way of everyone trying to everything in the same way.
> This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy.
Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless.
I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot planning, adaption to change is very slow and cumbersome, velocity charts serving management more than the team itself, tickets that represent multiple stories at once, management adding tickets(i.e. more story points) without removing less important ones, gigantic release cycles, etc.
For me the "minimal set" of rules that can still be called Agile is a mechanism for measurement, and a retrospective. You use the retrospective to perturb the process, and you use the measurement to decide whether that perturbation was a success or a failure.
That's it - old school cybernetics. If you used feedback loops to iterate towards a successful process, you're doing Agile. If there are parts of the process that are off-limits to you (eg management insists on doorstepping your standups) then you're not doing Agile.
Of course, we "prime the pump" somewhat by throwing in a bunch of extra rules at the beginning that we know from experience are likely to work, but I think that Agile, done right, has a lot in common with Nomic.
Of course not, and that's really the point. Plenty of organizations will tell you they are Agile when they aren't truly following the Agile manifesto, but that's not going to stop the evangelicals from eating the horse manure("our team has standups 'n stuff") that reassures them that their belief system works.
Everyone's bullshitting each other, and I wish it would stop, but I know it won't. Not everyone can be a "true scotsman".
I'm not even defending Agile or other related methodologies like Scrum. They have some good ideas, but I haven't seen quantifiable evidence that they are good for businesses. Many of the ideas are good for software engineers, but that doesn't mean they are actually good for teams or companies. Even then, I've management use "responding to change over following a plan" as a license to make more arbitrary changes to what engineers will work on in a given day because they can take it. Planning days and point systems be damned.
Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier.
Standups can take different shapes, the 'V' in MVP differs wildly by industries, and the cycle time that a product needs to have can be determined by external market forces (e.g. the school year).
Agile is meant to adapt to the characteristics of the business it is used in, rather than to be specifically some universal way of everyone trying to everything in the same way.