Arguably the most structured framework of the Agile methods, Scrum was firstintroduced 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.

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 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 great 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 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.

Lean

Agile project management dictates that you break your work up into smaller, shippable portions, but it doesn’t say much about how to manage each of those portions of your project. Scrum tries to fix that with managers and meetings; Lean, on the other hand, adds workflow processes to Agile so you can ensure every part of your project is shipped with the same quality.

With Lean project management, you’ll still break up your project into smaller pieces of work that can be completed individually. You’ll also define a workflow for each task, something that’s reminiscent of the Apollo project and its five box system. Perhaps you’ll have a planning, design, production, testing, and shipping phase—or any other workflow of phases that you need for your task. Cooking a meal might need a preparation and cooking step, while a writing workflow might need an editing and fact-checking step.

Lean’s stages and their flexibility make it a great system for making sure each part of your project is done well. It doesn’t have Scrum’s strict deadlines, or force you to work on one thing at a time as TPM does—in fact, you could have various tasks in various phases of your Lean workflow at the same time. What it does do is let you build a system tailored to your team.

Just like Agile, Lean is more of a concept than a set-in-stone project management system. You can use the Lean ideas, and build the system you need for your projects.

LEAN STRENGTHS

If you liked the idea of Agile, but wanted a way to make sure each part of your work is consistently finished with the same level of quality and oversight, Lean gives you the extra tools you need to make that happen. It’s still flexible—you can define the stages of your project portions as you want—but there’s enough structure to make your projects a bit more guided.

LEAN WEAKNESSES

Every part of your project doesn’t necessarily need the same level of oversight or the same steps for completion, but lean treats everything the same. That can be one major downfall in using it to manage projects with diverse parts that all need completed.

Lean also doesn’t have any process to make sure the final project is completed, making it easy as it is with Lean to let your projects drag on forever. It’s again something communication can clear up, but it is worth keeping in mind.