So you’ve decided the Waterfall methodology isn’t for you.
We can’t blame you. Waterfall is great for building bridges but not so much for building software. Especially if you’re looking for tighter release cycles and more customer interaction.
People are telling you to check out Agile, but that’s not for you either. You want to build a range of prototypes, not commit to a single minimum viable product.
Rapid Application Development (RAD) might be worth checking out.
RAD is a time-tested model for the software development life cycle that focuses on quickly developing several prototypes, then reusing code and components to refine the product.
But how do you implement the RAD model on your team? This article will tell you everything you need to know.
What are the software development models?
In business — and software in particular — there are several dominant project models.
RAD and Agile are 2 of the best known, but there are also the Waterfall and Prototype models. Each one is slightly different, with its own distinct use cases.
If you pick the right model, your team can get many times more productive than it would have been otherwise.
Let’s examine each model in detail.
We’ll start with Waterfall since it’s the oldest model and the one that teams naturally default to if they don’t know any of the others.
The Waterfall model is a step-by-step approach. The design team starts by gathering user requirements, then designs a product that meets every user’s needs.
They hand the design to the engineering team, which builds the product. The QA team tests the product, the Marketing team advertises it, and then it gets released.
Waterfall is ideal for certain situations. If you’re building a house or an airplane, Waterfall is the only method that makes sense. But there’s a disadvantage: if the customer doesn’t like the final product, there’s not much they can do about it.
The other 3 models were designed by people who understood that software provided unique opportunities for end-users to help determine how products were developed.
They all emphasize short feedback cycles, but each has a different approach to solving Waterfall’s problems.
The Agile model grew out of the Agile Manifesto, published in 2001. In contrast to Waterfall’s demand for a complete product before shipping, Agile is built around shipping a minimum viable product, then improving it with each subsequent release cycle.
An Agile development team gets to see how their product performs in the real world before deciding what new features to add.
Then there’s the Prototype model. It’s ideal for teams that have to start development without knowing all the project requirements.
In Prototype, the team starts by building a single prototype of the final product. Then, working with stakeholders, they iterate the prototype until it’s a suitable foundation for the rest of the project.
The Rapid Application Development model is similar to the Prototype model, but with a twist: instead of one prototype, the team develops several prototypes in parallel. Each of these prototypes is then shared with the client, who gives feedback on all of them.
The big advantage of RAD is the ability to reuse code.If the stakeholders ask for changes to one prototype that match the features of another one, code from the second prototype can be recycled in the first, making for an incredibly quick development cycle.
The major disadvantage of RAD is that you need a lot of people working in parallel.
Building several prototypes at once takes a big staff. If you have the people power, though, it’s one of the best ways to get satisfied customers.
What is the difference between RAD and Agile?
First, they work at different levels.
Agile is a philosophy, arguing that the power of software to enable tighter release cycles makes Waterfall obsolete. It requires a framework — like Kanban or Scrum — to work properly.
RAD doesn’t make any philosophical claims. It focuses on the development level as opposed to the broad vision. In fact, by some definitions, RAD is a form of Agile framework.
Second, Agile focuses on features, while RAD is built around prototyping. An Agile team ships an MVP and works on improving it using client feedback. A RAD team works with the client from the very first step.
Finally, by virtue of being a philosophy instead of a framework, Agile is much less interested in stages than the RAD model. Most Agile frameworks use a single phase — such as Scrum’s famous sprint model — as the operational cadence for everything.
The RAD model, by contrast, works on a 4-phase approach. We’ll get into those in a minute.
Who should use each life cycle model?
Before moving on, take a look over this handy reference for which software development model might be best for your team.
- Use Waterfall if you’re building something other than software, that’s easy to plan out in advance.
- Use Prototype if your users don’t know exactly what they want yet.
- Use Agile if you don’t know who your users will be yet. Pair it with a framework like Scrum or Kanban.
- Use RAD if you have uncertain client requirements but a large number of developers who can build multiple prototypes in parallel.
What are the phases of RAD?
Rapid Application Development is typically broken into 4 phases, though lots of workplaces have their own interpretation.
Requirements planning
Building a product with RAD methodology always starts with requirement planning. In this phase, stakeholders meet to discuss the scope and objectives of the project.
Developers, clients, managers, and other members of the team might be involved here. They’ll ask questions like:
- What problem is this project trying to solve?
- Who are our clients? If we don’t have any yet, who is the target audience?
- What options do our target customers currently have for solving this problem?
- What does the product we’re developing need to do?
- What will success look like?
This phase is more focused on business goals than technology. It’s not the time to think about code and features; it’s about figuring out why you’re building this thing at all.
It’s also about communication. During requirements planning, it’s vitally important to get every stakeholder on the same page.
Disagreements about the nature of success are expensive at best, and at worst, can be fatal to project success.
One way to avoid dangerous miscommunication is to record the results of requirements planning in a central dashboard that can easily sync everyone’s perspectives.
Take a look at an example below — a template we built for monday.com.
That’s our customer requests template. We designed it to record stakeholder requirements in a way that’s visually appealing, updates automatically, and is fully customizable to your needs.
A good dashboard for requirements planning saves an enormous amount of hassle in the long run.
User design
User design is the heart of the RAD methodology. It’s a unique phase where developers, non-technical stakeholders, and end-users work together to build and iterate working prototypes.
The user design phase of RAD involves several development teams working in parallel. On a quick development cycle — usually no more than 1-2 weeks — they’ll each develop a prototype, using the business goals from the previous phase as a guiding light.
End-users will be directly involved at every stage, providing feedback on what they like and dislike about each of the parallel prototypes.
An extremely tight feedback cycle between developers and clients is incredibly important here.
The monday.com software development template can be customized into an ideal Rapid Application Development tool.
In the screenshot above, it’s arranged into quarters, but we’ve made it simple to change headings and columns to focus on parallel prototype development instead.
A user-friendly dashboard is the best way to make non-technical stakeholders into active participants.
Through our Github and Gitlab integrations, you can even sync your user design template with your version control process, automatically updating all your clients when a team makes changes to their prototype.
As you iterate several prototypes in parallel, don’t be afraid to borrow parts from one to improve another.
If a client says they like the interface of prototype A, the backend of prototype B, and the integrations of prototype C, use the next iteration cycle to combine them all into something completely new.
Rapid construction
The rapid construction phase of RAD is made possible by your hard work integrating clients during the first 2 phases.
Because of the requirements planning phase, you know that every stakeholder agrees on what a successful product will look like.
Because of the user design phase, you’ve been able to translate that vision into reality, creating a prototype that conforms to everyone’s ideal vision.
Now, it’s time for the developers to construct a working product using the designs from the user-guided phase.
During rapid construction, the advantages of code reuse become clear. You’ve already built and iterated so many prototypes that almost every feature you need is within arm’s reach. Reusing code and designs can make this phase go incredibly fast.
The monday.com single project template, pictured above, is an excellent tool for keeping everyone on the same page when it’s time to build the finished product.
Rapid construction has multiple sub-steps. You’ll need to make quick plans, develop wireframes, code features, and test for bugs — much like in traditional development, only faster and easier due to everyone’s work on the front end.
A dashboard helps keep everything from getting out of sync.
It also helps your team keep clients in the loop, as this phase isn’t about the developers “going off on their own” — all stakeholders should still be able to have their voices heard.
Cutover
The cutover phase involves getting the product ready for launch.
It’s not the end of development — there’s still time to make final changes to the product and iron out the last remaining bugs.
However, while the developers and clients are working out the final kinks, it’s time to prepare the product for prime time.
If the project is meant for wide release, and the users have been representatives of the general public, the monday.com product marketing launch template is your friend here. It’s a simple, automatically-updating, visual dashboard for evaluating the success of all your work.
In the event your product needs to go back to the drawing board for any reason, this template can sync with all the others to provide complete information for every team.
What are some Rapid Application Development tools?
monday.com is an ideal companion for every software development life cycle and philosophy, but RAD might be the one where it shines the brightest.
RAD relies on communication, which is one of monday.com’s guiding design principles.
monday.com is about dashboards talking to each other, apps talking to apps, and people and teams communicating in a snap.
We’ve already highlighted 4 of our favorite templates, but that’s just scratching the surface. monday.com has templates for every area of your business. They’re supported by integrations with the tools you rely on, like Slack, Zoom, Outlook, Gitlab, and Adobe Creative Cloud.
It all adds together into something we like to call our Work OS.
Instead of building a tool that would force your team’s take on RAD into a rigid mold, we’ve handed you a toolbox to bring your Rapid Application Development process to life.
Get ready to build a RAD team
Using customizable tools, it’s easy to get your team onboarded to a RAD approach in no time at all.
The Rapid Application Development model can unlock your creative potential, satisfy your clients, and guide you to build things you’d never have attempted otherwise.
Check out our templates today, and see how monday.com can help you harness the power of RAD.
