The Agile framework called Scrum defines three roles -- Product Owner, ScrumMaster and Development Team. Nowhere in the authoritative definition of Scrum, "The Scrum Guide", authored by Jeff Sutherland and Ken Schwaber, is there mention of a role, title, or person called a project manager. In fact, there is just one mention of the word "project" and that is in reference to a Sprint. The word "manager" doesn't appear even once. What is a project manager to do then in the context of Scrum?

In 2005 I conducted a session titled "Is Your Job Extinct?: The Role of the Project Manager and Business Analyst in Agile" at Project World and the World Congress of Business Analysts in Orlando, Florida. In the week or so before the conference, I happened to be co-teaching a Certified ScrumMaster class with Ken Schwaber. In a break during the class, I was rummaging around I my bag and placed a draft copy of my conference session slides on the table. Out of the corner of my eye, I noticed Ken pick up the draft and flip through it. Then he set it back on the table and walked away. A moment later I found what I was looking for and began putting things back in my bag. When I got to my draft copy, I saw that next to the session title Ken had scribbled in large red print, "HELL YES!!!" Indeed, in a world with Product Owners and self-organizing Development Teams, what need is there for a project manager role?

Project managers who attend my Certified ScrumMaster classes often ask what happens to the project manager role in Scrum. When this question comes up, I call upon the first value in the Agile Manifesto — "individuals and interactions over process and tools". "Project manager" is a title. Titles are in effect a tool. We use titles to convey status, authority, and to some extent, the nature of the work performed by a person. However, we should never allow a title to define the value of the work performed by that individual or the value of the individual themselves. We must always remember, titles are not people. People are people. And Agile is fundamentally about people.

To sort out the answer to the question of what happens to the project manager role, I lead the class attendees through a discussion in which we identify the various activities performed by project managers outside of Scrum.  As the activities are called out, I capture them on a flip chart until I've filled up the left half of the page. (I call this paper boxing. Even though there are more things we could list, we've run out of room on the page!) I ask if these are important activities. For the most part, they are. I ask if the activities go away with Scrum. For the most part, they don't. Then I draw a vertical line down the middle of the page. Reminding everyone that there are only three roles defined in Scrum and to keep in mind the rights and responsibilities of each role, I challenge the attendees to identify the Scrum role principally responsible for each listed activity. As they identify the roles, I record their responses on the right side of the page. In short order, as a group, we parcel out each of the project manager's activities to the appropriate Scrum role. While there is the occasional gasp or "ah ha!", Scrum's simple and clear partitioning of the three roles ensures quick consensus on which activities belong to which roles.

The question remains, however, as to what to do with the person who has the title "project manager". Well, the last thing we want to do is lose a multi-talented, experienced, highly capable individual. Good project managers possess all of these characteristics. Scrum is fundamentally a team-based framework. What team wouldn't want such an individual as a member of their team? After all, there is plenty of work to go around. The main challenge for project managers is letting go of trying to be principally responsible for the activities of all three Scrum roles. To successfully transition to Agile, project managers need to embrace self-organization and be open to discovery of where they can best add value. They have a lot to offer.