A few years ago, I used to run the West Coast PMO for Canada’s largest digital agency, and I had the opportunity to introduce Agile development for the global delivery team while increasing the project management team size from 7 to 27 PMs in two years.

In a digital agency, the strategy and creative teams complement the technology team. Given this heterogeneous team composition and the diversity in the type of engagements, we recognized several types of Project Managers (PMs):

  • Producers – PMs who have a creative orientation, so they resonate well with the Creative team, being able to bring domain expertise (say retail, or gaming) to help create better marketing campaigns on multiple channels. The Producer role in an agency is similar to the role of Producer in a gaming company, such as Electronic Arts. A campaign is typically smaller in size (typically 200-1000 man hours), so Producers often need to juggle multiple projects at the same time.

  • Technical PM – has a technical background and runs complex technical projects, typically over 5,000 man hours, such a eCommerce, system integration, or the deployment of an enterprise CMS over many locales.

  • Pitch PM – professional companies in general and digital agencies in particular put together laborious pitches to win new business, often to respond to an Request for Proposal (RFP). The pitch PM has to manage a (generally geographically dispersed) multi disciplinary team to put together a proposal under tight timelines – which often results in intense, long hours, with a senior team, for an outcome that has both high importance and high visibility. So pitches are short, high-intensity, pre-sales projects, characterized by high risk, uncertainty with regards to scope, fast thinking and decision making. The Pitch PM has to able to manage the senior / executive team (often feels like herding cats), to handle the pressure and the long hours through bursts of high-energy. So pitches are like running a 100m sprint, while a technical (‘big build’) project is like running a marathon.

Nowadays, running delivery and the PMO is part of my role at Aequilibrium, a technology consulting and Agile delivery company. With the transition to Agile, the role of PM is elevated from command-and-control to servant leadership, enabler and roadblock remover. A good Project Manager is like an orchestra director – while he does not play a single note, he ensure the team is playing in unison and the right tempo and energy happens at the right time.


When an organization transitions to Agile, where there is no explicit PM role, what happens to the PMO team?


Evolve the role of the PM to span across several of the roles of an Agile team,  in order to support the new development process which promotes collaboration and enables self-managing teams.

Efficiency through Delivery Excellence

Evolve the PM role to a Scrum Master role focused on following the process and maintaining the heartbeat, removing impediments, reducing friction points, alleviating bottlenecks, keeping the morale high, reducing disruptions and maximizing the throughput of the team

Effectiveness through Leadership and Domain Expertise

Allow the PM to become a proxy to the Client Product Owner, ensuring there is alignment and clarity with respect to the deliverables for each sprint and working with the team to define the best possible solution to the business goals identified by the Product Owner, and thus maximizing the business value delivered and improving product market fit (focus groups, frequent customer feedback)


Enable the PM to optimize throughput with transparency and Data-Driven decision making: weekly reports or a customer dashboard showing metrics which indicate the team’s velocity for each of the past iterations, the estimated size (in story points) of the backlog for the current release, the Candidate Release Plan (how the scope is mapped to the various remaining iterations), burndown chart which indicates.


Evolving the PM role will lead to better outcomes (the solution delivered maximize business value), increased throughput, faster and better decisions that are data-driven. While sometime companies are looking to save money by building teams comprising only developers and testers, my experience has always been that a good PM more than just pays for himself, leading to less risk and better outcomes delivered at a lower cost (by removing blockers and buffering the team from distractions) and over a tighter timeline (the PM proactively plans ahead to make sure everything is in place ahead of the time for the team to work effectively).

Potential Bias

PM as Scrum Master

Especially when coming from a command-and-control environment, the PM may be tempted to direct the delivery team on how much work must be completed in a sprint in order to meet external deadlines. The PM should be reminded that they can increase the velocity of the team by removing obstacles, having clear expectations with the product owner in order to reduce rework, and by minimizing the disruption of the team. However the amount of work that is delivered in each sprint must be set by the entire team.

Another thing to be cautious about is for the PM to direct which tasks to be completed by whom and when, rather than allowing the team to self-manage.  The team should be autonomous, but also accountable to each other (rather than to the PM), and this accountability should be reinforced during the daily scrums and the Iteration Retrospective.

PM as Product Owner

Often times, the role of the PM is to complete a project fixed scope, fixed price and fixed timeline. While this type of engagement is not well suited for Agile development, it still happens quite often. When the PM is also the Product Owner, he may be tempted to give into pressure from other stakeholders (Product Manager, execs, client) and push more features to the team than can be achieved in the given timeframe. To avoid this bias, ensure the PM focuses on identifying the features which produce the highest business value, while enabling the team to determine a fast-paced yet sustainable velocity.

PM Tasks and Deliverables

During Agile Planning

The PM should focus on “just-enough” planning, rather than on big-upfront-planning. During Agile Planning, a multidisciplinary team is typically engaged from the start, which includes both Planners (Client Partner, PM, BA/Product Owner, Tech Lead) and Builders (Dev, QA, DevOps, designers and/or interaction architects).

Example of Tasks and Activities

  • identify key stakeholders and define roles and responsibilities, including their required availability throughout the project

  • determine the process (for example, Agile Scrum using 3-weeks iterations) and tools (for example, Confluence for collaboration and Epics and JIRA Agile for User Stories)

  • identify the project risks, including integration points and dependencies on 3rd parties

  • make sure the project scope is clearly defined, and appropriate resource, time and budget contingency (for example, and extra Sprint) are allocated in order to reflect the project risk and the client’s tolerance to risk (for example, reflecting the clarity of the scope and the complexity of the functionality required)

  • establish milestones, delivery dates and acceptance criteria

Typical Deliverables:

  • Rules of engagement: includes roles and responsibility, availability expected from key stakeholder, process and tools

  • Communication plan: includes weekly status reports with dashboard of activities and risks

  • Statement of Work: encompases the legal contract which captures the project scope, deliverables, assumptions, milestones and budget

During Build and Delivery

Example of Tasks and Activities

  • ensure alignment and visibility

  • drive communication and online collaboration

  • remove blockers and impediments

  • manage risks

  • capture meeting notes and manage action items

  • manage the project risks, including integration points and dependencies on 3rd parties

  • update burndown chart and the other Agile metrics from the project dashboard and communicate the impact on timeline and budget based on the variation in project scope and the team’s velocity

Typical Deliverables:

  • Decision registry: keep track of the key decisions and the reasoning behind them

  • Risk registry: keep track of the key risks and their corresponding risk approach (avoid, control, accept, or transfer)

  • Weekly status reports: typically include an executive summary and a dashboard of Agile metrics

Is your company using Agile delivery? If so, how did the PM team handle the transition and how did the role of the PM evolve?

Posted by:Aequilibrium

With a track record for building and leading high performance Agile teams and delivering great software products and engaging user experiences, Adrian’s focus has always been on delivery excellence. Adrian is the Founder and CEO of Aequilibrium—a Vancouver-based digital product development and design agency dedicated to creating winning web, mobile and IoT solutions. Adrian also makes a mean espresso and can teach you a killer chess move or two... in English, French, Romanian or Italian.