Transformation of the PMO

To be more responsive to their customers and users, an organization may need to transform, transition or even eliminate their current PMO. If so decided, SAFe provides various options.

It has been my experience that the function and role of PMOs in large organizations is unique to that organization’s context. Each PMO has its own unique charter and own unique responsibilities and one PMO may look very much different from another PMO in both tone and activity. However, one theme seems to be true about many PMOs, they were originally created to perform governance associated with fiduciary and legal responsibility.

This article is not going to tackle the question of whether a PMO brings value to an organization. In many cases (especially in highly regulated industries), it does. In other cases, its just an impediment to the flow of business value and innovation.

The question that this article is going to tackle is what a PMO might transform into or transition to once a decision has been made that the PMO is no longer providing the needed value to the customer and the organization.

If business agility is the ability to turn on a dime for a dime, then organizational structure, including the PMO, simply must change to provide this.

Evolving Structure

SAFe is involved in organizational and structural change over time. The rate of change is limited by several factors, most importantly, the appetite for disruption that an organization is willing to tolerate.

Enter the Agile PMO

At the beginning of a transition to SAFe (or agile for that matter), the organization might start by implementing Scrum for select individual teams or organize teams under the Essential SAFe configuration.

In this scenario, the traditional PMO might remain but “start” to change the way that it does business (e.g. Start using basic agile metrics in a haphazard manner for teams or programs doing agile).

At this point in the organization’s maturity, the organization’s PMO that has slightly changed the way that it is operating might start calling itself an “Agile PMO”. One might describe an Agile PMO as a pig wearing lipstick; however, we must remember that SAFe (or OCM or Kanban Method, etc.) does not require overnight change, but rather, incremental, evolutionary change.

In this situation, it is likely that you’d have a bunch of “Agile Project Managers” connected to the “Agile PMO” running around using the word “agile” and still have no idea what agile really means.

It is important to remember that this behavior is a symptom of the “Agile Project Managers” trying to remain relevant during the organization’s (and especially the PMO’s) transition or transformation to agile.

During that current state (e.g. people calling themselves “Agile Project Managers”, etc.), the structure, system, and behaviors of the actors in both will be riddled with what we would consider anti-patterns in agile; however, it is important to support “any” good behaviors coming from this group of people, remembering that the more that you push on a system, the more the system is going to push back.

It may very well be that the role of the Agile PMO is to help launch new Agile Release Trains. The initial SPC (SAFe Program Consultant) might be a member of the Agile PMO or a consultant hired by the Agile PMO. However, the role of the Agile PMO may be to figure out a way to transform, transition or even eliminate itself to allow for the better flow of value to the customer and users.

The Disappearance of the Agile PMO

As the Agile PMO disappears, there are 3 new constructs to choose from:

  • Delegation to the Program & Teams. With SAFe, over time, both the PMO and the Agile PMO can disappear and be replaced by no portfolio level at all (this is preferable in many instances) with authority delegated to the program and team levels.
  • Delegation to the Large Solution. In some cases, the PMO/Agile PMO will disappear and be replaced by a Large Solution structure that includes SAFe’s Economic Framework, a Lean Agile Center of Excellence (LACE), and Communities of Practice (CoPs) plus authority delegated to the program and team levels.
  • Lean Portfolio Management. Or, in highly regulated industries, the PMO or Agile PMO might be replaced by some combination of a Lean Agile Center of Excellence (LACE), Communities of Practice (CoPs), a small Lean Portfolio Management team, SAFe’s Economic Framework, plus authority delegated to the program (and perhaps large solution) and team levels.

