Agile vs Scrum: Key Differences in These Methodologies

Agile and Scrum, two common concepts in project management, are frequently used synonymously. There are, however, key differences between the two. Namely, one is a methodology and the other is a tool for project management. 

Think of Agile as a conceptual design and Scum as the blueprint for achieving it. Agile is guided by a set of big-picture values and principles, but it doesn’t go into the finer details of how to manage a project. Scrum, conversely, lays out roles and responsibilities, as well as requirements, and provides a process for delivering a project. It’s among the most popular tools for managing projects under the Agile framework. Let’s dig into the differences between Agile vs Scrum.

A Time Before Agile

Agile is an approach to project management. It’s used by many industries but was developed initially to meet the needs of the software development industry.

It was created as an alternative to the Waterfall framework – a traditional methodology for project management. The Waterfall framework worked well for some industries, such as manufacturing and construction, but it wasn’t as flexible as many software developers needed it to be.

Inherent in the Waterfall framework is the need for a clearly defined scope prior to the start of a project, a linear approach to developing a product, and product delivery at the end of the process. Interaction with clients comes at the beginning, as the scope is being defined, but there is little engagement with them as the project unfolds, and there are few opportunities for changes. This works if you’re building a bridge because the requirements are not likely to change. 

For leaders in software development, the world is not so defined. This became especially apparent to the industry in the early 1990s, with the proliferation of PCs. It was taking an average of three years to deliver new software at that time, yet technology was changing so rapidly that the software was at risk of being obsolete by the time it reached the market. 

The technology writer Peter Varhol writes, “The problem was, businesses moved faster than that, even 25 years ago. Within the space of three years, requirements, systems, and even entire businesses were likely to change. That meant that many projects ended up being canceled partway through, and many of those that were completed didn’t meet all the business’s current needs, even if the project’s original objectives were met.”

How Agile Came to Be

This dilemma is what motivated 17 leaders in the software development industry to develop the Agile framework. In the early 2000s, the Agile Alliance, as they called themselves, created a project management methodology that would meet the needs of their industry and create the type of organizational structure that they wanted to work in. 

They did have models to build upon. For example, a decade earlier, James Martin of IBM and others developed an approach called rapid application development (RAD) to reduce the time spent on project planning, get into development quickly and collaborate throughout. Rapid application development also endorsed taking an iterative approach to software development by creating prototypes. 

Another influential model for managing projects was Scrum. Its founders, Ken Schwaber and Jeff Sutherland developed Scrum in the 1990s, well before the Agile framework came to be. They named Scrum after a term used in rugby, which means working together toward a common goal. 

For new, complex projects, Schwaber and Sutherland believed that the best results would come from small, self-organizing teams that are given objectives rather than assignments and the freedom to determine the best way to meet those objectives. They also espoused iterative development cycles of two to four weeks each, called sprints. 

Schwaber and Sutherland were among the 17 leaders who formed the Agile Alliance. The group held its most seminal meeting was held in Utah in 2001. What emerged from that gathering was the Manifesto for Agile Software Development, the origins of the Agile framework. It reflected concepts taken from RAD, Scrum, and other progressive approaches to project management used at the time. 

The Agile Framework

Agile begins with the premise that the problem to be addressed is complex, the solutions are unknown and requirements will likely change in the process of development. It recognizes that the project team will need to collaborate closely, seeks regular feedback, and adjusts its plans as the project progresses. 

The Waterfall framework doesn’t provide the flexibility or structure for such practices.

The Agile framework comprises four values, which were crafted in such a way that they accentuated how “waterfall-like” they were not. They would value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Twelve principles flesh out these values. They too are so contrary to Waterfall methods that they might have seemed radical to traditional project managers. Together, the values and principles form an approach that is more horizontal than siloed, more iterative than linear. A model that encourages regular, frequent input from the business side and welcomes change requirements. 

Agile vs Scrum

The third principle of the Agile manifesto reads, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” This summarizes the intention of Scrum well.

Schwaber, one of Scrum’s co-founders, describes Scrum this way: It “helps people and teams deliver value incrementally in a collaborative manner … [T]hink of it as a way to get work done as a team in small pieces at a time, with experimentation and feedback loops along the way.”

Under Scrum, projects are broken down into short periods of activity – called sprints – of two to four weeks each. Cross-functional teams meet before each sprint to plan it out. Each sprint represents an incremental step toward the end goal, and teams measure their progress on the basis of the working software they produce. 

Lessons learned are also inherent in this model. At the end of each sprint, the team reflects on what could have been done differently to produce a more effective product. With that reflection, the team adapts and can fine-tune the product. At the close of the project, the team delivers software that has been tweaked and tested throughout the process. 

How Scrum Works

Putting these concepts into practice, the Scrum process is governed by a set of guidelines:

• Each Scrum runs on sprints
• Each sprint lasts no more than four weeks
• The team has daily standup meetings of about 15 minutes each to check in on progress and reassign work as needed
• Each sprint ends with a retrospective to evaluate accomplishments, review lessons learned, reroute any unfinished work, and prepare for the next sprint

Scrum also prescribes a structure:

• The Scrum product owner is responsible for the overall initiative and liaises with the client
• The Scrum master is the go-to person for questions about workflow, priorities, project changes, and workload
• Team members are called Scrum developers, and they are dedicated to the project throughout 

All of this describes a process that is consistent with Agile values and principles. But Scrum takes it one step further. To be Scrum, every sprint must produce a “shippable” component of the end product. This is at its core and articulates the difference between Agile vs Scrum.

Wrapping Up Agile vs Scrum

Because Scrum empowers teams to organize and prioritize projects and adapt as they need to, it works especially well for projects that don’t have clear requirements and are expected to experience change. 

As the tech writer Varhol explains, this describes most software development projects. “[S]oftware design is both a science and an art, with imperfections and associated human limitations. First, we simply don’t know how to define software very well. Users can describe their business workflows, but they can’t tell software designers what features will automate them and how those features should work. Our inability to precisely define what is needed before starting to build the product separates software engineering from most other engineering disciplines.”

There are, however, other project management tools for software developers – Top Project Management Tools for Software Development. Within a Scrum project, there is also room for using other tools, such as Kanban boards. Which tool, or combination of tools, is best for your project will depend on the requirements of your project and the structure of your organization. 

The biggest takeaway is that you can use Agile without Scrum, but Scrum won’t work for your team if you’re not following the principles of Agile.

---

Continue to explore the rest of Terminal’s content offerings. If you are interested in learning more about how Terminal can support your organization and accomplish your development goals, please get in touch with our team!