RAD as a term predates Agile as a term by about ten years, but it isn’t really a “parent” of Agile. Both were created as reactions to perceived shortcomings with traditional software development management techniques. However, RAD is a prescriptive method for writing software, using successive prototypes to elicit requirements and refine the application. Agile, in the originally introduced form, is a philosophical position describing the difference between traditional approaches and the values focused on by agile practitioners.

So no, agile software development is not a type of RAD; they address problems at different levels of abstraction.

I don’t think it is correct to categorize development methodologies in hiearchies. So no methodology is “under” or “above” any other. It is much more logical to think about common points of methodologies. Quite often, real-world application of methodology involves combination of many similar methodologies and it is up to managers to come up with working development model.

In case of RAD (which I’m not experienced with) vs. Agile it seems only commonality is iterative development. RAD seems to prefer rigid phases with specific goals and outputs. Agile is more about single development phase where everything happens. Also Agile develops software directly with possibility of features being removed instead of prototyping beforehand. (which might end up same as agile, because quite often prototypes are immediately integrated into working software, instead of doing it correctly once again)

Tl;dr

Agile shouldn’t be perceived as a defined method that can be compared to others in terms of its procedural content.

RAD tools

Reading this question today, my recollection of “RAD” in the mid-to-late 90s was that it was synonymous with certain tools like Delphi, Visual Basic, and FoxPro. My experience and recollection is Microsoft-centric, obviously.

The hallmark of these tools was a good integration of a modern programming language, an IDE, a drag-and-drop visual designer, an ample standard library, and (seemingly) a ruling idea that as little as one person working alone could hope to master and harness these facilities to assemble business-specific GUI applications.

This contrasted with development in say C, where everything had to be assembled from lower-level elements (even the string type).

Agile “Methods”

I’m actually surprised to hear that “RAD” refers to an articulated development method. I wonder to what extent this was widely known in the 90s – it’s possible that the book/author referred to in the question was relatively obscure at the time, whereas “RAD tools” weren’t.

It’s important also to remember that Agile isn’t an invention (or even a coherent and widely-agreed method), and certainly the familiar names in Agile advocacy were not originators of the ideas.

The Agile method is often defined in opposition to its nemesis Waterfall, and for simplicity’s sake writers may often make it appear that the computer world started with Waterfall, that there is a binary distinction between the two methods, and then through the 90s there was an enlightened transition to Agile.

In reality, the thinking and approaches stereotyped in the “Agile method” have always existed, and is characteristic of individuals or small teams of development staff who are untrained in any method.

Waterfall is actually the later development, driven by two forces, and the deficiency of Agile in coping with them, as follows.

Firstly, the need to yoke ever-larger teams together on vastly more complicated projects – you can’t just keep iterating the Titanic or the Second World War, and neither can be handled by just a couple of guys with welding equipment.

Secondly, a constant attempt by management to proceduralise and divide the roles of analysts and developers, in the same fashion as analysts and developers themselves proceduralise, divide, and computerise other roles in a business.

The expression of these forces is the same: more planning, more procedures. But the resulting rigidity and mindlessness eventually becomes the problem rather than the solution, as the production line turns out computerised Spruce Gooses instead of Antonovs, or just produces the deafening racket of work – grinding, hammering, breathless workers scurrying around urgently – but nothing is ever ready to leave the factory door.

The backlash to this dysfunctional degree of Waterfall-ification is then “more Agile”, which either means a curtailment of the scale of the project (effectively forcing the business to accept something smaller or simpler, which it is actually capable of producing), or the reintroduction of more experienced and capable workers who are capable of grappling with a project of the relevant size and who have the power to impose their own decisions (and marginalisation of approaches which involve drones blindly following procedures and methods).

Conclusion

In my view, the Agile “method” (in any sense of the word which means a defined procedure) either doesn’t exist, or if something by that name does exist then it’s actually more often a form of Waterfall, despite its own claims.

Proponents of Agile, like (off the top of my head…) Fowler, do not really describe a procedural method by which they actually develop. Instead they really describe what they are against. They are against planning (at least anything of a nature that binds them), and they are against getting it right first time (demanding the right to have as many goes as necessary to get it right).

