
Projects and Scrum: friends or foes?
Every now and then I see people with profiles like “Agile Project Manager” or even “Senior Agile Project Manager”. I’ve been trying to figure out what that means.
And by doing so, I started to think about the word “project” in itself. What is a project? Can we do projects with Scrum or are they two different things? I often get this question in courses also, often by project managers: “whats the role of a project manager in Scrum?”. There is an easy answer, but that does not answer the question: how do Scrum and projects relate to each other? And is there such a thing as an “Agile Project Manager”?
What is a project? Can we do projects with Scrum or are they two different things?
What’s a project?
My journey started by looking into the word “project”. Often we have used words for ages without actually knowing what it stands for. So maybe I could find the answer there:
noun: “An individual or collaborative enterprise that is carefully planned to achieve a particular aim.”
verb: “Estimate or forecast (something) on the basis of present trends.”
Okay, so this is according to Google — about the reach of my journalistic abilities. But still, I guess it makes sense. This is the first important finding. There are a couple of important set of words here:
carefully planned: so projects are about meticulous planning. Predictability. Often because we want to reduce risk by gaining knowledge. We’ll get into that later.
a particular aim: I like this one. We have a goal. That’s important. It’s always good to have a goal. It creates meaning for the team. Something to work towards.
In the verb we can discover more of the same: estimating is important, but also based on present trends.
What is Scrum?
To know if we can do projects with Scrum, we must understand what Scrum means as well. Let’s take a look at the single source of truth, the Scrum guide:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Difficult
There are a couple of things I find difficult about how we “run” projects. First: often the work is made more important than the people doing the work. Thus we shift people around from one project to the next. Often doing multiple projects at the same time, loosing a great amount of productivity and creativity.
Second: often the goal we set out to achieve is forgotten when the work starts. We make the planning and estimating more important and we focus on setting the scope and loose sight of the goal that needs to be achieved.
I have been part of these projects, where there were no adjustments, major phase gates and we deliver only towards an end date with a fixed scope and budget. But if we’re trying to be agile, that means we want to change that, right?
Agile Projects
Now we know what a project is. But what’s an agile project? Does it mean that we iterate towards our end goal, delivering value (products and services) along the way? Sounds like Scrum to me.
However, often an agile project is just a new name for a regular project. Where we don’t deliver incrementally but with one big bang. We put the scope of the project above the goal and we loose focus.
Is that were the “agile project manager” comes into play?
Agile Project Manager
An agile project manager manages the project in an agile way. I haven’t been able to find out what the exact responsibilities are of an agile project manager in comparison to regular project managers. It’s even so that I have approached a number of people on LinkedIn having that title and asked them what it means exactly. I got one response: “Because the market wants it that way.”

But I dó know that in Scrum, the accountability of the work a project manager used to do is distributed among the three different roles: Product Owner (maximizing the values of the product delivered by the Development team), Scrum Master (servant leader to the Development team, Product Owner and the organisation, teaching to use Scrum effectively, guardian of the empirical approach), and Development team (the people building and delivering the product to a DONE increment).
I once did a workshop with the steering committee of a project and explained Scrum to them. One of them said to the others pointing at the framework: “What are we steering? This should be enough to steer our project right?”.
The Scrum framework with the three roles should cover all the project management tasks a project manager has in a “regular” project.
Empiricism
With Scrum, empiricism is of great importance. We need to create transparency on our product and on our process all the time, so we can continuously inspect and adapt towards our goal.
Without making an actual product, it’s impossible to do this. We can’t inspect something that is not there yet, or only written down in a plan, business case or analyses. I’m not saying they are useless, but they need to help you get to a done increment of your product as soon as possible.
Risk
A lot of times I hear people saying that Scrum does not address risk. There is no document describing the risks, that may be true. But the best way to reduce risk is to create a shippable increment that can be used by customers. Maybe not the full-blown product or application with everything that we envision would be in it, but we can gather feedback based on the usage of the product and the customer can already use it to their advantage. It will make for a better product and will help us keep building the right thing!
If it helps, it’s also good to think about products instead of projects.
So how about scaling?
With one team delivering one product, you may think: this makes sense. But what if we need projects and manage them when we scale? We cannot manage 100 Scrum teams working on one product.
The answer to that: no, we cannot manage 100 Scrum teams working on one product. As all scaling-frameworks will start out with: don’t scale if you don’t have to. It will create dependencies and that means more coordination between teams, more effort of integrating, especially if you want to do that every Sprint, like in Scrum.
And because this article is not about scaling I will not answer that question. The world wide web is full of articles and consultants that are willing to help you manage those dependencies. I would like to start (and end) small:
Can we do projects with Scrum?
I think we can. In a sense, one Sprint within Scrum should be a project in itself, with start and finish. We work towards a (Sprint) goal, we plan, refine, forecast, build and deliver. The key is when we make it too big, we fall into a lot of those old habits. Trying to predict the future. Assume we can handle uncertainty without actually building a product. We try to manage risk by creating more documents and holding more meetings. That way we are actually increasing the risk tremendously on multiple levels!
The best way to reduce risk and predict the future is by shipping your product or service at the end of your Sprint. If that’s difficult: good, you’re on the right track.
Ask yourself this: if this Sprint would be our last, will there be value for my customer at the end of our Sprint?

Scrum can be used in projects if the scope is not fixed, but the goal is to deliver customer value.
I think we are evolving from a project driven mindset (project being a fixed time and scope) to a more product driven mindset. Scrum can be used in projects if the scope is not fixed, but the goal is to deliver customer value. And those insights are allowed to change over time. That’s why it’s good to think about products instead of projects. It’s a different way of looking at the work. Give it a try, you will find product and Scrum like each other even more than projects and Scrum.
This is an article by guest author Jasper Alblas. Jasper is a Professional Scrum Trainer for Scrum.org and an awesome Scrum Master. Together with The Liberators, he frequently teaches Professional Scrum Master- and Professional Scrum Master II-classes.
