As of 2018, are there any documented approaches to delivering software that are not classed as Agile?
Of these approaches, are any supported by or adopted by FTSE100, Fortune500 or flagship software companies?
Caveat: When using the term Agile software development I am referring to the widely accepted frameworks (Kanban, Scrum, XP etc).
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
There is considerable evidence to suggest that massive enterprise software installations including SAP and NASA reject most of the frameworks we class as Agile.
This is due to the scale of such deliveries requiring considerable amounts of up-front planning, even if the design is not finalized. The costs are traditionally extremely high and it is unlikely the system will work until the whole thing has been assembled although it might pass lots of testing suites and simulations.
Whilst Agile advocates might gnash their teeth at this, we need to separate tactical software-delivery patterns from the overall frameworks used for delivery.
So, someone might be working within a waterfall organization using some Agile patterns. Or, the organization might be largely Agile but one department has adopted some waterfall type planning despite being huge Agile advocates.
It becomes very hard to argue any organization is not doing Agile if they have adopted some or all of the patterns listed above in any phase of their delivery. As an aside, it should be being Agile not doing Agile but it is almost impossible to reverse the way the word Agile is being used. You are onto a loser with that argument.
There is a bridge between the traditional waterfall world and the Agile landscape; we call this technique Spiral Development. It can use waterfall type planning and discovery up front to provide the level of certainty required in dangerous installations but allows for rapid iteration once certain variables are known. Of course, like all things, even Spiral Development has it's purists and detractors and is plagued with its own bikeshedding debates.
Here is a peer-reviewed paper from NASA arguing for The Business Case for Spiral Development in Heavy-Lift Launch Vehicle Systems
The Spiral Development process is now being widely used for large Government program acquisitions and lends itself to the project described here. The main advantage of this concept is that it builds on existing capabilities and assets, as opposed to starting up a “new sheet” vehicle program from scratch. Spiral Development designs recombine existing assets in new configurations to function in extrapolated operating conditions.
SAP has published official guidance for Projecting Managing the delivery of an SAP installation (typically multiple years of work) via the weighty guidebook which outlines the 16 sequnential steps required for a successful SAP project.
However, there is also the officially supported Accelerated SAP (ASAP) which can be viewed at the SAP Blog. You can find a nice overview on SlideShare.
There is also detailed guidance for individual SAP components such as the Hana in-Memory Databse. You can find those project management guidelines here.
Like all things Project related, you can find examples and refutations galore. SpaceX have successfully challenged the incumbent NASA delivery timelines by aggressively adopting more Agile methods for prototyping, manufacturing and testing of components; however they, like Tesla, remain the exception to the rule for lots of reasons.
If you are interested in how SpaceX are leveraging Agile frameworks then I would suggest a critical reading of Elon Musk: How the Billionaire CEO of SpaceX and Tesla is Shaping our Future. Ignoring the title, the book has huge amounts of Agile and delivery related insights from the engineering teams. FOr instance, the first Tesla MVP was created in an Excel document before it went anywhere else.
As I noted above, this seems largely opinion-based. The only way I can think of to possibly have an objective viewpoint on "Is Agile more efficient than Traditional?" is to look at statistics.
Luckily, we have the CHAOS Report by the Standish Group for that. Going by those numbers...
Yes. Traditional is, on average, less efficient.
Note, however, that that only applies to the average. Situational modifiers must also be taken into account.
Agile or non-Agile: As per my opinion the project type derives it, for example Scrum meeting- our project is on going development project with 5 to 10 people then agile scrum meeting is very good, if same is with more then 100 people team then it becomes bit difficult; if our team with 4 members and handles 4 different tools then everyday meeting might not useful etc. so we need to analyze, then adopt and evolve.
