These are the Differences Between Agile and Scrum, and How They Differ From Waterfall

Do you notice that everyone using the words ‘agile’ and ‘scrum’ interchangeably around the office? Does your daily scrum feel like a regular old status meeting? Does it feel like everyone around you is saying your organization is “doing” agile but you’re just not seeing the results? There may be a misunderstanding of the fundamental aspects of scrum and agile, how they work together, and how they should be different from traditional project management methods. 

What’s the difference between agile and scrum?

One of the most common misconceptions about scrum is that it is synonymous with agile. Agile is an umbrella term that refers to a family of approaches that share common values and principles. Scrum is a commonly used agile framework that offers guidance for how work can be organized to maximize value to the end-user.

While scrum is implemented at a product development team level, agile focuses on the entire organization, including its leadership and company culture. 

Many organizations use scrum in combination with other agile principles and practices to organize their teams. However, even if scrum seems like a relatively easy framework to implement, there are changes needed on the individual and organizational level to realize the full potential that agile promises.

How is agile different from traditional project management approaches?

Traditionally, products were only created using a “waterfall” methodology. Requirements are defined upfront and the budget is allocated on a per-project basis. Value is released to the end-user at the end of the project. As a result, by the time a version of the product is finished, it could be months or years with requirements that were possibly never revisited. Today, more and more competitors are coming to market trying to do what you do, but better and quicker. Customers can end up leaving you for competitors that provide the same services and products but are more responsive to their users' immediate needs. 

The challenge with the waterfall methodology is its focus on having a fixed budget, scope, and schedule. Once the project nears completion, your development teams can be pressured to participate in death marches that require them to work nights and weekends, leading to major employee burnout. They have received little to no feedback from the end-user and you now have a product that no longer matches the current needs of the user.

Major changes to requirements require you to restart the entire waterfall process again or drop the project completely. This creates unnecessary waste of time and money and can have a negative impact on the morale of your employees who may be deeply invested in the success of the project they just finished.

Enter an agile framework like scrum – used to break down complex projects into smaller pieces so teams can continuously deliver value on a more frequent basis. It’s a more collaborative and flexible approach, so you can respond to your client’s evolving needs and changes in the market. The scope is made flexible by continuous refining of functionality that is added to the product backlog, the budget can be allocated and based on how well the product is performing, and the time frame is extended until the end of the product life cycle. 

Agile approaches like scrum also place value on the individual, both on team members and the end-user. It’s a change not only in the way we do things but also in how we think about what really makes great products: great teams! That’s why agile is not a management process; it’s a mindset that thrives in the various communities and organizations that have chosen to take the call to make work a more enjoyable and rewarding endeavor.

The history of agile and scrum

There was a time when agile didn’t have a name. At first, it was born from a desire to move away from cumbersome software development approaches that could take years to deliver a product in its entirety. Several methods were evolved, including scrum, to find a way to shorten the time to market and deliver more value to customers, sooner. However, there was still a gap that none of the previous approaches had pinpointed. 

The short story goes: In February 2001, 17 people from different software development communities gathered at a ski resort in the mountains of Utah to talk about how software development could keep up with the changing needs of users. What came out of that summit was not another framework, but a name for a collection of values and principles that encapsulated what these developers really sought - to consider people as the most important asset in the development process.

Agile did not start on those snowy mountains, nor did it end there. In many ways, agile is still an evolving collection of beliefs that has spawned a myriad of frameworks and methodologies focused on one thing: improving the world of work.

Scrum precedes the Agile Manifesto by about 8 years but is considered part of agile due to its iterative and incremental approach to delivering customer value. Its main focus is to provide high-quality products sooner, with faster feedback cycles to make sure you are building the right product while promoting continuous improvement and reducing team burnout. 

Like agile, scrum has evolved over the years. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. 

You may be thinking, “why is it called ‘Scrum’?.” The term is borrowed from an analogy put forth in “The New New Product Development Game,” by Hirotaka Takeuchi and Ikujiro Nonaka, published in 1986 in the Harvard Business Review. The authors compare high-performing, cross-functional product development teams to rugby teams using the scrum formation when they restart play.

"This new emphasis on speed and flexibility calls for a different approach for managing new product development. The traditional sequential or “relay race” approach to product development… may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements."

How does Scrum work?

The Scrum Framework is deceptively simple: 

• A product owner creates a prioritized wish list called a product backlog. 
• During sprint planning, the team pulls a small chunk from the items towards the top of the list. That chunk becomes the sprint backlog. The team decides how to implement the sprint backlog within the time frame of the sprint. 
• The team has the given sprint (usually one month or less) to complete its work, but it meets each day to assess its progress (in the daily scrum). 
• Along the way, the scrum master keeps the team focused on its goal. 
• At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder. 
• The sprint ends with a sprint review and retrospective. 
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. 

All work performed in scrum needs a firm foundation of values for the team's process and principles. With its emphasis on teamwork and continuous improvement, scrum both creates those values and relies on them. These values complement, rather than detract from the agile values. 

• Commitment. Because we have great control over our own destiny, we become more committed to success. 
• Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner. 
• Openness. As we work together, we practice expressing how we're doing and what's in our way. We learn that it is good to express concerns so that they can be addressed. 
• Respect. As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect. 
• Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.

What are other agile concepts?

Scrum can be a great introduction to the world of agile. It’s a lightweight framework that has few rules. Even so, teams can spend years trying to master scrum. Success can only happen if you look at scrum as part of a longer journey towards agility. To make working with scrum a more delightful experience, you can bring in other agile concepts such as building quality in (lean), or pair programming (extreme programming), or even limiting work in progress, a concept from kanban. Other agile concepts focus on a larger picture that needs to be addressed outside of transitioning teams to scrum. This includes incorporating agility into product management, HR policies, and leadership, to name a few.

Any person could devote their career to learning about scrum and agile, and mastering any of these concepts - which can make determining where to start a daunting task. The first step is to learn to articulate what scrum and agile really are outside of being a corporate buzzword thrown around but not fully understood.

Want a refresher on the basics of scrum? Take the eLearning course “Introduction to Scrum”