Copyright to Peter McBride, © 2011.
This interview by Max Wideman followed a presentation on Agile Project Management Basics to the Canadian West Coast Chapter, Vancouver, BC, on August 16, 2011
Illustrations reprinted with permission.
Published December 2011

Editor's Note | Roles and Responsibilities 
Conventional versus Agile Approaches | Agile Principles

Roles and Responsibilities

1. MW:Your slide #4: "Roles and Responsibilities" (See Figure 1) suggests that on a full-blown project there could be up to nine key people in the core team. In terms of man-hours and in your experience, roughly how large would a project have to be, to support that number of people each in their own roles? It seems to me that the whole point of "Agile PM" is to reduce bureaucracy.

Figure 1: Roles and Responsibilities
Figure 1: Roles and Responsibilities

Peter McBride: I don't want to set myself up as an expert. I can only speak from my research and experience but let's see what I can contribute.

Yes, the structure calls for 9 roles, if not 9 people. Agile does not differentiate between small and "full blown" implementation, so there are always 9 roles that must be filled. Agile's point is not so much to reduce bureaucracy, not at all as far as I can see. It's objective is to be a fast moving flexible structure for managing projects that are subject to lots of change. These roles ensure the business buy-in remains high, technical issues are "owned' and managed, and an adequate team is in place to do the job properly.

Are there projects too small for this? Yes, of course. I have done several one-man projects in my time. But I filled all those roles, even as one person. The roles MUST be filled if the project is to reach its correct target in its most efficient manner. Agile, PMI, IPMA, all agree on this point.

2. MW: I would be a little anxious about the position of the project manager in the illustration. I could see the four surrounding the PM simply bypassing him/her, and thereby reducing the role to a mere "post office", collecting and distributing data. This is no speculation - I have seen it on real projects, never mind Agile!

PMcB: No philosophy can prevent politics and bypassing. If a team is so inclined, they will do that, and damage their outcomes as a result. It is the nature of humans to try and get what they want. Therefore, teaming is critical - as it is in any project. Regarding the diminished role of the PM - well, I believe the PM is an administrator in any case, or should be. Not specifically a Postmaster, but not a worker bee. There is no reason the PM needs to be the top banana in any project either. The Charter and goals of the project should be the top of the ladder, don't you think?

3. MW: I can also see that the three: Business Visionary, Project Manager, Technical Coordinator, could be in real conflict - especially if there are personality conflicts.

PMcB: Of course there can be conflict! And if I were the PM on such a team, I would be arguing that no project should be attempted until all those conflicts are resolved. How can you run a project with the leadership team in conflict? Why would you try? Nope, I'd back out of that one if I had it. Until we PM's start saying NO in the face of certain disaster, we remain partially responsible for the failed projects we are involved in.

Editor's Note  Editor's Note

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page