What is the Role of the Project Manager on an Agile Project?

The most common question I get asked related to roles on agile teams is around what becomes of the traditional role of the project manager or the business analyst.

The question comes up because agile projects have only three roles: the Scrum Master, the product owner and the development team member.

In this post, I will focus on the project manager role and its evolution in relation to agile projects. 

The Project Manager: How Do You Fit into an Agile Team?

As teams began to adopt and transition to an agile software development environment, and as it became more popular and mainstream, the Project Management Institute (PMI), Project Management Association of Canada (PMAC) and other organizations around the world created the agile project manager role and introduced a career path for professionals transitioning to agile projects.

On some agile teams, the agile project manager is referred to as a Scrum Master. If you've ever wondered how different the roles are of a Scrum Master and agile project manager to the traditional project manager role, let's look at that now.

Authority: The traditional project manager role moves from a command-and-control, hierarchical position to a servant-leader or facilitator position. This is the essential role of the Scrum Master.

Requirements: The responsibility of ensuring the requirements are defined and providing direction for the product and services being delivered move from the project manager to the product owner. The product owner assumes the responsibility for ensuring the requirements are defined, prioritized and ready for the team. This is achieved iteratively, through just-in-time planning and progressive elaboration of requirements. Work Assignments: Assigning work and getting the status of the work completed moves from the project manager to the team members. The rationale behind this is that the agile team is a self-organized group of highly skilled professionals, accountable for the work they commit to in a sprint. The team takes ownership and accountability for meeting the project and team goals.

Managing Stakeholder Expectations: Providing the project status to stakeholders and sponsors moves from the project manager to the product owner, since it is the product owner who provides direction and leadership to the team, so that they can build the right thing and deliver business value based on priority and ROI.

Leadership and Support: The Scrum Master serves the product owner and the team so that they are better able to do their jobs by assisting them, facilitating creativity and fostering empowerment. The goal is to allow the team to self-organize and become a mature high-performing team. This is a change to a servant-leadership model.

Removes Impediments: If the agile development team is unable to resolve issues within the team, for example external dependencies and challenges that are out of the team’s immediate control, the Scrum Master helps remove obstacles and support the team.

To be successful in this transformation, the project manager needs to take on the role of a Scrum Master to become the champion of the Scrum process and facilitate the team’s adoption of Scrum with the understanding that they have no authority over the Scrum team. If this is a role you are considering, you will need to not only adapt and transition your skills, but also move towards an agile culture that embraces agile values. 

Are You 'The Scrum Police'?

I remember my first job as a ScrumMaster. I took it very seriously. I saw my job as being the custodian of Scrum, and ensuring everyone was doing it correctly.

Does any of the following sound familiar to you?

Make sure all the Scrum meetings are set up and rooms booked One minute before the daily standup, call people to make sure everyone attends the meeting Call each person’s name for them to answer the three questions in the daily meeting Make sure any discussion outside the three questions gets parked for after the standup meeting Time the daily scrum to make sure it never exceeds 15 minutes Insist that templates get used for stories Insist that story points are used Create a company-wide template for all Scrum artifacts Force everyone in the team to attend retrospectives Ensure the team completes everything they committed to each sprint Assign work to team members in the sprint Complete Scrum assessments online to see how your team compares to other teams

I did all of the above with the best intentions.

I really wanted Scrum to work, and I really wanted to help my team succeed. I thought this was what was necessary for them to succeed, and I thought that it was what my job entailed. 

Experience has taught me that whilst the above seemed like a good idea, I was actually slowing down my team's learning curve and its level of maturity as a team.

So what would a ScrumMaster with more experience do with the examples I mentioned above? Let's look at that closer.

"Make sure all the Scrum meetings are set up and rooms booked."

Anyone on the team should be able to book meetings and rooms. Perhaps ask the product owner to book the review and backlog grooming meetings, since they would know which stakeholders to invite, and ask a team member to book the daily standups.

"One minute before the daily standup, call people to make sure everyone attends the meeting."

Don’t call people for standup, just start on time. If no one arrives, then sit down again. Ask the team during the retrospective if they missed the standup or if something might have gone better if they had the standup. If you teach them to rely on you calling them, they will not take accountability for themselves to be at the meeting on time.

"Call each person’s name for them to answer the three questions in the daily meeting."

Let the team decide how to do this, even if the first few are a little chaotic. Consider what would happen if you weren’t there for a standup. Also, calling peoples' names implies they are reporting to you; instead, they should be talking to each other. Ask a question at the end like, “Is there anything we would like to change for tomorrow?”

"Make sure any discussion outside the three questions gets parked for after the standup meeting."

Although the standup is not supposed to be a problem-solving meeting, you need to use your judgment on if the conversation is adding value to the participants. Better yet, encourage the team to call each other if they go off topic in the standup, rather than you having to monitor it.

"Time the daily scrum to make sure it NEVER exceeds 15 minutes."

Although daily scrums should be 15 minutes or less, actively timing them usually means you are focusing on the wrong thing, and will drive the behavior of having a three-minute meeting of no value, just to be able to “look good." The duration is much less important the the content of the conversation.

"Insist that certain templates get used for stories."

Don’t force any story templates. The point of a story is to have a conversation and shared understanding. Templates imply written documents, and changes the emphasis from the discussion to the artifact.

"Insist that story points are used."

Let the team decide how they want to size stories. We have a workshop you can run to try out four different styles, then let the team decide what works best for them.

"Create a company-wide template for all Scrum artifacts."

Allow teams to create their own artifacts. This gives them some freedom, creativity and allows them to express themselves. Consistency is much less important than people having the ability to change things to fit their own needs better.

"Force everyone in the team to attend retrospectives."

Retrospectives should be valuable enough that the team wants to attend them. If people don’t want to attend, don’t force them. Rather find out why they don’t want to be there, and work on that problem.

"Ensure the team completes everything they committed to each sprint."

As a ScrumMaster, you are not responsible for delivery. The point of commitments and actuals is not for them to always match, but rather for your team to figure out what they can deliver comfortably.

"Assign work to team members in the sprint."

If you feel the need to assign team members work, I would dig a bit deeper and see what the underlying reason is. Asking the team an open question like, “Is there anyone on the team who can help with this?” is better than assigning something to someone on the team.

"Complete Scrum assessments online to measure how your team compares to other teams."

While Scrum assessments might be helpful, the team should be assessing itself and deciding what the results mean for the team. Usually, if Scrum Masters are assessing their teams, it is because they are wanting to see how their team is doing as a reflection of their value as a Scrum Master. Rather, ask your team what you can do to add value to the team as a Scrum Master. 

Some Final Thoughts

Consider if you are making your team dependent on you, or helping them become a self-organizing team. Try to be less of a master ordering the team around and more of a servant leader, helping the team become better than it is today. These days, we judge the effectiveness of ScrumMasters by how well the team learns, deals with conflict and collaborates, rather than which boxes they check on a Scrum checklist. 

Choosing a Retrospective Topic

I am a firm believer that the best retrospectives tend to be focused on a specific topic. Picking a theme and exploring what we currently think of it, and how we can improve in that area is almost always more productive for a team than having a general "how can we get better" conversation.

But how do you pick the topic? There are a few common ways for teams to do this ...

Ask The Team

Dedicate some time at the start of the retrospective to ask the team what they think the topic should be.

This could be as simple as giving each member of the team three sticky notes and asking them to write a topic on each, then gathering them all on the wall and looking to see if there is a clear majority winner such as "Dealing wiht bugs."

Perhaps there are some connections that make sense to tackle together.

Alternatively, we could ask each team member to write three feelings on sticky notes and do the same exercise of clustering them on the wall.

We might then end up having a retrospective on frustrattion. Why are we frustrated? How could we become less frustrated in our next sprint?

Ballot Box

Technically, this is still in the "ask the team" area, but there is a difference in that this is anonymous and in real time before the retrospective as opposed to at the start of the meeting.

With ballot box, a box is placed in the team area where team members can post cards with an idea for a retrospective topic as they occur during the sprint.

Then, at the start of the retrospective, we just empty the box and see what ideas we have, and make a decision.

ScrumMaster Choice

In my Scrum Mastery course, I explain that I believe ScrumMasters should always reserve the right to pick the topic that the team should explore in a retrospective.

An elephant in the room is what the English refer to as an obvious truth that is going unaddressed.


Sometimes the team may be too nervous to address the topic that really needs addressing and in those cases, the ScrumMaster should be prepared to help the team by highlighting it. 

As with anything, if the elephant is avoided for long enough, the team will develop coping mechanisms.

The problem is, these coping mechanisms don’t deal with the issue and actually make the problem even less likely to be removed because it doesn’t seem quite as necessary any more.

Great ScrumMasters courageously expose, and encourage teams to explore, the elephants in the room as soon as they notice them.

They don’t judge, but neither will they let their team tolerate and get dragged down by these problems.

Instead, they offer to lead an exploration. For example, the elephant in the room could be that one of the team members is getting into the office later and later.

The team is accommodating him by shifting the daily scrum and, sometimes, writing up their conversations, but this is leading to inefficient teamwork and resentment is growing in the team. 

Before this spirals into outright anger and rebellion, the team should confront and solve the problem.

A great ScrumMaster acts as a mirror for the team so she can reflect back what is happening in the team.

This is not a finger-pointing exercise but done with as much compassion as ruthlessness so that the team feels this is important enough to tackle but not defensive about admitting it needs tackling.

I recently blogged on compassionate ruthlessness here.

There is always room for good old ScrumMaster intuition. During the sprint, ScrumMasters are in a privileged position, able to see a lot of what is going on with a certain detachment.

They can -- and should -- be listening to what is being said and what is not being said, looking out for good examples of team dynamics and development as well as opportunities for further team growth.

Great ScrumMasters have no issue with starting the retrospective with a challenge based on their own observations, for example:

“This sprint, I have noticed a larger proportion of time than normal has been spent on fixing defects. I wonder if it would be a good idea to take some time out to explore why this might be and what we could do about it.”

Set The Team Up

Whichever method you choose, and you will definitely take the context of the situation into account, it's almost always a great idea to start the retrospective with a compelling goal that engages the team and helps set them up for success.

Most of the time, this goal will come from the team, but sometimes, it's OK for the ScrumMaster to step in and challenge the team with a compelling challenge to explore. 


What Do Great Scrum Masters Do?

Geoff Watts is one of the leading Scrum thinkers in the world, and one of the few to hold both the Certified Scrum Trainer and Certified Scrum Coach designation. He's also an instructor at Front Row Agile with a newly released online course, "Scrum Mastery: From Good To Great Servant-Leadership," based on his book of the same name. 

Geoff shares patterns that he has seen the good and the great servant-leaders (such as Scrum Masters) display in his time working with many Scrum teams. Here, we'll talk with Geoff about some of his concepts behind becoming a great Scrum Master. 

Tell us a little more about why you wanted to teach Scrum Masters how to be great. 

Geoff: There are loads of Scrum Masters out there, and still precious little actual guidance for how to do what is a really tough and largely undefined job. So I wanted to share some practical tips that people can use straight away to help become more effective. 

What about those people who have read your book already -- how can they learn from your online course?

Geoff: I’m very aware that people learn in different ways and I have been asked many times about the possibility of turning my book into an e-book or online video. So this is another way of learning for those that prefer a more visual and/or audio method. 

Having said that, some of the more pleasing and surprising comments have been from those who have read the book and taken the course. Many of them have said that it brings the book to life and helps explain points in a different way. 

Describe the training a Scrum Master can receive to push him or herself to greatness.

Geoff: In my course, I cover the main characteristics and skill sets that I have found in the truly great Scrum Masters; the ones who have inspired great agile teams to build great products. 

In fact, these characteristics have formed a useful acronym that the course has been built around. I’ve found that the best Scrum Masters tend to be RETRAINED:


There is a section in my course with videos dedicated to each of these characteristics.

If you had to pick one skill above all others that is most important for a Scrum Master, what would it be?

Geoff: That's a tough one, but I’m pretty sure the most important skill for a Scrum Master is listening. And, more specifically, to listen empathically; that is, to be able to listen without judgement or personal agenda and with the ability to understand that person’s point of view. 

Great Scrum Masters listen with a genuine curiosity and desire to understand and help. Even more than that, they listen with the intent of helping those talking to understand themselves. 

They listen to what is being said, what is being implied and what is not being said. This helps build a connection and rapport, and also helps them in one of their primary jobs: removing impediments to productivity.

You use the term “servant-leader.” What does that mean to you?

Geoff: Well a servant-leader is someone whose primary objective is to ensure that others are able to do their jobs. They exist first and foremost to help the progress and development of others. 

Scrum Masters fit this bill because they don’t really have a huge amount of personal responsibility. Product owners are responsible for ensuring that we are building the right product and the right features within that product. And the development team is responsible for ensuring that the product is being built correctly. 

The Scrum Master is there to ensure that both the product owner and the development team are able to do their jobs effectively. Part of that will be achieved in the short term by helping them use Scrum, but over time, the Scrum Master may actually guide the team past the need for a framework like Scrum.

And that is often the greatest test of a servant-leader: getting the team to the point where it is totally self-sufficient.

Will you do more online courses in the future?

Geoff: Absolutely. I’m convinced that this is a big part of the future. I’ve had to travel a lot in my job and I’m humbled that people regularly travel hundreds and sometimes thousands of miles to come to my classes. But, there’s no real reason why that should have to be the case. 

This kind of medium allows me to potentially reach anyone who is interested without them having to travel or take days out of the office. I already have a couple more courses in the pipeline: one on retrospectives and one on coaching skills that I’m really excited about, so stay tuned. 

For more info from Geoff, check out free chapters of his online course on Front Row Agile, here.