News

Once upon a time, I used to run projects.

To be honest, I am probably a better BA than a PM, but I have run quite a few projects and my projects always seemed to come through okay.

So when I encountered agile projects with product owners on them, I was pretty relaxed.

I had encountered ScrumMasters but they were no real challenge, I just chewed them up and threw them back to the hungry team to finish them off (not really). Working with a product owner sounded quite straightforward too.

Little did I know that I was about to encounter the clash between managing projects and owning products. In fact, it was not until I encountered my first real product owner that I even realised there was a clash.

I could give you the short story, but I am at an airport with time to spare, so let me share the whole journey with you. This is a semi-true story recollection of what happened. It is based on my experience, but I have compressed several experiences into a single project.

I was always a lucky project manager

I was always a lucky project manager and many of my toughest projects seemed to come good because the universe wanted me to succeed, rather than because I did all the right things in the right order.

I always felt accountable for the project, I always focused on what really mattered and I was always good at scrounging the resources needed to get things done, so maybe those things helped me to be lucky.

Anyway, I was pretty happy as a PM, even before I heard of “agile”.

Some of my projects were pure “waterfall,” where I managed to deliver things on time and on budget. This involved some half-decent planning, but more importantly, I managed to get a team who executed the plan really well.

We always had a shared understanding of what the goal was and what the plan was. We also openly discussed how realistic (or even absurd) it all was. We even had formal risk registers with actively managed risks.

Some of the other projects that I ran were “James king style” where we had an objective, but no sensible plan in any real detail beyond some headings. We spent more time inventing unexpected solutions to emerging problems than we spent following a good plan. We justified our actions based on achieving outcomes or avoiding dire consequences, rather than completing our tasks as predicted. In fact, I developed a reputation as a problem solver and a person who could deal with weird problems.

Each project was different and that was part of what I loved about the role.

Then some “Agilistas” told me that waterfall didn’t work. I was confused because it had always worked for me.

“Waterfall does work,” I said “I have even done it myself when I am not running ‘James King special’ projects.  It is good and you should try it.”

The Agilistas scoffed at my waterfall ways and told me that waterfall projects always fail. They even had statistics and a lot of anecdotal data (produced by other Agilistas) that proved it.

I responded that in spite of the agile data they presented, waterfall did seem to work for me – I had verified, real experience too.

The Agilistas were dubious, so I described what I did and the Agilistas seemed to get very excited 

“See – you are secretly doing agile,” They exclaimed”, You are using self-organising teams and you are updating your scope as you go.  You even have the right business people involved.”

I was still confused because I thought that what I was describing was just called “good project management.” It was not waterfall or agile or RUP or prince 2 or Pharoah 1 or feng-shui based, it was just what you did when you ran projects.

Anyway, they suggested that I try some “agile project management” and so I gave it a go. It seemed to work really well and so I did some more of it.

In fact, it seemed like it was just a disciplined way of doing what I already knew worked. Plus it gave me permission to admit what I was doing underneath the covers.

I had always had a critical path on my projects, but I had never really mastered the powerful PM tools like MS Project.

I could produce project plans and track milestones but I never got around to “baselining” the project, because I thought things would change. In fact, I often used Excel to track my project if I didn’t have multiple teams tripping over each other. I even bashed things together on whiteboards and with index cards, which people told me was a symptom of doing agile stuff.

The agile people said I could throw away my MS Project and focus on delivering value. So I was pretty happy about that, even though I never really gave up on my love of critical paths and milestones.

But down the track, some Scrumians appeared. They told me that they had a product owner and a scrum master and so they didn’t need a PM.

“No problem” I said – just do your time sheets and stay off my critical path and you will be happy.  I will be your friend.  Otherwise I will hit your team like a tornado.  It’s your call really.

I had a simple rule – if people were delivering what they said and they played well with other teams, then I was easy going. But if people come near my critical path and held things up, or they got in the way of other teams, then I would chase them down until they delivered enough to make me relax again.

It seemed to me that the PO was really a mini-sponsor and the ScrumMaster was really a mini-me. It meant that I could focus on managing budgets and risks while having coffee with the sponsor and the scrum master could rally the scrum folk in order to get things done while the PO would make sure people were working on the right things.

At first, things were great. The ScrumMaster and the team would come an see me if they needed help or if they needed to buy new resources.

But then one day a ScrumMaster told me not to talk to the team. This is the best way of convincing me to get close to the team since it usually means “we are in trouble and do not want to tell people.” So I went to see them every day.

The scrum master kept telling me to leave the team alone, which helped to confirm that I needed to stay close to them. I said I would relax if I could talk to them sometimes and come to their meetings … and I felt that they were on top of their work.

After a little friction, we agreed that I would manage the organisation and he (the scrum master) would manage the interaction of the team. He looked “in” with the team and I looked “out” for the team. Times were good.

Then I met a real product owner

