News

In my last article, I claimed that you can have an agile project manager who ran agile projects. But the projects I described did not involve “typical” agile teams.

So now I want to show that a project manager can work well with a typical agile team.

Let me start with a simple question: 

Can a project manager work effectively with a typical agile team? 

What is an agile team?

In order to answer the question, I feel like I should explain what I mean by “an agile team.”

I looked in the dictionary and I found out that agile means “quick and easy of movement.” I guess I could conclude that an agile team is one that can do things quickly and easily.

That sounds right, but I’m not sure it is sufficient, so let me build on it.

I claim that being “agile” requires us to empower teams. In fact, this simple principle is core to everything I believe agile stands for.

You can disagree, but you are wrong. Or more accurately, everything in my argument is based on the need to empower teams, if this is incorrect then my entire argument is wrong and you can stop reading.

On the other hand, though, if you accept that empowerment is a given for an agile team, then I can define agile this way:

• In the agile context, we empower teams to do good work; and

• Agile is really just a “way of working” that focuses on making it quicker and easier for empowered teams to do good work.

I know agile is really a mindset and that we should all “be agile rather than just doing agile. But an agile mindset does not presuppose any specific roles or processes. So for today, I am sticking with my simple definition because I am discussing the role and value of a project manager.

Now I can rephrase my original question:

How can a project manager add value when the way we work is based on making it quicker and easier for empowered teams to do good work?

This sounds straightforward. I can ask project managers if they are making it quicker and easier for empowered teams to do good work. This is the concept I explored in my article “The problem with project managers and self-managing (agile) teams.”

Let's continue – if a project manager is making it easier for an empowered team to do something, then what do I actually mean by:

• An empowered team; and

• Make it quicker and easier to do good work.

The simplest possible model - one person

Let me go super basic and assume that my team has only one person in it. By definition, a team probably has more than on person, but bear with me.

Let’s say that I ask someone to do something and I want them to succeed.

My first option is the micro-manage them to ensure success. But this will not work in an agile setting because micro-management is the opposite of empowerment.

So I decided to empower them, but is this really a good idea?

Well yes – if they will succeed. But maybe no if they will fail.

I only really want to empower the team if they have a good chance of succeeding without me micromanaging them.

So I guess when I ask them to do something, I want to understand whether they are likely to succeed.

When I empower them – are they likely to succeed?

To make this determination, I could look up the person’s date of birth and do an astrological reading. But I am not really into that and in any case, most project managers are ill-equipped to help with astrological readings.

Instead, I can ask a couple of key questions:

• Can they do the job well – Are they a good worker?

• Are they set up to succeed – Will the forces of the universe help or hinder their success?

I believe that someone can do the job well if there are the following is true:

1. They are clear on their purpose – they know what needs to be done and they really care about it.
2. They are good at their craft – they have the problem solving, artistic or mechanical skills to do the job really well.
3. They are good at self-management – They can manage their time well, they are resilient in the face of setbacks, they know their limits and their potential; they can apply themselves well to getting the work done.

Often, we can also predict whether the universe wants them to succeed. This might come down to many things, but here are some of them:

• Will the person have access to the resources and the information they need?
• Will others be likely to help or hinder them?
• Are there impediments that will make success difficult?

OK great, but is any of this useful?

No – because we want to look at agile teams, not a person doing something on their own.

Sorry about that, but it was an interesting diversion.

A simple model for a team of more than one

Let’s change another variable. I still have empowerment but I no longer have only one person in the team.

Now I have asked a team to do something for me and I want them to succeed.

Again – If I want to micro-manage them then I am not being agile because agile teams must always be empowered in order to succeed.

So I come back to my key question – will they succeed when I empower them?

Even though we now have a team rather than an individual, I think we can use the same approach:

• Can they do the job well?
• Will the forces of the universe help or hinder them?

Agile teams often fail for predictable reasons

Sometimes agile teams fail and if they do so then I predict that is will often be because of one or more of the following reasons:

1. They are not good at their craft.

• This might include that they are not permitted to spend the time to perform their craft well;
• This might include teams who master one craft, but forget that in a cross-functional (multi-disciplinary or multi-craft) team, we do not master one craft at the expense of all the others that we need; and
• This will always include teams who hope to succeed with agile but don’t respect the importance of a continual focus on good craftsmanship.

2. They do not own their own vision or they do not share a clear purpose that they all align to
3. They are not good at managing themselves
4. The forces of the universe mean that any team will struggle in the current situation that they are in.

We can shift the odds to make success more likely

But agile teams do not always fail and I think there are actually some concrete things we can do in order to massively improve their chances for success.

The first thing we can do is called “chartering:” This means that the team spend time together challenging and aligning their thinking to agree on the following areas:

1. Agreeing on what good craftsmanship requires in their context

