The Role of Project Manager in an Agile Environment

by Shama Bole, Sr. Agile Consultant

The traditional role of a Project Manager (PM) is becoming obsolete – or at least evolving – in the world of Agile software development, and Project Managers must adapt in order to be effective. Often it is simply a matter of ‘doing whatever needs to be done’ to get or keep the project moving.

A client manager made an interesting comment to me – that she loved working with me because I didn’t draw a line in the sand about what constituted my job and what did not. When our client first determined that they wanted projects run Agile, I embraced the methodology and in the process discovered a renewed love for my PM role. I truly enjoy the principles that underlie working Agile. It’s not just another recipe to be followed because it is the flavour of the month, but rather it aligns with my working style and personal philosophy – my personality, if you will. But most PMs have been steeped in the more traditional waterfall methodology that is in contradistinction to Agile, with the latter’s emphasis on iterative development, incremental delivery, self-managing teams and attendant artifacts.

As a Project Manager, my tasks include the traditional:

  • Project Financials & Financial/Portfolio Reporting
  • Status Reporting
  • Project Governance
  • Identification of missing roles/resources and resolution/escalation of same
  • Business stakeholder communication
  • Issue/Risk communication/resolution/escalation – removing blockers
  • Project Planning
  • Change Management

As a Scrum Master (SM), I’m also responsible for:

  • Ensuring the team adheres to its processes (and all that entails in terms
    of artifacts and meetings)
  • Resolution/escalation of inadequate or ill-defined user stories – ensuring
    Product Owner accountability
  • Removing barriers and shielding the team from external interference

Conventional wisdom suggests that the Project Manager and Scrum Master roles are in conflict, owing to the PM role being one of “command and control” and the SM persona being very much that of a “servant leader”. I have always seen myself as that servant leader since, not being a technical expert or a SME, my job is to keep the project on track and remove blockers to progress. Either as a PM or a SM, I serve the team. The area where one might identify a potential conflict is where, as Project Manager, I protect the interests of the product owners (primary stakeholders) and project goals, whereas in the Scrum Master role I protect the core/delivery team from all outside interference. But to put a combative slant on these roles is to assume a zero-sum game (with the Product Owner and delivery team at odds) rather than a collaborative venture that provides optimal results for all.

I don’t think command and control is a sustainable mode of operation. As has been proven with Agile, the best possible outcomes result from the team organizing and managing itself. This may be perceived as threatening to some in the project management community because it suggests a diminishment of the PM role. I am currently combined PM/SM on three projects and purely PM on a fourth, with my role on that fourth project being to manage tasks and obstacles that fall outside of the sprint (e.g. data acquisition from source/transactional systems), and I do not feel it is a diminished role; having a Scrum Master take on daily project activities frees me up for other projects and to take on more. That said, the combined PM/SM role is often attractive to managers and clients because it obviates the need to hire a separate Scrum Master.

One area that frequently struggles with the transition to Agile is that of project financials. Funding for an Agile project would be in iterative chunks, feeding directly into value of throughput for the Business by the delivery team. I have heard this referred to as a “factory” model, suggesting an assembly line approach to development – this isn’t wholly inappropriate given that so much of Lean and Agile grew out of manufacturing. Budgets for projects are arrived at with an estimation approach that is still rooted in the world of waterfall-run projects (I have had interesting conversations with personnel in Finance when providing administrative details such as what is the “In Service” date for an Agile project). However, one of my projects that is run Agile is currently in the fifth phase of development – this suggests that delivery of previous requirements has bred trust between the product owner and project team to the extent that they have renewed our funding based on the product owner’s confidence that we will meet his changing requirements and provide what he needs to stay competitive and efficient. It’s not a blank cheque, but it comes close to a factory model.

In line with the challenge just mentioned, Product Owners are constantly desirous of knowing how much scope may be accomplished given what is left in the project budget. I actually find that I have a better grasp on the realities of what we can and cannot deliver within budget using an incremental delivery approach. In my PM/SM hybrid persona, I use Release Planning as well as team velocity and burn rate to provide the product owner with such an estimate. My caveat to the product owner is always that release planning activities take the core team away from delivering user stories, so that is a trade-off that the Business needs to make. This usually discourages the product owner from constant demands along these lines!

For Project Managers who have relied on a highly structured model that imposes timelines as drawn up by a long term project plan with dire repercussions to follow if said plan is violated, working Agile or sharing the Scrum Master role may seem quite incompatible; traumatic, even, based on what I’ve witnessed at times. The good news is that adapting to Agile gives new life to a discipline at the crossroads of alternative pathways for software development, allowing PMs to re-invent ourselves and stay continuously relevant to the art of Project Management.