What is an Agile Project Manager?

If you Google “Agile Project Manager” you’ll find a lot of stuff out there, much of which is inconsistent. There are job descriptions asking for one, there are classes to learn how to be one, but the definition is still not clear nor is it consistent with agile development ideas or the Scrum Framework. Watch this video or read the transcript below with Professional Scrum Trainers Robert Pieper, Jason Malmstadt, and Greg Crown to find out more what is meant by the term “Agile Project Manager”.

Never miss a post.

Sign up now and receive updates when we post new content.

I will never give away, trade or sell your email address. You can unsubscribe at any time.

Robert Pieper:  If you google this topic, you’re gonna find a bunch of things out there for “agile project manager”. But what does that even mean? What is an agile project manager? So I started doing some digging, and there’s not really a clear definition anywhere. But here’s the main idea: If you’ve got a project manager, and they’re using some agile development techniques, they’re using agile ways of working with the team and managing the backlog and some of these kinds of cherry picking of practices you often find in Scrum or extreme programming… Mix that with traditional project management, and you get this “agile project manager”. So the main idea is you’ve got one person who is sort of owning the management of the projects when in Scrum, we kind of flip that around. It’s the entire scrum team that manages the project and so they don’t have a dedicated role in Scrum. Yet we keep seeing this Agile Project Manager thing all around the internet and on job descriptions. So speaking of the job descriptions thing. Greg. What are your thoughts on this? When you see job descriptions looking for an agile project manager? What are you thinking?

Gregory Crown: Well, first, I think project management with an Agile spin is perhaps better than a project management without the Agile spin. But I think we’re still going to see that the accountability and ownership of the success or failure for the projects will rest primarily on the shoulders of one person. So whether you are an agile project manager or just a regular project manager, you still bear the responsibility and accountability and ownership of the project. Its success. And its failure. So as these job descriptions really add some new ideas: familiar with agile practices, know how to manipulate the backlog, have thorough stakeholder engagement, understand the needs of the customers – those are a very agile way of thinking – but it still ends up pressing on the shoulders of one person. Because then it says, “and also able to influence the execution of the project.” So it’s still on one person, all the things tied to one person with an agile twist. It might be a bit better, but it’s still management of people and tasks and projects. And I think that’s where the job descriptions are really not all that different. Just maybe with a little agile spice. That’s about it.

Robert Pieper:  Like a little cumin…a little bit of chili pepper.

Gregory Crown: Just a little extra kosher agile.

Jason Malmstadt:   I’ve seen this play out in several organizations where you have, you know, the company has decided from on high, we’re doing Agile, give us all the “agiles’ or however they’re going to phrase it. And then they just don’t know how to operate without that role of project management. And so rather than leaning into self management and building autonomous teams that manage their activities that manage their backlogs that manage all the things that need to be managed in development activities, they still have sort of a predefined scope. They have a predefined budget, they have a predefined timeline, and yet somehow we’re doing Agile or trying to be agile. It takes a lot of the adaptability out of it. You’re mixing the paradigms here where you have this predetermined path, and we’re not really optimizing for the ability to learn and change and move in different directions to accommodate some of those unknowns that are inherent in the complex domain. So I think there really is a fundamental misunderstanding here when we try to bolt on project management into these agile teams.

Robert Pieper:  and kind of piggybacking on the fundamental misunderstanding. We see companies that are asking for agile project managers and looking for them actively or defining this role… It’s often a sign that they don’t get it and I hate to say that in a judgmental sort of way, but more they don’t understand the point of this word “agile”. It’s not about sprinkling a bunch of practices on top of your existing project management techniques. It’s about fundamentally changing how your business operates to optimize for nimbleness, for agility, for the ability to pivot quickly when you realize you’re on the wrong path. Traditional Project management isn’t really set up to look for those things. It’s set up to keep the train on the tracks. Keep to the plan and of course, manage risks and identify them as you’re moving along. But they’re fundamentally tuned for different things. And when you take one technique that’s tuned for rigidity and staying the course or staying on the path and managing risks as opposed to looking constantly for a new way to execute on a goal. You put those two together and you end up with some sort of Frankenstein hybrid that oftentimes doesn’t get the best of either world. And so for those of you looking for new jobs or whatever, in the agile project management space, it’s oftentimes a great opportunity for you to find those companies looking for those hybrid roles, because they get to cut your teeth on teaching those companies the benefits of a more nimble way of working and what this word “agile” means in the first place. If the company’s already got it, there’s no teaching opportunity there. They already know it. So yeah, those are my thoughts on it. 

Robert Pieper

Robert Pieper has been a licensed Scrum.org Professional Scrum Trainer since 2014 and National Public Speaker since 2013. Robb holds an MBA from Marquette University and an Electrical Engineering Degree from Milwaukee School of Engineering. Robb has 15 years of professional software development experience with a passion for making Scrum work delivering real products and services