Long back, I posted an article on LinkedIn titled, Lessons Learned in Establishing a Project Management Office (PMO.) It centred around the discussion of plan-driven projects, typically manifested by the waterfall methodology.
I subsequently spoke on this topic at a Project Management Institute (PMI®) chapter meeting and was asked to incorporate some thoughts on how the PMO might support adaptive or Agile methodologies. Having now helped establish several PMO’s, I’d like to share a few thoughts on this.
Firstly, Agile is different philosophically in many ways than waterfall. One of the main tenets of the Agile Manifesto is "Working Software Over Comprehensive Documentation." This does not mean NO documentation; it just means that working software is valued more.
Conversely, the plan-driven project typically relies heavily on documentation. And therefore, the waterfall-based PMO reflects this by having any number of templates, forms, and archived notes. So, for example, the well-stocked plan-driven PMO has templates for charters, risk registers, project management plans, etc.
But in Agile, let's say specifically in the Scrum variant, the team requires artifacts such as product backlogs (essentially all the requirements), sprint backlogs (what activities you will perform during a sprint), and release plans (how many sprints you will need to perform). Often – outside of reporting – Agile teams don’t use much more than that.
In the PMO’s in which I have been involved, we created these templates and put them in the repository, but, depending on the type of PMO it was, 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 in the team 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 a project should be Agile. It should not impose its philosophy on every project.
You might argue that the “world is going Agile.” In a very real sense, yes, it is. But there are any number of projects that have lent themselves for years to the waterfall methodology and continue to do so. A colleague of mine works for a telecommunications company and they are always rolling out new networks. This is such a well-understood technique that classic waterfall works quite well for them.
One area in which the Agile PMO can assist is in gathering metrics. Since Agile is all about delivering value, how well teams deliver that value might be of interest. You can track and measure such things as a team's velocity, burn-up or burn-down rate.
Since the Agile PMO has visibility across the organization, 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.
And while it is by no means known as an exemplar of agility, PMI recently published an Agile Practice Guide1. They noted three things about the Agile PMO that I agree are worthy of note:
- An Agile PMO is value-driven. It provides the right value at the right time, not imposing on its customers but working with them in a consultative fashion.
- An Agile PMO is invitation-oriented. A corollary of the first precept, the PMO is available to all in the organization but especially invites in those who find the concept and its services of value. Their interest makes them much more likely to engage.
- An Agile PMO is multidisciplinary. Not all PMOs are created equal. The more successful ones are centers of excellence and provide not only project management-related expertise but also advice in disciplines such as change management.
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 takeaway here is to make sure that the Agile PMO is ....
1. Agile Practice Guide, p. 81. ©2017, Project Management Institute, Inc.
© Jim Stewart, PMP, CSM 2018