The Agile Project Manager: To Facilitate, Serve and Protect

Some agile teams build and maintain their project’s rhythm, happily developing the system. Sure, they may encounter issues–but they can manage those problems and they successfully release the product. No one works overtime, the product owner is happy and the users are happy with the system.

Then there are the other teams. I meet many agile team members who say, “We really need someone full time to help us. We can’t do the technical work and do all the other stuff we need to do for the organization. Maybe if everyone else was agile, we wouldn’t need someone–but we do right now.”

Those teams need agile project managers. Not a directing and controlling project manager, but a facilitative, serving and protective project manager. The agile project manager has several clear roles: to facilitate the team’s process, to serve by removing obstacles and managing risks, and protecting the team from disturbing outside influences.

Some of you are probably saying, “We don’t need a real project manager to protect the team’s process. We have a Scrum Master to do that.” Or I hear from an XP team that they don’t need any management–they are completely self-organizing.

If you are using Scrum, yes–a Scrum Master does protect the team’s process. But I see Scrum Masters who are supposed to do technical work and remove obstacles and manage risks, as well as protect the team from people who want to perturb the team or its process. It’s too much work. Anyone who has both kinds of tactical work will choose technical work because of the team’s commitment to the backlog for a sprint. When the team commits to the stories, no one will put the stories at risk to do project management work.

I also see XP teams who are so focused on their project work that they miss organizational cues that throw their projects off course. More than one XP team has been surprised by some manager’s decree that they could no longer have a dedicated customer or product owner, or that senior managers still wanted to see project status reports in phases.

Agile project managers are not controlling or directing the team. The agile project manager serves the team and creates an interface for the rest of the organization to work with the team.

Facilitate the Team’s Process

How many agile teams do you know who have missed a few retrospectives? Or maybe their backlogs are not ranked, or they are not quite getting to “done” at the end of an iteration? Even agile teams do not always notice when they are in a rut or if their process is not quite working. In these cases, it’s important to first notice that things are not quite right and then help the team understand why. People do things for reasons that appear to be good at the time. Have those decisions gone on too long? Does the team need something else?

One organization had successfully piloted agile, and was proceeding with their rollout. Their third project team, ThirdAgile, had stopped doing retrospectives at the end of their iterations. They didn’t notice their velocity was decreasing because they had stopped keeping velocity charts. Then at the end of one iteration, their demo failed. Over the team’s objections, management assigned them Chester, a project manager.

Chester did not take any directive actions. He asked the team what “done” meant to them, and he wrote it on a large paper in the team room. He asked if they could do a retrospective before starting the next iteration. The team declined. Chester tracked their velocity at the stand-ups on the whiteboard in the team room. The next demo passed and the team did a retrospective and discovered a number of issues they could address. In addition, they discovered a number of obstacles they had not addressed before.

Remove Obstacles

Savvy project managers remove obstacles that prevent their teams from being successful–that’s not new. What is new in agile is the transparency of obstacle acknowledgement and the tracking that agile teams may use to see obstacles over time.

One of ThirdAgile’s problems was insufficient team space. Their original team room had been transformed into a meeting room, and not all of their cubicles were in the same physical area. They had asked facilities to move them, but facilities was busy with other problems and hadn’t gotten to these requests.

Although the space problems were obstacles, the obstacles were opaque to the rest of the organization. The team had been too busy to manage the obstacle removal themselves. Chester included an obstacle list on the team room wall:

Obstacle Report
Rank Obstacle Request Date Days Since Original Request
1 Lack of team room March 12 63
2 Cubicle moving for Jim, Tom, Sally March 12 63

When you report the facts and put the obstacle report wherever you put your project information, you provide transparency for the project and for the people who have not yet removed your obstacles. Of course, just listing obstacles on a report is not enough: The project manager needs to work across the organization to remove the obstacles.

First, Chester brought his management to the team room and showed them the obstacle report. Since he had no technical responsibilities, Chester had the time to work with facilities and to pursue the requests through management to get the team the space it needed.

Some of your obstacles may be quite difficult to resolve. If you need technical specifications from a vendor, you might not be able to influence them to provide those specs when you need it. But when you create an obstacle report, you make the problems transparent to the team and to the rest of the organization.

Identify and Manage Risks

On any project, you want to catch problems or issues when they are risks before they become problems. An agile project manager can look for risks because there is no need for command-and-control work on the project.

The ThirdAgile team certainly had risks. They were supposed to integrate their system with some changes to the underlying database another team was delivering. Chester made a point of visiting the database team to see how they were progressing. He realized that they were going to be an iteration later than anticipated, so he worked with the product owner to reorder the backlog so ThirdAgile could still do valuable work (not just the database work).

You may have significantly worse risks than a supplier’s deliverable being just a little late. Having a project team member look a little ahead to anticipate and manage risks helps the rest of the team continue their work in flow.

Protect the Team and Their Work

ThirdAgile proceeded for several more iterations. They were on the verge of telling Chester that they no longer needed him. Then, senior management changed. The new VP of product management did not understand what a product owner did. The new VP of technology thought agile was a license to hack. The two of them decreed that the organization would move back to waterfall.

Chester and the other agile project managers had just one iteration to build a case for agile. They showed the data that explained how their projects were completed a little faster, and with many fewer customer-visible defects. They gathered the customer support data and explained that the organization was actually making money on support because there were fewer calls and happier customers.

One of the ThirdAgile team members said, “We were heads-down on the project. It never occurred to us that new management would care about how we did our work as long as we did it well. We were totally surprised by management’s decree that we revert back to waterfall. Thank goodness we had Chester. We were able to continue our work and let Chester fight the craziness. We won, but it was close.”

Some managers are not accustomed to the management transparency that agile requires. Agile can push managers past their comfort zone. When that happens, the product and the project team’s process is at risk. Who better to fight for the team than an agile project manager?

Agile Project Management Serves the Team

Agile teams do not need a command-and-control project manager–far from it. But many agile teams need a facilitating, obstacle-removing, risk-assessing, team-advocate project manager.

Agile project management has a place. Maybe when agile turns into the way everyone works, we won’t need agile project managers. But until then, consider whether your team needs someone who does not do technical work but serves the team. You might decide that you need an agile project manager.

© 2010 Johanna Rothman. This article was originally published on Gantthead.com

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.