There is no such role as project manager in Scrum. But there are project managers in the organization. So what is the project manager supposed to do when the team is transitioning to Scrum? The easy part is that this question has already been asked and answered so many times. The hard part is that the answers are different and sometimes contradict each other.
I'd like to share my experience of several possible ways the project manager can fit into the Scrum world. Each of these scenarios has worked well for at least one team. It's my hope that reading about these experiences will help other teams and managers find their own answers.
One of the strong opinions in the Scrum world is that the project manager must never become the ScrumMaster for a team. I once attended a presentation given by an Agile expert who told his audience of managers that the project manager must never be the ScrumMaster. Period. When asked, he said there might be unique cases in which such a transition would work, but those would be extremely rare. The reasoning behind this is understandable: the ScrumMaster is not the manager of the team, and people don't report to her. If, however, the role of ScrumMaster is assumed by the current project manager, people will still see her as the boss, and no magic wand will make them suddenly change their perception.
I don't mean to completely disagree with this opinion. What I'd like to do is to put it in a less peremptory way. Anyone can be a good ScrumMaster if he or she possesses the right personal qualities for the role. The official title of the person is the last thing we'd want to care about when assigning Scrum roles. What really matters is whether or not the person can actually do the job well. Why must project managers automatically be considered worse than others? Just like anyone else, a project manager can become a fine ScrumMaster if he or she has the knowledge, skills, and the right personal qualities.
Let's picture Project Manager Beverly, whose project is now transitioning to Scrum. Beverly has been in a management role from the very beginning of her career. She has never tried to pretend that she can write code better than her developers. Beverly has always respected her team and trusted its members to do their jobs. She has always believed that the best way to get results from the project is to build a team of motivated professionals, set a clear goal and defined priorities, let the technical people make the technical decisions, empower the team to take initiative, and make sure they have all they need to work and that nothing is standing in their way. The team sees Beverly as the one to go to with any problems or concerns; they know she's on their side and they feel comfortable communicating project estimates to her because they're sure there will be no "boss pressure." She, in turn, feels protective of her team and treats their needs with the same high priority as client's requests. It has always been Beverly's goal to facilitate effective communication, resolve and prevent conflicts, remove impediments, and ensure maximum visibility into the project for all the stakeholders.
Will Beverly make a good ScrumMaster for her team? Yes, she will.
The product owner is as important as the ScrumMaster. Without a good product owner, the project is likely to fail. While ideally the role of product owner should be assumed by the client, this isn't always possible—or the client is so busy that, though officially the product owner, he or she isn't always available to the team.
In this case there is a need for a product owner, or proxy product owner, local to the team. The project manager is a good candidate. Interfacing with multiple stakeholders to transform a never-ending flow of change requests into a prioritized list is something the project manager can do well and has most likely been doing before.
There are things that project managers usually do that aren't part of either the ScrumMaster's or the product owner's role description. When transitioning to Scrum, someone needs to decide where those responsibilities land. It may be beneficial to keep the project manager in such a role, while introducing the two new roles of ScrumMaster and product owner.
In this case, the project manager can maintain her management responsibilities; have the project team report to her; conduct periodic individual performance reviews; deal with promotions and salary raises; be the primary interface to higher management and other departments such as IT, HR, Accounting, and so on; and be the escalation point for the ScrumMaster to raise project impediments.
Another strong opinion in the Scrum world is that it's a bad idea to combine any two roles in one person. Again, I don't mean to completely disagree, because sometimes it really is a bad idea. But there are times when having one person play several roles can work well. It all depends on the knowledge, skills, attitude, and personal qualities of the person in question.
Below are the four ways in which a company could combine three different roles in one person. I had experience helping teams implement each of the four. Sometimes we were able to find the best approach from the beginning; other times we started with one option but, when we saw it wasn't working as well as we wished, we transitioned to another option. This worked fine. A negative result is still a result. We inspect and adapt.
If the project manager must never become the ScrumMaster, then it's an even worse idea to maintain both roles and have them played by one and the same person. Indeed, I've seen it failing to the degree that the team had to switch to another approach. More often, however, it's a popular way for organizations to approach Scrum implementation. Companies are hiring "Project Managers/ScrumMasters" who are supposed to be both the managers of their teams and good ScrumMasters. Is that possible? Anything is possible. A manager like Beverly would do a great job as ScrumMaster. If she also keeps all her management responsibilities that aren't part of the ScrumMaster role, she'll naturally combine the two roles.
Of course, one of the reasons this doesn't always work may be the project manager's workload. "A dead ScrumMaster is a bad ScrumMaster," after all. If the project manager is so busy with all the management work that he doesn't have time to attend daily stand-ups, it would be a better idea to go with Scenario 3. Keep the project manager as the project manager and let someone else from the team, someone with the right skills and attitude, assume the ScrumMaster role.
Similarly, if the project manager can make a good product owner and at the same time keep her management responsibilities, there will be a natural blend of those two roles. I've seen it work well for multiple teams. In this case there needs to be someone from the team assuming the ScrumMaster role, just as in any other case when the project manager doesn't become the ScrumMaster.
Combining the roles of ScrumMaster and product owner in one person is a subject worth a separate article, book, or maybe even a TV series—so much has already been said and written about it. It's a popular opinion that product owner and ScrumMaster roles contradict each other and thus can never be successfully played by one person. But what makes them contradict each other? Well, the product owner is the person who represents business stakeholders and wants the product out the door as soon as possible. Meanwhile, the ScrumMaster is the person protecting the team from business pressure, making sure they have time to concentrate on their work and being certain that there's nothing standing in their way. Thus a Scrum project is a constant confrontation between the ScrumMaster and the product owner; at some balance point between the two, the project can move in the right direction. How could these two roles be possibly combined in one person?
I'd like to disagree with this point of view, since the roles of ScrumMaster and product owner have never appeared to me to be in opposition. These are two roles that supplement each other in the mutual goal of establishing a healthy project environment and building the right product. The product owner is not supposed to be the one constantly bombing the team with new requirements and pushing it to commit to more than it could possibly get done. (That's what all the business stakeholders do.) And the role of product owner was invented to protect the team from this "noise," to have one person owning the backlog, which includes setting priorities and making sure the never-ending flow of requirement changes gets to the backlog and doesn't distract the team in the middle of the sprint. The product owner is also there to communicate progress to business stakeholders and set realistic expectations. The product owner is part of the team, playing a vital role for its success, and the success of the Scrum process.
For a better visualization, I like to picture the product owner as a frontline shield protecting the team from the outside world, while the ScrumMaster is the second shield. Whatever distraction manages to get past the product owner immediately faces the ScrumMaster. While the product owner would focus mainly on clients, the ScrumMaster would protect the team from any distractions coming from inside the organization.
The product owner owns the product; the ScrumMaster owns the process; the two of them work together to make sure the client, top management, and the project team are happy. So why can't one person do both? Isn't it exactly what has always been the responsibility of the project manager? Again, it won't always work, but it can and does work well given the right set of skills, knowledge, and attitude. Returning to the analogy above, if the product owner and ScrumMaster are one person, then he or she alone must be able to make the double-layer shield around the team.
This one is relatively easy, as it derives from the three above. If you can have one person play the two roles of project manager and ScrumMaster, or project manager and product owner, or ScrumMaster and product owner, then you can have one person play all the three roles at the same time.
This can be a beneficial approach to follow on a small project where there is not enough work for a full-time project manager, ScrumMaster, and product owner even if two of the roles are combined. In such a case, having all the three roles played by one person may save the project team from part-time management. What's so scary about a part-time manager? Ah, that is a completely different story. . . .
When looking for the best solution for your project, don't lock your mind into the cage of assumptions and prejudice. Anything is possible, and what didn't work for someone else might work very well for you. Start with what makes the most sense, see how it goes, inspect and adapt, and have fun!
Share on LinkedIn
Share on Twitter
4