They have good reason for taking that position, but they are perhaps intelligent enough to know that describing their agenda so baldly would have gone down like a lead balloon with their employers. They say just enough to cause the constraints to be released, without being too blatant about what the release of those constraints means in plain language – no guarantees, and no accountability.

The guarantees and accountabilities offered by Agile practitioners – such as for small incremental deliveries – are often trivial and of no value to a business. Businesses usually need a transactional guarantee that all increments will be successful, or else none of them are worthwhile and the project is cancelled.

A carmaker wouldn’t accept a new design where only the wheels are guaranteed but the engine isn’t, nor a horse-buyer accept guarantees on just two of the horse’s legs – the value exists in the whole integration, and without the integration no component is valuable enough alone to justify itself.

But you have to be a technical expert to appreciate that, and if you are that expert, then you’re within the in-group who know there is no alternative way.

The methods by which Agile practitioners actually do work together probably changes dynamically and are subject to variation, and involves crucial internal cognitive activity whose workings they are not in a position to articulate as written methods. Their real agenda is to ensure their conditions of work, and the organisation of their work, are such as to allow that cognitive activity to actually occur and for any methods they work by to be altered quickly at their own behest. It’s a call for an absence of method, other than one which they alone determine as they go.

There is probably much literature describing what software developers do in terms of their external behaviours or the artefacts they produce (like code), but little examination of what is going on inside their heads or being absorbed from their environment, as a pre-requisite to the behaviours and artefacts they produce.

I would suggest rather than trying to enumerate many “methods”, and categorise them as Agile or non-Agile, that the situation be seen as something like a tension between two stereotypical styles of development along the lines described above.

• Agile methodology is oriented to build applications in an iterative mode with a fast pace of delivery or demonstration to stakeholders, Agile methodology requires to suit the development process for a concrete project. The main idea is to split a project into small iterations for small teams, where each interaction is a small list of user stories, which can be realized during 2-3 weeks, including testing and delivery. It emphasizes close collaboration between engineers, stakeholders, and domain specialists to define user stories and even UML flowcharts to demonstrate WHAT must be on output. Minimal functional changes are supposed. Then development, testing, and delivery of a product started and performed for feedback.
  The Agile methodology encourages autonomous teams, which decide how to perform the development process. It does not declare any requirements to design and engineering norms, especially SOLID, DRY, or technical constraints. It may be in conflict with the design and engineering norms of a company, which develops a number of projects, and has a technological stack, design, and engineering norms. Technical leadership of a company is not interested in a code being repeated n times, or a spectrum of frameworks of the same type will be used. Thus Agile does not negate repeating development of the same blocks by a number of teams, for example. It is absolutely clear, that in real life, Agile teams should work under technical supervision and constraints. In this case, Agile is very effective. In a nutshell, Agile teams must be coordinated and have a common platform (that is out of official Agile rules).
• RAD methodology is more structured from the engineering point of view and includes business modeling, data modeling, process (flow) modeling, creating the application, and testing turnover. RAD defines the development cycle as shorter than usual and gives more attention to the reusing blocks of code.
  RAD phases are oriented to fast iterative prototyping of products when Agile iteratively delivers the realization(!) of user stories. Unlike Agile, RAD is more object-oriented and is a good choice for modular systems (that is remarked by a number of authors). RAD is marked as encouraging the reusability of components, which is very important to organize development on a company scale. RAD is applicable more for large projects than for smaller ones. RAD is not as friendly as Agile for progress monitoring.

But…

• RAD also is targeted to closed prototypes, and scalability evolves to be a challenge.
• Despite attention to OOP and code reusability, RAD in my mind is associated more with monolith architecture, than with SOA and microservices ones, and Agile is vice-verse accordingly. However, for sure, RAD can be applied to both of the architectural modes when initially planned for them. But in this case, the whole RAD frame should be divided into Agile-like boxes per service and, maybe infrastructure box.
• In a nutshell, despite many similarities, the methodologies are different in real practice.

However, they can be combined for large systems.