• The team spend the time needed to agree on what good work will look like and then they regularly reflect on how they can improve their craftsmanship.

2. Agreeing on their purpose

• The team spend time clarifying their vision by creating a problem statement, vision box or team value proposition.

3. Agreeing on how they should work together

• The team spend time on a social contract and possibly on a framework or operating model in order to work together as well as possible.

4. Understanding the world they operate in

• The team regularly assess the forces of the universe that might impact them and they change course based on the prevailing weather, the rocks that might be in their way, new opportunities that they stumbled on and other factors.

 The second thing we can do is called leadership:

1. Someone becomes the lead artisan (senior developer, tech lead).

• The experienced artisan supports empowerment by teaching people to be better at their craft and by connecting the team to the other artisans in the organisation so they work together well. This makes it quicker and easier for the team to do good work.

2. Someone becomes the PO.

• The PO supports empowerment by connecting the team to the vision or the problem that they are solving. This makes it quicker and easier for the team to do good work

3. Someone becomes the team facilitator (executive assistant, scrum master, kanban commander, iteration manager)

• The team facilitator helps the team work well together. This might include simply facilitating the work or it might involve coaching and challenging the team to improve the way they work together. This makes it helps the team to do good work in a quicker and easier way

4. Someone becomes the “something” (PM, coordinator, etc)

• This person helps the team react more quickly to changes in the forces outside the control of the team by allowing them to be better informed.
• Ideally, this person also exerts at least some control over the outside world. This might involve acquiring resources, managing contracts and vendor/client relationships, managing dependencies between teams etc.

So where is the project manager?

Finally – some conclusions.

The project manager would actually be hindering the team if they:

• Got in the way of the team being empowered
• Got in the way of the empowered team doing their own chartering
• Undermined the leadership roles that help make it quicker and easier for an empowered team to do good work.
• Got in the way of the team’s ability to observe, understand and influence the “forces of the universe” that exist outside the team.

For example, I looked at how a project manager (me) might undermine a product owner by not allowing them to own the product.  This was my article called The problem with project managers and product based thinking. But the same is true if the PM undermines the ability for the experienced artisan to lead the team in mastering their craft.

Just as bad though, would be having a PM remove visibility from the team by taking away their “line of sight to the customer” or their “ability to see what is happening outside the team. And just as bad would be hindering the team's ability to influence the world outside the team (dependencies on other teams, funding models, changes in customer expectations etc.

Here is the good news though. The project manager would be “making it quicker and easier for an empowered team to do good work if they:

• Helped the team become more empowered, by coaching them, creating permission for them to act, protecting them from distractions and micromanagement etc;
• Helped the empowered team with their chartering by facilitating the process, creating links for the team, creating time in a project for chartering, or even just accept and champion the need for the team to do this chartering rather than just rushing around trying to deliver stuff;
• Supported and strengthened the leadership roles within the agile team … or even filled one of them; and/or
• Helped the team understand the outside forces that will impact them and where possible exerting an influence over those forces to change the odds in favour of the team succeeding, or even just reminding everyone that it is not the teams fault that we suddenly had a budget cut – the team will adapt but we will get less from them if they have fewer resources.

That is my generic answer.

So, do we actually need a PM?

The PM is not always needed and is sometimes actually an impediment to agility … because they do not support a way of working that is based on making it quicker and easier for an empowered team to add value (err .. .do a good job).

On the other hand, there are many situations where a project manager can actually help make it quicker and easier for the empowered team to do good work.

I know this will shock you, but some teams have both a product owner and a facilitator, But nobody is specifically there to support better craftsmanship and nobody is specifically there to help the team integrate into the world around them, where there are many forces at work that will impact the likely success of the team.

Not all teams have a project manager that can help teach the team to be better at their craft. But actually, some teams have “Delivery lead” who merges the team facilitator role with the experienced artisan role. Indeed this was almost the default when I started “projects.”

But even where the team owns their own quality and technical decisions (my favoured model), the project manager might be brought in where a team need support with understanding and influencing the “forces of the universe” that are not within the team’s control.

So there we have touched on two patterns for success:

• A delivery person, who helps the team do good work by both helping them with their interaction and their craft. But this is not necessary if the team are fully empowered to control both of those things.
• A person focused on understanding, interacting with and influencing the outside world, so the team can get on with their job.

Where to from here?

Next time though, I want to go a little further. I will look at some common patterns or approaches where I think a project manager can work well with an empowered team that does its own chartering AND has its own product owner, experienced artisan and team facilitator.

Then you can finally agree or disagree with my view that we definitely do NOT need project managers in agile, except where we do.

Again, note, however, that these conclusions are based on my own experience and my “dodgy” models of successful agile teams.

This is not best practice and it is not “correct agile.” This is a rough and dirty summary of what I think works for me, with the teams I have worked with.

Posted by James King
Copyright © James King