Scrum has some really good points to it but one of its failings is that it doesn’t recognise the role of the project manager. This in turn creates all sorts of difficulties for Agile teams, especially those that are transforming a large organisation. To my thinking if we let go of the PM role then who is going to take over governance of the projects? This is where I think Atern has got it right as it not only recognises the need for the PM role but strongly encourages its use. However, my experience informs me that often PM’s in the Atern role have a hard time switching their thinking and behaving to be more aligned with the Agile way of working. However I personally believe that the Atern handbook doesn’t help the plight of the PM in an all new Agile world as some of its direction can be somewhat misleading. In this article I will explain more, but I am hoping to get hold of one Atern’s luminaries to shed some light for me on some of these differences.
My appreciation for PMs
But first, let me clear up a few points as in the past I have been accused of “Project-Manager-Bashing” on some of the courses that I deliver. I have come from a PM background where I have run projects in Waterfall and RUP; I have also coached and consulted PMs on projects running Atern and Scrum. So I have much empathy (note, not sympathy – that’s way too debilitating to be in any way resourceful) for PMs moving from a mindset and associated behaviours of waterfall to Agile. During a transition to Agile there is a time where many (not all) PMs will flounder as they grapple with the new behaviours required of an Agile PM and the thinking that supports these behaviours. The transition required of PMs is IMHO the most stark and contrasted change required for any of the roles on an Agile project or programme. To this end I believe that PMs need support and challenge, in equal measures, during this transitional period. This support and challenge is often provided by means of Agile coaching especially adapted for PMs. (You can check out our offering here.)
What is the role of an Agile Project Manager?
In my opinion the Agile project manager (APM) is a mainly externally facing role. The main goal of the APM is keep the customer happy and satisfied, in this case the business; if I’m talking in Atern terms here I mean the business visionary and sponsor. Now there are other high level managerial duties that the PM will carry out such as high-level project planning and scheduling (do note that I did not include estimating here), monitoring progress against the base-lined project plans, removing impediments that are outside of the solution development teams’ scope and so on.
However the Atern handbook does give the following, what I would call misleading, advice (see p40 under responsibilities):
“managing the overall configuration of the project.” mmmm – What is meant by configuration here? If we are talking the setup of the teams i.e. should we structure the available people into two or three solution development teams in order to deliver, then I firmly believe that this is a job for the team to consider. Isn’t this what we mean by empowerment? Aren’t Agile teams supposed to be self organising? I’m not saying that PMs shouldn’t have some input into this because there may be limitations or restrictions that may mean that the teams can’t organise in the way they would optimally like to.
“motivating the teams to meet their objectives.” I don’t think so! But imagine for a moment if that were true what possible “carrots” or “sticks” would the PM be offering their team. When I coach PMs I help them understand this one point at the outset: the only way a PM will motivate the team is by seeking to deal with what Herzberg refers to as the Hygiene factors, things like environment issues, bureaucracy and red-tape, an escalation point for relationships with other team members (between departments) and salary & benefits. (Of course even this last one not many PMs have much control over.) I’ve had many PMs have most interesting discussions with me on this point and some even go so far as to say that they feel that it is their responsibility for the teams happiness! Good luck with that one, but I feel that this is a topic for a completely different blog post, but maybe you can provide me some answers below as to why this is a completely unrealistic expectation that is placed on the PM?
“coaching the solution development teams when handling difficult situations.” mmmm – again I can interpret this in many ways. OK if a team member comes to the PM then I would say by all means be a supportive ear or a challenging voice. But I feel that the PM ought to be building a network of leaders below them through the team leaders. Often PM will unintentionally build learned helplessness into their teams by being the person who will solve all the teams problems and issues for them. This is why I have serious reservations about the ab-use of the term “coaching”. Much of the coaching I have observed is actually mentoring and falls under the banner of telling people what to do; but hey I know that ship has sailed and I’m not going to be able to get the whole Agile community to address the misappropriation of the term Agile Coach, so ’nuff said. But coaching isn’t a clever or manipulative way of telling people what to do or giving them advice, that is one small part of coaching that is reserved for “emergencies” and is applied with many caveats.
The PM as the “one wring-able neck”?
I have saved the most challenging quote from the Atern handbook for last: “The Project Manager role is responsible for all aspects of the delivery of the solution.” (The highlighting of all is mine.) Ouch! So are we back to a case of the PM being the one wring-able neck? If the project fails the PM gets the boot? I know this might still be the prevailing wisdom within organisations, but it is inherently flawed. If the PM believes that they will be the one wring-able neck then they are going to act in ways that will be dis-empowering for the team. Where is their responsibility? Are they being given permission to fail. I know this stuff really reads well in the text books just before we pop off to sleep to dream about our projects being in some Disney movie, but in actuality is the environment within which projects are delivered “blame-free” and “safe to make mistakes and learn from them” zones? This is not the case in all organisations. If not then this ceases to be a management issue and becomes a leadership issue. I’ll write some about this in up and coming posts.