From Project Manager to Scrum Roles

“How does the PM role translate to Scrum?” is one of the more typical questions in my Scrum courses. Here’s the results of one such exercise that we did with the participants to find an answer. 

As can be seen, a large chunk of typical project manager responsibilities become things Product Owners (green in the picture) are supposed to own, and another big chunk is for the Development Team (red). There’s a few splashes of blue (for ScrumMaster) and a sizeable number of items that Scrum is silent on (yellow). 

 

What is/was project manager anyways?

“Project” is an execution management structure. Projects are set up to deliver some target outcome, usually within specified timeline and budget. 

“Project manager” is thus a person who is supposed to manage the project. 

Since projects are about execution, the question of value is often secondary. Or if not secondary, but it’s typically given from the outside and assumed to be known (that is, that the person or board who granted the budget also evaluated the value and found it sufficiently high to warrant the budget). Therefore most of project management is about managing work and cost, because the improvement of value is usually not part of the assignment. Return-on-Investment (ROI) is optimised when the cost is minimized.

Project managers are also hubs of communication. Keeping track of information and status, using that to determine where the project is compared to expectations, and deciding on actions to possibly steer the project (and at least ensure that tasks are being worked on by the right people). Since the traditional project management is about task breakdown, definition and distribution, and then putting them together for releases, this kind of centralized coordination makes sense. Individual project members are experts in their own contribution and do not necessarily even understand all the elements of the big picture. Besides, communication is away from getting their own piece done.

 

What PO gets

Product Owner is a business role. A huge part of the role is the responsibility to understand what value means, and then communicating that to the Team through the Product Backlog, priorities, and milestones. They also get some responsibilities that relate to shorter term, but they often share them with the team.

As can be seen from the picture, the PO inherits all responsibilities regarding longer term progress and project purpose. PO is not a business analyst; the team can usually handle most of that, as long as they have clarity of what is the agreed scope of each selected story. 

“Project”, however, is a poor concept for PO’s in many cases. Even the role name says “product”, and implies that value is an integral part of the role. Unlike projects, products have a variable value element – it is no longer fixed. Increasing value and ROI during the project is one of the essential goals PO’s have when leading development. This is something most PM’s are not experienced in. 

So PO’s may have to be well versed in all kinds of things outside classical project management – sales, marketing, business management, product strategy, product innovation, customer development, etc. In some organisations, the reality of PO’s is quite far from that level of responsibility, so many PO’s can be effective without deep understanding in those areas.

It’s not surprising that many PO’s have titles like “product manager” and “service manager”, although “product owner” is becoming more common.

 

What Team gets

The Development Team is self-organizing, and that means that they adopt all responsibilities regarding the development of the product and the management of that work. This also includes all communication within the technical peers and other teams.

In many ways, the Team role is the most familiar for most organisations, but the challenge of self-organisation is, well, a challenge to most supposedly-self-organizing teams. Most teams struggle taking ownership of their own work management, and often benefit greatly from having a competent ScrumMaster or Agile coach working with them. 

 

What ScrumMaster gets

As seen in the diagram, the SM gets hardly anything. They do receive a supporting role in risk management, escalations and kick-off (according to the picture). Thus, the typical perception that PM’s become SM’s (or “Agile Project Managers”) is a bit unfortunate, since it does lead to quite a few negative behaviors. 

So most of the responsibilities of the ScrumMaster role come from outside the PM role. However, they often do spend significant time helping the PO and the Team learning their roles, so they do at least need to have an understanding of all the responsibilities and activities of those roles. 

All that said, there is one thing that unites the SM and the PM – they both deeply want the project (or product) to succeed. They just take a 180° difference stance on how to reach it. The traditional PM is expected to be right there in the middle and take ownership of taking the team to success. It is their hands that move. ScrumMaster instead sees that they have have find a way to get everyone else’s hands moving, and that in order to achieve that, they have to let go of direct personal responsibility. 

 

And the yellow stuff?

Scrum is silent on pretty much anything outside the immediate control framework, so it’s up to the users of Scrum to determine what they will do with those items. At least in consultancies, there are many things that just need to be done, and someone has to do them in order for the project to exist – contracts, invoicing, customer relationships, steering groups, reporting, etc. I call this set of activities the “project management service”. 

I’ve seen many solutions in organisations. Some teams actually have a project manager who does those things, but they let the PO, Team and SM take care of the content. In some teams, the ScrumMaster does those things, but they need to be careful not to become a PM in their relationship to the Team. Sometimes one of the team members, a senior probably, will take care of that “service”. Sometimes it’s someone outside the team, like an account manager. 

Whichever way it goes, it is important to recognize that a person doing those activities should not be granted formal authority over the team. They should see themselves an enabler and ally for the Scrum Team. They are managers of the things, not the people. And if they are granted organisational power over the Team, they must be very careful when to use it, in order to not break the self-organisation of the Team.

 

So what should a PM do when transitioning to Scrum?

There are lots of different PM’s, and thus it greatly depends on the person themselves.

• Some PM’s already act largely like a ScrumMaster in their PM role, so for them, becoming a ScrumMaster is often a very small step.
• Some PM’s are very business-oriented, so for them, the PO role may come very naturally. 
• Some PM’s are very technical in their background, and they might actually like going back to technical roles and become Team members again.
• Some PM’s seek more managerial roles, and seek to support Agile teams from various organisational positions.
• Some PM’s struggle to find a natural place in the new system and some do check out, looking for more traditional project setups.

