Abstract: What does the PMO actually do in an agile, learning organisation?
The leading vs dragging PMO In many organisations the PMO tends to be part of the problem rather than part of the solution. They tend to frustrate attempts to improve agility that come from either bottom-up team level adoption of agile and top-down desires to improve organisational agility. A lot of the changes that come from adopting agile have a habit of breaking the mold that the PMO is used to. We tend to see a shift from the left-hand side to the right-hand side of this list:
Less of this, more of that In 140 characters:
. Plan —> Forecast
Resources —> Teams
Push —> Pull
Reqmnts —> Expmnts
Projects —> Initiatives
Dates —> CostOfDelay
— Joshua J. Arnold (@joshuajames)
September 7, 2016 Leading change vs defending status quo Unless they’ve been hiding under a rock for the last decade or so, the teams already get this. In my experience, senior managers also get it. Although they may not use this language they do understand the need to change the culture. The PMO tends to get stuck in the middle though, defending old-skool, outdated thinking that doesn't fit the new more agile world of software and product development. Often they just don’t know any different and they’re using what they’ve been taught as “best practice”.
The thing is, the PMO, with it’s wider portfolio level view of teams is actually well-positioned to really add value and improve the system as a whole. But maybe they don’t know how they could be helping? Based on many years helping organisations from Maersk Line to Starbucks, public and private sector I'll lay out an informed view of the six things the PMO should be more focused on.
Learning Outcomes: - Understand how the PMO is well-placed to add value in an agile organisation
- Learn 6 things an Agile PMO needs to nail
- Advice for agile PMOs: (More of this, less of that)