But then the product owner started making decisions without telling me. I went to see her and told her that while her input was welcome, she needed me to approve any major shift in scope.

Then she informed me of a terrible truth

“You must have me confused with an SME”, she said, “I own the product.  I’m not an adviser, I own the vision for this project – so I need to decide what we do next.”

Apparently, she owned the vision and value of the project. That is what the “owner” part of the PO role definition means.

It sounds good, but it meant that she was in charge of the vision, the direction and the prioritisation of work while I was in charge of the scope and budget. She was not just bringing information to the team, she was deciding what the team would do.

I spoke to the scrum master and he agreed that she was turning out to be quite annoying.

He had expected her to feed stories to the team but here she was asking them to go off on side adventures. She even had them helping people create training courses and write user manuals when they wanted to write code.

Apparently, she thought that being the product owner meant being responsible for the whole product. So the development team were forced to help other teams deliver things that were not really their focus, but mattered in terms of creating the product.

I decided that if she was responsible for the mission, then she did need to make calls on what to work on next, even if that distracted the team from what they were good at.

“If she is responsible for the whole thing, then she should have the right to get people to work on the whole thing – not just write code,” I said.

I told the ScrumMaster to “suck it up” and work with the product owner. This led to some friction because the ScrumMaster thought that his job was to protect the team and keep them focused on writing and testing code, while the product owner thought they were able to work on whatever matters.

I am still not sure where the boundary is, but it seemed to sort itself out for that project.

I left them to sort out what “product” and “done” meant and they seemed to come to an agreement. But I had my own concerns – If I am the scope, deadline and budget guy, but the PO is the one setting the vision and scope, then there is a problem.

I checked with the sponsor and he confirmed that I was still accountable for the budget and for the team delivering on time. But the Product Owner was accountable for value and prioritisation.

“But hang on,” I said, “If she controls the vision, then she needs to control the scope.

If I control the scope as PM, then she can only really make changes that have a small impact. We would be setting her up to fail.

But if she controls the scope and the prioritisation, then I can only manage the budget based on her whims. I can’t control a budget or a deadline if I cannot impact scope, quality or value.”

The sponsor agreed and told me to sort it out.

Typical, I thought – the sponsor always agrees that something needs to change, but then just asks the PM to make sure it gets sorted out and goes off to drink coffee with his friends.

So I went back to the product owner and we had a long chat. Then we realised what the problem was. There was a clash between project thinking and product thinking.

She “OWNED” the “PRODUCT” while I “MANAGED” the “PROJECT.” But nobody was really sure what a product was and what ownership meant. So while I was clearly managing a project, she was half responsible for the project and half responsible for a “product.”

There would be no problem if the project was the product. She would just own it and I could help manage the vendors, scope, budget and things. In effect, she would be the sponsor.

We came up with the view that the project would actually be just another step in the product lifecycle.

This helped because we noted some differences that would otherwise be confusing:

• Projects are temporary things that start when someone asks you to start and then end at an agreed point. This means that you are often handing something over at the end.
• Products start life when the first user encounters them and evolve until you decommission or retire them. This means that “projects” only matter if they improve the product or help to retire it. They do not exist for their own sake and their mandate is actually subservient to the goals of the product.
• Projects generally have a temporary team because they are temporary endeavours. But products often have an ongoing team who grow with them. And the product team includes people who design and construct the product, people who maintain and enhance it and people who represent the product to customers, not just the people who build things.

We also agreed that “product” really meant “the thing we are changing in this project.”

A product could mean “a consumer product,” an “internal product,” an “ongoing service,” a “user experience” an “IT application” or even a “process.”

This kind of made sense to me because I had worked with process owners and asset owners before, so I could relate to that.

But nobody had defined our work in terms of a product. We had all defined the scope of “the project” and the budget for “the project.” We were half in product land and half in project land.

We decided to stop and re-calibrate.

The product owner and I ambushed the sponsor and said that we could not run an agile “product thing” without defining the “product thing”. So we spent half a day agreeing what the product was.

Then we wondered what a “project” was.

Based on my BA background, I realised that this was the time to use CRUD.

“We should use a plan on a page and then CRUD,” I said.

Clearly, they had never been BA’s though because they both looked at me blankly.

So I had to explain. This is roughly what I said:

1. Firstly we define the product using a product statement or something
2. Next, we define what value needs to be created or what risk needs to be removed etc … we can use the plan on a page.
3. Finally, we should define the “project” as an initiative to do one of the following

• C is for create.
• Are we creating a new product?
• Are we adding some new features?
• R is for read. Maybe you cannot “read a product” but you could do research.
• Are we researching or discovering anything new?
• Are we investigating or analysing the existing product?
• U is for update.
• Are we updating the existing features of the product?
• D is for delete.
• Are we deleting a product? Or are we removing features or retiring old stuff?

They were still not convinced and to be honest we could have been far more sophisticated.  But the key was that:

