Agile vs Scrum: Everything You Need to Know
Is all Scrum agile? Is all agile Scrum? Are all squares rectangles?
Yes, all squares are also rectangles. But when it comes to Scrum vs agile and agile vs Scrum, it’s a little more complicated. You can’t really pit one against the other at all.
To get to the bottom of this distinction, I’ll give you an overview of agile, Scrum, how they are related, and what makes them different… but also the same.
Agile explained
If something is agile, it has the ability to move quickly and easily. Like a bird or a dancer, agility connotes dexterity, control, and adapting to changing conditions at speed.
And for the group of software engineers who called themselves the Agile Alliance and coined the term “agile software development” on a snowy Utah ski weekend in 2001, agile stood for everything that traditional development frameworks did not.
At the time, these renegade “agilistas” were turned off by the constricting policies and mountains of unused documentation that seemed to come as standard in traditional development. In his brief history of what came to be known as the Agile Manifesto, Jim Highsmith, cofounder of the group, described their reason for needing a fresh approach:
“In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies.”
In short, they were tired of process for process’ sake.
The group wanted something different, though they weren’t in perfect agreement. Each member represented a different software development methodology: Scrum, DSDM, XP, Crystal, and others. And so agile was born of a variety of approaches.
To help standardize this frankensystem, the Agile Alliance wrote the 12 Principles of Agile Development, summarized below.
Companies that choose to work with these principles must throw out the traditional top-down organizational structure. In agile, project management is shifted from supervisors to “self-organizing teams” built around “motivated individuals.” The business and development ends of the company need aligning, but oversight means little more than simply trusting the team to get the job done.
The development pace of agile is based on the constantly changing needs of today’s consumers. Unpredictable user needs demand timely and “continuous delivery” or product improvements: for example, new features or fixes for common performance problems.
Which creates another shift. Though agile companies still plan years ahead and employ talented management, the motivators behind planning and accountability aren’t managers but customers. Even as a product is nears the “end” of development, companies still need to be ready to respond to market-driven changes indefinitely.
Essential features of agile
Agile doesn’t come with a rigid set of rules to follow. Just three key hallmarks that can help you stay on track as your customers, business, and product evolve:
- Iterative development: Agile frameworks break large projects into a series of steps or iterations. As it completes each iteration, the company incrementally approaches (and when necessary, adapts) its development goals.
- Integrated development and testing: Agile prizes constant feedback—be it from end-users or within the self-organizing team. During development, each iteration has a testing phase. Often developers and testers work as part of the same team.
- Sustainability: Agile systems generate as little overhead as possible. Think less documentation and status reports, more time spent working toward development goals.
As you now know, the Agile Alliance was formed by people who promoted different development methodologies. While they could all sign on to the 12 Principles, they would go on to found and work with companies that employed a variety of agile practices.
Scrum and other approaches to agile
As a result, the agile family comprises a number of process frameworks companies can use to plan, prioritize, develop and maintain their products. Many of these predate software development.
For example, Toyota first started using Kanban in manufacturing to improve its hardware systems long before software existed as it does today.
Yet since the rise of agile, these methods have come to take on new meaning as frameworks for software development specifically.
So while each process framework helped to build agile, agile has given each process framework a sort of software-driven renaissance. It’s a two-way street, like this:
I won’t get into all of them here (here’s a good overview if you’re interested). Let’s zoom into the most popular one.
The Agile-Scrum relationship
Put simply, Scrum is a subset of agile. But that doesn’t really capture the give-and-take between Scrum, agile, Kanban, and so on. These practices are continuously evolving as companies experiment and find success with one strategy or a blend of a few.
Scrum is by far the most widely adopted, though.
Scrum describes a system of roles, “events” (or milestones), and “artifacts” (the pieces of information that come together to form a plan) designed to address the complex challenges that come with changing demands. Its principles help companies create the right environment for continuous improvement.
Scrum explained
So how do Scrum principles align with the essential features of agile?
In Scrum, small, self-regulating groups complete work in one- to four-week iterations known as sprints. These Scrum teams are also cross-functional, meaning they make up all the expertise they need within the team to get the work done.
Let’s explore those artifacts, roles, and events in more detail.
Scrum Artifacts
The key artifacts you need to know are the sprint goal, increment, and backlogs.
The increment is a small product improvement delivered by the Scrum team at the end of the sprint. This increment is guided by the sprint goal and is a total of all sprint backlog items completed during the sprint. Sprint backlog items are chosen from the product backlog, a to-do list of product improvement ideas to pull from when the user need arises.
Scrum Roles
A Scrum team is made up of a product owner, development team, and Scrum master.
The product owner is in charge of managing the backlogs by coordinating customer and stakeholder priorities. The development team is in charge of strategizing the production of the increment. The Scrum master is in charge of facilitating sprint events and creating the optimal environment for the team to do the work.
Scrum Events
Along with the sprint—the time-boxed period a team has to complete an increment—Scrum teams follow a set structure of Scrum events to help plan and execute the increment successfully.
In sprint planning, the product owner and development team agree on which work to complete during the sprint. Each day of the sprint, the team meets for daily Scrum to inspect progress and make adjustments. At the end of the sprint, they engage in a sprint review—which updates the backlog and defines problems to solve for the next sprint—and sprint retrospective that helps the team inspect and adapt their processes.
In fact, every aspect of Scrum should be transparent, inspected, and adapted. Every meeting is an opportunity to reflect on processes and figure out how to improve.
Though there is a lot of room for variation within the Scrum framework, the specific relationships and responsibilities are what distinguish Scrum from other agile methodologies. Where others are fluid, Scrum is highly prescriptive.
That said, Scrum requires a lot more from companies than a change in vocabulary. It takes full commitment to Scrum values.
Because Scrum is both profitable for companies and difficult to adopt, it’s fostered an active community of Scrum professionals who work to support companies making the switch. They have put together plenty of resources and certifications for Scrum masters and other stakeholders looking to learn more.
Revisiting the question of “agile vs Scrum”
Drawing a clear line between agile and Scrum isn’t too hard once you understand how agile influenced Scrum and vise versa.
A company that practices Scrum is agile, no doubt about it. And a team can only be Scrum when fully committed to its principles—roles, events, artifacts, and all—regardless of how much it subscribes to agile as a whole.
Understanding the relationship between Scrum and agile also helps make sense of how Scrum compares to Kanban and other process frameworks that fall under the agile umbrella.
But if there is one basic truth to both agile and Scrum, it’s that this field is constantly changing.
