This keeps coming up in quite a few conversations I’ve been having lately. Does the PMO have a place in an Agile Software Delivery team/company/project etc? I have a couple of opinions on this and its really an either/or.
If your organization currently has a Project Management Office and you have a strong hierarchical reporting structure, I believe that you can repurpose this group of folks. Especially in the case that the people in the organization are really looking to embrace a new role. Don’t get me wrong, this will come with challenges. Traditionally the PMO is a command and control type org that breaks down work and assigns out tasks and manages to delivery. In an Agile model, you typically don’t have much use for this type of behavior as you are working with a group of empowered, self-organizing and intelligent knowledge workers. However, what I think often goes left unsaid is the need for vertical reporting of team data as well as program level data. As a delivery leader, I’m not so interested in sprint burn downs, task burn downs etc, but I am interested in predictability metrics, feature completion against a roadmap and overall quality of the codebase. This is stuff that I think the PMO is very well suited for. In this model, I’d call them “Ambassadors of Transparency”.
Now if you are starting something up from scratch, my opinion is that adding the layer of a PMO is probably unnecessary. With the right tooling and the right scrum master or product owner, I believe that this information can be shared and flowed in a different manner. I find that in this model, the team(s) are all in on the upcoming milestones and they are owners of their data in addition to their code so they are more than happy to share their progress. Basic scrum doesn’t really have a recipe of this and neither does the kanban method, but I think that’s what I like most about finding the right balance of process and people … you tailor to your needs based on the framework.