The True Role of a PM on Agile Projects

So, what does the PM do on agile projects? If the team self organizes and selects their own work from the prioritized feature list, should the PM just buy pizza and keep out of the way? Well they are short changing the team if that is all they do. Rather than a fear of role erosion, PM’s should be maximizing business value delivery and looking to broaden their skill set with more leadership practices.  This post outlines four core roles and ten core principles managers of agile projects should practise. 

Working in Parallel
Before we start, the transition to agile does not happen overnight. There will be a long and sometimes awkward transition period as all the project stakeholders adopt a more collaborative and empowered approach to work. Some people will be quicker than others to make the transition and the PM often has to continue with traditional PM activities, behind the scenes, to ensure no balls are dropped on the project.

Ideas not new to agile, just a renewed emphasis
The Agile PM traits of a downward serving model and Leadership rather than Management were not invented by Agile guru’s. Instead agile teams found that the management styles that favoured people over process, collaboration over command-and-control worked best on agile projects. Leadership that moves the emphasis from doing-things-right to doing-the-right-things is a better complement to agile methods than the detail oriented task management popularized by modern project management. Interestingly, project management (emphasising achieving things through task control) is a relatively new phenomenon based on Fredrick Taylor’s Transformation View of task decomposition (1900). Whereas Leadership (emphasising achieving things through collaboration and shared vision) is as old as human collaboration itself. "When the best leader's work is done, the people say, We did it ourselves." - Lao-Tzu (604 BC)

Agile PM Role 1: Obstacle Removal

From a lean perspective, it is the development team who generate business value and so a critical role for the PM is to maximize this value delivery by removing any impediments to their progress. This means solving problems and removing obstacles that may be hampering the teams work. At the daily stand-up meeting where the team reports progress, planned work, and issues, the PM needs to take note of the issues and make their resolution that day’s to-do list. By solving or easing these impediments the development team will go faster and more value will be delivered to the business. Some agile PM tools now support impediment backlogs, a kind of prioritized obstacle removal list for ScrumMasters and project managers to track their work of impediment removal.

Agile PM Role 2: Diversion Shield

As the name suggests, the diversion shield role entails protecting the team from off-topic requests and excessive compliance work that diverts from the current iteration’s objectives and general business value delivery. When working closer with the business it is often tempting for business folks to make side requests for changes or enhancements direct to developers that sidetrack planned development effort. While agile projects positively encourage these business insights and requests, the proper channel is through the iteration planning meeting or requests to the Product Backlog Owner. The PM needs to remind people that requests should go through those channels so that we can maintain iteration focus and establish a reliable velocity (progress metrics) to help plan future work.

In addition to internal diversions, the PM must especially protect against external diversions. Time fragmentation saps productivity so shielding the team from non-critical external demands will pay dividends. Physically co-locating team members is an effective way of preventing external interference. However, if one or two people are still located in their old departments or workspaces it is so much easier for them to be drawn back into non-project work. In the lean vocabulary, activities that do not directly contribute towards business value delivery are called “Compliance Work”. Compliance tasks include duplicated time recording, non-project meetings and other administration tasks. Minimizing these calls on the team either by hiring staff to do them or by removing the need for them is an important aspect of maximizing the effectiveness of the team. Doing something “just because” is not a valid reason, try practicing the ask “Why?” five time exercise to establish the real reason for administration tasks and see if they can be achieved some other way.

Agile PM Role 3: (Re)Communicate the Project Vision

This may seem like an odd one, but a critical role of a project leader is to communicate and re-communicate the project vision. By creating a clear image of the completed system and project goals, stakeholders can check and align their decisions and work towards the common project objective. James Kouzes and Barry Posner, authors of the best selling book “The Leadership Challenge”
describe it like this “Leaders need to reveal a beckoning summit towards which others can chart their own course.” Put simply, a common vision helps keep people pulling in the same direction. While this may sound obvious and trite, it is common for divergent views to develop between well intentioned team members. Developer’s desires for simplicity or new technology can diverge from user requirements. Analyst or QA desires for completeness and conformance can diverge from PM and sponsor requirements for progress and completion.

Jim Collins in Good to Great writes that a trait of Level 5 Leaders (the most effective, and leaders of great companies) dedicate a much higher percentage of the work time to communicating and re-communicating project and corporate vision. Kouzes and Posner believe it is almost impossible for leaders to over communicate project vision and it is a critical step for effective leadership. So, don’t have just one vision exercise at project kick-off, develop your iteration goals and then assume you are done. Continually look for opportunities to communicate the project vision and new ways to illustrate and reinforce that vision. You may sound like a broken-record to yourself, but the “a-ha” and “OK, now I get it” connections made by internal and external project stakeholders will pay dividends.

