Agile Development Blog

In an earlier post, I asked an Agile test question, “Are PMOs Obsolete in Agile?”

While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.

8 Ways To Re-Tool a PMO in an Agile Environment

1. Have the PMO involved in helping rollout Agile on several pilot projects

   This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.

   Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.

2. Learn from Lean: start a Kaizen and Gemba mentality now

   The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.

   Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.

   In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.

   Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.

3. Change your definition of “Standard of Work”

   This is not a set of standards defined by and enforced by the PMO for project conformance.

   In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.

   (In my previous post on the PMO, Brendan Flynn has a wonderful comment about how he and his PMO engage teams at Shoplocal in doing this work.)

4. Facilitate and be a Servant Leader

   Don’t control.

   The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.

   A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.

   Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.

   They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.

   So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.

5. Provide guidance on regulatory adherence

   In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.

   The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.

6. Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption

   Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.

   I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.

   Our Rally whitepaper about Applying Lean Pull principle for Program level Agile is a great guide for the Agile PMO working with programs of teams.

7. Guide non-IT/Engineering organizations

   Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.

   Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.

   The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.

8. Foster useful metrics

   Let go of that Waterfall security blanket around what are useful project or program metrics.

   Determine which metrics to track that directly help organizations concentrate on value delivery.

   Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.

   An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.

   Look in the Appendix of our whitepaper A CIO’s Playbook for Adopting Scrum for more ideas on useful metrics in Agile adoption.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

note: PMO stands for Project Management Office.

To PMO or not to PMO? That is the question. Or, put another way, in our Agile test this week, please answer the following question:

Are PMOs Obsolete in Agile?

(a) YES!

(b) NO!

(c) Uh, maybe?

(d) All of the above :- )

What’s your answer?
Before you tell me, here is some food for thought:

Archeological Dig for Extinct Life Form

(a) YES!

Yes, if your PMO maintains a  rigid conformance posture informed by Waterfall approaches to managing and tracking project risk and success, it is obsolete. Lose it. Here’s why:

• Agile has no place for rigidity.

• Agile rewards flexibility, responsible change, and continuous growth. This is true in processes, in practices, and in people.

• Agile doesn’t seek conformance. Agile seeks emergence of the most useful, sustainable practices that deliver value, team by team, item by item, timebox by timebox.

• A PMO that determines standards and then enforces these standards through status updates runs counter to the core of Agile.

• Agile seeks more than status updates. There is no punishment or reward system other than finding impediments and removing them.

A conformance-based PMO, in contrast, will tend to hold onto old habits: create standards; enforce their standards; collect detailed status information about how projects are conforming to their standards; create pressure to bring non-conforming projects into line. Such a PMO can inadvertently (or purposefully?) create a culture of blame and hence engender skewed reporting by projects in order to avoid associated “punishments” or public flogging. This PMO with its incumbent culture will absolutely kill an Agile initiative before it has started.

So, if you find yourself in this environment, lose the PMO or you will never win with Agile.

(b) NO!

If your PMO is prepared to be a liaison and evangelist of the Agile rollout across the organization, don’t lose them! They can be a pivotal force that ensures the true essence of Agile; they seek to find out what delivers value in a regular rhythm and to keep improving on it.

The PMO has an incredible vantage point in an organization: they can look around and “see the whole”. Heads-down Agile project teams concentrate on what works in their singular context. An Agile  PMO, on the other hand, with a broader view, has the golden opportunity to continuously survey project teams to learn from them what is working well and then spread that good news to other teams and to the management.

An Agile PMO applying Lean Principles such as eliminating waste and amplifying learning can serve as the servants to the Product Owners and ScrumMasters. They can support the Agile project teams by facilitating cross-fertilization of best practices. They become the guardians and carriers of the Agile emergence. You might say they are act as the Agile pollinators.

Note: see my post “8 Ways To Re-Tool a PMO in an Agile Environment” for further information about how to create an Agile PMO.

(c) Uh, Maybe?

Ultimately, it comes down to this: What transitional fortitude does your organization have to move to a new way of doing things: the learning, the facilitation, and the Servant Leadership required of an Agile PMO?

That is the big MAYBE that will be sitting like an elephant in the room with you as you consider an Agile rollout with your PMO.

My Rally colleague Mark Kilby has a great way of testing this: Is your PMO prepared to sign an Agile PMO Manifesto?

We, as an Agile PMO, value:

• Kaizen (retrospections for continuous improvement) over Conformance and Consistency
• Org-team mutual Service Level Agreements over Top-down Policies and Processes
• Communities of Practice over Central Authority

(d) All of the above :- )

So, where are you, where do you want to be, and how do you hope to get there? You may, at any time, be any one of the above, or all at the same time. Fear not! There is a way.

Just remember, answer (a) YES! reminds us that a traditional PMO has no place in a  truly Agile organization and is hence obsolete.

To get to answer (b) NO! your PMO must be prepared  for jolting change in its principles and practices. It may seem daunting. But Agile and Lean have great guidance to protect you along your path.

And, at any time during your Agile Adoption, you may find yourself in the ambiguity of (c) Uh, Maybe? or (d) All of the above :- )

If you are prepared to embrace the 10-step Agile PMO guidance and Mark Kilby’s Agile PMO Manifesto, you will be on the righteous Agile PMO path.

So, now tell me your answer to the question: Are PMOs Obsolete in Agile?