In my last article I used a home made leadership model to look leadership in a self-managed (agile) team. I then used this as a basis to look briefly at how project managers might help or hinder an agile team.
Here I take that concept a step further by looking at how people use project managers to support agile product management.
I will explore some typical PM “role patterns” and then give my opinion on whether each is a good thing (a pattern to consider copying) or a bad thing (an anti-pattern to avoid).
As with the last couple of articles, this one is based on my own experience and my own opinions rather than being a summary of accepted practice or validated research.
I had hoped that by writing a pile of articles first, I would be able to ensure this one was short and to the point. Unfortunately it turned out to be very long. But I thought splitting it further might just dragging things out.
So I apologize for the length of this article, but I still hope it is helpful if you have time to drink a tea and read through it.
A quick catch-up if you missed the articles
If you have read my other articles then you can skip this section. But just in case you are not sure where I am up to, let’s recap.
I am assuming that you have a team is empowered and competent. The people in the team are reasonably clear on their purpose and on how they break their work down.
Otherwise I recommend not worrying too much about the PM, but rather that you focus on setting the team up to succeed when you empower them.
I believe that we can expect them to succeed if the following is true
- They are clear on their purpose;
- They are good at their craft;
- They work together well; and
- They are set up to succeed in that the forces outside their control align to create an opportunity for success.
Based on this, I expect that they use “Chartering” to make sure that they are all on the same page.
Chartering is an activity where the team work through different ideas and viewpoints to come to a common understanding about their mission.
That is my definition anyway. In particular they spend time together working through different ideas and viewpoints about:
- The purpose of the mission that the team are current on and what they need to do in order to complete the mission;
- The way the team will work together as a community; and
- The expectations and practices of good craftsmanship in the context of the team and its mission.
They might capture their understanding in a document and then call it a project charter, or they might simply agree that everyone is clear on what they need to be clear on and leave it at that.
Adding a traditional project manager to this scenario can create issues for two reasons:
- Instead of relying on a project manager to manage their work, the team manages its own work; and
- The Project is merely a step in the evolution of the product and even the product is only a vehicle for delivering value to a customer (or beneficiary). So managing the project is less important than evolving the product which is less important than adding value.
But there is still room for leadership in some form. The team often finds it valuable to have a facilitator, steward or leader to align the team to each of the 3 aspects of their charter.
Based on this, I see 3 common leadership roles in agile teams:
- The Product Owner leads the team in understanding their mission and what they need to do in order to complete it. The “PO” might be called the Customer, the Client, Product Manager, Process owner, Gatekeeper or something similar;
- The team facilitator helps the team build healthy interaction and perhaps adopt some standard team practices. They might be called the Scrum Master, Iteration Manager, Kanban Commander, Executive Assistant or something similar; and
- The lead artisan leads the team in defining and agreeing the technical expectations and recognized practices of their craft or profession. They might be called the Guru, the Tech Lead, the master craftsman, lead writer, Head Physician or similar.
The scope of these roles can conflict with the expectations of a traditional project manager and in some cases they make it possible for teams to operate effectively without a PM.
Back to the purpose of this article
With all this chartering, self management and agile leadership, where does the PM fit in?
The first pattern – The PM takes on a new role and effectively ceases to be a project manager
The simplest approach to using a project manager with an agile team is to let the PM fill one or more of the agile roles.
For example, the PM might evolve into a team facilitator (scrum master, iteration manager etc). They are no longer managing a project so we don’t need to call them a PM.
But the PM does not always become a pure scrum master. Instead I see the PM merging into two or more of the agile leadership roles:
- In digital media teams I have encountered “producers.”
- These are effectively people performing a combined role of team facilitator and product owner.
- They own and explain the vision, as well as facilitating the team’s work.
- I think this approach works well where the creative nature of their work means that the working relationships and development methods are so closely intertwined that it is hard to separate product visioning from work break-down and team working processes. Because of this it is helpful to have one person across each of them.
- When I worked in teams that provided a specialist service, I was sometimes the “lead” or the “senior craftsman.”
- I was, in effect, both the lead artisan and the team facilitator.
- While I was not technically the product owner, I worked with the client to advise them on what to do, as well as how to break the work down and to understand what to prioritise next.
- I think this approach can work well if there is a vendor/customer partnership and the team have specialist skills that give them an insight the work that the client relies on.
- In large organisations I have seen people called “delivery managers.”
- These people are a combination of team facilitator and lead artisan.
- They work with a product owner who is accountable for setting the vision and helping the team make sense of it.
- When I ran infrastructure projects and worked with enhancement teams, this was typically the role I was playing, regardless of having the job title of project manager.
- Again, this approach work where there is a vendor/customer partnership rather than a team who see themselves as part of the same organization as the product owner.
In each of these cases, there is a danger that the person wearing multiple hats sacrifices one part of their role in order to focus on another aspect. There is also a danger that the person becomes a dictator and inhibits real empowerment.
Finally, there is a danger that the leader has the wrong focus for real value creation:
- A delivery lead/agile project manager may think in purely project terms (How to I ensure we deliver this project) without really considering the creation of value or the long term product direction; or
- A producer/customer who is only focused on getting what they can out of the team. They facilitate collaboration and planning but really bias it toward unsustainable delivery in order to achieve short term outcomes or they ignore craftsmanship because they are in charge of both facilitating team deliver and aligning to customer needs, but they do not understand nor care about how the experts build and maintain their products.
These patterns work well when the “ex-PM” can foster empowerment and facilitate chartering. It is also important that they facilitate a clear understanding among the team, the “ex-PM” and the stakeholders as to the decision rights and focus.
These are simple approaches and they work well for small to medium teams.
So lets turn our attention to some approaches that people use when things get bigger and more complex. In these situations the team is likely have a dedicated product owner, a lead artisan and a team facilitator who are NOT the PM.
Is there still a PM role in these circumstances?
Anti-patterns for the PM (bad approaches)
One approach I have seen is where there is a PM and a product owner, but the PM captures the product owner and over-rides their decisions:
In this situation the product owner is reduced to being an SME, but they are still blamed for the result of the project.
The PM controls the scope and budget and makes the final decisions, constraining and inhibiting the PO from adding value.
Now rather than the work of the team being aligned to business and customer needs, the customer expected to align to the team needs to build something in order to finish the project. Value is lost and everyone is sad.
Champion of the team who holds back the forces of the wider business
The next pattern is one that I struggle with, because I think it can be useful in the early stages of agile adoption, but it eventually inhibits the team from creating value.
The organisation is not yet ready to go agile, but the team has been told to be agile anyway. This creates a disconnect between the way the team is operating and way the rest of the organisation is operating.
If the PM is strong enough, they may hold the organization at bay long enough for the team to gain momentum and to convince the rest of the organization to join them.
But usually what happens is that the PM is simply enabling the disconnect between the team and the organization to continue. The organization gets to demand agility without really empowering the team and the team gets to run amok without being accountable to the organization.
This is a disconnect that the PM attempts to mitigate for a time. But a lack of accountability and a lack of control mean that eventually things will come undone. Either the team will cease to be agile or the organization will see unexpected decisions and scope changes as being a failure to deliver and will stop trusting the team.
Next is a pattern that surprises me each time I see it, but that I should really see coming by now. You might call it the “PM as the fix-it guy”
The assumptions I have made about the team turn out to be wrong:
- The team are not good at what they do, so the will do bad work if they are not supervised;
- The product owner is not clear on how to create a vision or break work down to achieve value; or
- The team facilitator is “protecting the team” from both the product owner and those craftsman who want to slow down to support better craftsmanship.
As a result the steps in to take control of the things that are not coming together. Doing so seems to work for a while, but in fact it diminishes the impact of both the team chartering and the accountability of the people in the roles that are meant to help the team in these areas.
If you see the PM writing code, the project is in trouble.
What works some of the time – the uneasy truce
There are also some patterns that work.
A common pattern that adopt when they go agile is to adopt two core ideas – “the scrum master is inward facing” and “the project manager is outward facing”.
This means that the team facilitator helps the team collaborate, plan their own work and remove those impediments that they can tackle on their own.
The project manager then supports the team by acquiring the resources that the team cannot secure on their own, removing large impediments that the team do not have the ability to remove and managing the interaction the team has with vendors, other project teams and other groups within the organisation.
For example you might see the team facilitator running the team retrospective, but the PM running the steering committee. You might also see the team agreeing on who within the team will do specific testing this sprint, but the PM sources specialist testers for things like IT Security testing, accessibility testing and so forth.
I have seen this work and I agree with it in theory. But the issue I fear is that the PM will be the contact point for the team when interacting with many of the stakeholders.
So the PM is meeting with the key players in the organisation (for example architecture, audit, steering committees) and the team facilitator and senior craftspeople do not know what is going on. Or the PM is not aware of what is happening informally within the team as the team move in a different direction to what the PM is telling people the team are doing.
This pattern requires good working relationships and great communication. So it can work well but it can also lead to trouble
Patterns that do work well
There is one pattern that I mentioned in a previous article, where the PM (me) took a deliberate “demotion” by agreeing that the PO was in charge of vision and direction while the PM was really a project administrator rather than a project owner.
This means that the PM is part of the team rather than the leader of the team. The PO sets the direction and the lead artisan makes decisions about quality and workmanship. Also, the team facilitator helps the team plan and execute its work.
The PM focuses on things like tracking the budget, organizing for new team members to get the equipment they need, making sure vendor contracts are managed and producing reports.
The PO makes the final call on whether to change scope, build bells and whistles or MVP’s and so forth. The role of the PM is to ensure that when the PO makes decisions, those decisions are well informed.
Just as the UX, BA or data analyst supports the PO with relevant information and analysis about customer needs, the PM provides relevant information and analysis about the potential budget impact of decisions, the contracts that need to be updated or the status of key resources that the team needs. They also support the artisans in the team by making sure they have access to the building, good tools to use etc.
This is not a glamorous role and it is sometimes combined with the team facilitator role. But it is a different focus and skill set, so for some teams there is a real need for project administration and/or tracking to help inform team and stakeholder decision making.
This model relies on clear accountability and good communication of how things are tracking. It also requires good organisational skills for the PM
The next model I have seen is where the team is empowered and the PO is making decisions, but the team is dependent on another department or another organization.
In this case the team need some way to find and engage the people who they are dependent on, so they have a person who acts as a concierge.
The concierge might be called a PM, a vendor manager, and account manager or even an infrastructure PM.
The is attached to the team (full time or when needed). The team are in control of their decisions and the management of the work.
But they go to the concierge when they are not sure where to find the things they need or they need help engaging others for help. This role could be done by either the lead artisan or the team facilitator, but in some cases the engagement of a particular vendor is complex, or the team lack expertise in a core area (training, IT, etc).
It is important to note though, that the PM as concierge serves the team by providing advice and supporting their engagement of people with skills or resources that the team needs. The concierge is not a project owner, but a relationship facilitator and a resource seeking specialist.
OK, for a single core team, these models work well. But in a complex world there might be multiple teams working together toward a common goal and there might be complex governance expectations that the team needs to be aware of. So this is where the final two patterns come in.
The first is an extension of the team facilitator role, but involves facilitating the planning between multiple teams. So it is a little like the concierge role, but it is different because it is no longer about a single team seeking support from an outside party.
As the project scales or as the product expands to a combination of multiple products and services, there will be dependencies, clashing expectations and resourcing issues that impact multiple teams.
Let me give an example that is probably less to do with product development but is aligned to clear value.
Firefighters fight fires. So firefighters must be very agile in every sense of the work. When a fire behaves unexpectedly the team must respond quickly and effectively.
Call headquarters. Tell them that Larry’s leg is catching on fire and ask them what we should do … said no firefighter ever.
But in a large fire, there are multiple teams of firefighters, all responding quickly to different parts of the fire. They all react quickly based on what they can see, but they are blind to what is happening on another floor in the building or over the next hill in a bush-fire.
So an experienced firefighter stands back, observing all the teams. He or she does not need to micromanage the teams, since each team is empowered to act on their own instincts, training and observations. Each team is also likely to have its own facilitator who the team look to for clarity and they do not need to bosses yelling at them when things are dangerous
Rather the senior firefighter provides macro-management. They are looking at a different horizon, anticipating the resourcing needs of teams, passing information between teams and providing clarity around the big picture so that each team can focus on what is in front of them without being terrified of what might be coming their way.
In this model, each team has its own facilitator, who interacts with the PM who facilitates the collaboration and planning across teams. The PM might be called a release manager, Nexus Star Commander, Release Train Engineer or, in my case once the infrastructure PM.
In the same way each team has its own head artisan, who interacts with other teams by working with a master craftsman, Sensei, solution architect or enterprise architect. Each team also has a PO who works with a Product Manager, C3PO (ie Chief Product Owner) or similar person.
So the three leadership roles remain the same, but chartering and leadership appears at multiple levels.
This model requires excellent management of feedback loops because it is NOT a matter of the PM, enterprise architect and C3PO setting the direction for others to follow. It involves constant communication, facilitation and feedback loops.
Finally there is a model I call the parent model, named after the way that parents empower their kids, but actually retain some accountability
I trust you but I will check
Really though, this is not about parents or about project management. This is about governance.
Let me explain this one.
I am assuming that you are hiring people you trust well enough to empower them rather than trying to control the way they work. I am also assuming that they are competent, clear on what is needed and good at managing themselves.
So why might we need governance beyond the roles that we have already discussed?
Let’s look at the example of an operating theater, I would expect a surgeon to make their own decisions based on their expertise, their skill and their observations of what is happening. I would expect them to work well with nurses, technicians and anesthetists to create an effective self managing team during the operation. I would also expect them to abide by a recognized set of ethics and professional practices.
However, I would certainly not want a project manager coming in to interrupt the operation to make everyone go to a steering committee or prepare status reports while the patient lay on the table.
In the same way I often find an obsession with “governance” is an excuse for “interruptions” and not really empowering the team.
But there is a risk of bias and group-think when people work together in a tightly bonded team and they rely on each other closely.
Also, in any highly regulated industry, or any profession where ethics is considered important, there is often a need for governance because of the nature of the work.
This does not mean that we can hire bad people as long as we govern them. Rather it means that professionals should manage their own work, confident that others teams are behaving well, that they can seek help and guidance when they are unsure and that they will find out if outside factors change.
In this pattern, teams manage themselves but they agree to work within a governance framework that requires a level of independent assurance or a level of reporting for the organisation beyond the decision making performed by the team and their leaders.
Finally – a conclusion
Not all teams need a PM.
But I have very often used the model of “the PM as administrator” in order to make it quicker and easier for teams to perform their work and make informed decisions. I guess this is my favorite pattern.
I have performed the role of PM as facilitator across multiple teams and the concierge role more than once and it has worked well.
It is also possible to merge models, but if you do then you need to:
- Remain clear on the decision rights that the PM and others have;
- Ensure that teams are empowered; and
- Ensure that the “other leadership roles” are able to lead rather than being managed by the PM.
In practice though, I guess it is up to you to decide whether your agile team needs a PM who performs any of these roles, or whether the team can deliver the same outcome without them.
You might also disagree with the patterns I have identified, since they are based on my own experience rather than recognized best practice. But I have found them to work well for me.
Finally, I have found a lack of clarity around the role of a PM who is there can be worse than having no PM … and having no PM might create a gap around things like budget and dependency management, vendor concierge services and potentially governance services and other areas.
I apologize for the long article and I hope it has been helpful.