Scrum is NOT for Project Management

Once Again for Emphasis: Scrum is NOT a Project Management Framework

Scrum is for complex product development, enhancement or maintenance, not project management. The authors of the Scrum framework assert that they designed all the parts of the Scrum framework to help organizations effectively deliver products into the marketplace.

Now, when we talk about “marketplace,” fundamentally what we mean is a place where people pay money for your product. They have choice. They don’t have to buy your product. And, at least potentially, there’s competition. You have customers who may buy your product. They may choose a competitive product instead. Or they may choose no product.

Product Management vs. Project Management

The Product Owner is the role in Scrum that’s closest to being a traditional project manager role. The Product Owner is responsible for the business success of your product and, in particular, that the work of the team has a beneficial positive return on investment.

If you spend $100,000 on a Sprint for a team, hopefully the value of the work produced is $150,000 or $1 million; at least more than the $100,000 expenditure.

The Product Owner creates a list called the Product Backlog—a list of all of the business features, benefits and problems that the team needs to solve in creating the product.

The question is: does the Product Owner create the list beforehand so it is completely ready? The answer is no. The list is evolving and this is one of the reasons why there’s some contradictions between Scrum and project management because of the very definition of a project:

“A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end.” PMBOK, 5th Edition, Chapter 1, Section 1.2, p3

A Project is a Unique, Temporary Endeavour

On the other hand, product development is not necessarily a temporary endeavour. The marketplace determines how long you work on a product, not a deadline or a scope definition. The work on a product continues as long as that product is earning revenue for the company. As long as there’s demand for enhancement and improvement of the product, development can continue.

This is really critical because it means that the Product Backlog is never signed off. It is never a fixed scope. It is never a deterministic list of what will happen. And it is constantly evolving.

In Scrum, the only change management control is whether or not the Product Owner puts something on the Product Backlog. That’s it. It’s completely open to anything else. The Product Owner controls the Product Backlog, determines what’s on it and what order things are listed.

The order of the backlog determines the order that things are worked on by the team. The Scrum Team works on backlog items and typically, a team will work in these blocks of time called “sprints.”

The idea of a Sprint is that it’s a large-scale time box. It has a fixed start and a fixed end. It’s a temporary endeavour that creates a new unique result. In other words…

A Sprint is a Project

Every single Sprint is an independent project.

• It starts with selection of scope—namely some Product Backlog items.
• There is some initial planning to figure out how to implement that scope.
• The team does the work.
• The team has daily status checks.
• At the end of the Sprint, the team hopefully delivers a valuable result. It also gets feedback from the marketplace again and not just from the stakeholders.
• Then the team figures out how to do their work better, so they run a project post-mortem called a retrospective.

And then the Team starts a new project immediately which is called… another Sprint! If project management occurs anywhere in Scrum, it is within each Sprint.

Scrum is a Container for Project Management

You do many projects in Scrum, not the other way around.  Unfortunately many organizations insert some aspects of the Scrum process within their traditional project management approach… this is not Scrum.  Or at best, it’s immature Scrum.

One of the key ongoing efforts within the team is the idea of Product Backlog refinement. This is an activity that the Product Owner does with the whole Scrum Team to constantly ensure two things:

1. That the Product Backlog represents the latest knowledge about the needs of the marketplace. What do our customers want and need?
2. That it is in a state of readiness for the next Sprint, which simply means that it’s in order. The Product Owner has put it in a specific order to say “hey, the items at the top ought to be chosen in the next Sprint.”

Now, the Product Owner doesn’t determine how many items the Scrum Team does.

What needs to happen is that there might be big business problems that need to be refined and split into smaller and smaller problems so that you can fit several into a single Sprint. These are still called Product Backlog items regardless of their size. Often, they are written as user stories. But that’s not a requirement of Scrum. That’s just a technique that a lot of people use.

Inside of a Sprint, you have a few different meetings, or ceremonies, which are very simple.

Making the Project (Sprint) Plan

At the start of the Sprint, you have Sprint planning: choosing the backlog items from the top based on the team’s understanding of their own capacity; how much work they can reasonably accomplish.

They make some sort of detailed plan or forecast about how the work will be accomplished. That’s the responsibility of the team, not the Product Owner. The team collectively figures out how to do the work.

At the end of this Sprint planning, the team sets a goal. This Sprint Goal is like a theme for the Sprint. You can think of it almost like a project charter for the Sprint. What is the purpose of our Sprint? Why are we doing the work in this Sprint?

The team uses the Sprint Goal to guide the work as the Sprint is going along so that, if there are unexpected things that arise, the Team makes good trade-off decisions.

Collaboration

Scrum also differs from traditional project management in a fundamental way: the whole Scrum Team is self-organizing. Individual team members aren’t assigned tasks, they volunteer for tasks and activities. They collaborate. No one is ever told exactly what to do or how to solve a problem.

For example, Wilson might say “hey, I want to draw the little cloud for the user stories on the diagram,” and no one can say no. But maybe Sue Joy says “actually, I’d like to help with that. Let’s do it together.” That’s also allowed.

Self-organizing people are free to collaborate—to work together on an activity, a task or a Product Backlog item.

If I come along and say “Jessica, why don’t you work on the big Scrum circle?” That’s not allowed. I can’t ask or suggest or tell anyone on the team, regardless of my role—whether I’m a team member, the Scrum Master, the Product Owner or someone outside the team—no one can tell individual team members what activity to take at any given time.

There is a middle ground. You can say “oh gosh, I recognize a problem and I’m not able to solve it myself.” You can bring that problem to the attention of the team and say “hey team, we’ve got this problem. Can we work on it?” or “who would like to work on it?”

But you can’t look someone in the eye and say “who would like to work on it?”

And of course, as a Scrum Master, you would never assign a task yourself. If you have a background in project management or if you’re the kind of person who always thinks that way, this will be hard for you. Encouraging self-organization is a very challenging task but it’s your most fundamental practice in becoming a good Scrum Master.

Releasing the Pressure

The intention is that there’s no pressure for any particular individual to do any particular task other than your own individual skill, motivation and capacity. You as an individual assess whether you are able to contribute and how you will contribute.

The Product Owner may want approve it or present a potential goal, but ultimately it’s the team’s responsibility to create it and commit to it. That is what Scrum is designed for.

There’s a simple analogy: hammers are really good at pounding in nails. That’s what they’re for. But if you really want to, you can use a hammer to crush rocks or to pound a screw into wood if you don’t have a screwdriver around. But those other applications aren’t the intended purpose for the tool.

Scrum liberates the team and its members from the traditional confines of project management, freeing them to self-organize, set their own goals and decide collaboratively what work to do and how to accomplish it.

And just so we’re clear, project management has no place in a true implementation of Scrum.

—

This article was adapted from a transcript of a recent Certified ScrumMaster class that Mishkin taught in Toronto, ON.

If you find this useful, please consider contributing with our
“Value for Value” model.