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.