RallyDev.com
Mon 13 Apr 2009
8 Ways To Re-Tool a PMO in an Agile Environment
In an earlier post, I asked an Agile test question, “Are PMOs Obsolete in Agile?”
While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.
8 Ways To Re-Tool a PMO in an Agile Environment
- Have the PMO involved in helping rollout Agile on several pilot projects
This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.
Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.
- Learn from Lean: start a Kaizen and Gemba mentality now
The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.
Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.
In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.
Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.
- Change your definition of “Standard of Work”
This is not a set of standards defined by and enforced by the PMO for project conformance.
In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.
(In my previous post on the PMO, Brendan Flynn has a wonderful comment about how he and his PMO engage teams at Shoplocal in doing this work.)
- Facilitate and be a Servant Leader
Don’t control.
The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.
A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.
Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.
They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.
So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.
- Provide guidance on regulatory adherence
In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.
The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.
- Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption
Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.
I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.
Our Rally whitepaper about Applying Lean Pull principle for Program level Agile is a great guide for the Agile PMO working with programs of teams.
- Guide non-IT/Engineering organizations
Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.
Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.
The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.
- Foster useful metrics
Let go of that Waterfall security blanket around what are useful project or program metrics.
Determine which metrics to track that directly help organizations concentrate on value delivery.
Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.
An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.
Look in the Appendix of our whitepaper A CIO’s Playbook for Adopting Scrum for more ideas on useful metrics in Agile adoption.
About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.
I love the picture almost as much as the content (the perfect picture of balance in a PMO) – I can’t wait to forward to some of my key customers
There is a level of down-the-rabbit-hole insanity that you have to have reached to get to the point where you can read this impenetrable drivel and think it has anything to do with Agile development, or development of any sort.
This is just consultants talking to each other. You need *SEVERAL* pilot projects, mark you, before you get to the point where you’re Kaizening your Gembas! Maybe a three-day intensive course on how to use Rally would help get your PMO being a Servile Leader!
You’re all nuts.
I think Kaizen and Gemba, done well, are very disciplined approaches for an organization to embrace. We agree. I also agree with you that starting with a few pilot projects is THE way to go. It is what I always recommend when asked how to adopt agile.
Sometimes, however, organizations want to (need to?)go complete cutover and want the PMO to “organize” it (read: “control it”). My goal with the 8 guidelines is: if you have a need to go organization-wide, then you are going to have to pay attention to a whole new set of PMO disciplines than one team alone would do. AND, those new disciplines include NOT controlling the adoption top-down.
Could be a “nuts” way of managing large scale risks or for converting traditional organizations to agile. I don’t think so.
Hello again Jean,
I do like your post. Following up from my response to your last post on the PMO and in light of the “nuts” comment …
The Lean principle of “Standard Work” is seen in how we execute on delivering value to the business … how value flows. We optimize our standard work through our retrospectives and our Kaizen events. The critical aspect of this is the people doing the work get to improve the work. Management facilitates to ensure we actually practice Kaizen and then follows up to enact the ideas and sustain the changes, but it is the people that suggest and execute to make the improvements (this to me is a major connection between Lean and Agile … it is about the people doing the work). Standard work allows us to measure where we are and where we want to be … and it only stays “standard” until we improve it … then it becomes the new standard (waterfall execution to Agile execution to …..)
“Going to the Gemba” is about management and our fellow co-laborers going to the “factory floor” to SEE … to live and experience reality in order to improve reality. One must walk the path and listen in order to understand how to make real and lasting improvements. This is a much better way of introducing changes instead of the back office or ivory tower approach. So going to the Gemba is practiced during Kaizen … and yes it is a disciplined approach that helps to drive out a culture of continuous improvement. I have been involved in many Kaizen events and it is always very fun to hear comments from people participating in their first Kaizen event of moving from skepticism to excitement … excitement because their ideas were listened to and put into action … and they get to put them into action!
Finally, to help re-tool the PMO, I would add a 9th point (or a sub point for 6) … Visualize and manage flow through Value Stream Mapping (VSM). A VSM allows us to understand the flow of “value asked” to “value received” and guides our Kaizen events … think of it as our roadmap of our portfolio for continuous improvement. It allows us to see and to ask “why” … why is that queue so big … why are we waiting so long at this point … is the output of that process step delivering any value?. In a way, a “kanban” board (agile team scrum board) is a sub-VSM of a larger VSM that helps us see the flow of value (work requests, stories, minimal marketable features) and helps us manage our queues in order to optimize them to minimize waste.
Phillip
I wonder to what degree it’s necessary to provide the folks in the PMO with at least some kind of potential carrot in the form of ‘there’s still a place for you’.
if you just tell them they are extinct, there’s no place for them and this will mean they’ll be sacked in short order then their sense of self preservation kicks in. Once that happens they will do everything in their power to hinder, embrarras, sabotage, and defeat the move to agile. They will brand it as a ‘fad’, dig up instances where moving to agile has failed (never mind why they failed, just find a bad example or three, quick!)
They’ll brand it cowboy programming, bemoan the lack of control, the inadiquite planning, and have fits over the whole ‘ad hoc’ (as they see it) nature of the beast.
So fine, show them a path where they don’t lose their jobs.. but also make sure that they commit to the process, not just give it lipservice. I expect perhaps the hardest thing for them is going to be giving up control. They’ve been schooled in it, they’ve spent most of their time not only ‘controlling the process’ but believing that it was absolutely essential to do so. HOW you manage to break them out of that mentaility is I expect absolutely key to success.
Next you need to make sure that everything they are doing ads value. It can’t just be assessments, evaluations of techniques (the people in the trenches can tell you if something is working or broken) and other typical PM style busywork. Make sure improvements they suggest really are improvements, focussed on the constraints that are holding you back, and not peripheral window-dressing that doesn’t increase velocity, provide better quality, or reduce costs.
[...] Agile Blog When Jean Tabaka and Ryan Martens (founder of Rally Software) talk Agile, people listen. This blog has a growing following for posts like this one: “8 Ways to Re-Tool a PMO in an Agile Environment.” [...]
[...] Agile Blog When Jean Tabaka and Ryan Martens (founder of Rally Software) talk Agile, people listen. This blog has a growing following for posts like this one: “8 Ways to Re-Tool a PMO in an Agile Environment.” [...]