Northeastern’s Joe Griffin, Associate Vice President of Business Development and associate teaching professor in the Master of Science in Project Management program, explains the difference between Agile and Scrum in project management.
For those who have an understanding of agile and Scrum, you’re likely thinking, “What a strange title for an article.” If you recall your own introduction to all things agile, though, you probably remember how confusing some of the language around agile project management can be. I certainly found it confusing at first.
In a previous article on easing into agile project management, “agile” was explained first and primarily as a project management philosophy centered on specific values and principles. Think of agile broadly as a guiding orientation for how we approach project work.
For instance, if you’re following an agile philosophy in managing your projects, you’ll want to have regular interactions with the client and/or end users; you’re committed to a more open understanding of scope that may evolve based on feedback from end users; and you’ll take an iterative approach to delivering the scope of work. But how does one apply these and other agile principles and values in a structured or guided manner? Enter Scrum.
Download Our Free Guide to Breaking Into Project Management
A guide to what you need to know, from today’s in-demand skills to the industry’s growing job opportunities.
What Is Scrum?
Whereas agile is a philosophy or orientation, Scrum is a specific methodology for how one manages a project. It provides a process for how to identify the work, who will do the work, how it will be done, and when it will be completed by. Of course, you may ask, “How is that different from ‘traditional’ project management?” The best way to illustrate this is to share the process for how Scrum projects are executed.
Here are the steps you need to take, courtesy of Scrum Alliance, the largest professional membership and certification organization in the agile community:
- A product owner—the person who represents the end user or client—creates a prioritized wish list called a product backlog
- During sprint planning—“sprint” meaning a short period of working on project deliverables—the team pulls a small part of the scope of work from the top of that wish list, a sprint backlog, and decides how to implement those pieces
- The team has a certain amount of time, usually two to four weeks, to complete its work, but it meets each day to assess its progress—daily Scrum
- Along the way, the ScrumMaster keeps the team focused on its goal, kind of like a project manager, but allows the team much more self-direction and organizing
- 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—or rather, lessons learned
- As the next sprint begins, the team chooses another chunk of the product backlog, part of the scope, and begins working again
In many ways, this mirrors aspects of traditional project management. One of the key differences, however, is how one creates “shippable” portions of the project along the way rather than everything at the very end. So instead of waiting 12 months to deliver a final software solution to a customer using a more traditional approach, one may deliver six smaller versions of the software solution that continue to build on the previous release, allowing the customer earlier access to the software and the chance to iterate and adapt along the way.
It’s Not “Scrum or Agile?”
So the question is not, “Should we take an agile or Scrum approach?” Instead it’s, “If an agile approach is right for this project, then what agile approach or methodology should we use? Scrum, Extreme Programming (XP), or another?”
It’s important to remember that the “what will make a project successful” isn’t merely choosing the right methodology, but executing that methodology in a mature and skillful manner. It requires not simply knowing the steps of a methodology, but understanding how to communicate effectively, lead a team, apply critical thinking and problem solving skills, and be adaptable to the organizational dynamics and complexities around you.
This is why you should only consider the technical skills as only one component of the skills necessary to lead projects successfully. This is why Northeastern’s project management program doesn’t focus solely on technical skills, but pays significant attention to developing competencies in teamwork, communication, leadership, critical thinking, problem solving, and organizational awareness.
You will certainly learn about agile methodologies in our Graduate Certificate in Agile Project Management program or our degree concentrations in agile in our Master of Science in Project Management. But, more importantly, you will learn how to execute the projects in a skillful and mature manner from experienced professionals who have dedicated years to refining their own skills in the real world.