Agile PM Role 4: Carry Food and Water

We need to provide resources in the form of tools, compensation and encouragement to keep the team nourished and productive. People cannot continue to contribute iteration after iteration to the best of their ability fuelled by professionalism and duty alone. We need to learn what motivates the team members as individuals and finds ways to reward them for good work. Saying a sincere “thank you” for some hard work is a great place to start.

We also need to celebrate small victories (and of course large victories) as we go. It is tempting to save the project celebrations to the end, but without some regular recognition we may never meet the (successful) end. As I have mentioned before, celebrations and recognition is a momentum building exercise, we need to practice them frequently so obstacles can be broken through and the final project goals accomplished.

Another example of this type of support includes taking an interest and arranging for training and other professional development. By growing the skills of the individual team members we not only gain the benefits of this new knowledge, but also show that we want to build skills for the team not just extract work and information from them.

Ten Principles to Manage Agile Projects By:
In addition to these four core roles there are of course a host of other activities the PM should keep in mind. Jeffery Pinto in “Project Leadership: from Theory to Practice” has a great list of principles that includes the following:

1) Learn the team members’ needs
2) Learn the project’s requirements
3) Act for the simultaneous welfare of the team and the project
4) Create an environment of functional accountability
5) Have a vision of the completed project
6) Model the desired behaviour towards this vision
7) Resist meddling and recognize team conflict as a positive step
8) Manage with an eye towards ethics
9) Take time to reflect on the project
10) Challenge the process

So, while buying pizza and sometimes keeping out of the way clearly fit these roles and principles they do not begin to describe the full range of work required to effectively manage agile projects. From time-to time take a moment to checkpoint your behaviours against these lists and see if the project can be better served by some work on neglected areas.

Comments

[Meade]

After reading your article - I had to sketch out what a PM responsibilities are - basing it on my prior experiences and think it's a bit more then you have listed above. I agree with your list - but Agile or not - think a PM has wider responsibilities. I sketched my understanding of those here: http://itprojectguide.blogspot.com/2007/05/project-manager-responsibilities.html

[Mike Griffiths]

Hi Meade,

Thanks for your comments, my post was intended to outline core roles and principles to focus on and is missing a whole host of activities that need to occur.

I like your mind map of tasks, but again this is incomplete also, for instance I see no reference to Quality. (e.g. monitoring Quality, QA planning etc.) The same goes for sub-contractor management and elements of estimation.

Another trouble with trying to generate exhaustive lists is that many of these roles are domain specific, so to keep it applicable I stuck to a high level. However, I could have done a better job of explaining that this is by no means a complete list.

Best regards
Mike

[Nigel Tymms]

Hi
Just out of interest, this Agile method looks identical to DSDM that i used several years ago to implement software projects. Is there any difference from your perspective ? If as I believe there is little difference then I assume all the DSDM literature I still hold is pretty much interchangeable.

[Mike Griffiths]

Hi Nigel,

DSDM is one of the oldest agile methods and so the principles it recommends still hold true to today. Areas in which more recent agile methods have brought additional emphasis include team self-selection of work and increased retrospective based adaptation. I was very fortunate to be involved in the creation of DSDM in 1994 and it is reassuring to see how well it has lasted and how it continues to evolve.

Regards
Mike

[Rajeev Singh]

I like the fact that it is important for you to celebrate small victories. Not sure what you mean by functional accountability, though. Very informative article, overall.

[Mike Griffiths]

H Rajeev,

Thanks for your feedback. Pinto’s “Create an environment of functional accountability” recommendation speaks to the importance of people knowing what they are responsible for. It is related to shared leadership. The Build-Manager is accountable for ensuring the software build process works and is up to date. The project manager is accountable for communicating project metrics and issues to the Steering Committee, etc.

RACI matrices can be useful in communicating functional accountability, but the real key is the ownership of functions, the shared trust and responsibility amongst the team. This is the environment we need to build.

I hope this helps clarify the recommendation. Thanks for reading and commenting.

Best regards
Mike

[David McLean]

Mike,

What a great article, the best I've seen on the subject.

And isn't it always nice to have 10 points to sum up - its a nice round number ;-)

But the number 9 has much more interesting properties (http://home.c2i.net/greaker/comenius/prepare/9798/nine_2.htm) so I would suggest removing 2) Learn the project’s requirements. 5) Have a vision of the completed project, I would argue is the key element and I think this can be achieved in agile without #2 and indeed must be so. This is because the requirements should not be seen as fixed and so arguably it is wasteful to 'learn' them. Infact its wasteful in the first place to write them out in detail and therefore it shouldn't be possible to 'learn' them. The goal however is more likey to be fixed and hence it would be more productive to focus on that (#5).

Dave