People have been excited about Agile for years now, so it’s hard to miss all the articles and research about the benefits it brings. But a passing familiarity with Agile is often just enough to leave you confused by the torrent of terminology that gets thrown around.
Don’t worry! Agile is all about ensuring the perfect isn’t the enemy of the good. You don’t need to be an expert fluent in all the terminology to start unlocking the wealth Agile benefits like better efficiency, transparency, and employee empowerment. In fact, many people initially assume Agile and Scrum are the same thing. It’s understandable considering Scrum is the most popular Agile framework.
Understanding the basic difference between Agile and Scrum is enough to start applying some Agile principles to your own work.
So in true Agile spirit, it’s time to stop worrying about your Agile knowledge and dive into the basics you need to get started. Here, you’ll learn what Agile and Scrum are and how to determine the best way to apply their principles to your own work.
The overarching goal of Agile is to deliver value more frequently. It’s easy to get into the weeds about all the processes connected to it, but all of them tie back to this core idea.
To deliver that value Agile breaks projects down into smaller pieces in order to get feedback on it more quickly. Then, that faster feedback can be applied to improving both the work itself and the processes behind it. At the same time, Agile focuses on using that information to pivot when necessary instead of throwing more and more resources into something that isn’t going to work.
But frankly, that all probably sounds a bit abstract. So let’s look at what this looks like in practice.
Imagine someone at a car company spending 5 years building a new model only to release it and learn nobody is interested. They may have spent months agonizing over getting the steering wheel just right only to learn that nobody cares!
Chances are, you’ve done something like this before, especially if you’re a perfectionist.
Instead of waiting until something is essentially “perfect” to get feedback, Agile strives to find ways to test ideas throughout the process. So that car company may release the new steering wheel as an option in an older model. Or they may simply throw up a landing page showing the car and ask people to put down a $100 deposit if they’re interested
(crazy idea, right?)
These approaches allow you to see what people care about and use that information to improve the product. The other core idea that drives the Agile approach is a focus on delivering value to stakeholders. In other words, the main purpose of work is to deliver work that’s actually valuable and not just meaningless busy work.
So while Agile principles focus on breaking up work to get feedback, the overall goal is always delivering value. Of course, there’s a lot more to Agile like visualization, cross-functional teams, etc. but this basic idea is all you need to get started.
The guiding principles laid out in the original Agile Manifesto lay out how work should be built around the people doing the work. In other words, if the way your team is working leads to burnout, then you’re not being Agile. The abilities and needs of team members should guide how work is done so that work is sustainable.
This also means trusting people to do good work and giving them the resources they need. Instead of old-school “command and control” style management, Agile is built around listening to understand what’s needed and working to make it happen.
Agility also embraces change. If a stakeholder changes their requirements late in the work process, that’s okay because it means the work produced is more likely to be valuable to them.
The Manifesto also talks a lot about “working software.” The idea being communicated is that half-finished work that can’t deliver value is, well, not valuable. How often have you completed 80% of something only to set it aside for weeks or months. This is like paying for something now and not actually receiving it for months. It’s inefficient and keeps potential value locked up and inaccessible.
While its origins date back further, the original Agile Manifesto was written for software developers by software developers.
Its writers were sick of spending months building software only to immediately realize it contained major flaws once a customer actually used it. That’s why, when done right, implementing Agile feels liberating and empowering. It wasn’t created by a management consultant somewhere to extract 10% more work out of a faceless workforce, it was created by people doing the work who wanted to simply work smarter and not harder.
Since then, manifestos have been written for all sorts of other functions like marketing, sales, and even HR. Each one is a little different but they all rest on the same core ideas about how to best structure work to deliver more value.
There are a nearly infinite number of ways to implement Agile. From very specific and structured approaches to hybrid methods tailored specifically for one team, it’s far from one-size-fits-all. The most popular framework for implementing Agile principles is Scrum.
Scrum uses Agile principles to get well-defined teams to work in set periods of time called sprints. This ensures work gets broken down into smaller units so value can be delivered and feedback obtained more frequently. It also ensures teams regularly reflect on their work and discuss ways to improve.
For example, a Scrum team typically works in two-week sprints. This means every two weeks the team gathers to refine their backlog and commit items for processing, a kind of to-do list for that sprint. The team will then typically meet for quick daily standup meetings to update everyone on what’s happening, lay out the day’s priorities, and flag any problems.
Those standups help ensure everyone is on the same page and when a team member gets blocked on something, the team can work to quickly get them unblocked. At the end of a sprint, the team usually holds a retrospective meeting in which they discuss what went well, what didn’t, and brainstorm ideas for improvement.
Those ideas then get transformed into experiments that can be run during the next sprint. This is how Scrum creates a culture of continuous improvement, where the output of each sprint can be analyzed and experiments used to test new ideas for improvement.
But as you can probably tell, Scrum is quite structured. When teams tend to form and break up regularly or when work is difficult to break up into portions that can be completed in a single sprint, it gets difficult to use. The other major challenge is that applying Scrum generally requires teams to throw out all of their old processes, which often creates internal resistance, confusion, and other challenges.
That’s why Hybrid approaches exist to modify Scrum for easy use in areas outside of software development like marketing.
We threw quite a few terms at you in the last section, so let’s quickly define them. It may seem like a lot, but once you understand these 5 terms, you’ll have the basics you need down.
This is the set period of time your team will work in. You can choose the length that works best for you, but typically 1-2 weeks is ideal. This offers enough time to get real work done and to test ideas.
If you’ve ever assumed some work was done only to realize your definition of “done” was different from someone else’s, you can appreciate why user stories are so important. They describe what value the work provides to the end user, making it clear who the work is for and what value it should provide that user once it’s done.
A backlog is your team’s to-do list. You might have a general backlog where you stick any work you’d like to do eventually and then a sprint backlog where you put work that you want to get done in this specific sprint. Knowing how much to put in your sprint backlog is tricky, so it’s best to use techniques like planning poker to determine how much work a user story will require. Then over time, you can get a feel for what’s realistic for each sprint.
The person who works to support the team, ensuring they make the most of the framework, is the Scrum Master. Not everyone on a Scrum team may be familiar with how it works, so the Scrum Master works as a coach, helping educate, lead, and keep things on track. They may also do things like hold 1-1 meetings with team members to keep their finger on the pulse and get ahead of potential issues.
If the Scrum Master is all about ensuring the team operates efficiently, the Product Owner is the person who ensures that efficiency is being put towards the right goals. Put another way, if the Scrum Master is tuning the engine, the Product Owner is navigating. Product Owners are the ones ensuring the team always keeps the ultimate product goal in mind. Otherwise, teams can easily get lost in process efficiency and forget what it’s all for.
Because Scrum is a framework within the broader philosophy of Agile, the main thing they share are their values. Each focuses on delivering value, fostering effective collaboration, transparency, feedback, etc. Both encourage teams to be adaptive, responding to change quickly and efficiently to produce more value instead of sticking with an approach simply because it was decided on sometime in the past.
Because of these similarities, it’s very easy for people to confuse Agile and Scrum, particularly when they’re just getting started.
The main differences between Agile and Scrum come down to specifics. For example, the Agile Manifesto is just 68 words while the latest Scrum Guide comes out to over 3,800.
So while working in an Agile way can mean a wide variety of things in practice, using Scrum means following a much more specific approach. This means that while Agile emphasizes the creation of teams that are able to self-organize and deliver value on their own, it doesn’t specify roles within those teams. Scrum on the other hand prescribed specific roles like the Scrum Master and Product Owner.
Importantly, Agile is also focused on continuous delivery while Scrum is more focused on continuous improvement. This is why many approaches to Agile like Scrum use some of the principles that encourage continuous delivery to also improve the teams themselves.
Before proceeding to learn how to choose the best framework for your needs, why don't you take a breath and see the state of Agile marketing this year?
By now it should be clear that Agile vs Scrum isn’t really the choice you need to make. Rather, it’s whether Scrum is the best Agile framework to use. So how can you decide whether Scrum is right for your needs?
In short, Scrum is ideal for stable teams whose work is easily broken up into sprints with clear goals and guidelines. So if your organization tends to form and reform new teams regularly, Scrum probably isn’t the best choice. Likewise if there’s no easy way for your work to be turned into individual parts that can be 100% completed in a single sprint, Scrum isn’t ideal.
That said, there are still ways to access all of the benefits Scrum offers even if the caveats we just mentioned apply to you by using hybrid methods like Scrumban. The 7th annual State of Agile Marketing Report found that this remains the most popular Agile approach along with Kanban and Scrum in large part because of its flexibility. This is also why hybrid methods predominate in most business functions, though developers still tend to prefer the structure Scrum offers.
To take one example, you can still plan your work in sprints, but manage that work using a Kanban board. This enables you to access the visualization and work management benefits of Kanban along with the structured sprints of Scrum.
That said, creating your own hybrid method without a firm understanding of Agile principles is a recipe for disaster in the form of “fake Agile.” This is when you think you’re working in an Agile way but are actually making mistakes that prevent you from getting the result you want. Avoiding this problem requires ensuring the people developing your hybrid approach have enough Agile knowledge and experience.
If you’re interested in trying out Scrum or a hybrid approach, you’ll need to begin with a foundation in Agile fundamentals. We offer courses designed to do just that! Whether you want to try learning at your own pace or prefer attending live courses where you can learn from real instructors who can answer your questions, our courses have the knowledge you need to begin your Agile journey.