Regardless of the chosen role, it is critical that the person understands that their role is no longer to tell the Team what to do. This may be harder than most expect :). 

 

The Essence of Agile Thinking

When you start to use Scrum (or any other Agile framework), it will suck. So you try to fix it. Your mindset will define which way you will go – either back to Waterfall or to actual Agile.

To understand what I mean, please imagine a project that seeks to deliver a customer a system they request for. At the end of the project, we find out that the customer doesn’t like the outcome, despite the fact that it matches their original request. 

 

Why did that happen?

Our brain seeks to understand why things happen around us they way they do. These explanations, for the scenario above, tend to fall into two primary beliefs for the cause:

1. We didn’t do good enough a job in defining the requirements up front, so we naturally built the wrong thing since, well, we built the wrong thing, as planned.
2. We did not show the results early enough for people to detect the difference between “want” and “need”, so we were exposed to actual requirements too late.

The first one we might call “predictable mindset” (or “waterfall mindset”). It is founded on the belief that the most optimal way to build something is to find out all the requirements up front, then plan the optimal way to solve the problem, and finally deliver it according to the plan. In this mindset, when things go wrong, it is because we didn’t do some earlier steps well enough, and the processes are fixed by doing (and spending more time on) the early steps better next time.

The second one we might call “emergent mindset” (or “Agile mindset”). That mindset is founded on a belief that people suck* at defining requirements up front for anything more complicated than a simple physical thing (and there’s a really hilarious video about defining requirements for sandwich) and that the most effective way to detect what people really want is by showing them something and then listening what they say when they try to use it. Obviously, a person with this mindset will think first, to establish what to build as a first iteration, but they never trust the input completely. 

You can “listen” to your own mindset by retrospecting what was your initial reaction or interpretation to the scenario, or when things go wrong in real life. Which response was stronger? Sometimes you trigger both, but probably one tends to dominate in most circumstances.

[* An Agilist would never blame anyone for that, though, since they recognise they themselves are just as bad at defining requirements.]

 

How does this belief affect our use of Agile frameworks?

Let’s imagine another scenario. Let’s say we try to use Scrum for the first time. Unsurprisingly, we will discover many things that do not work fine. The new process feels awkward and in many places it doesn’t live up to our expectations**. Thus, we need to change our ways of working in some way in an effort to try to fix [our use of] Scrum. 

[** Scrum has never promised to fix our problems; only that it will show all our problems to us. It’s up to us to fix our problems.]

If the predictable mindset is strong in us, then the way we fix our problems is by trying to improve the inputs into our process. We will add preliminary steps and effort. We will try to do the up-front planning better, in the hopes of delivering a righter product in a righter way. Multiply this a hundred times, for all the problems that we discovered, and what do we get?

We’re back to waterfall. In our efforts to fix our Scrum, we rebuilt the up-front planning, try-to-do-everything-right-the-first-time process. Every step of the way we tried to improve things, yet we got back to where we tried to get away from. 

If the emergent mindset is stronger, then the way we fix our problems is by introducing intermediate points where we expose our work to our users and customers, and seek their feedback on the things we’ve completed so far. In order to do this, we need to build less at a time, and make it work so that it can be used in some way. It will also force us to discover techniques that allow us to design, code, test, and deploy in smaller steps. Multiply _this_ a hundred times, and what do we get?

The process we end up with may not be Scrum, but it will be very effective at discovering every possible assumption we might have and aggressively testing it on our users. The process will find ways to very rapidly deploy very small pieces of functionality, and also modify anything we have done in the past without excessive costs. 

As a classic Agile quote says, we learn to “turn on a dime, for a dime”, or any other suitably small coin.

And that’s what Agile techniques are all about – enabling us to inflict change on our product without killing ourselves doing it. 

 

It doesn’t really matter which framework you start with

My favourite is Scrum, but I like Kanban almost as much. Lean Startup is awesome, too. I like SAFe less, and LeSS more. But never mind, the selected framework is not really relevant. What is relevant is how you modify it, or how you modify your organisation, as you learn the challenges the selected framework reveals to you. 

The way you interpret causality, and consequently how you try to fix the system, define whether you can be Agile or not***. That mindset defines where the road will take you, regardless of where you started from. It is impossible to make Scrum or Kanban work if your improvements re-establish up-front effort as the standard solution to problems. 

[*** Assuming you want to solve complex problems using Scrum and Agile]

 

So is predictable mindset just wrong?

No. There are many systems, mostly mechanical, where the causality is in fact predictable and where the right approach to fix processes is to increase (or improve the quality of) up-front planning. Most of engineering is in that camp. Also a lot of manufacturing and logistics is there. Waterfall is the archetypal framework to developing those predictable systems. Our very advanced technologies and capabilities are a testament to the value of the mindset, and its application there.

The problem lies in using the same mindset in systems that do not have predictable causality. We need the emergent mindset to explain how to deliver value and improve processes in social systems. And even in engineering, the research and planning of how to be able to do something is a human system and thus “Scrummifiable”, though not in exactly the same way as in software.

So I do not wish to remove the predictable mindset from engineering, only to highlight that a single mindset is not sufficient to understand our reality and be effective in unpredictable systems.