What Agile Project Managers Do, Part 1

One of the questions I hear all the time with people transitioning to using agile is this: How do we organize the project if we don't have a project manager?

If you read Manage It!, you know I don't buy the idea of a controlling project manager. But a facilitative project manager? Oh my. That is a horse of a different color.

In organizations where plan-driven approaches have reigned supreme, managers think about managing people, not projects. Nope, managers exist to create the environment in which people can do great work. Project managers might even be quite helpful. I have talked before about when I am the “wall around the team, protecting the team from management mayhem.

Here is a list of what an agile project manager might do:

  • Facilitates the team’s process. New-to-agile teams don't have agile baked into their DNA. Who will learn more about how they can make agile work for them? Who will schedule the retro and make sure it occurs? (PMs do not have to facilitate the retro. They make it occur.)
  • Removes the team’s impediments, that the team members cannot remove themselves. Many impediments are at the organization level. The team isn't going to tackle them. The team needs to “delegate” the impediment to the PM.
  • Assists the team in measuring the team’s velocity and other measurements. For example especially for new-to-agile teams, I like burnup charts. I like to measure defects over time. I like knowing the fault feedback ratio. I like cycle time, cumulative flow and other lean-related charts. Who has the time to do this? Because PMs assess risks, the PMdoes.
  • Assists the product owner in writing stories for the next iteration. I don't know of too many POs who understand how to write small-enough stories for iterations.
  • Prepare the project vision/Facilitate the project vision.
  • Prepare the release criteria/Facilitate the release criteria.
  • Facilitate the team's definition of done.

Assist the team in managing the team’s risks. This can be many different things:

  • Managing sponsor expectations
  • Managing the project portfolio so there is no context switching
  • Obtain more funding
  • Making sure the long-lead-time items show up on time
  • If there is intersection with items across the organization/outside the organization, that everyone understands what those intersections are and that everyone resolves them.

There may well be more PM functions. (If you know of any, please comment. Thanks.)

Project managers who act as servant leaders fulfill useful functions. Project managers can be especially helpful if managers don't understand the difference between resource efficiency and flow efficiency.

Controlling project managers? Not so much.

In part 2, I'll describe what agile PMs do not do.

10 thoughts on “What Agile Project Managers Do, Part 1”

  1. Great Post!

    I totally agree that the Project Manager role in an agile context it is totally different than in a traditional one. Agile PMs need to focus more in helping the team to deliver the product instead of asking continuously for deadlines and current progress to write reports to senior management

    In my opinion, the main problem is to find the right person for the role. As it needs to be someone who can speak the language of the different stakeholders (Technical team, Product Owner, Senior management, etc…), have experience in the topic so he can remove hurdles to win the trust of the team and be willing to invest his time in helping others.

    But once you find the right one, it totally makes the difference 🙂

  2. Pingback: New PM Articles for the Week of September 26 – October 2 - The Practicing IT Project Manager

  3. Pingback: Dew Drop - October 3, 2016 (#2336) - Morning Dew

  4. I’m curious, where does the ScrumMaster role fit with an agile project manager? I ask because a number of the items that are mentioned above are what I have thought of as SM functions.

    1. Hi Glenn, the short answer is that a Scrum Master is an agile project manager.

      Here’s the longer answer:

      Back when I took my CSM, the Scrum Master was not supposed to assess risks. I sort-of remember that the SM was not supposed to say to the team, “It’s time to charter the project,” or do any of the project-specific facilitation work that I had always done as a project manager. (I was not always a totally facilitative project manager/servant leader, but I never did the command-and-control thing that too many PMs fell into.)

      When I asked about this in my CSM class, the instructor firmly told me, “The team does that. All that.”

      I asked what about if the team didn’t know to do that? The answer was, “When they retrospect, they will learn.”

      For me, that was way too late. I am glad to see the Scrum Guide has evolved.

      Now, Scrum was developed for collocated cross-functional teams. At least half the teams trying to transition to agile or use agile find that Scrum doesn’t work. The ceremonies don’t work because they need people to be together in one time zone. Scrum assumes that people can commit to an iteration’s worth of work, and not be interrupted or change.

      My experience is that rarely occurs. I see many teams where people are not collocated, or even in one time zone. Those teams need someone to remove impediments, help the team see their flow of work, and to protect the team from forces that would tear the team apart.

      Scrum is a famous and well-known approach to agile. It is not the only approach to agile. I have discovered that many teams need to see their workflow. When they use kanban, either with or without iterations, they often succeed more than when they tried Scrum.

      An agile team can use iterations without using Scrum. A Scrum team can use kanban boards.

      Some teams don’t need the servant leadership of a project manager. I can count those teams on one hand. Many more teams need someone to nurture the idea of agile, to help the team understand or develop their team norms, and to help the rest of the org realize their impediments and solve them.

      1. Thank you. The extended description helps.

        The servant leadership support is so critical to help get to not only the “team does all that” but also the “PO does that” and “let me help with that”. It is always a balancing act helping each role to feel responsible for their outcomes.

        1. Glenn, IMNHO, the balancing act is key. I wish there was a recipe for this. I would tell everyone. But, there is not. That’s why I’m writing an agile/lean project management book.

    1. HI Michelle, I used the definitions in this post for an agile project manager. Here’s what agile technical architects might do:

      – shepherd the business value of the architecture.
      – write code to (possibly lead) explore the architecture
      – balances short-term goals with overall system integrity, risk, etc.
      – writes acceptance criteria for system qualities and quality scenarios
      – may help define the product vision.

      Here’s how I use architects most often: Discover the impediments that prevent the teams from Frictionless Releases. Now, put the architects on anything that’s an impediment. Since I expect architects to write code, they deliver value to the team (or teams) and the project.

      Your list might be different if you are integrating COTS instead of developing your own product.

      This means the architecture role becomes shared among team members. This is even more obvious in a program.

      I have an entire chapter about agile architecture from the program’s perspective in Agile and Lean Program Management.

Leave a Comment

Your email address will not be published.

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

%d bloggers like this: