Agile exists for the particular constraints of software development, where requirements are unknown, change is relatively cheap, and feedback loops are very tight. I wouldn't expect it to be appropriate to other domains.
The Agile Manifesto was largely a reaction against the blind application of process developed for civil engineering to software development, and the features you point to are real reasons that civil engineering process is a bad fit for most software development.
But the Manifesto doesn't specify process, it proposed priorities and objectives that should be considered for process that (changing only the words “working software” to whatever it is you want to produce) are fairly broadly applicable.
Of course, most “Agile” shops aren't Agile at all, they are improved over what the Manifesto reacted against only in the small way that the process that they blindly impose without applying the considerations of the Manifesto is a Frankenstein’s monster combination of things other people designed for some other team (probably not all the same team) working on some other problems (probably not the same problems) in some other part (probably not all the same part) of the software industry.
I disagree; I think those priorities are appropriate because of the unique situation of software development. Prioritising individuals and interactions over processes and tools makes sense because it is easy to adapt and modify software tools, and because software allows abstracting out any form of repetition without needing to make it a process. Prioritising working software over documentation makes sense because source code is understandable in itself to a much greater extent than physical artifacts. Etc.
No, it makes sense because the processes and tools don't work if they don't work with the individuals and their interactions, and that's true in much wider domain than software development (it's true of any highly skilled, or even more generally labor-supply-constrained, work, where you can't easily replace the workers with ones that fit the preferred process; it may be applicable even more broadly, since sense of ownership of process can be a morale and productivity booster), so the process and tools must be subordinated to the team rather than vice versa.
> Prioritising working software over documentation makes sense because source code is understandable in itself to a much greater extent than physical artifacts.
No, prioritizing the production objective over supporting artifacts makes sense because of the fundamental nature of an objective. That's just as true when the production objective is not software (doing so will result in different levels of documentation and other supporting artifacts for different production objectives, sure, and software may often have lower documentation needs than many other tasks, but the prioritization isn't about do less documentation, it's about “do only, but still.all of, the documentation that has utility outweighing cost in support of the production objective of working software”.)
This is backwards. Software enshrines the repetitive business process and (hopefully) automates it as much as possible. This is happening regardless of whether that business process was defined before the software was implemented.
> Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor.
Agile just means closing as many feedback feedback loops as you can as early as you can, and to preserve opportunities to course-correct for as long as you can. All this to keep the destructive effects of surprises (which are sure to catch you) as low as possible.
This is good engineering practice, plain and simple.
Maybe a bad example, but it's basically mandatory to include a manpage for a cli utility, but do you always include drag & drop for a file uploader?
1 - Is it a domain where "user story" means something? 2 - Is it a domain where you can iterate fast?
Usually for UI these two conditions are met. From my experience, when talking about big infrastructure projects, they aren't
All else equal, smaller or shorter feedback loops are better. And often shortening a feedback loop is worth considerable tradeoffs elsewhere.
It's certainly the case that being able to iterate fast may not be currently possible, but being able to do so, or even just being able to iterate faster should probably always be a priority (even if not the top one).
This all applies even to physical real-world infrastructure. I remember a story about a city somewhere (South America?) where the mayor (?) was able to shorten the feedback loop whereby roads were built or repaired. That seems like a good, even great, thing, even at somewhat considerable cost.
What kind of big infrastructure projects were you thinking of specifically?
We have an API that is used by external systems, those systems (and developers) are our "users".
It's vital to think of API consumers as users, because it avoids the "REST is CRUD" attitude by focussing on the business/system functions that are being expressed, which leads to focussing on the Nouns, not the verbs of the business.