I spoke with a project manager recently. She told me her story.

I used to facilitate project teams as a project manager. Why a project manager? Because the project had a beginning and an end. We had (and still have) too many products to keep the same teams on them for a long time.

For programs, the team stayed together and moved to a different feature set/internal product until the program finished. I stayed with that team until all of us finished the program. Now, we all had choices. We could move to a new product and/or a new team. Some team members moved around, but many stayed with their products and continued to the next project or program.

When I learned to manage programs, I managed programs like that, too. My job was to smooth the way for people to deliver products.

Part of my job was to create timelines so the organization had an idea of what we would deliver and when. These were the “we think we can do this feature early and these later” kind of timelines. Never a Gantt chart. Often, a roadmap that didn't look like commitments. I worked with the teams to refine the specifics using rolling wave planning. We always worked towards delivering features. We delivered something every week, which worked pretty well.

Then, we went “all-Scrum” so my managers called me a Scrum Master. That was fine. It was still my role to help a team be effective and deliver. We didn't have a full-time Product Owner, so I helped our PO figure out when we could deliver which features. For the programs, they called me “Chief Scrum Master”—even though we used flow—not iterations.

Now, they want to call me a Product Owner. I'm not a PO—I don't manage the backlog and I don't want to. I'm something else. I facilitate teams to deliver something. I smooth the way for the teams. What should I be called?

Let's first discuss what my colleague does and how we might name that role.

Scrum Master or Agile Project Manager?

If my colleague worked in Scrum, she might be a Scrum Master. However, she does not “promote and support Scrum as defined in the Scrum Guide.” (You might like Why an Agile Project Manager is Not a Scrum Master.)

Scrum is not her job. Her job is to facilitate the team(s) to deliver value as fast as they can. Not faster, so they create garbage for the future. No, as fast as is reasonable.

She's an agile project manager. When she manages programs, she's an agile program manager. (See a ton more about this role in Create Your Successful Agile Project.) She helps the team in these ways:

Facilitate the team's process. That includes helping the team see their state and measurements. (She spends a lot of time asking this question, “How's that approach working for us? Do we need to measure something?”)

Facilitate the team's working agreements, how the team agrees to work together.

Facilitate the product's vision and release criteria with the Product Owner.

Assess, manage, and remove the risks and obstacles the team can't manage. She spends time with managers for a lot of this work.

Either facilitate the retrospective or help others facilitate the retro. She's been experimenting with having people outside the team facilitate, so she can participate.

As she said, she helps teams deliver products. She never told people what to do or how to do their work. (Are there project managers who did and still do? Of course. Some of them are even Scrum Masters. Changing a role name doesn't change a person's actions.)

Her company can call her whatever they want. However, the farther they move from facilitating the team's work, the more they confuse everyone.

And, in this organization, they now have the worst of all possible worlds: insufficient team facilitation and no product person to shepherd the business value of the product. (See When You Have No Product Owner At All.)

What a Product Owner Does

If you use the term Product Owner and haven't read the Scrum Guide, please do. (Here's a link directly to the Product Owner in the guide.)

My project-manager colleague was correct. She is a servant leader for the team. If the team uses Scrum, she might be a Scrum Master. However, her teams rarely use Scrum. They more often use flow with various cadences of planning, demos, and retrospectives.

(Why? She's working in a part of the organization that's trying to get feedback as quickly as possible. They also change what they're doing more often than once every two weeks. And, they have unpredictable interrupting work.)

I like to think of the Product Owner as the person who shepherds the business value of the product through the team. (I wrote an extended series about this, starting with Product Roles, Part 1: Product Managers, Product Owners, Business Analysts.)

The shepherding consists of:

Defining the problems the team needs to solve and ranking those problems.

Offer a look-ahead for the team. (Not just this batch of work, but where the work will take the product.

Understanding and possibly making external commitments the team needs to deliver

There's a lot more the PO should do. (I wrote more in Create Your Successful Agile Project and Agile and Lean Program Management.)

My colleague isn't a product owner.

Role Names Have Power

I don't meet many teams who are self-sufficient. I meet many more teams who need facilitation of some sort. Even if just to understand what the greater organization needs from the team. (As a team member, I don't want to go to 20 meetings a week just to understand. Do you? I want the project manager to do that.)

And, every team I meet needs product guidance. I prefer to separate the team facilitation from the product guidance. (That's now, where I rarely see an agile culture. Maybe if I saw an agile culture we wouldn't need that separation.)

I encourage the feature team to influence the PO to change the rank of the work. And, if the PO can see something in the work that changes the product's business value, the PO should comment. (And, I'm totally fine with these comments being loud and vigorous.)

Here are my working definitions for the roles:

Agile project managers facilitate and lead teams through their obstacles and risks to deliver the product. Often, they are the wall around the team so the rest of the organization doesn't prevent the team from succeeding.

Again, in my never humble opinion, Scrum Masters need to do this instead of “promoting and supporting Scrum.” The Scrum Guide disagrees with me. That's fine. (Scrum, like Agile Coaching, is not the goal. Product delivery is the goal.)

Agile program managers manage the obstacles that prevent the teams from delivering the product. They solve the problems across the organization that prevent teams from delivering. They manage any necessary coordination. (See Component Teams Create Coupling in Products and Organizations.)

Product owners shepherd the business value of the product in the short term and the long term. Depending on how large the program or the organization is, they might use a product value team to manage the long term.

Does Changing Role Names Add Value?

My colleague raises an interesting question. Her organization doesn't seem to want to change her role responsibilities. And, they don't seem to realize the difference between someone who facilitates the team and someone who manages the product backlog on behalf of the customers.

With this name change, my colleague has more trouble doing the work she wants to and sees the need for.

Her managers need much more assistance than the teams do. They're attempting to impose “agile” on everyone else instead of themselves.

Gratuitous name changes don't change what we do. And, if we choose to change the names for roles, let's explain what the new name means.

I prefer to not make the various names overloaded operators, but that might be me.

If you suffer from this name change, consider asking what your managers want you to deliver. Or, explain what your role is and what you want to call yourself. But, don't confuse anyone with a name that doesn't reflect your role.

Share this: Email

Twitter

Facebook

LinkedIn

Tumblr

Print



Like this: Like Loading...