A Few Thoughts on Establishing the Agile PMO

A while ago, I posted an article entitled Lessons Learned in Establishing a Project Management Office (PMO.) That article was largely freighted towards discussion of plan-driven projects, typically manifested by the waterfall methodology.

I subsequently spoke on this topic at a Project Management Institute (PMI) chapter and was asked to incorporate some thoughts on how the PMO might support adaptive or Agile methodologies. Having now worked on a couple of them, I’d like to share a few ideas and ask for yours:

Firstly, Agile is different philosophically in many ways than waterfall. One of the main tenets from the Agile Manifesto is “Working Software Over Comprehensive Documentation.” This does not mean NO doc, it just means that working software is valued more.

PMI’s Project Management Body of Knowledge (PMBOK) is absolutely loaded with ideas for possible documentation. And even though you may not use that tome as a guide, the plan-driven project typically relies heavily on documentation. And so therefore the waterfall-based PMO reflects this by having any number of templates, forms and archived notes.

But in Agile, let’s say specifically in the Scrum variant, you need things like product backlogs, sprint backlogs and release plans. Often teams will create these in spreadsheets. In my experience we created these templates and put them in the repository, but teams were free to use them or not as they decided.

If teams in Agile are, by definition, self-organizing, what else besides templates might a PMO provide? Well, the best practices organizations will be able to provide Agile coaches to kick-start a project. As one Agile coach advised me, this helps create a mindset right from the start. And of course the PMO can then provide ongoing mentoring and training.

This same coach advised that not all projects should be Agile. If a product that the team is creating is well-understood or the culture of that division does not support the Agile philosophy, the PMO can advise as to whether or not a project should be Agile.

One area in which the Agile PMO can assist in is gathering of metrics. Since Agile is all about delivering value, how well teams deliver that value might be of interest. You can track and measure such thing as a team’s velocity or burn-down rate. I’d be curious to hear from anyone reading this article and who may have an Agile PMO, how you’ve handled this area and whether recording this information was of value across the organization.

Since the Agile PMO can see into all the Agile endeavors, it has the unique ability to coordinate resources and best practices among teams. In a sense, it is an overseer of quality and resource management. Some organizations employ the concept of Scrum of Scrums, wherein Scrum Masters who are “ambassadors” from other teams, regularly convene. The PMO could facilitate this get-together to share ideas, especially if teams are siloed.

Key point – if you’re introducing Agile into a more traditional organization, try to do it in such a way that management is comfortable with the tools you’re using. In one company that I consulted to, we made sure to use recognizable formats and templates wherever possible. People ask for change but nobody really likes it very much.

These are just a few of the ideas that we (it’s a team endeavor to set up a PMO), considered. In the instances where I’ve done this work, I’ve kept a copy of the Agile Manifesto handy. The key here is to make sure that the Agile PMO is ….

Agile!