An agile PMO is really a contradiction; the PMO is a conservative enterprise project-centered administrative function. Not the first association that comes to mind when someone says agile.  At the same time, in a large company the PMO can provide a lot of valuable support.

So, in my new role as PMO Lead I thought I could do things differently. But after six months I found myself stuck in vicious circles of reporting and planning further and further away from the real work. (Meanwhile the real work didn’t exactly go in the right direction either…)

This story is about how I transformed my PMO role and what a more agile PMO could be like.

To start with I was lucky to have excellent guidance in this process and to be part of the best team. Then I also found a good value-focused mindset: even if you’re not where you want to be, not doing exactly what you want to do, you can always act on your values. And that is good.

Mike Burrows takes a wonderful approach with values in his book “Kanban from the Inside” and in the following posts I will go through them from my perspective, applied to the transformation of the PMO.

Agreement: Agree to pursue incremental, evolutionary change

Change management in the PMO glossary will be defined as the process of tracking changes to the committed plan, scope or cost. Very seldom is this about managing change to improve how we do things. A process flaw will be articulated as an issue that would then be assigned to someone to deal with.

When things are slowly only getting worse, maybe a tough turning point can be a good thing? For me it was. The turning point was “the Quality Review”, something we would refer to for a long time in our program. We got a well-needed sense of urgency. This was good (given that we, unfortunately, were where we were).

I think we knew quite well what our main problems were, but we had been neglecting them for too long (the elephants in the system).

So we defined a clear, challenging and motivating vision to serve as strong guidance for the coming critical period. One part of the vision was Continuous Delivery and this I will come back to.

The need for change and the vision was then clearly communicated, discussed and agreed. We now had a starting point and a clear direction.

Leadership: from administrators to change agents

With a clear vision and an urgency to change we found a new valuable purpose for the PMO: drive change.

The first thing was to rename the PMO to “the Improvement Team” (yes, it’s just a name but that new name made a difference). And even if many traditional PMO tasks still needed to be handled, they were not the main focus anymore.

Then we, the PMO team, started working like any other development team: Kanban board, stand-ups, reviews, pairing and testing. We took a clear ownership of the overall end-to-end process, and where needed we supported with improvement, alignment, and reviews across the program.

Transparency: from heavy reporting to dashboards

How to get rid of all that reporting? Well, the answer is you need to provide something other than a static, time-consuming report, something better.

To visualise current status and the latest progress we invited all stakeholders to joint demos. Our stakeholders as well as our teams were spread geographically so it was a struggle to get these demo sessions good. But it was well worth it.

Soon the highly-important-emails asking for reports were gone and all detailed plans were more or less replaced by high-level forecasts (we did keep program-level risk and dependency management).

Each team had their own dashboards already but we didn’t have any for the program. So we introduced common dashboards, put them strategically where a lot of people walked by and took every chance to explain how to interpret the data. This was very positive in how it encouraged people to connect and learn.

It’s simple: people ask for reports when they are uncertain. Be open, transparent and engaging and you won’t have to write them.

Collaboration: from an annoying silo to a supporting team

The PMO is often kind of disconnected from the other teams, from the work. At the same time the PMO needs to know everything (for the reports…). This can be annoying.

Back to the vision and Continuous Delivery. The program consisted of 12 development teams and a platform that didn’t like to be split when deployed. This meant we were stuck with joint releases but still wanted to do them smoothly and often. Lack of branching strategies had also placed us in a very dark merge hell. Therefore all teams needed to align on our process in detail and stick to agreed improvements with discipline. Close and engaging collaboration was key.

For this we used a variant of Community of Practice, a virtual team with a shared interest/motivation but that also had a strong mandate. To communicate practices from the CoP’s we tried different formats: we needed a clear but also motivating tone. We found short videos, sometimes as interviews, helpful.

We also needed to make sloppiness hurt a little.

“Make policies explicit!” ….and then use merciless dashboards to signal any violation to those policies. BAM!

To be continued….