If, by now, you haven’t had an Agile evangelist hunt you down to explain how the project management methodology will revolutionize your product, service, or industry, you may find that your office is parked squarely under a rock. Or, considering how likely it is you’re currently working from home, that your Zoom invites are buried under a digi-rock.
No matter who you ask, no one is indifferent to Agile, and everyone has an opinion about how it should be done (and why the way you do it is wrong).
Of course, there are plenty of valid reasons Agile is constantly discussed. Over the last two decades, Agile has forced companies in software and beyond to reevaluate their culture and how they can best deliver value to end users.
So how did Agile rise to the top of a field crowded with other project management methodologies? Let’s take a look at what makes it unique, why many modern orgs swoon over all things Agile, and how it stacks up against other non-Agile approaches.
Do you hate meaningless documentation and the rigid, up-front project planning of the 1970s manufacturing era?
Are you even aware of the meaningless documentation and the rigid, up-front project planning of that era?
Either way, let's talk about how Agile was the ultimate response to that.
For 97% of companies surveyed in the latest State of Agile Report, the Agile project management methodology has freed them from the slow, document-laden norm of decades past. Agile isn’t just inspired by a vision of software development that views developers as people instead of assets; it’s shown a notable ability to drive productivity and profits. In fact, nearly all of the companies—95%—that use Agile approaches report improved development practices and results. Additionally, according to the Harvard Business Review, some companies see a 60% growth in revenue and profits when they shift away from traditional, heavyweight project management.
It’s no wonder Agile has become modern industry’s favorite project management flavored Kool-Aid.
The Agile methodology isn’t supposed to be about creating process: it’s about focusing on what Agile Alliance member Jim Highsmith calls the “mushy stuff”—that is, valuing software developers not as assets, but as people—in order to deliver good products to customers based on their frequent feedback.
In short, Agile is deeply rooted in the idealism that drives software companies—and other industries—to set out to create something visionary.
Today, with Agile in the mainstream, it seems obvious that the best way to create a revolutionary product is to gather and implement feedback frequently, focus on cross-team collaboration, and create space for developers to be creative. But in 2001, when a group of “organizational anarchists,” as The Agile Alliance calls themselves, got together (presumably, based on that name, after meeting up at Burning Man), this wasn’t so self-evident.
Frustrated by the engineering and software development processes of the ‘70s, ’80s, and ’90s, evangelists of extreme programming (XP), Scrum, dynamic systems development method (DSDM), Crystal, pragmatic programming, and other project management frameworks came together to come up with an alternative to traditional, documentation-driven project management methods.
The result? A 68-word manifesto that emphasized incremental iteration, flexibility, and customer satisfaction above documentation, rigid process, and following a set plan.
Since its inception 20 years ago, many have argued that Agile is less a project management methodology and more of a philosophy that can be applied to a myriad of other frameworks.
This was important because it called organizations to reexamine not just their workflows, but their culture. And, because Agile wasn’t bogged down by specific rules and needs for documentation, it could be spun up to increase productivity, prioritization, collaboration, and developer creativity in almost every environment.
Editor’s note: You, of course, may disagree that it always does these things as well as claimed. I may disagree with that too. Such are the joys of discussing and implementing Agile.
Despite the division between Agile evangelists and non-Agile practitioners, the methodology itself doesn’t demonize the processes of its competitors. Instead, it outlines a set of values that those who adopt it should prioritize, leaving it to those adopters to decide just how Agile they want to become.
On one side of the spectrum sits full agility—completely overhauling your culture and workflows to align yourself with the Agile Manifesto—and opposite it lies the traditional waterfall methodology so popular in years past (and sometimes still popular now). Between the two are a multitude of hybrids and Agile flavors for different use cases.
At this point, it’s safe to say Agile has surpassed waterfall as the most popular project management methodology.
Agile and waterfall are perhaps the most opposite of the methodologies on this list, and the most often compared. While Agile has firmly taken the spot as the most used project management methodology, many companies still use elements of waterfall, or a mix of both.
The main difference between the two is that where Agile focuses on people and flexibility, waterfall hinges on process and documentation.
As a result, the waterfall methodology focuses on rigorous development processes, only allowing developers/engineers to move on to the next pre-planned step of a project when the previous stage is fully complete. Because of this, projects using waterfall may take longer to develop or to pivot to end user feedback.
Where waterfall focuses on fully completing large chunks of a project in order, Agile emphasizes real-time feedback integration from stakeholders and customers by breaking projects down into smaller, workable pieces that can be changed at any time.
Waterfall is better suited for smaller projects with a clear scope and well-documented process. In contrast, Agile is better suited for rapidly changing, feature-driven projects developed with small or mid-sized teams.
DevOps and Agile share a similar goal: driving efficiencies between teams to get the end product in the hands of users as quickly and efficiently as possible. Both methodologies are similar in that they unite behind an overall outcome—better collaboration—and can be integrated into a variety of frameworks.
However, the two methodologies focus on bridging communication gaps at different levels to the reach goal.
Where Agile focuses on using iterative processes to foster collaboration between developers and customers, DevOps aims to close the higher-level communication gap between operations and development.
Interestingly, while Agile is known for its speed and flexibility, DevOps actually delivers code much faster, aiming for daily or hourly releases instead of the two-week sprint schedule used in Agile projects.
If you’re working in an environment with robust documentation, large teams, and a focus on quality over responsiveness, DevOps generally makes more sense. But because the two methodologies fill gaps at different organizational levels, they’re often stacked to maximize collaboration.
Where Agile offers software development teams flexibility and the ability to prioritize innovation, the spiral model’s documentation-driven nature is all about risk mitigation.
If you’re feeling lucky—AKA, if you have a higher risk tolerance— Agile may be the way for you. But if you’re working on a high-risk project that’s hard to scope, spiral may be a better match.
Whereas Agile tackles the challenges of product-market fit, spiral’s number one goal is risk handling. It gets its name from the spiral-shaped journey developers go on to reach release. Starting in the center with a concept of requirements, functionality and prototypes are added on in four phases:
This calculated development methodology relies heavily on documentation at each step to avoid project issues.
Because of its rigorous, documentation-driven process, spiral parks almost directly across the spectrum from Agile. Where spiral is best used for large projects that require continuous changes and internal prototyping before being released to customers, Agile delivers the most value when used for complex projects that are frequently released to customers and don’t rely on strict requirements.
On the surface, RUP and Agile look pretty dang similar. Both value iteration and incremental development—that is, breaking down larger projects into smaller, more digestible chunks—but when you dive beneath the surface, there are a few key differences between the two project management methodologies.
If you’ve talked to anyone practicing Agile development, they’ve probably thrown around the word “continuous” to describe the development flow, which turns out to be one of its main distinguishing features. Where Agile drives new capabilities on an ongoing sprint schedule, RUP relies on four (the magic number of project management methodology, it seems) decidedly non-flowy phases to push projects forward:
Additionally, like pretty much every non-Agile company, teams using RUP rely on documentation and up-front project scoping to get things done.
RUP uses a traditional, top-down approach to project management, defining the roles on development teams, and relying on model-heavy use cases to create templates for projects whenever possible. This makes RUP really useful when teams don’t need to frequently upgrade to new technologies and include developers with highly-specific skills.
However, there is something to be said for merging Agile with RUP—called the Agile Unified Process. This enables dev teams to leverage the highly iterative nature of RUP but trim the fat of business modeling, requirements testing, and analysis and design processes to speed up development and make the project more responsive to user needs.
Agile refers to one singular methodology based on the original value-driven manifesto, but in the two decades since its inception, dozens—possibly hundreds—of framework variations have emerged for different use cases.
As noted, there are enough Agile-inspired frameworks to drive you crazy. But teams tend to settle on a variant of one of the following five most popular options, depending on their use case:
Every year, more and more companies—software and otherwise—look to Agile to improve how they operate and iterate. The future for Agile is bright, if not a bit confusing, considering how many forks and variants have been born from it since 2001.
What makes Agile stand head and shoulders above the rest is exactly what makes it so hard to define: Its set of core values can be interwoven and used alongside nearly any existing methodology.
So, despite what many diehards say, there really isn’t a wrong way to do Agile as long as you have solid project managers and align with the manifesto’s core values. Whether you casually sip or chug the Kool-Aid, Agile can—and likely will—change how you think about development.