Scrum vs. Agile: A Detailed Explanation of Their Relationship

Imagine someone walks into your office today and asks point-blank: “scrum vs. agile—which one should we adopt?” What would you answer?

Well, as it turns out, the correct answer is “nothing” because the question makes no sense. It’s easy to be confused in this sea of buzzwords, I get that. And I definitely get that, in this day and age, most professionals involved in software development have at least a passing familiarity with agile methodologies. But when people ask “scrum vs. agile?” they’re putting together two things that aren’t really in opposition to one another.

And that’s essentially what this post is all about. It will show how comparing scrum and agile really is like comparing apples to oranges. We’ll start with a history lesson—a brief one, don’t worry. We’re going to cover the history of the waterfall methodology so you can understand what problem agile was meant to solve.

Then we’ll continue advancing in time, showing how, in the 1990s, a group of experienced software consultants started to tinker around and experiment with software development methodologies in order to try and solve the problems they’ve seen during their professional careers.

We’ll then explain how all of that tinkering and experimentation led to the creation of methodologies—such as scrum—and ultimately, the release of the Agile Manifesto. You’ll learn exactly what those two concepts mean, how they relate to each other, and how to really go about adopting them at your organization.

Before “Scrum vs. Agile”: The Waterfall Model

Before we dive into the similarities and differences between scrum and agile, we must first understand what problem they’re trying to solve. If this is a new trend (spoiler alert—it’s not that new) that’s trying to address the problems of a previous trend…then what was the previous trend? In short, it was the waterfall model.

The waterfall model, or simply “waterfall,” is a sequential approach for developing not only software applications but also other types of engineering projects. The reason for the name is that in this model, development is considered a stream that flows steadily through the phases, like a real waterfall.

The Waterfall Model: Typical Phases and Basic Rules

Let’s quickly cover some of the basic rules of this model, as well as its component phases. The principles are, in short:

• The project is made up of sequential, linear phases. Although some degree of overlap and back-and-forth are allowed, the general purpose is for the development to flow from one phase to the next.

• The organization must plan, define deadlines and budgets, and implement one whole system at a time.

• Over the life of a project, the organization keeps control of it via extensive documentation. At the end of each phase, written documentation should be presented as a result.

And what about the phases themselves? While they can vary, the phases are typically presented as such:

• Requirements analysis. In this phase, extensive interviews are conducted in order to capture the requirements for the new system. The output of this system is a product requirements document.

• Software design. This phase uses as input the previous phase’s output, namely the product requirements document. Based on the information contained in that document, the team will elaborate the specifications for the design of the system, encompassing the domain model, database schema, business rules, and the overall software architecture for the application.

• Implementation. At this stage, developers start to actually write code based on the specifications that were produced as a result of the design phase.

• Testing. After implementation is done, it’s time for the testing phase, whose goal is to find out and fix as many defects as possible in the system.

• Deployment/Installation. When the application is coded and tested, it’s time to deploy it to the final user.

• Maintenance. That’s the longest phase in the project. It goes on indefinitely, as long as the project continues to be used.

The Waterfall Model Disadvantages

At this point, it shouldn’t be a surprise to the reader that the waterfall model wasn’t exactly a success. But why is that? A full treatise on waterfall criticism is way outside the scope of this post, but we’ll briefly cover some of the most important problems of this methodology. We need to understand what issues the later movements were trying to address.

The Only Constant Is Change…

The general criticism of waterfall is that the model is too bureaucratic and lacks flexibility. Since it’s composed of phases that flow from one to the next in a pre-established order, the model is too rigid and it’d often make it hard for organizations using it to react in the face of changing information.

One of the main problems is right at the start of the model, with the requirement analysis. As anyone who actually writes software for human beings to use will know, clients often don’t know exactly what they want or need. Or maybe they do, but they have a hard time expressing those needs. And even if they know what they need and know how to express those needs perfectly, they can always change their minds. Some markets experience profound change in short time periods. It’s often a business need to change the nature of the application during development to address sudden changes in the market.

… And Waterfall Doesn’t Like That

The waterfall model just doesn’t cater to such scenarios. Since requirement analysis is the first phase, it might be months or years between the clients expressing their needs and the day they can see and interact with working software. What if the team built it wrong? Or what if the team built it perfectly—right to the requirement analysis specification—but the client expressed itself poorly? What if their needs changed? There are just too many “what-ifs” involved.

Another common criticism of waterfall is that it sees testing as a phase. And that phase comes too late in the process. When the team finally finds out about critical bugs, performance issues, or even functional problems, it might be too costly to go back and fix those things.

A Little Bit of History: The Tragedy of Waterfall

You might now be wondering something. If the waterfall model is such a disaster, why has it gained such widespread adoption? The short answer is that people misunderstood the original document. Want to hear the long version? OK, here it goes.

In 1970, Winston W. Roice published a paper titled “Managing the Development of Large Software Systems.” Due to this paper, people to this day say that Roice is the creator of the waterfall model, which isn’t true. First of all, the term itself doesn’t appear in the paper. Secondly, Roice doesn’t claim that he created the model he describes in the paper. Rather, he says that that’s a common approach he’s observed and that the implementation described has serious flaws.

