Greg Geracie, Actuation Consulting, Take Charge Product Management, Steve Starke

9 Steps PMOs Should Take to Enable a Successful Agile Transformation

In 2013, Agile, Business Analysis, Lean, Product Management, Product Management Facts, Product Marketing, Product Owner, Product Teams, Project Management, Scrum by [email protected]3 Comments

The Chronicles of an Enterprise Agile Transformation (Part Six)

Over the past several weeks, our transformation has taken a backseat to portfolio planning for next year. During this time, many teams have commented on just how big a change Agile is.

The PMO’s role is becoming increasingly critical to the rollout  even though this function was not initially called upon for assistance. Today’s blog post will highlight the top nine steps the PMO should take to enable a successful Agile transformation.

I’m also writing a sister post for our friends at Planbox where I explore if rolling out Agile to an enterprise can be done using Agile principles. I thought it would be fun to challenge the conventional thinking behind an Agile rollout. To read my post at Planbox click here.

Now, onto our nine steps…

  1. Setup a core team PMO to monitor the entire deployment. The PMO needs to be in a supportive role and help out those new to Agile. The PMO can also be used to mentor business leaders so that they fully understand what’s expected of them and what they can expect out of their teams.
  2. Define how the PMO should govern the Agile deployment. This includes deciding on the tools to be used, how these tools will be integrated, and what metrics and measurement will occur. This step is critical because it’s very easy for Agile teams to customize their processes – according to their needs – which may or may not be in the best interest of the organization.
  3. Define/create templates for documentation and defining standards. Yes, documentation! One of the items abused in Agile projects is documentation. For example, how will user stories be recorded? And what kind of documentation will be created to turn over the project to support teams?
  4.  Identify a couple of (preferably low risk) pilot projects and execute them with some of the” key” influencers while providing a coach to ensure the entire teams’ success.
  5. Slowly deploy Agile to the entire organization. Gauge the organization’s ability to successfully deploy and sustain the Agile approach.
  6. The PMO needs to learn, fine-tune, and find the right balance. In the majority of organizations this means finding a hybrid approach that’s suitable to your organization as each organization’s needs, size, complexity, and environment are different.
  7. Attend project/program retrospectives to get feedback. A lot of communication happens within the scrum team but this communication rarely makes it outside to the broader organization. Therefore, the PMO’s participation is very important in order to  understand pain points and best practices.
  8. Take lessons learned (from retrospectives) and distill what worked and what didn’t work. I don’t advocate text book implementation of Agile or any process for that matter! See what works for your organization and fine-tune your implementation accordingly.
  9. Share success stories and make these pilot projects the basis for future training sessions and mentor selection. This will help generate positive momentum within the organization.

Keep an “eyes-wide open” approach throughout the entire process and communicate, communicate, communicate!


  1. How do you help PMO members themselves, and sponsors, let go of direct control in favor of indirect control (through the feedback loops of agile).

    Regarding #6, do you see organizations unknowingly cutting through the load-bearing walls of agile? How do you detect this? How do you remedy it?

    1. Author

      Hi Robert – I am posting Steven’s response.

      How do you help PMO members themselves, and sponsors, let go of direct control in favor of indirect control (through the feedback loops of agile).

      Regarding PMO members, it’s all about focus. Project Managers are typically inward focused and used to controlling the detailed engineering project schedules. Agile removes this control and typically leaves a project manager feeling like “what am I supposed to do now”. Focus your PMO resources on how they’re managing the entire delivery effort and not just the software development portion of it. PMO resources need to be more focused on delivering the value…and not just software code.
      Regarding sponsors – I’ll need to explore this a bit more. I’m not sure what you mean by sponsors having direct control. A product owner should have a reporting relationship to a sponsor…and thus sponsors of product development, whether it’s done through Agile or not…still have control.

      Regarding #6, do you see organizations unknowingly cutting through the load-bearing walls of agile? How do you detect this? How do you remedy it?

      I’m not sure I’m in complete agreement with what you’re calling load-bearing walls. But to your point, you have to identify what metrics you need to measure to quantify success. If quality practices need to improve, then you should baseline your technical debt and ensure you track progress against the improvement. If speed to market is another, you should again, baseline current revenue and ROI based on each release. Then deploy Agile and measure if those values change by the increase in speed and ability to deploy to production faster. Improving customer satisfaction could be another metric to measure. I think it all depends on the organization and why they’re using Agile in the first place, and what they call success.

  2. Thanks for replying; I’ll see if I can answer your questions.

    By “sponsor direct control,” I mean the defined scope/schedule/budget, funded yes/no arrangement between a business exec sponsor and IT. I’ve also heard it called Duopoly or management by project/deal. Under Agile, the defined scope goes away, and Sponsor control is more spread out.

    “Direct” wasn’t the right word; I can see why that didn’t make sense. It’s more of a change in control over time. The old way, simplified, is beginning-and-end. Do the deal, then wring their necks if they don’t deliver, with maybe a new deal in the form of a big change order part way through. The new way is more continuous. Provide overall direction to the PO and adjust as feedback–velocity and user reactions–become available.

    I mentioned sponsor control because one of the more insightful things I ever heard about Agile was that the biggest barrier to adoption was “convincing senior management to give up the illusion of control at the beginning,” this from Bob Martin in 2003.

    Which of my proposed load-bearing walls do you think it’s safe to remove? Or, is there a wall I missed? I introduced the load-bearing wall concept because I saw organizations doing what you describe–adopting Agile in pursuit of a particular goal. But as early-majority firms are prone to do, they left out those practices that didn’t seem to be related to the goal, or that were politically incorrect. Without its load-bearing walls, Agile fell down. Not only was the original goal not meat, but the organization now had “Agile antibodies,” i.e. “We tried that and it didn’t work.”

Leave a Comment