Podcast: Play in new window | Download (Duration: 10:15 — 9.4MB)
Subscribe: Android |
Is your software development project facing constant setbacks? Rapid Application Development may be what you need to get your project back on track.
We’re going to discuss problems that you may have experienced with your development teams, and how a methodology called Rapid Application Development may be just the right ingredient to jumpstart your projects or get your project back on track. We’ll cover three main topics:
- Common Failures with other methodologies
- Benefits of Rapid Application Development (RAD)
- How to get started with RAD
Common Failures with SDLC Methodologies
You’ve probably heard of Waterfall, the classic methodology that dominated in the 70s and 80s. The typical method here was to gather all business requirements up front, then develop the project. It had the advantage of having a detailed design up front, but the disadvantage was that it took months if not years to deliver the product. Furthermore, when the product was finally completed it was delivered to the client who hadn’t seen virtually anything up to that point, so sometimes there was a disconnect between the initial design and the final release.
Software development faced a crisis in the early 1990s as demand increased exponentially for software for enterprises. Waterfall just didn’t move fast enough for businesses, so new methodologies were developed to shorten the Software Development Life Cycle. In fact, Agile and methodologies such as Rapid Application Development (RAD), Paired Programming and Extreme Programming have their roots in the 90s. Most of these work by doing smaller iterations of a project released over a period of weeks.
Flash forward to recent years and Agile or Scrum are currently some of the most popular buzzwords for software development. Agile is not necessarily a methodology, framework or process. It’s more of an umbrella that covers a range of these. Scrum is a subset of Agile, and is a widely used lightweight process framework, requiring development cycles called Sprints. Unfortunately for some, the methods they adopt for Agile may or may not work as desired.
I’ve seen firsthand teams that just don’t deliver, even though they seem to be following well thought out processes. From my experience, these seem to due to constant distractions and/or the inability to estimate correctly due to unknowns.
One common scenario has team members starting their typical work day sometime between 8 and 9am, followed by a stand-up meeting at 10, lunch around noon, followed by meetings in the afternoon for planning or investigation. Now while this may sound like a pretty full workday to some, I’d like to look at it from the point of view of a developer. Now, all developers are not alike, but from the way I am and what I’ve seen in my colleagues, some of the best work and productivity is when we have a solid 3 to 4-hour block to code. If we have meetings every couple of hours, or distractions through instant messages or others interrupting me to ask questions, then our productivity suffers.
Inability to Estimate Accurately
Teams are typically asked to estimate tasks for each Sprint, placing some items in ranges, such as 2-4 hours for this task, 8-12 hours for this task, and so on. Typical estimates are based on how much time it should take to create something based on something similar previously developed. The problem is that this ignores true innovation. Sometimes we’re asking developers to do something that has never been done before and trying to force an estimate in advance. That’s like saying to Thomas Edison—invent this new gizmo, but before you do tell us how long it will take.
Introducing Rapid Application Development
As I said earlier, RAD is not new. The RAD model is based on prototyping and developing in increments with no specific planning involved. While that may sound crazy to some, for the right project, RAD is a powerful, extremely fast method for delivering working solutions. But it isn’t right for all projects. RAD works best for projects that can be either modularized or prototyped. It also requires highly skilled team members. So it might be great for startups or smaller projects, but not necessarily good for the enterprise, unless you’re pulling out a smaller piece of a project.
Benefits of RAD
- RAD is much faster development than other methodologies. But how fast? I’ve developed fully-functioning sections or prototypes created in hours rather than days/weeks. Recently, for example, my client and I developed an adhoc report system from scratch in three days. And those weren’t full days; just blocks of 3-4 hours spread out over the 3-day period. 15 hours total for a new reporting system from scratch.
- RAD also encourages customer feedback and can accommodate changing requirements along the way, allowing for rapid completion of screens that meet both business needs and user needs.
- As an added bonus, there’s less intensive testing required since testing is more in-depth during development.
How to get started with RAD
RAD starts with getting the right people – but it must be the right mix! It’s dependent on technically strong team members for identifying business requirements, and extremely well-skilled developers who can handle all aspects of coding requirements.
For Example: Business owner with technical expertise is paired with a senior developer. Between the two of them, they can identify every detail of what the business and user sides need and they have the skills to develop it from requirements to database to code to deployment.
A typical work setting consists of 3-4 hour sessions, possibly twice per day but not 5 days/week otherwise there’s a risk of burnout. The goal is to keep productivity high and intense, squeezing out more in less time. But you can’t squeeze too much or else you’ll defeat the goal.
The focus is on a modular application: Objectives are in smaller increments, such as a Report section, Client Management section, etc.; with user screens and admin screens.
My Typical RAD Session:
- Session starts with a whiteboard to visualize goal from both the database side to user screens.
- Next steps starts at the database, where tables and scripts are created based on business requirements
- Next coding begins as screen(s) are created, tested and completed.
Rapid Application Development is an alternative to speed up your software development life cycle. While it’s not for everyone, it may be just the right tool you need to get your project back on track or prototype something new in half the time of typical methodologies. If you’d like to experience RAD first-hand, or would like help getting your team up to speed, reach out to me and I’ll be glad to help.