RallyDev.com
Wed 8 Apr 2009
Are PMOs Obsolete in Agile?
note: PMO stands for Project Management Office.
To PMO or not to PMO? That is the question. Or, put another way, in our Agile test this week, please answer the following question:
Are PMOs Obsolete in Agile?
(a) YES!
(b) NO!
(c) Uh, maybe?
(d) All of the above :- )
What’s your answer?
Before you tell me, here is some food for thought:
Archeological Dig for Extinct Life Form
Yes, if your PMO maintains a rigid conformance posture informed by Waterfall approaches to managing and tracking project risk and success, it is obsolete. Lose it. Here’s why:
- Agile has no place for rigidity.
- Agile rewards flexibility, responsible change, and continuous growth. This is true in processes, in practices, and in people.
- Agile doesn’t seek conformance. Agile seeks emergence of the most useful, sustainable practices that deliver value, team by team, item by item, timebox by timebox.
- A PMO that determines standards and then enforces these standards through status updates runs counter to the core of Agile.
- Agile seeks more than status updates. There is no punishment or reward system other than finding impediments and removing them.
A conformance-based PMO, in contrast, will tend to hold onto old habits: create standards; enforce their standards; collect detailed status information about how projects are conforming to their standards; create pressure to bring non-conforming projects into line. Such a PMO can inadvertently (or purposefully?) create a culture of blame and hence engender skewed reporting by projects in order to avoid associated “punishments” or public flogging. This PMO with its incumbent culture will absolutely kill an Agile initiative before it has started.
So, if you find yourself in this environment, lose the PMO or you will never win with Agile.
If your PMO is prepared to be a liaison and evangelist of the Agile rollout across the organization, don’t lose them! They can be a pivotal force that ensures the true essence of Agile; they seek to find out what delivers value in a regular rhythm and to keep improving on it.
The PMO has an incredible vantage point in an organization: they can look around and “see the whole”. Heads-down Agile project teams concentrate on what works in their singular context. An Agile PMO, on the other hand, with a broader view, has the golden opportunity to continuously survey project teams to learn from them what is working well and then spread that good news to other teams and to the management.
An Agile PMO applying Lean Principles such as eliminating waste and amplifying learning can serve as the servants to the Product Owners and ScrumMasters. They can support the Agile project teams by facilitating cross-fertilization of best practices. They become the guardians and carriers of the Agile emergence. You might say they are act as the Agile pollinators.
Note: see my post “8 Ways To Re-Tool a PMO in an Agile Environment” for further information about how to create an Agile PMO.
Ultimately, it comes down to this: What transitional fortitude does your organization have to move to a new way of doing things: the learning, the facilitation, and the Servant Leadership required of an Agile PMO?
That is the big MAYBE that will be sitting like an elephant in the room with you as you consider an Agile rollout with your PMO.
My Rally colleague Mark Kilby has a great way of testing this: Is your PMO prepared to sign an Agile PMO Manifesto?
We, as an Agile PMO, value:
- Kaizen (retrospections for continuous improvement) over Conformance and Consistency
- Org-team mutual Service Level Agreements over Top-down Policies and Processes
- Communities of Practice over Central Authority
So, where are you, where do you want to be, and how do you hope to get there? You may, at any time, be any one of the above, or all at the same time. Fear not! There is a way.
Just remember, answer (a) YES! reminds us that a traditional PMO has no place in a truly Agile organization and is hence obsolete.
To get to answer (b) NO! your PMO must be prepared for jolting change in its principles and practices. It may seem daunting. But Agile and Lean have great guidance to protect you along your path.
And, at any time during your Agile Adoption, you may find yourself in the ambiguity of (c) Uh, Maybe? or (d) All of the above :- )
If you are prepared to embrace the 10-step Agile PMO guidance and Mark Kilby’s Agile PMO Manifesto, you will be on the righteous Agile PMO path.
So, now tell me your answer to the question: Are PMOs Obsolete in Agile?
When it’s all said and done the PMO is simply an implementation of an organizational policy set by the PMO sponsor, the CIO or COO with any luck. If the PMO is running amuck of Agile, then the organization probably is too. It could be that senior leadership has decided to adopt agile in name but has yet to grasp lean principles. Completely independent of the PMO they are likely still holding on to “command and control” structures and senior leaders make commitments without involving the development team. Worse still, maybe the development teams have moved from home grown agile initiatives to more formal ones, while still paying lip service to the structures put in place by the PMO process, thus wasting resources on “shadow compliance”.
In any event, something has to give and the PMO might as well be an agent of change along with the governance function. Let’s face it, a weak agile initiative (read weak scrum master) can go off into the weeds like a project with a weak project manager. I’m fortunate enough to serve on a PMO that has an SEPG function which is all about owning and evangelizing the software engineering processes. After all, its not going to grow itself no matter how organic it is, it still needs “water” and “sunlight”.
Scott, first of all, thank you for your comment. Secondly, I think your insights are spot on! The PMO is very often a reflection of the overall organizational health or dysfunctions. Take a look at your PMO and you can learn a lot about the organization in general. And to your point, a failure of a PMO to evangelize or embrace Agile is probably due to big hairy constraints set on them from above and all around. n these cases, the PMO is held captive and potentially made a scape goat, which is very often in the job title anyway…. Nicely done, Scott! Jean
Sorry but how is the “Prime Minister’s Office” relevant to Agile ?
Define your terms – not all readers know what you know
Hi Alan,
PMO stands for Project Management Office. Do you have one in your organization? What are your experiences with their role? If you don’t have one, why do you think that might be valid for your circumstances? Thanks, Jean
[...] got the idea for the title by reading the post “Are PMOs Obsolete in Agile?” but honestly the idea has been [...]
Thanks for the mention! Jean
Jean – great post, I love that you are actively blogging!
We definitely fall under the B) No category. That is, we are agents of change, evangelists reinforcing the values and principles of Agile throughout the organization. This was especially true as we initially rolled out agile practices, where there were many cultural hurdles to overcome. Having this central group banging the drum every day helped with our adoption and eventually its optimization of removing wasteful practices.
In my view (as the head of a PMO), there is a place for PMO like standards in that we help to define or facilitate working agreements across the organization. The purpose of working agreements is to help define expected behaviors of each team. Sounds very PMOish. The PMO lays out the framework, but the teams define, inspect and adapt to make it their own.
Brendan, as usual, you clearly GET what it means to rollout Agile, from team to team, and across the organization. I love that you emphasize that your PMO at Shoplocal pays attention to a drum beat. I had known that in the back of my head from some of the great PMOs I have worked with. Just didn’t think of it while writing the post :- )
Also, it is so critical that you have built safety and trust with regard to setting up any agreements of standards by having the teams define them. You as PMO are faciliting those discussions of insight and then capturing as a service to the organization.
I have an upcoming post of my list of top guidelines for Agile PMOs. Hope to see you there!
Thanks again for your great thoughts. And congratulations!
Could I suggest another blog topic titled, “How to convert your PMO to an Agile PMO”? Regardless of what you’re developing, be it a PC-based software app or the next generation mousetrap, Agile practices can be employed to improve your ability to deliver business value.
As manager of a nascent PMO and self-appointed Agile evangelist at a company(here in Boulder) where PC-based SW development projects are only ~10% of the project universe with the other 90% being development of electronics/mechanical devices, my goal is to spillover Agile practices out of the software arena and into other engineering disciplines as much as possible. Those practices may be “less-Agile” when applied to development of circuit boards, for example, where iterations can’t be had in a few weeks, but the effect on collaboration, commitment, focus on adaptation and continuous improvement is game changing.
Agile may seem foreign to a PMO whose business is outside of software development, yet would benefit greatly if someone handed them an “Agile PMO Conversion Kit”.
Eric,
A conversion kit “one size fits all” may be a bit too strong a term for how I’d guide a traditional PMO to go Agile. However, to your point, I’ve listed 8 general re-tooling guidelines for an Agile PMO in my latest blog post. See what you think about these and if they resonate with your experiences.
Also, congratulations with your vision of the “agile spillover” outside of the software development group. I have worked with some clients using Agile for embedded software, firmware, and hardware development and deployment. Indeed, this sense of collaboration, coordination, commitment, and overall project visibility can be profound. Magical things occur if people in all parts of the organization are prepared to truly engage and not just pay lip service to the agile transition.
Hi Jean – the PMO does not have to be obsolete …
I look at the PMO (project/portfolio management office) similar to what I have experienced in an organization driving out lean … the KPO (Kaizen Promotion Office). The KPO was responsible for driving out “continuous improvement”, managing the whole (Value stream) and for promoting a culture of kaizen throughout the company. Similarly the PMO may manage the whole (portfolio view), promote a framework of lean/agile thinking, promote a culture of community and help the organization understand and deliver business value. This to me is the mission for the modern day PMO. Further, the “project managers” that work as part of the PMO must turn to facilitation, partnering with the business to understand the whole (value stream), be an agent of change, foster high-bandwidth communication and consultation. Is this too big of a challenge? I don’t think so … it just takes leadership and passion … that however is sometimes difficult to find.
Phillip,
I love it! Kaizen Promotion Office! Maybe that is what we should explicitly request as a name change as organizations transition Agile across teams or teams of teams (Programs). It makes the mission of “the office formerly known as PMO” so obvious. Thanks for sharing. I also think this backs up the comment from Brendan Flynn about how his PMO works at Shoplocal. Perhaps you two should hook up and share more ideas together and with the rest of us? I’d love it.
BTW, check out my blog today regarding my 8 ways to re-tool for an Agile PMO. You’ll see Kaizen and Gemba sprinkled liberally throughout.