When the Scrum framework is introduced within an organization or a team, I often notice a lack of understanding regarding the Project Managers’ role. What do they become in an Agile organization? Do they still have a place?
Over a few weeks, several people have asked me these questions. During a Professional Scrum Master II training, I had the opportunity to participate in an exercise that allowed me to confirm my interpretation in a very practical way.
Let’s start with this exercise. Imagine cards describing responsibilities, for example: Sprint Backlog, Personal Growth of the Dev Team, Impediments, etc. Participants need to sort these cards by person responsible: under the Dev Team, the Product Owner, the Immediate Supervisor, the Scrum Master or the Project Manager.
At the end, the hammer dropped: no responsibilities for the Project Manager. So the role has become obsolete in a Scrum Team. As for the immediate supervisor, he continues to have his own responsibilities that are, however, far from micromanagement.
How is the Project Manager’s role becoming useless? Even though it is one of the key roles of traditional project management…
In the end, the answer is pretty simple: the Project Manager’s responsibilities are assigned to the different other roles of the Scrum team.
It is difficult to establish a list of tasks for the Project Manager, because it very often depends on the company. Here is a list of responsibilities that appear to be what is most frequently expected:
- Writing the specifications
- Defining the priorities
- Assigning the tasks
- Managing the team
- Assessing the risks
- Ensuring the quality of the development
- Defining the work process, the methodology
- Providing a technical solution
- Communicating and reporting to hierarchy and clients regularly
- Controlling the budget, the delays and the scope of the project
- Supervising the maintenance and evolution of the project
This list is derived from the Guide des métiers (in French).
If we take a look at these responsibilities again and compare them with the responsibilities of Scrum team members, we notice that they are divided between the different roles:
During an Agile transformation, some responsibilities usually linked to the Project Manager will be redefined. For example, communicating and reporting to the client will become: “collaborating with the client.” The Review is one of several occasions to do this. In the same vein, I tried to put only one responsible role per task in the table above. The topics could, however, be carried by several team members.
Let’s not forget that being Agile allows us to ask ourselves the necessary questions (inspection) and to adapt ourselves to find the best ways of working together to deliver value. This value should be delivered as fast as possible to validate the result as soon as possible and mitigate risks. So it really is teamwork for most of these responsibilities.
I often notice that people gravitating around a Scrum team who do not know the framework well, talk to the Product Owner or the Scrum Master as if they were the Project Manager.
Five years ago, I was beginning as Scrum Master with a new client as I had been Project Manager for many years. I quite naturally turned toward “Scrum Mastering” because I already had a fondness for people and work processes. And however, it was sometimes hard to get rid of old habits…
I remember attending meetings with the Infrastructure department without any other team member present, to coordinate tasks related to creating servers and installing firewalls… I challenge you to find a section in the Scrum Guide showing that it’s the Scrum Master’s responsibility. In hindsight, I see the importance of letting the development team be responsible for these tasks. They need to feel responsible for carrying the technical solution in its entirety, not only for the development.
During a transition, it is sometimes difficult for former Project Managers to find their place in an Agile Organization. One of my teams had the chance of being helped by an Agile Coach when they initiated the transition project. During a round table, we were presenting ourselves and someone said: “Before, I was Project Manager, now… well, I am a simple developer.” In one sentence, we could feel the spite and maybe even sadness of that person regarding the loss of status.
It required a lot of work to make this person understand their enormous value within the team; beyond the title they were given. I would like to quote my colleague Tremeur Balbous who proposes to reinvent your place within the organization. Among other things, he says: “I invite you to reconsider the question with a different point of view; that of exploring the value that you can, being the person that you are, bring to your team or to your company.”
Agility to Scale
I have sometimes heard the argument that a Project Manager could be useful in an Agile context where several teams have to coordinate their work. If it’s the case, I would be inclined to recommend a framework like Nexus that allows the implementation of a scaled Agile structure, without having to reinstate the role of Project Manager.
To wrap it all up, I would say that where we were used to have a one-man band who was managing all aspects of the project, we now have a jointly responsible team, composed of people sharing the different responsibilities.
By distributing tasks, we are faced with a distributed power where each person on the team can influence strategic decisions related to the product. As a matter of fact, we are actually talking about a product in Scrum, not a project. It then appears logical not to find a place for the Project Manager as such.
It will therefore be important to revisit both the responsibilities and the commitment of the former Project Manager with the team to better adapt to the new state of mind brought by Agility.