Such work is often found in the public sector, and you can tell that a concept has already been mainstream for a while when the government starts pushing it as the latest thing. As usual, the latest thing is also being pushed as the silver bullet that will make government programs super-efficient. The truth is that government projects don't fail because of process - they'll get enough money thrown at them to overcome a whole lot of process inefficiency. They fail because they are - well, complex and very large scale to the point that nobody really understands the whole solution to the point of being able to assess the consequences of a butterfly wing flapping on one side of the effort.
Most of the heavy-duty engineering processes are intended to mitigate the risks posed by those conditions by at least trying to document what is going on and making sure that everyone involved has a chance to put in their two cents as to potential impacts when an change is contemplated. But it takes time (and money) to write all this down, time to read and understand it, and time to comprehend the implications of proposed changes to it.
Discussions of "Agile at Scale" have been going on for several years, but one leading candidate approach to achieving that goal is the SAFe method (http://www.scaledagileframework.com/). I have not studied it enough yet to say that it provides all the meat that is really needed (for instance, a comparison with DSMD would be useful), but it has some solid case studies and it is certainly attracting the right sort of attention. A lot of that may be due to the brilliant acronym for dealing with government offices because it addresses precisely the number one concern: can a system developed via an Agile process be considered "safe"? "Safe" having many meanings:
- Will it grow to support tens of thousands or millions of transactions or users?
- Can we trust it in life-or-death situations (military, air traffic, fire or police dispatching, etc.)?
- Will it be proof against determined cyber-attack?
- Will we be able to use it and repair it many years from now when the current leading-edge technology is long obsolete?
And of course the most important question: "Will this go well enough to delivery that I won't be embarrassed by having championed doing something different?"
There is no way that a development project can deliver quickly if every aspect of the surrounding infrastructure (both physical and process) has to be debated at length is not re-invented from scratch for each project. My own interest in the topic was stirred through being unable in several different agencies to get any pragmatic or pro-active guidance from enterprise architecture or from IT security; even waterfall projects would complete half their development work in the time it would take to get a review of the initial concept.
That simply won't work for an Agile approach. The enterprise needs to make key decisions at a high enough level that they can be defined and decided (even if they have to be changed later) so that the development teams can get on with providing those useful deliveries. And the enterprise needs to be protected from short-cuts taken by fast-moving but tunnel-visioned project teams.
My favorite quote in the SAFe materials is the idea that Enterprise Architecture must be treated as a first-class citizen. To that I would add, "and enterprise architecture needs to earn its citizenship", by providing the patterns and guidance that project teams need - or agreeing to work with the front-running project to tweak its requirements to permit the adoption of whatever the team comes up with as the enterprise standard.
I don't know that SAFe really does address all the legitimate concerns of an enterprise, or whether it really only does so using the same processes that would also be employed by any competent organization even if it were using the waterfall life-cycle model.