In each of these three options, it should be noted that in SAFe:

  • The PMO (based on its original function and role) disappears
  • The number of managers at the portfolio level (especially project managers) is going to decrease substantially (usually, these people are retrained for servant leadership roles such as ScrumMasters, RTEs, etc.)
  • Governance is built into the system (in a fashion like building-in quality) and financial governance is based on objective metrics in a cyclical fashion (on demand, every system demo, and every 10 weeks to decide whether to persevere or pivot)
  • CapEx & OpEx models are replaced by Lean Budgeting whereby value streams (Large Solutions and/or ARTs) are funded, not individual projects
  • Projects are replaced by products and value streams
  • Long-standing feature teams and ARTs are created and maintained without mixed-matrix resourcing
  • Release Management and gated processes are transitioned to a Continuous Delivery Pipeline model which includes a Release on Demand capability with the authority to release delegated to the teams/program.
  • Performance management changes (is typically replaced by iterative impact feedback and coaching) as the “team” and the “Agile Release Train” become accountable instead of simply by individual performance.
  • Go to market activities are delegated to the Product Manager and the Solution Manager (if there is a Large Solution)
  • Reporting significantly changes. Specifically, objective metrics (business value points planned vs. actual for the ART) and innovation accounting metrics (actionable vs. vanity metrics) are used.
  • It all starts with training of change agents and leadership 😊

An Alternative – Deleting the PMO By Edict

As an alternative to transitioning from a PMO to an Agile PMO to one of the options discussed above, an organization’s leadership might decide to immediately delete the PMO from the organizational structure by edict. If this were to happen, the organization would organize around Agile Release Trains (ARTs) and then move forward, using other elements of the framework as needed (e.g. perhaps simply using SAFe’s Economic Framework).

There are pros and cons to this alternative.


  • May result in potentially faster organizational change and the desired benefits and outcomes sooner
  • May set the tone for further and faster organizational change throughout the organization
  • May result in a feeling of freedom and autonomy which drives innovation sooner


  • The organization may not have the appetite for the disruption that this might cause
  • May result in immediate layoffs (some might say that this is better than a lingering death, but I’ll let you be the judge based on your own specific context)
  • May result in chaos unless there is clarity of vision, consistent support (training, coaching and champions), and modeling by executives and managers of servant leadership behavior driving self-organization and self-management
  • May result in fear and confusion which paralyzes individuals in the organization
  • The organization may not (yet) have the necessary automation and/or infrastructure in place for traceability for audits associated with regulations, laws or site certifications in highly regulated industries

The Case for Epics, Epic MVPs, MMFs, and MVPs

OK. The PMO is being transformed, transitioned or eliminated. But “big” work remains. How to handle epic-sized work?

Epics are big. How big? In the PMO days, epics were considered really, really, really, big stories or groupings of stories or groupings of features. And an epic might take an extended period to complete.

In SAFe, an epic can take multiple program increments (a PI is 10 weeks long) to complete. However, we have a concept in SAFe called the “Epic MVP” that allows us to validate the veracity of the benefit associated with the epic earlier. This allows us to persevere or pivot earlier instead of continuing to build something large and without benefit.

“Epic MVP” stands for Epic Minimal Viable Product. An Epic MVP can be thought of as the minimal number of features (MMF = Minimum Marketable Feature) necessary to put something into production or a production-like environment for feedback from both customers and users.

The “MVP” in “Epic MVP” is not the same thing as “MVP” that we get from Eric Ries’ book “The Lean Startup”. Ries’ “MVP” stands for Minimum Viable Product and its definition is the minimum amount of work necessary to learn whether to pivot or persevere. This is called validated learning.

SAFe uses Ries’ “MVP” also; however, whereas an “Epic MVP” might take an entire program increment to complete, the first iteration of an “MVP” might be very low fidelity (e.g. paper prototype), take only a few hours of work to complete, and never make it into production or a production-like environment at all. Therefore, the validated learning that comes from multiple iterations of MVPs might be inputs towards the creation of MMFs and the Epic MVP.

Epic MVPs are used to validate the epic’s benefit hypothesis surrounding the customer. The MMFs (Minimum Marketable Features) that make up the Epic MVP each have their own individual benefit hypothesis that also needs to be validated.

