What is an Agile Project Manager?

April 8, 20134 min

A few weeks ago I received an email message from a former student with some disappointing news – the company had fired all the ScrumMasters and replaced them with “Agile Project Managers”.  That meant a former student of mine was out of work, looking for a job and Scrum had suffered a serious set back in their organization.  That was kind of sad :(

When I first read the message, I thought to myself “What is an “Agile Project Manager?”  So, I did some research to see when this term came about (early 2008), to look for some articles about these agile project managers (APM) to find out what they are and why businesses prefer them over ScrumMasters.

When most people think of a project manager, they envision someone who is held accountable for managing scope, cost, quality, personnel, communication, risk, procurement and other aspects of product delivery.  This is person we typically blame if things go wrong or the person we browbeat if we feel things are going wrong in some way.

Personally, I never understood why anyone would ever accept these responsibilities.  It is not like the project manager does the work, so how can they be accountable for quality or the schedule?  The project manager does not decide the business objectives, so how can they really manage scope?  And should they manage scope if the business domain is in flux and changing rapidly?  The project manager is usually not a functional manager, so how can they be held accountable for personnel or their performance?   I understand this is how PMI wants to define the project manager role, but I want a pony and that does not mean I am going to get one.

IME, I tend to think  project managers are often at odds with Scrum.  If you read Ken Schwaber, he tells us that project managers were deliberately left out of Scrum.  In his opinion, project managers are counter-productive to knowledge work, diminish creativity and decrease the intelligence of the Team (I can almost hear the collective “Hip! Hip! Hooray!” from the people who support this statement and the collective “What an ass!” from the people who disagree with Ken).  If you follow the PMI definition of a project manager on a software team, in many cases you just end up with someone who tells people how to do their job or a project nanny.  Both of these behaviors are very irritating to highly-skilled professional and diminishes respect, trust, commitment, focus and self-organization.  When people tell me that their company has cut out the ScrumMasters in favor of APM, what they were saying is they wanted that one person they could blame if the effort went bad.

It sure would be nice if you could look at diagram, see someone’s name in a box (always at the top of some pyramid) and say “Oh yeah…Carlton.  That is the reason why this project failed – bad project manager.”  It would be nice (like having a pony), but in many cases it simply would not be true.  Product efforts fail for many reasons.  A lot of them are due to what I call the initial conditions: the way the project was initiated (not enough time or resources), lack access to empowered decision makers or organizational constraints, i.e. bureaucracy and aversion to success.

In Scrum, we rely on self-organizing Teams to do the work and hold them accountable for quality, communication and technical risk.  The Product Owner is responsible for business risk, communication, scope and cost.   While there is no project manager in Scrum, for project or programs that are very complex or have lots of governance, some project management duties (notice the distinction here), still need to be completed.  Management activities such as personnel management, procurement, business communication and other activities that typically are completed by the project manager might be best completed by having someone on the Team whose primary function is management.  However, keep in mind these people are not managing the Team, but the management activities.