What Happens to the Project Manager?
The person stays, the role not
The third and preliminary last article in this miniseries deals with the question of what happens to the project manager when a team goes agile.
Before continuing here, you might want to read:
- “Projects and Agile — a Match Made in Hell?” (No!), and
- “Project Managers and Agile — an Ill-Fated Union?” (Yes!)
Old and new roles
Organizations generally struggle with answering the question of what to do with roles that become superfluous or even are at odds with new ways of working. Often the easy path is chosen, which is to keep the “legacy” roles like project manager while supplementing new ones as in product owner and scrum master.
It isn’t uncommon to even see entirely new roles being invented and added to the mix. Or weird combinations (IMHO) like “agile project manager”.
One-off roles for specific contexts within certain teams are not a problem, but organizations defining roles and processes by which all teams have to work are.
This article deals with the specific role of the project manager.
The project manager
Firstly, remember that not all product development benefits equally from being done agile. Some work in your organization might still be best done the Big-Design-Up-Front way, with project plans, central coordination, etc. Those endeavors probably continue to require project managers to ensure a smooth and successful execution.
But, for those cases where you would be better off with an agile way of working, what then happens to the project manager?
It is just easier to use established terminology, which is why I again will use the Scrum framework here. As you already know, I’m not in any way implying that agile has to be Scrum or that doing Scrum makes you agile.
Say you have a project manager but want to go and experiment whether Scrum is the right fit for you. Don’t just leave the project manager hanging, and add a product owner and a scrum master to the mix. That’s the easy, yet the wrong way out. As in Scrum, the product owner, scrum master, and developers take all the responsibilities formerly held by a classical project manager, keep the latter will create all kinds of confusion. Instead, figure out what her¹ strengths are of said project manager. Depending on that, she might make a good product owner, scrum master, or developer.
If the project manager used to have an excellent working relationship with the stakeholders of whatever product she was building (remember, everything is a product), if she understands the business well, is a visionary, and decisive, she might make an excellent product owner.
If she, on the other hand, is exceptional in organizing things, facilitation, servant leadership, removing impediments, understanding agility, and envisioning a truly agile team, then maybe she is meant to be a scrum master?
Why not become a developer², though? This shouldn’t be seen as a demotion. The developers build the product. They are the ones who, at the end of the day, create the value. They might not be as efficient and effective as they are with good leadership around them, but without the developers, there wouldn’t be any product at all. Developers are the most important people. Everybody else is there to make their work better and faster — which potentially multiplies the teams' productivity, of course, but that’s another story.
Whatever you do, look at each individual case. See it as a chance! Don’t do an automatic mapping from project manager to say product owner. Easily done, yes, but you’d be sending the wrong signals (“product owner is just the new word for the project manager”).
“Nothing worth having comes easy” — Theodore Roosevelt
The Difficult Discussion
We also have to address the elephant in the room: Yes, sometimes everybody, including the project manager herself, would be better off when she finds a different employer. There is still — and probably will be for quite a while — lots of demand for good traditional project management out there.
Bad Compromises?
Unfortunately, many organizations take the easy route and stick to all the roles and, as such, now have product owners, scrum masters, and project managers on their agile teams?
What problem are they solving apart from avoiding having to make difficult choices? I think none.
Is this your organization? Is it being clear about what the responsibilities of the project managers on your agile teams are? And are those then responsibilities that were removed from either the product owner, the scrum master or the developers? And did you remember to tell everybody this? Or were the other roles left in the dark and are now slowly finding out that what you call a scrum master or product owner and what literature generally suggests these roles encompass, are two different kettle of fish?
And no, calling it an “Agile Project Manager” (figure 2) doesn’t help either. Not if you continue to have product owners and scrum masters alongside. It doesn’t make your organization more responsive.
Will the “jack of all trades, master of none” solution (figure 3) work? I seriously doubt it. I think it is much more likely to be a smoke screen to cover up that we have no clue what the person holding this role will be responsible for. In German, we’d call that an “Eierlegende Wollmilchsau” which literally translates to “egg-laying wool-milk-sow”.
If you go down this road and combine roles from both the classic project and the new product focused world, there is a good chance you will sow seeds of uncertainty, frustrated team members and ultimately face serious difficulties due to new levels of confusion.
For agile teams, I’m suggesting taking the hard step of getting rid of the role of a project manager and making things as simple as possible. Should that turn out to be too simple (which I predict rarely will be the case), each individual team can always decide that they — in their specific context — indeed require a project manager. But that’s up to each single team to decide, not the organization as a whole.
The simpler the process and the structure, the more flexibility do your teams have to find a setup which works well for them and their particular situation (which btw. changes all the time, that’s why they need to be agile).
Now, take a look at your favorite scaling framework. Does it maybe have too many roles? Is it too complicated? Did you add even more roles to it? Did you hold on to some legacy roles? Why? Do they solve a real problem?
I am not saying you have to do Scrum. I am not saying you need to have a role accountable for effectiveness and one for efficiency (though I like that model). I am not even saying you can’t have project managers anymore. I am saying that many organizations have some unpleasant work ahead of them. They need to weed out some of their many roles. Their current operating model has become too complicated. Dealing with the project manager vs. product owner vs. scrum master is an opportunity to take one step towards a simpler setup.
And hey, perhaps you consciously want to keep the project manager, but instead not have a product owner or scrum master. That’s fine to. It is the overlap of responsibilities of these three roles (as they usually are defined and lived) which is the problem. Even if you keep all three roles, you have to make clear what everybody is responsible for.
Remember, agile means delivering in small increments and receiving feedback to improve the product (and your process) continuously. How you achieve this doesn’t really matter. If you can do it with 100 different roles overlapping in responsibilities and what not, so be it. Congratulations. I just haven’t seen that in my career. I have only observed that kind of structure leading to plenty of problems and confusion.
Conclusion
Reduce your complicatedness and get rid of some of your roles. It is like cleaning up your basement — really hard to do, but the result is very rewarding. Clarity is the consequence. Much easier to navigate for everybody. Lean out your organization. A few guardrails rather than many complicated rules will make your self-managing teams much more efficient over time. They will thank you for it. And you them.
Creating and removing roles is not symmetrically effortful. The first is super easy, while the latter is very hard. Think three times before you create or even carry over a role from “the old world”.
Strive for a Minimal Viable Bureaucracy (MVB) and invest continuously in leaning out your organization. Reducing the number of roles is just one aspect.
Most importantly, remember that I was talking about the role in this article, not the person.
As encouragement to all project managers out there: I presume you like picking up something new on your time anyway. Like learning a new language, a music instrument, cooking or finding a new hobby. Why not do the same in your job? If you were good as a project manager, you’ll probably do great as a product owner, scrum master, or developer. It is extremely rewarding to learn new things.
As a fellow Dane said
“To dare is to lose one’s footing momentarily. To not dare is to lose oneself.” — Søren Kierkegaard
Always …
Any feedback is welcome, even tiny things like spelling mistakes or sentences which are hard to understand.
I enjoy discussing. I enjoy being challenged. I enjoy learning about and experiencing new perspectives.
[1] … or he. I am not too fond of spending a lot of energy on the gender discussion, and I won’t write “them” because that’s grammatically wrong. That’s why I decided to refer to everybody as a female. It could just as well have been a male, of course.
[2] The word “developer”, of course, spans over a lot more than “just” software developers. Designers, testers, engineers, business analysts, requirement engineers, etc. — they are all considered developers (in Scrum anyway).
