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.
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:
In each of these three options, it should be noted that in SAFe:
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.
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.
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.
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).
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:
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 email@example.com