Implementing Scrum: How Does the Project Manager Fit In?

16 January 2012

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!

Article Rating

Current rating: 4 (3 ratings)

Comments

Tom Mellor, CST,CSP,CSM,CSPO, 1/16/2012 10:35:33 PM
When I first used Scrum so many years ago, I had been a project manager at my little company for just a few months. I quickly realized as I sowed and honed my fledgling PM skills that much of what was expected of me in the role was contrary to my management and leadership philosophies that revolved around servant leadership and supportiveness of teams who ought to be trusted and empowered to do the work demanded of them.

In studying Scrum at that time, I immediately discerned the characteristics and behaviors desired (even needed) in a ScrumMaster and those aligned with my philosophies and behaviors. Over the years, my observations of many project managers reveal a wide variance of abilities and skills that tend to serve ScrumMasters and Product Owners well. I believe that the biggest problems and impediments to PMs becoming ScrumMasters are really systemic to organizations and cultural in nature. Many if not most organizations demand that their PMs be accountable for meeting project delivery timelines, staying within budgets and complying with product quality standards. These organizations also ostensibly expect and even require the PMs to employ those various necessary evils to be sure those objectives are accomplished. Consequently, the PMs often reach into their "bags of tricks" to make the magic happen and their survival is foremost in their minds and everything else comes after that, including serving the team.

Discussion about this article could easily take people down the slippery slope of debate within and without the agile community that seeming has increased over the last couple of years about the usefulness and even desire to have project managers on agile-based projects. Certainly, attention has grown with the intiation of the PMI Agile Certified Practitioner. The genesis of that matter harkens back to when executives from PMI visited the Scrum Alliance at the SA's Gathering in Orlando in 2008. They were appalled at the notion that the broader agile community had not approached this grand and noble organization for guidance and counsel as to how project management should be utilized in agile-based development. They were even more puzzled when I suggested that they should really reflect and contemplate on the internal reasons for why their organization had not been approached by the community. I went so far as to suggest that PMI's long advocacy of hugely bureaucratic processes and various other rather contemptible practices had sown the seeds of discontent among our growing agile community. Hole smokes, Batman! How could that be??!!

Well, now the issue has grown more and more contentious, it seems. I imagine there will be much commentary about this article. That is good, I suspect. There is no role of PM in Scrum. Ken Schwaber told me in one of our numerous discussions about it that he simply felt that PMs typically offered little value and often presented significant interference. When I asked him about what a company like mine with so many PMs should do with them if it adopted Scrum, he suggested that they become ScrumMasters, Product Owners, or perhaps most desirable in his mind, simple cease to exist. I imagine that he could not envision such contention over the matter, but then it was seemingly easy for all of us to believe this dragon would sleep and easily be slayed and to minimize the real influence and impact of these well-entrenched management cultures in so many companies. That was rather naïve!

I commend Tatyana for her courage in taking on this issue, especially in hostile territory. I wonΓÇÖt compromise on my opinion ΓÇô the project manager as a role should go away and be replaced with project leadership that is not role specific. I believe project management skills are certainly useful and for sure, the ΓÇ£right kindΓÇ¥ of leadership competencies and experiences are desired for people who take on leadership roles in projects, formally or informally. But, there will probably always be many organizations who will demand that PMs be part of their IT and product development work centers. We need to help them figure out how to apply Scrum in some sort of cohabitable manner. Thanks, Tatyana, for spurring thought and discussion. LetΓÇÖs hope it stays rational here.

Tom Mellor, CST and recovering PM
Petri Heiramo, CST,CSP,CSM,CSPO, 1/17/2012 12:46:25 PM
Thanks for writing the article, Tatyana. You bring up good points about real life challenges in getting the right people for the roles. I'll share one example and one warning. The example is from my past employer where we did train project managers (it was a software development supplier) to act as SM's (and usually had PO's from customer organization). In that experience, I would say that roughly 20% of the ex-PM's transitioned into SM role pretty well, becoming good SM's. About 20% missed the mark pretty badly and remained PM's with a new label. The remaining 60% did probably a passable job, that is, the teams did fare better than in the past, but not in great Scrum fashion. I would estimate that similar spread can be found in most organizations applying that tactic. The warning is related to combining roles onto one person. I have found that part-time ScrumMasters often become what I call ScrumSecretaries. These people don't have the time to do good ScrumMastering (and to train themselves to be one) and therefore focus whatever time they have to running the ceremonies. The challenging SM tasks, like building the team or helping the team develop their development skills and practices, tend to be forgotten. These Scrum teams may look ok on paper, but tend to lack the spirit. I would never recommend any organization who is _serious_ of getting Scrum work right to combine roles. -- Petri Heiramo, CST, recovering traditional process improvement manager
Sune Lomholt, CSPO, 1/30/2012 9:04:16 AM
Tatyana, thanks for your pragmatic and realistic observations. I with transitioning a large organisation with both projects that typically spand several organisational "silos". Furthermore, the business consists of several brands and channels. In such a situation I strongly believe that you have to make exactly the considerations you outlined. For example, if the projects spands several business and system areas level of coordination is increased. Another layer of complexity is the brands and channels which require more of the product owner role. Thus I have found that a project manager (or project leader) can be very beneficial for ensuring some of the coordination. In the very small projects we have usually seen that the project manager also acts as product owner with reasonable success. Though it does require the right skill and competences as you clearly pointed out. In fact it is interesting that the thoughts you elaborate on actually supports the agile value "individuals and interactiona over process and tools". When we make very strict rules on how roles we are focusing more on the theoritical process and forgetting to focus on the actual people involved and how we want them to interact.
Steve Hunton, CSM, 6/22/2012 5:28:23 AM
Tatyana, the biggest obstacles I face is getting the client to buy into Agile and then to run their projects in an Agile way. There are too many who talk about "doing Agile" but generally it's not done in a proper way. The role of the Project Manager does exist but it's the clients understanding of that role that needs to be addressed. Many of my clients will put a dedicated Product Owner into the project but some do so without a full understanding of what is expect of the PO. I think it's important to get the PO to run the project, to be responsible for it and make the key decisions which is essentially the Project Manager role. Because so many customers are so quick to assume that the Scrum Master is the Project Manager, it's up to us to set out the roles and responsibilities at the outset of the project and then for the Scrum Master to fully coach and mentor the Product Owner to take responsibility. If people are dedicated to the project then you can make this work, the Product Owner will do a great job and there'll be one more client that understands the distinction.
Sekhar Burra, CSP,CSM,CSPO, 12/17/2013 12:54:05 AM
I believe the biggest road block for implementing agile is the old stereo types that people carry from their traditional methods. Nevethless, a well articulated one..Good stuff Tatyana.

You must Login or Signup to comment.