Adopting agile in organizations usually impacts the role and activities of project managers. Scrum offers the possibility for project managers to become Scrum masters or product owners. Project managers can also adopt their way of working and the things they do to work together with Scrum masters and agile teams.
Jim Bird wrote the blog post agile - what’s a manager to do? in which he discusses how agile projects can be managed and the role of project management when working with agile teams. He explains the view of Scrum on project management and managers:
In Scrum (which is what most people mean when they say Agile today), there is no place for project managers at all: responsibilities for management are spread across the Product Owner, the Scrum Master and the development team.
Project Managers have the choice of becoming a Scrum Master (if they can accept a servant leader role and learn to be an effective Agile coach – and if the team will accept them) or a Product Owner (if they have deep enough domain knowledge and other skills), or find another job somewhere else.
An organization can decide to change the role of project managers to Scrum Masters as Jim describes:
It seems like the most natural path for a project manager is to become the team’s Scrum Master, although there is a lot of disagreement over whether a project manager can be effective – and accepted – as a Scrum Master, whether they will accept the changes in responsibilities and authority, and be willing to change how they work with the team and the rest of the organization.
The Scrum Master is a “process owner” and coach, not a project manager. They help the team – and the Product Owner – understand how to work in an Agile process framework, what their roles and responsibilities are, set up and guide the meetings and reviews, and coach team members through change and conflict.
His blog post describes several project management activities that are needed and often not done by agile teams when an organization is adopting agile. Some examples are setting up projects, outward communication and risk management:
First, there’s all of the work that has to be done upfront at the start of a project – before Iteration Zero. Identifying stakeholders. Securing the charter. Negotiating the project budget and contract terms. Understanding and navigating the organization’s bureaucracy. Figuring out governance and compliance requirements and constraints, what the PMO needs. Working with HR, line managers and functional managers to put the team together, finding and hiring good people, getting space for them to work in and the tools that they need to work with. Lining up partners and suppliers and contractors. Contracting and licensing and other legal stuff
There are a lot of people who need to know what’s going on in a project outside of the development team – especially in big projects in big organizations. Communicating outwards, to people outside of the team and outside of the company. Communicating upwards to management and sponsors, keeping them informed and keeping them onside. Task boards and burn downs and big visible charts on the wall might work fine for the team, but upper management and the PMO and other stakeholders need a lot more, they need to understand development status in the overall context of the project or program or business change initiative.
Scrum done right (with XP engineering practices carefully sewed in) can be effective in containing many common software development risks: scope, schedule, requirements specification, technical risks. But there are other risks that still need to be managed, risks that come from outside of the team: program risks, political risks, partner risks and other logistical risks, integration risks, data quality risks, operational risks, security risks, financial risks, legal risks, strategic risks.
According to Jim there is still a need for project managers in organizations which are working with agile teams:
Agile spreads some management responsibilities around and down to the team, but doesn’t make management problems go away. Projects can’t scale, teams can’t succeed, unless somebody – a project manager or the PMO or someone else with the authority and skills required – takes care of them.
In the blog post project manager to scrum master Rohit Ratan Mani discusses how moving from waterfall to agile impacts project managers. He describes what can happen when an organization adopts agile:
In an ideal scenario, a SM would start working with the team to drive the project as an interface with management, which will understand Agile. But in reality, many times management asks:
- Where is the project plan?
- Where is the risk management plan?
- What is the critical path?
- What percentage of the tasks is complete?
- Where is the S-curve for the project?
He suggests that project managers should take the role of a Scrum master:
In my opinion, a SM can take up the role of bridging this gap with management by helping them understand how the new process maps to the old one. Knowledge of traditional PM activity, along with an understanding of the SM role, is required to take up this dual role. Many argue that a SM has a different role and approach toward project execution, and a traditional PM should not take up a role of SM. In my opinion, a PM with thirst for adopting Agile fits the role of SM and can bridge the gap between a Scrum team and management.
According to Vidya Venkat Scrum masters and project managers can co-exist. Her blog post accommodating project managers in scrum provides two lists with the activities that Scrum masters and project masters do:
Role of a Scrum Master
- Manages Scrum process – As a leader of the project the Scrum master ensures that end to end execution of the process is maintained.
- Ensures team dynamics and function – Execution of work requires a cohesive team with well-defined parameters to work. This is taken care by the Scrum master.
- Maintains impediments – A Scrum master ensures that the projects are running smooth and removes any barriers surrounding it.
- Does planning of sprints – Any project requires the achievement of goals, one of the focal points of a Scrum master is to plan, accomplish and release them.
- Communicates with external interface – Passing the message down the layers is an important aspect which the Scrum master are always glued on.
Role of a Project Manager
- Manages all aspects of project –The project manager is the captain of the project and he provides end to end support from start to end.
- Does Goal setting – The Project Manager needs to understand outcomes and ensures that they are measurable and realistic
- Encourages ‘Team Bonding’ – As the master of the entire project, the Project manager ensures that his team is well collaborated and defines the work by understanding their capabilities.
- Ensures project communication – The torch-bearer of the project is solely responsible for overall communication of the project to get the message clear till the end.
- Is the Focal point – Finally, the project manager is the single point of contact for sharing and communicating any information related to the project and thus has an important role to play.
In the article surviving—and thriving in—your first scrum master role on Agile Atlas projects manager Elizabeth Lloyd wrote about her experiences of working as a Scrum master for the first time:
Being a scrum master is different than being a project manager, and there were many times I had to make a conscious effort to go against my natural tendencies. I had to unlearn some behaviors and put in place new ones that aren’t utilized in project management.
Elizabeth shared four things that she wished she had know before starting in the Scrum master role:
- Don’t always follow your gut (...) I learned to take a breath and pause whenever my decision-owning project manager self started to rise up. Instead, I let the team own their decisions, with me serving as a facilitator who removes barriers rather than controlling the outcome of the discussion.
- Value prioritization over scope (…) I realized I needed to move into a true scrum master role: supporting my team, accurately calculating our velocity, removing blockers and barriers, and projecting how many story points our team could accomplish by the dates set by the project manager. It was our project manager’s responsibility to escalate any concerns about scope and make sure stakeholders understood the effect that working in a scrum environment would have on the deliverables, timeline and other governance.
- Define, define, define (…) After talking to some fellow scrum masters and prompting the team during our retrospectives, I realized that the team didn’t clearly know when a story was ready to be developed – they had no “definition of ready” (…) we agreed upon nine points, and I had each of the team members commit to saying “no” if any of the nine points were not present at sprint planning.
- Stick to your “scrum guns” (…) When [the team] didn’t want to pull in a piece of work, I had to back them up. That meant saying “no” to our product owner. It only took one time of sticking to our “scrum guns” before she made sure she planned earlier and had all of her ducks in a row before coming to planning.
