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.
