As others have pointed out, you may have been given the directive to set up an “Agile PMO” as a solution to a set of requirements that may not yet have been well articulated. Until you can get to those unstated needs, your chances of success will be limited. Without knowing those requirements, the best generic input that I can provide is to look at your PMO’s processes and procedures with a lean mindset, deciding what really adds value and what adds waste. Reference the book “Lean Software Development” by Tom and Mary Poppendieck for some great insight into lean thinking. Use the Agile Manifesto as a set of guiding principles. For example, the Manifesto states that you should value “Individuals and interactions over processes and tools”. What a thought! Many PMO’s are all about processes and tools. Manage your backlog of projects in much the same way an agile/scrum team might manage a set of user stories. You create the backlog, find a way to assign business value to those backlog items, and work only on the highest business value items. Business value may or may not necessarily be measured in terms of finance. And, just as a scrum project team continuously refreshes and review the priorities in their story backlog, you would do the same for your project backlog. The reference materials that Don Kim provided are great.
I would also add a few other great books such as “Agile Requirements” written by Dean Leffingwell and “Lean-Agile Software Development” by Allan Shalloway. Don’t let the titles throw you as both books address lean approaches to the PMO. Or, if you listen to Larman and Vodde in their book “Scaling Lean and Agile Development”, they suggest getting rid of the PMO and avoiding an agile PMO. You’ll have to see if their rationale makes sense for your situation.
If you want a very concise view of one agile PMO approach that I really like, see the following LitheSpeed blog post “5 Steps to Make Your Project Portfolio Flow”
