Scrum and projects

Time to read: 6 minutes

I need to get something off my chest. It's a personal thing, so don't mind me. But maybe it will get you thinking also. It's been on my mind for quite some time. Troublesome sometimes.... Here it goes.

Every now and then I see people with profiles saying "Agile Project Manager" or even "Senior Agile Project Manager". I've been trying to figure out what that means.

And by doing so, you start to think about "projects" 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 "the Agile Project Manager"?

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 something is there. So here we go:

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

Ok, it's according to Google..., but still, I guess we can agree 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. So we have a goal. 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. Sounds like we're also discovering here based on what we already know?

What is Scrum?

So to know if we can do projects with Scrum, we should understand what Scrum means as well. So we 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 becoming agile means we want to change that, right?

Agile Projects

So we than reach the term agile projects. 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

So, 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 project 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.

I could give you a list with the different responsibilities of a project manager and show which of the roles fulfill those in Scrum. But i'll leave them out for now. It's beside the point.

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?

Ok, I hear you thinking. With one team delivering one product: I hear you, makes sense. But we need projects and manage them when we scale right? 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.

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, deliver... I think 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 enormously 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?

What are you thoughts? Please leave a comment and I'm happy to discuss!