Suddenly it’s 2015! If you’ve been in hibernation for the past few years, you will notice that suddenly everybody is doing Agile in corporate IT (Yes, I deliberately said doing and IT). Where we used to battle to get the mandate to pilot an Agile project, it has become the standard by now.
Now, the real work can begin! It is only today that we begin to see the consequences of agility. Business units are misaligned, portfolio planning doesn’t fit the agile pace and the Project Management Office doesn’t know how to support the agile teams.
In the next few blog posts I will focus on the role of the PMO in an Agile organization. When it doesn’t change its way of working, a PMO can crush the benefits of the agile way of working.
What has always been the role of the PMO?
In most organizations the PMO is a controlling body. It instructs project teams with guidelines, templates and processes. This is why often the PMO resides closely to the senior manager (CIO, Program manager, VP, …)
For example: They instruct the project managers on how and when to report in a project board. Which data they should present and in which format.
A classic PMO which suddenly has to deal with an agile project will behave the same way. They will explain the product owner or scrum master (depending on which on the think is now the project manager) that they should prepare for a monthly project board. In order to do that, they should enter their project plan in the corporate tool, so that a baseline is present and the project can be managed in detail. When the PO or SM explain that they have no project plan, but a prioritized product backlog, the PMO gently but firm asks them to convert it into a Gantt chart anyway. In the next project board, the product owner will show the Gantt chart and slowly but surely change his behavior.
Instead of keeping his focus on managing value through a well prioritized backlog, he starts managing a planning and forget that it’s not the plan that needs his attention, it’s the scope.
In an agile team, the scope drives the planning. A new piece of scope will delay the release, removing a piece of scope will accelerate the release.
What the PMO should have done are 3 things:
- Ask the PO for the main project driver.
What is most crucial for this project? Do we have a minimum scope we want to deliver? Are we trying to release before a certain date? Do we have a limited budget? This is important for the way the PO will manage his release planning. - Ask the PO for the product backlog.
Since the product backlog is the major driver of the project, it should be healthy, estimated and prioritized. The PMO can assess this, but also help to get it into a good state. - Provide the PO with agile release planning tools.
At the bare minimum, a PO should be able to plot a release burn-up chart from his product backlog. This gives him (and the project board) a good overview of the evolution of the project, sprint after sprint and stimulates the agile way of thinking to deliver product increments until enough business value is realized. If no project management tool is available that supports this, the easiest way is still to do it in excel.
By asking these 3 things, the PMO supports the agile team with the necessary tools to effectively manage their project in an agile way. A healthy, estimated product backlog is the basis for steering an agile project. With the use of a product burn-up chart, we avoid falling into the trap of micro planning and have a good tool to track progress and report to management.
In the next blog posts, we will explore how an Agile PMO can track the budget, organize a project board and standardize accross teams.
photo credit: _MG_9781 (license)
SkyCoach 
Reblogged this on SutoCom Solutions.
Hi Nick,
Interesting topic. I definitely see the same mismatch of a traditional PMO with an agile approach. I’ve found the DSDM small pocketbook on the top quite interesting (read it a few times). http://www.dsdm.org/webshop/books
Looking forward to see more info on the subject!
Kind regards,
Frederik
In essence, an agile PMO is a PMO supporting agile projects. Perhaps in a smaller organisation (with only a few projects or a few teams), there’s no need for a PMO, but in a larger organisation there is. In a large organisation, the CxO or main project sponsor will not come and visit your team everyday (well, they’re encouraged to!). Furthermore, at the management committee level, they need correct KPIs to effectively evaluate and prioritise projects.
The point is that a PMO needs to be organised to support agility. The PMO can also aim to standardise some agile practices. In a organisation in transition to agile, the PMO will be challenged by agile approaches – some projects will be agile, some not. The goal is to come to a situation where the PMO is promoting and spreading agile approaches, and to grow understanding regarding agile at the management level.
The PMO needs to put an effective governance and project portfolio in place without hindering the collaborative and self-managing aspect of teams.
The agile PMO differs from the traditional PMO on some points, for example:
– decisions regarding project funding (rolling wave budgeting: budget ranges or limited budget allocation vs. traditional fixed annual budgets)
– project KPIs (velocity, lead time, customer involvement / satisfaction vs. traditional KPIs such as FTE resource utilisation, milestone time tracking, scope changes, … )
– ROI decisions (evaluate the added value continuously vs. traditional one time business case evaluation at the beginning of a project)
– resource management (ensure stable teams, level experience between the teams, stimulate cross-team learning, in case teams break up: ensure quick re-allocation of team members vs. traditional FTE resource utilisation assigned to project tasks)
Other areas the agile PMO can offer support:
– stakeholders (ensure stakeholders are frequently available for direct contact with the teams)
– quality (ensure modern engineering practices, proper configuration management, built-in quality)
– dependencies (ensure clear overview of backlog dependencies between different projects)
– product owner (rolling wave planning, product roadmap planning, elaborate product vision)
– facilities (workshop facilitation kits, ready-to-use meeting resources, etc)
– knowledge (wikis, promote knowledge sharing, setup of community of practices, etc)
– agile contracting
Article by Mike Cohn on PMO:
https://www.mountaingoatsoftware.com/articles/the-roles-of-the-project-management-office-in-scrum