The Epic MVP validation focuses on customer delight and whether the organization can make money from it. The MMF validation focuses on user delight, if users will want to continue using the feature, and if users will tell other potential users how great it is.

Where Do New Ideas Come From?

So, we have these things called Epics, Epic MVPs, MMFs, and MVPs, but where do all of these come from? Where do new ideas come from in the first place?

In the old world, epic-sized work would be determined by the PMO and work assigned to short-lived teams. Project Managers would break the epic-sized work down into tasks through the WBS process and plan out roadmaps (visualized as Gantt Charts).

With the transformation, transition or elimination of the PMO, WBS must be replaced by something more agile.

Continuous Exploration

In SAFe, we have a construct called “Continuous Exploration” which is one of three interconnected cycles in the Continuous Delivery Pipeline. The Continuous Delivery Pipeline is a key construct for every Agile Release Train. It does not require a PMO, an Agile PMO, or the SAFe Portfolio level at all.


Continuous Exploration is the process of constantly exploring the market and user needs and defining a vision and a set of features that address them. The four major elements of this cycle include: (1) Collaboration, (2) Research, (3) Synthesize, and (4) Implementation.



In SAFe, collaboration is not from the top down, nor from the bottom up. It is multi-directional collaboration.

If an organization is using Essential SAFe, everyone collaborates (bi-directionally) with Product Management, as described in the diagram above.

If an organization is using Portfolio SAFe, then an additional role called the Epic Owner is added. This role is rather unique as it can be ANYONE in the organization. Where do big new ideas come from? From ANYONE in the organization and this person is called the Epic Owner.


If Portfolio SAFe is being used, the role of the Epic Owner changes over time. Since Portfolio SAFe uses a portfolio kanban system to obtain a “go/no go” decision on the epic, the Epic Owner’s role during this time is collaborate with the various other roles for the purpose of shepherding the potential epic through the portfolio kanban system to obtain the “go” decision.

As part of this analysis and review towards a “go” or “no go”, the Lean Portfolio Management team would review the 2-page Lean Business Case created by the Epic Owner (in collaboration with other members of the organization) and assign WSJF to the epic.

Once there is a “go”, the Epic Owner becomes a SME for those implementing the epic.


Let’s focus first on how basic every day Scrum handles research. We do experiments, right? And these experiments are in the form of spikes (validated learning through iterative MVPs), right? Many times, before an epic (something big) can be approved (receive a “go”), research is needed. These experiments might be in the form of low fidelity prototypes that are done in an iterative way towards higher fidelity. These activities are done at the team level or within a UX team or in collaboration between the two.

SAFe supports the above activities initiated at the team level but goes beyond this.

SAFe supports Design Thinking techniques for research like customer visits, Gemba walks, active requirements, elicitation techniques, trade studies, and original and applied market research and the Product Management team leads this. I say “Product Management” team because although there is a Product Manager that leads the Product Management team, the Product Owners and other SMEs are also be part of the Product Management team.

In SAFe, we do not put up a wall between agile team members and the customer. In fact, it’s the exact opposite. Therefore, a SME doing research by visiting a customer site could and should include agile team members.


What’s Being Synthesized?

In SAFe, Product Management synthesizes their findings into the key SAFe artifacts of vision, Roadmap, and Program Backlog. The net result is a set of features that are in the backlog and are ready for implementation.

Shared Vision

SAFe, along with other scaling frameworks, is built on the concept of Peter Senge’s “Learning Organization”. To create this, a “Shared Vision” (one of the 5 disciplines) is required. Shared Vision is a collaborative effort that first requires individual “personal visions” which in turn requires individual “personal mastery”. Product Vision, like any other type of vision, works the same way.

Delegated Content Authority

Pulling from David Marquet, what we want is both clarity and competence to move the decision-making to where the information resides. It is for this reason, that collaboration is not only necessary, but required in SAFe. However, there is a balance. Just like Scrum, SAFe designates content authority and process authority by role and event. SAFe, like Scrum, is a cohesive framework that works when these content and process authorities are respected and fails miserably when disregarded.


