We’re agile we won’t need project managers anymore!
This is a common thing I hear from people when organizations start their agile journey. This is a statement that is met with either great joy or a lot of concern. For those who have unpleasant experiences with command and control project managers, a team “becoming agile” is a chance to get rid of that project manager and gain more freedom. For those who are project managers this statement is one that is very concerning as its a direct attack on their position and their livelihood. I disagree with both points of view when it comes to this topic.
People often see project managers as “anti-agile” or that agility and project management are opposites. Agile transformations don’t try to do away with project managers what it tries to get rid of is the command control mentality that is associated with the role. Over time as teams get better and better at organizing themselves the need for a person dedicated just for that purpose is no longer necessary. When that happens project managers shouldn’t worry as there are many roles they can take on.
Be a product manager or product owner
This is the most obvious fit for most project managers as there is an overlap between the responsibilities of the two roles. Both project managers and product owners work with and are in close proximity to the development teams and both roles are concerned about generating the most value from the time that we have. In most organizations both these roles the ones who are accountable or responsible for the delivery of the product.
So what’s the difference between the two roles? Product owners and managers don’t have authority over the team, unlike traditional project managers. The way they are able to handle manage delivery is through managing the scope of work being done. Product owners create a clear roadmap and vision for the product and its features. When this vision is communicated well towards the development team they are able to understand the intent behind each feature. This understanding becomes key to coming up with the best solutions available. Cultivating this relationship is the key for product owners to be able to come up with the best value for the time that the development team uses. By removing the fat from the work being done the product owner is able to influence the time it takes to deliver work. Ruthlessly prioritizing the work being done allows the product owner to influence the order of delivery of items in order to follow the roadmap they have planned.
Traditionally project managers gain control of outcomes by managing two things. They manage the people doing the work or the time being used. The people doing the work are compelled to work faster or longer hours so that the outcomes can be achieved. Alternatively, they sue for more time by getting extensions on deadlines and the like. They also sometimes do both. Product managers influence outcomes by managing the scope of work being done. Through good prioritization, well thought of features and good relationships with the development teams they are able to deliver the expected outcomes with the least amount of effort.
Join the team
Most project managers would have a good understanding of the project from the standpoint of the user and would know the stories behind certain features or decisions that have been made. This means that they could take on some of the testing or analysis load. They’d be valuable when figuring out how things work and identifying risks in the system. Any task that would need domain knowledge and analysis could be done by the former project managers.
What could make this difficult? The typical relationship between the project managers and the rest of the team is one where the project manager has “authority” over the team. Whether this authority is real or perceived it still makes the transition tricky. Making it work will require healthy communication from both sides, the project manager has to be aware of the dynamics and know how to take a step back, dial down the message or sometimes just help the team by facilitating conversations rather than leading it. Team members should also be mindful that the dynamics have changed, shifting their mindset from working for their former project manager to working with their former project manager.
Be a coach
The trickiest of all transitions to make but the most common one I’ve seen. The typical story goes like this. We’re going to try to be agile so we’ll try out Scrum, we’ll get all our project managers then send them to get their CSM or PSM certificate. They come back with a certificate in hand and ready to change the world.
Sound familiar? Probably because that’s how a lot of teams and organizations start out. On the surface it seems like it makes sense, project managers would typically help drive process improvement and try to make it better while a scrum team has inspect and adapt cycles where the goal is to get better. Project managers would be protecting the team from distractions and the same is true for a scrum master.
Why is it so tricky then? One of the biggest hurdles is the existing dynamics between the team and their manager. If they’re used to the project manager telling them what to do, driving process improvements and being the star of the show then they’ll just continue on with that. That’s not to paint project managers as overlords with whips who rule through fear, its more an acknowledgment of how things typically are. It’s very easy to fall back into old patterns of behavior and to do the same things just with different names and that’s the thing both parties have to be mindful of. This is the reason why it’s so tricky, even in the healthiest of relationships between a project manager and the team it’s still a tough line to walk. Is it impossible? Of course not especially if you’re aware of how things are.
At the end of it, all successful project managers are those who have a keen eye for detail, are good at building relationships and keeping teams and tasks organized. Skills like that will always be useful and valuable in any team and there is always value in someone who can do those things. Just don’t get too worked up about losing the “manager” in your job title.
To read more about agile teams check out my book The Agilist Field Guide.