We don’t have to tell you that the software development world is complicated. And the ever-expanding selection of methodologies, frameworks, and systems aren’t exactly helping clarify things, are they?
In our continuing effort to help separate the wheat from the chaff, today we’re taking a closer look at two of the more common, yet misunderstood, of the frameworks available to help sort out your own SDLC (software development life cycle)—namely the Scaled Agile Framework (SAFe) and rapid application development (RAD). Those links will take you to our deep dives into each of these individual methodologies, so today will be more of a comparison.
We’re going to give you a brief summary of each set of guidelines, then we’ll get to the meat of the article. Use cases and examples of where each framework shines and where each could use some augmentation. Our goal is for you to finish this piece with a solid understanding of scenarios where either SAFe or RAD would be the ideal methodology for your next project.
SAFe in a Nutshell
Scaled Agile Framework, or SAFe, is a relatively new adaptation of perhaps the best-known project management framework out there, Agile. In its short lifetime, Agile has gone from an upstart method trying to unseat the granddaddy of all PM methodologies, Waterfall, to being a force to be reckoned with. These days, Agile and its offshoots can be found in nearly every industry, across sectors, and on every continent.
SAFe emerged in response to the growing need of, well, growing companies. You see, Agile excels at providing the limited amount of structure a small scrappy startup would need to get their product to market fast—and leaves things like bug fixes and updates for someone to figure out later. By adding a thin yet effective layer of top-down management to Agile’s move fast ethos, SAFe lets a company grow its development efforts in time with the growth of the company as a whole.
Scaled Agile, the creator and provider of the SAFe framework, defines it like this:
SAFe provides guidance for all the levels of the enterprise that are actively engaged in solution development: Team, Program, Large Solution, and Portfolio. The result is greater alignment and visibility across the organization, connecting the business strategy to execution, enabling better business results, faster, and with a higher degree of predictability and quality.
So SAFe builds on Agile’s successes by helping organizations build a series of teams-of-teams as a foundation to then build their development division on. And it does this by adding aspects of lean PM fundamentals and that thin layer of oversight provided by management that is keyed into how Agile works and knows when to let the developers work their magic and when to step in to keep a project moving in the right direction.
RAD in a Nutshell
Predating Agile by over a decade, RAD was one of the first software development frameworks to be developed directly in response to perceived shortcomings in the Waterfall methodology. When RAD arose, the dominant SDLC framework at the time was still Waterfall, which, having come from the engineering world, was a rather strict, regimented, and hierarchical set of guidelines. Software development was just becoming its own distinct entity separate from the engineering world that spawned it and was in need of a new set of protocols that were a better match for the more laid back, casual, and creative way programmers were doing things.
The result was a loosely organized set of procedures based around a 4-step model:
- Requirements planning
- Prototype
- Build
- Finalize/release
In some later versions of this model, the prototype stage is broken down into a cycle that goes prototype > feedback > iterate > prototype > etc. thus including the user testing and feedback cycle that was inherent in this model and one of the primary reasons for its quick ascension. The RAD model excels in environments with a single, mostly autonomous development team that has a good blend of experience and specialization.
These principals have ultimately been able to help power low-code/no-code development cycles for organizations that might not have full-fledged development capabilities.
Where SAFe Shines
As mentioned above, SAFe is all about scalability, so the luster will be found in scenarios with multiple existing dev teams, or in an organization that’s already looking forward to building out such a structure despite maybe only being a single team for the time being. In other words, when you want to use Agile but are afraid you’re too big (or will be soon).
Example use case
Your startup just received an infusion from a second round of investors, and just released your product in beta. The CEO announced a round of hiring that will see your dev team multiplying to 3 full teams, spread across 2 sites and the potential is already there for a new office overseas in the next year.
You used a rough version of Agile with some aspects of Lean and other methods to get this far, so the idea of changing things up too drastically doesn’t really appeal. Besides, you’ll have a couple of team leads coming on board so each team will have someone watching from a higher level vantage point now. Before now, it was you and the 9 current devs in a room one floor below the C-suite.
Implementing a solid foundation grounded in the SAFe methodology seems like the perfect fit. Your teams won’t have to change much about how they operate on a daily basis, while you’ll have the structure you need to be able to report up the chain and keep the investors happy.
Potential Challenges Using SAFe
You might run into hurdles using SAFe when the one and only name of the game is SPEED. True, SAFe is faster than most other options at scale, the simple fact is that larger organizations just can’t generally move as fast as smaller ones. So by definition, if you’re big enough to be considering SAFe for its scalability, speed probably isn’t your number one priority.
The other area of concern is user feedback. If that is a crucial piece of your workflow, it can be a challenge to build it into a SAFe shop. If you’re trying to keep things moving, it’s not uncommon to find that feedback you’re receiving has no obvious place to go.
Where RAD Shines
If you’re a small shop that intends to stay that way, RAD is for you. If you pride yourself on including user feedback in your design iterations, RAD is for you. If your company consists of a single room full of smart people doing creative things with code, RAD is for you.
Example use case
The leadership team decided early on to bootstrap it. There will be no angel investors pumping cash into the company, so you’ll be making do with what you have, an amazing team of brilliant creatives building software that’s tailored to your user’s needs.
In the last 6 months, you’ve been able to hire one new developer, though you lost 2 to attrition halfway through the last production cycle. User input comes in daily through your social media presence (managed brilliantly by your marketing director, who also happens to lead the sales team) and your Discord. The productive feedback is immediately worked into the current iteration and sent to QA (handled by 3 of your devs) for testing.
In this way, RAD offers something of a mirror image of the strengths of SAFe: you can iterate extremely quickly, and you can turn on a dime to incorporate user feedback. If you’re trying to stretch your resources to fit a specific vision, this can be a valuable tactic.
Potential Challenges Using RAD
The instant your team grows enough to be split into 2, you’re going to start seeing some issues creep in. With its tight focus on speed and agility, RAD has a difficult time with a hierarchical power structure of any size. The autonomy granted to your team under RAD breaks down as soon as management gets involved, as that’s when the lack of centralized authority rears its head. Here, you’ll have to find a way to hold onto the benefits while potentially including some more scalable structure.
Which Is Right for You?
Would you hate us if we said “it depends?” Because in all honesty, it does. You know your situation, your team, and your company better than anyone so ultimately the call is yours. With that said, each of these frameworks has definite strong points. If you’re working with a single roomful of the best and brightest, you’ll see fantastic results implementing RAD. If you’re restructuring a larger organization or can already see growth in your future, you’ll likely see better results starting with something that can grow with you into the future, something like SAFe, for example.
And when it comes right down to it and you still have misgivings or just can’t answer enough questions concretely enough to get past the money people, looking for an IT services provider to partner with might be the way to go. If you find someone that offers nearshoring service, for instance, they can provide you with not only the framework but the devs you need to fill out your teams while you get things going. And they’ll be in your timezone to keep meetings and planning simple while you continue working on instituting the framework that will work the best for you and your people. In this way, problems of choosing, scaling, and rolling out the right framework for the right project become less a matter of guesswork and more a matter relying on strong expertise.
Learn More About Intertec’s Software Engineering and Support Services
Intertec specializes in building and supporting custom software for its diverse clients. Our experienced team of interdisciplinary professionals have experience at all stages of the software development lifecycle. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
