Project management is a field rife with buzzwords and fancy terminology.
But I humbly nominate Scrum as one of the most confused—and confusing—terms in the project management universe.
The good news is that Scrum methodology isn’t nearly as complicated as it might first sound. In fact, once you get a grasp on the basics of Scrum, you might even find yourself applying it to your own projects—formal project manager or not.
What is Scrum methodology?
Scrum takes an incremental and iterative approach to development as a way to ensure the frequent delivery of working parts of the final product.
To put it even more simply, as Gartner research director Nathan Wilson presented at the 2017 Gartner PPM Summit, “Scrum is a way of organizing work to promote agility.”
Gartner defines Scrum as “a well-known agile development method that provides a simple project management framework for organizing teams and their approach to system development.”
And physics is what happens when things bounce off of each other.
The good news is that the basic concepts of Scrum methodology can be explained quite simply, and once you understand those basics, you can use Scrum methodology to foster better teamwork, improve lines of communications, and get things done more quickly in your business.
First, let’s introduce the product owner. The product owner is the person or entity who wants something to be made. The product could be a new piece of software, a new gadget, or a go-kart.
Next, the product owner comes up with a wish list of features—called the product backlog—that they organize by order of importance to the final product. Say, that the go-kart has four wheels and a seat—it is technically a go-kart. But it’ll work better with a steering system and brakes—and those are of high priority. Lower on the list might be a cup holder and headlights.
Now, the team (the product owner and the Scrum team) get together for sprint planning, which is when the team decides together what to work on first from the product backlog. This small chunk of tasks is known as the sprint backlog.
Here comes the meat of the process. With marching orders in hand, the Scrum team embarks on a sprint (typically a two to four-week period, depending on the complexity of the product) to complete a feature from the sprint backlog.
But the Scrum team isn’t just pushing forward with blinders on, because they get together everyday to communicate progress and issues. This meeting is called the daily Scrum, and it is overseen by the Scrum Master, whose job is to keep everyone on an efficient path.
The Scrum Master is basically like the coach, on the field with the Scrum team, removing distractions and making sure that everyone is sticking to the Scrum playbook. The product owner—on the other hand—is like the team owner, up in the luxury box asking for wins and trusting the Scrum team to deliver.
At the end of the sprint period, the team should have a functioning piece of something to show for their work. Whether that is an automated chat box or a go-kart navigation system, the important thing is that the product must actually work at the end of each sprint.
The sprint period ends after the allotted two to four weeks when everyone gets together for a sprint review to determine what went well and what changes need to be made, then the team picks a new chunk from the product backlog to get to work on, and the cycle starts over.
This entire cycle—starting with the sprint planning and ending with the sprint review—goes on until either the deadline has been reached, the budget is exhausted, or the product owner is satisfied with the final product, whichever comes first.
Either way, Scrum ensures that the most important features are included in the final product.
Scrum: A history
The precise origins of Scrum are difficult to zero in on. Like many great ideas, the seeds of what would become modern Scrum methodology seemed to be germinating in the minds of multiple teams around the world over a period of about a decade.
It is generally accepted, though, that the roots of Scrum can be traced a 1986 Harvard Business Review study by two Japanese organizational theorists, Hirotaka Takeuchi and Ikujiro Nonaka.
Their study, The New New Product Development Game, compared flexible, high-producing product development teams to their counterparts on the rugby field, hence the term Scrum.You can’t see it, but there’s a pile of floppy disks at the bottom of that pile.
“…as in rugby, the ball gets passed within the team as it moves as a unit up the field,” the article suggests.
Then, in the early 1990s, several New England-based software developers put Scrum methodology into practice at their companies, namely Ken Schwaber at Advanced Development Methods and Jeff Sutherland at Easel Corporation. Each would go on to write multiple books on Scrum help write The Manifesto for Agile Software Development in 2001.
With that said, there’s a lot of confusion about the relationship between Scrum and Agile.
The Scrum vs Agile fallacy
Scrum vs Agile is a popular Google search query, but it’s important to remember that Scrum and Agile have never been in competition with each other, and never will be, in the same way that no one will ever ask themselves, “Should I get a dog as a pet, or should I get an animal as a pet?”
Scrum is a process.
As software executive Todd Little said at the Gartner PPM Summit, “Agile is not a process, it’s a mindset.”
Scrum, on the other hand, is a well-defined methodology with clear roles used to help teams operate in an agile way. Extreme Programming, Lean, and Kanban are other strategies that promote agility. Some especially creative teams have even combined these strategies to come up with hybrid approaches like Scrum-ban, Wagile, Water-Scrum-Fall, and Waluigi.
Believe it or not, only that last one was a joke.
Like anything, Scrum has its detractors. But in an ever-changing world it is important to constantly assess what works best for you and your team and what doesn’t.
Just don’t be a ScrumButt.
Who does the Scrum methodology work best for?
The Scrum methodology is ideal for any team that is creating a product at the behest of a customer and where the exact specifications of the final product are not explicitly detailed at the outset.
For this reason, Scrum methodology is an especially good approach for software development (which it was originally designed for), along with industries like fashion, architecture, or automobile manufacturing.
Damien Filiatrault, a certified Scrum Master and founder of Scalable Path, writes that Scrum “works by breaking each project up into bite size chunks, prioritizing them and delivering them in short bursts,” which we know as sprints.
When you think about it that way, you could even use Scrum methodology to manage your household.
Take a weekend honey-do list. You’re the Scrum Master, your kids are the Scrum team, and your significant other is the product owner. You pull “mow the lawn,” “clean out the garage,” and “take the dog for a walk” off the top of the backlog, then get to work.
Meet back in two hours for a Scrum meeting over lemonade.
Software for Scrum methodology
Did you know that there are software tools made especially for teams using Scrum? Here are a few of them to check out, based on a search of Capterra’s project management software directory and organized alphabetically:
- OrangeScrum has a free open-source version with Kanban view, but Gantt Charts require an upgrade.
- QuickScrum is designed for software development teams, and features a simplified user interface for accelerated adoption.
- ScrumDo is not Scooby-Doo’s other nephew, it’s an organization and collaboration tool originally designed for software developers that has evolved to serve any framework.
- Scrumwise lets you design your own task boards, and it also includes burn down charts and Kanban boards.
- VivifyScrum is a web-based tool and mobile app for everyone from software teams to freelancers, designed by the web development team Vivify Ideas.
Can’t get enough Scrum?
If you just can’t get enough Scrum talk, here are a few more pieces that you might enjoy reading: