For a true agile transformation to take place in an organization, a variety of values and principles will need to align. Among these, the one that I believe is the most necessary is “Trust”.
Introduction
I once had the opportunity to serve as facilitator at a local PMI user group meeting on the subject of PMO’s. I had worked with PMO’s in the past, both prior to the introduction of agility, and after agile had arrived and needed to be brought under the careful guidance of the Project Management Office. I worked with a PMO every day in my engagement at that time, so I readily accepted the offer to guide this audience’s-inspired discussion.
Each attendee had been asked to provide at least one question they would like to see addressed by their fellow audience members. Prior to the event, I had grouped the questions into some loose categories. There was a collection of questions asking how big an organization needed to be before a PMO was warranted. Others focused on how you measure the success of such an organization. Yet another collection focused on recruiting PM’s from other groups to join the PMO. There were a few questions that seemed intent on causing a disagreement. I set those aside to use in case of emergency.
I decided a good place to start the evening would be to introduce the group to Simon Sinek’s golden circle (from his book: “It Starts With Why”, and his Ted Talk). I asked the group to identify what PMO’s did, and I was immediately answered with a couple dozen one-word, or short phrase responses. Words like “oversee”, “monitor”, “assure” and “coordinate” were offered. I then began Simon’s infamous opening line, “Most people can tell you ‘What’ they do. Some can tell you how they do it. But very few can tell you why they do what they do.” And so I challenged the group to explain why you needed a PMO.
Again, a barrage of short words. Only these had a slightly more negative tone. Words like “enforce”, “compliance”, and “control”. In fact, it seemed like all of the words used were reactionary. Reactions to things that had gone wrong in the past.
As discussions died out on one topic, I read another from the list. When the answers came too quickly, or the audience appeared to lose interest, I’d pull out one of the provocative questions I had flagged from the list. My favorite was something along the lines of, “Since our PMO formed, we’ve seen an increase in red tape, a decrease in PM quality, and a general drop in our ability to deliver. Maybe PMO’s would work in other industries, but I think they don’t help in IT. Your thoughts?” As I finished the question, there was a sort of stunned silence in the room. Some people smirked at the audacity of the question. Some looked legitimately insulted. I pushed a little, “…or to put that another way. PMO’s suck. Who’s with me!?”
That got the conversation going!
As more questions came and went, we circled back to the whiteboard repeatedly. We talked about the conditions that caused the formation of most PMO’s. A common path involved groups of developers got out of hand, so a PM was brought in to control the situation. More teams formed, and more PM’s came in. Eventually, the number of PM’s was large enough that the differences between their methods caused problems. So a PMO was formed to bring the PM’s under control. One helpful attendee then explained how in a large enough organization, you end up evolving multiple PMO’s, and those PMO’s in turn eventually do things differently enough that chaos returns.
We circled repeatedly back to “Why” each situation existed. And time and again, it came down to one thing. Lack of trust spawned strict rules, and necessitated enforcers, with the PMO in the role of the police.
Role of the PMO
Establish standards, and validate that they are followed. To manage the Project Managers who manage the projects. To ensure that costs are contained.
Role of the Project Manager in Agile
My approach to agility is very Pragmatic (as opposed to Dogmatic). I’ve never liked rules-lawyers, so I don’t appreciate when people quote agile scripture as their only defense for why they make certain requests (demands) of the teams they train or coach. If I’ve learned one thing in my years as an Agilist, it’s that people really need to understand ‘why’ a thing is needed to truly embrace the change that such a thing demands. So, when I make a statement that Agile methods like Scrum provide no role for a Project Manager, I mean that as a simple statement of fact.
Scrum named only three roles: Development Team, Product Owner, and Scrum Master. The responsibilities traditionally laid at the Project Manager’s feet in a traditional model have been redistributed to those three roles. Things generally associated with the estimation and sequencing of work are allocated to the Development Team. Things associated with the prioritization of work, or the containment of cost are allocated to the Product Owner. And finally, things associated with governance, collecting/providing status, coordination with outside demands, or removal of blockers are assigned to the Scrum Master. To put that another way, accountability and responsibility have shifted to the role that is best equipped to control that aspect of work.
So what’s a poor