Arguably the most structured framework of the Agile methods, Scrum was first introduced in the 1986 as a way for “teams to work as a unit to reach a common goal,” according to its inventors Hirotaka Takeuchi and Ikujiro Nonaka. Scrum takes parts of Traditional and Agile project management ideas and combines them for a structured yet flexible way to manage projects.
Like Agile, Scrum breaks projects up into tasks that are completable on their own, and then assigns each a “sprint”—two to four-week slots of time dedicated to ship that phase of the project, with daily sprints to ship some part of that phase. It’s that focus on time that makes Scrum a bit more like TPM, bringing more structure to the Agile idea.
Then, to make sure the project is progressing as expected and meeting goals that may have changed along the way, Scrum requires a reassessment—and potential project changes—at the end of each sprint. It also divides responsibilities into three roles: the Product Owner (PO), the Scrum Master and the Team.
The Product Owner, who should be deeply familiar with all aspects of development, makes sure that everything aligns with business goals and customer needs with a mile-high view of the overall project. The Scrum Master is the team cheerleader—a liaison between the PO and the rest of the team—who makes sure the team is on track in each individual sprint. The Team then is the people working in each sprint, dividing the tasks, and making sure everything is shipped.
Scrum Structure
With all this management and focus on deadlines, Scrum’s main structure revolves around 5 meetings: Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
- Backlog Refinement Meeting (also called “Backlog Grooming”): This meeting is much like the planning phase of TPM and is held on day one of each sprint—you’ll look over the tasks left in the project, things left behind from previous sprints, and will decide what to focus on. The PO makes the call on how to prioritize tasks, and this ultimately determines how efficient the sprints are.
- Sprint Planning Meeting: Once the PO decides what to focus on, this meeting helps the team understand what they’ll be building and why. You could share “user stories,” describing features from the customer’s point of view, or could simply divide tasks for each team to work on during the sprint.
- Daily Scrum Meetings: Simple daily meetings that should only last about 15 minutes, Scrum meetings are a way for team members to update each other on progress. This meeting is not the time or place to air issues—those will go to the Scrum master outside of the daily meetings—but instead is a place to keep the ball rolling.
- Sprint Review: Since a potentially shippable item is expected at the end of each sprint, the Scrum framework naturally places an emphasis on review. Team members will present what they’ve completed to all stakeholders. While this meeting pushes accountability, its goal is to make sure that the sprint’s completed items match up with business and user goals.
- Sprint Retrospective: Held immediately after the sprint review meeting, the Sprint retrospective is full of collaborative feedback. Looking at successes and hold ups, everyone decides what is working (what they should continue doing) and what isn’t working (what they should stop doing). This should inspire the focus of the next sprint.
Where other project management systems might look like they simplify your projects and make them seem more manageable, Scrum can at first glance look overwhelming. You’ll need to delegate responsibilities and plan extra meetings—but that overhead can help ensure your projects are successful and stay on track. It’s a structured way to make sure everything gets done.
Scrum Project Management Strengths
Scrum is designed for projects that need parts of the project shipped quickly, while still making it easy to respond to change during the development process. With so many meetings and ways to delegate tasks, it’s also great to use when parts of the team may not be as familiar with a product’s context (i.e. developers from different industry backgrounds working on a system for the financial sector). You’ll always have someone looking out for the project as a whole, so if each person on the team doesn’t understand the entire project, that’s OK.
Netflix is a notable example of Scrum’s ability to help you ship fast. It updates its website every two weeks, and Scrum was a good match because it stresses the user experience, eliminates what doesn’t work, and leaves a small window of time to get things done.
For each site iteration, the designers would test new features, forget the ones that didn’t work out and move on to new functionalities. Most of the benefits the Netflix team saw with Scrum was the ability to “fail fast.” As opposed to launching one massive redesign with many components, their bi-weekly incremental design changes were easy to track; if something went awry, they knew exactly what it was tied to—and could fix it, fast.
Scrum Project Management Weaknesses
Like Netflix, you may experience downfalls of Scrum, such as upset designers who saw their beloved work chucked after testing showed it didn’t work—especially when the testing comes so quickly, and some may feel that the new ideas would work with more time. You might also have trouble adjusting if your team is accustomed to long release cycles—or, depending on your work, you might find shipping so often isn’t necessary.
Scrum’s meetings and management overhead can also be overkill for some projects, turning into something where you’re more focused on planning sprints than you are on actually getting work accomplished during them.