• If you do not know what the product is then you do not have a product owner.
• If you do have a product, you need to define it. Then you can define the project in terms of how you are altering (or adding value) to that product.
• Are you creating something new? Are you updating what is already there?
• Just as importantly, are there things that you are meant to research, discover or analyse as part of this project? Are there things that you can remove from the product?

It worked pretty well. Rather than one critical path to success though, we had critical features and critical outcomes, some of which were linked and some of which we could deliver on their own. It was no longer about delivering the project, but about delivering multiple things that added value along the way.

But where did that leave us all?

• We agreed that the sponsor should really have been accountable for the product. But he wasn’t.
• He was delegated by the organisation to ensure that we used the organisation’s resources properly on the “project”, so his role was purely governance.
• He would set boundaries around us all and the PO could make any decision she wanted, as long as she did not cross those boundaries. We called these boundaries our mandate.
• We also needed to respect the owners of the assets, services or other things we were adding value to. There was no point in successfully delivering a project that did not add value to the product. So the sponsor stopped being the main decision person and he had to be happy assuring that the right decision processes were followed rather than agreeing with all decisions. This was a bit of a shift for him, but he was happy as long as we could explain ourselves.
• The product owner worked with the team to “CRUD” the product and she was, therefore, the real boss. She also tried to get feedback on what added or hindered value.
• The scrum master worked with the team to help them work together better, as long as they worked on what mattered for the product. The team would, therefore, lobby and cajole the product owner a lot. So she had to spend a lot of time with them.
• I became the “project administrator.” They gave me a nice title, but really I was the administrator.
• I was no longer the captain of the ship or the head honcho.
• My job was to track vendor agreements, track budgets, consolidate reporting, track dependencies and acquire the resources the team needed.
• My work allowed the team to focus on their work and the product owner (and sponsor) to make informed decisions. So I was more the enabler or “force multiplier” as I like to think of it, rather than the driver
• I provided recommendations and dire warnings about imminent budget crises or painful vendor traps. But I really provided options for people to make informed decisions rather than being the decision maker. This was very odd for me, even if it is consistent with the role. But I gave it a go.

Things worked pretty well and I was free to work on some other hobbies (er – projects).  But I was no longer the fully fledged PM, I was the manager and tracker of things but not the key decision maker.  But I was also in a role I saw value in and I was able to focus on the things I brought to the party.

Is this a typical experience on an agile project?

The problem is that things do not always work out so well.

Some projects have a “PO” who is a subject matter expert, but who cannot make decisions or is not used to understanding the full spectrum of the impacts of those decisions. This means they are really a “PA” or product adviser and should be called that.

Some projects have a confused chain of delegation. One person is in charge of vision and priorities and the other is in charge of budgets and scope and deadlines. Apparently, in Hollywood, this is called “creative tension” and is how great producers work with great directors. But in my experience, it is a recipe for trouble.

Some project teams are working on a project that impacts many products, but also working on a product that is being impacted by many projects. This sounds hard so they simply call someone a product owner and someone else a PM and let them sort it out. This can work if you let the two people get together and invent their own approach. But it will not end well if you expect a disciplined approach to implementing a clearly identified outcome if you don’t know what the approach or outcome are.

Still, other project teams drop the project management role completely, because they hope that being agile means they will be successful. Then they lose track of vendor agreements, dependencies and even the risks and the budget of the initiative they are working on.

Losing track of things is particularly common where neither the PO nor the Scrum Master is skilled in managing initiatives – so nobody does the tracking and managing of things that are not clearly team scope or product outcomes.

In some organisations, people mitigate this by having an “Iteration Manager,” a “delivery lead” or an “implementation manager” who manages the numbers and things as well as facilitating the team. In my experience, this approach can be very effective.

But in truth facilitating a self-managing team and managing the resources needed by the team are two different things, so you can have a team facilitator and a separate project/initiative/release administration person.

My conclusion

For project managers, there is a potential problem when teams go agile. It is all about project versus product thinking and it needs to be sorted out.

We need to define what we mean by “product” and “who owns it.” Then we need to identify how the project fits into that and how we track and manage the resources, constraints and dependencies involved in allowing the team to be agile.

Based on all that we can divide up the roles by speed dating or agreeing on decision rights. It does not have to be too hard. So you will be fine as a project manager if you learn to tackle both product thinking and the concept of empowered teams.

In my next couple of articles, I will share my own views of:

• “When is an agile project actually a project and not a product?” I will look at times when I really was an agile project and treated it like one, rather than thinking in product terms
• “What are the patterns for success if you do have a project manager, a team facilitator and a product owner”. I have noticed some approaches work really well when you have an agile project manager (and not just an administrator) while others fail badly.

These will be my own opinions and not best practice, but I hope it will be useful to share them because people still seem really confused about whether you should have a project manager on an agile project and, for that matter, what they should do if you do have one.

Posted by James King
Copyright © James King