It also needs to be pointed out that a Roadmap in SAFe is not a Gantt Chart with a list of features. As shown below, a Roadmap has 3 sections, each that represents objectives (not features) in the current and two future Program Increment timeboxes. It also needs to be pointed out that only the objectives (and not the stretch objectives) of the current PI are committed to by the people in the ART and that the objectives in the next two PIs are only forecasted (not committed to).undefined

Program Backlog

The Product Management team (including Product Owners) is responsible for the refinement of the items in the program funnel. Refinement is not done in isolation, but collaboratively with the assistance of SMEs from various parts and levels of the organization including the teams.

Potential features are decomposed from epics and these features, after assigning a benefit hypothesis for the MMF, per Lean UX, are prioritized by WSJF and then used as an input to PI Planning.

It needs to be reiterated that an outcome of PI Planning in SAFe are PI Objectives, first at a team level and then rolling up to the program level. The ART and the teams in the ART are focused on meeting the PI Objectives, not simply finishing items in the program or team backlogs. This informs the roadmap and the Program Backlog and helps reshape the vision.


Lean Startup & Lean UX

Implementation in SAFe follows the Lean Startup Cycle. At its core, the Lean Startup Cycle is validated learning for decision-making on whether to persevere or pivot. It is a form of empirical process control that follows the PDCA cycle (or if you prefer, the scientific cycle of hypothesis-experiment-inspect-adapt). Together with Lean UX, this flows through the experiments of MVPs and MMFs at the team level and MMFs and the Epic MVP at the program level.

DevOps & Agile Engineering Practices

It needs to be mentioned here that the implementation element of Continuous Exploration is accomplished during the other parts of the Continuous Delivery Pipeline, including Continuous Integration, Continuous Deployment and Release on Demand. As such, DevOps and Agile Engineering Practices are key capabilities for the flow of these experiments.

When is a Product just a Project?

Both Scrum and SAFe focus on moving from “projects” to “products”. In this light, SAFe requires the following to occur:

  • First and foremost, the Principles of the Agile Manifesto must not just be talked about in theory but must be used in practice and behavior. Without this, it is unlikely that the desired outcomes and benefits will surface
  • Product Owners and development teams must not be “order takers”, but rather, collaborative partners in the development of the product vision, roadmap, and backlogs
  • Creation of feature teams (at least 80% of the ART should be feature teams vs. component teams)
  • Teams in the ART must be long-standing without mixed-matrix resourcing or playing musical chairs with team members
  • Collaboration of development team members must occur in backlog refinement at the team and program levels
  • While SAFe, like Scrum, supports intentional architecture (e.g. security, performance standards, etc.), development team members must drive emergent design, not any architectural team
  • While SAFe, like Scrum, supports “dual-track” integration of UX design, self-service tools (e.g. style guides, etc.) and UX skills embedded in the development team is preferred
  • SAFe supports the concept of Solution Intent, whereby development teams run groups of experiments (set-based design) rather than following a single point-design
  • Objective metrics and innovation accounting (vs. vanity metrics) must be used during the Iteration Review (every 2 weeks), System Demo (every 2 weeks), PI System Demo (every 10 weeks), and release (on demand) and benefit hypotheses regarding the customer and users must be validated at these events with the purpose of decision-making on whether to persevere or pivot
  • Development teams should not use tasks, as this is a symptom of not only a lack of cross-functionality, diminished team learning, and a lack of mindset to swarm, but also drives a mindset to drive individual effort and accountability instead of team accountability
  • Features are prioritized based on WSJF (Cost of Delay / Size). PI Objectives are prioritized based on Business Value points assigned by the Business Owner during PI Planning. User stories are subsequently prioritized based on the feature’s WSJF and the PI Objective’s BV points.


To be more responsive to their customers and users, an organization may need to transform, transition or even eliminate their current PMO. If so decided, SAFe provides various options.

For more information, please contact me at


Jonathan Emig

January 16th