It's all about getting a tighter feedback loop on smaller chunks of work. It's meant to deal with specification drift, scope drift, and people talking past one another about the customers' needs.

RAD can and is achieved without the dogma, process-heavy intrusion, and the dumbing down of Agile/Scrum/whatever.

I've been practicing RAD for nearly 30 years quite successfully. As an individual developer; a lead of a small team; and as the architect of a large team of teams; the practice is essentially the same:

1. Mock up the top level of the application to provide the application flow, leaving the next levels as apis to be fulfilled.

   The top level can then be demonstrated to the users, feedback taken and adjustments made whilst each of the apis at the next level are being implemented.

2. Each of the next level apis are treated in essentially the same way. They are initially mocked up in terms of their internal apis.

   Once they are mocked up and compile; they can be plugged into the top level. Which verifies they accept the inputs it wants to give; and returns (mocked) values of the type/order that it expects.

   As each of the apis moves from mocked to implemented; the previous level acts as the test suite for this level; and this level acts as the test suite for the previous level.

3. If a third or more levels are required; they are started as soon as the previous level has defined its requirements.

   Again, the lower levels are mocked up -- just taking and verifying inputs; and returning plausible values as outputs. Nothing more.

   And as soon as they are able to fulfill the interface to that limited level; they are plugged into the previous level.

The feedback loops between levels are short; change requirements feed down from the top as they happen; inconsistencies are detected immediately they arise; and are corrected immediately.

It works for any type of application; no matter how complex; or how large the overall team.

Individual teams are small, and only interface with those immediately above and below, so the typical humongous status meetings don't arise.

The design evolves as required and in parallel; loose coupled interfaces are enforced -- but fall out naturally; overnight integration builds tell everyone where things are and what needs immediate attention without all the extraneous process and paranoid navel inspection.