Yeah, that’s right. The paper that’s often (wrongly) considered the creation of the waterfall model is actually a warning against it. So, how did things go so wrong?

In 1985, the United States Department of Defense published the DOD-STD-2167A. This document represented their standards for working with software development contractors, and it’s biased towards the waterfall model. From this point on, the approach became widely popular, adopted in a number of government projects in the United States.

The Winds of Change

Fast-forward to the 1990s. During this decade, several software development methods started to emerge. Their creators had the goal of offering lightweight solutions to heavyweight methodologies—waterfall among them—that were rigid, bureaucratic and slow to respond to change.

These several methodologies differed in the details but were similar from a big-picture perspective. All of them emphasized shorter cycles of feedback, less emphasis on formal documentation, and clear and quick communication between clients and developers.

Here are some of the methods that evolved during that decade:

• Rapid application development (RAD)

• The unified process (UP)

• Dynamic systems development method (DSDM)

• Scrum

• Crystal clear and extreme programming

• Feature-driven development

Did you notice that scrum is on the list but agile isn’t? And why would that be?

The Agile Manifesto

The fact that those new lightweight methods shared a lot of common characteristics didn’t go unnoticed. People started to discuss a possible meeting where they could talk about these and other methodologies.

The meeting finally took place in 2001, when a group of 17 software developers, consultants and authors met at the Snowbird Resort in Utah. As a result of the discussions, they published the Manifesto for Agile Software Development, also referred to as the Agile Manifesto. The manifesto reads

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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

That is, while there is value in the items on the right, we value the items on the left more.

So, that’s what “agile” is. It’s a statement. It lists values, or principles, to be taken as a guideline. Agile is not a methodology or a development model.

Scrum vs. Agile: This Is Not a Thing

Since the release of the manifesto in 2001, the collective of those lightweight software development methodologies that emerged in the 1990s became known as “agile methodologies,” even though they predate both the term and the release of the manifesto.

So, I think by now it’s clear why “scrum vs. agile” doesn’t make sense as a question. They’re not in the same category. Scrum is one of the several methods that emerged in the 1990s that we now collectively know as agile methodologies. So, if you use scrum, you’re using agile as well.

Scrum Overview

We’ve talked so much about scrum that it would’ve been weird to finish the post without covering the method itself. So, what is scrum? How do you use it?

Definition

First of all, scrum is not just a software development methodology. Yes, the emphasis is on software development. But it’s possible to use scrum to manage projects in pretty much any knowledge field. And in fact, the method is widely adopted in areas others than software development.

Scrum is better suited for small teams (up to nine members). The teams break the available work into discrete units and then work on them during periods called sprints. A sprint can be as short as one week and as long as one month but not longer.

Roles

Scrum also employs a number of roles, namely the product owner (PO), the development team, and the scrum master.

The PO’s role in the process is to represent the client and its interests. As such, their main responsibility is to ensure the product meets the client’s needs. They might need to organize meetings, announce releases, negotiate priorities and scope with the development team, share progress with stakeholders, and a lot more.

By the end of each sprint, the development team should deliver a potentially releasable increment to the product. The team might have from three to nine members that perform all tasks needed to build the product increment. They don’t just code.

Finally, the scrum master is the person whose responsibility is to keep scrum itself working. This person should remove obstacles for the team. In this sense, the scrum master isn’t a manager or team lead, in the traditional sense. They act more like a protective layer between the team and external influences.

Some of the responsibilities of the scrum master include

• Helping the PO keep the product backlog organized, clear and well understood.

• Training the team according to the scrum principles.

• Promoting self-organization and cross-functionality within the development team.

• Helping the scrum team to remove obstacles to its progress.

Scrum vs. Agile? No, Scrum AND Agile!

The field of software development is fertile ground for buzzwords, acronyms, neologisms, and things like that. We just love that stuff, don’t we? And the realm of software development methodologies seems particularly prone to this tendency. Scrum, kanban, XP, lean, crystal methods, you name it. From some very enterprise-y names to others that are somewhat exoteric-sounding, there is a name for every taste.

In such a scenario, you or your peers might feel confused sometimes. However, you can’t allow the confusion to last forever. Everyone in the organization should share the same vocabulary. That’s the only sane path to meaningful discussions that in turn lead to valuable decision-making.

And that was exactly our goal with the current post: to improve your vocabulary and shred a common misconception to pieces, so you and your team can have fruitful discussions about software methodologies and which one to adopt. These conversations are never easy, but the first step is to guarantee everyone is on the same page and shares the same vocabulary.

Back to You Now

So, what’s the verdict? Should your organization employ scrum? I advise you to read more. And don’t just read about scrum; also research other agile methods. Then make an informed decision. But more important than this method and that method is staying true to the agile principles themselves. It also doesn’t hurt to use technology to your advantage, employing tools like the ones from Plutora that can greatly reduce the friction of managing your project.

Thanks for reading. See you next time.