The Agile PMO Role

The Agile PMO Role Tamara Sulaiman, PMP, CST July 28, 2008

The program management office is one area where an identity complex of sorts can develop when organizations shift to agile software development practices. To many practitioners in the agile world, the term "Agile PMO" sounds like an oxymoron. Under agile methods, agile teams are cross-functional, self organizing and self managing, right? Doesn’t this imply that a centralized managing structure like the PMO isn’t necessary anymore? While it’s certainly true that agile teams are cross-functional as well as self-organizing and self-managing, it is not true that there is no role for the PMO in an agile organization.

 

First, let’s take a look at what I mean by program management. The definition of traditional program management that I use is relatively straight forward: 

• A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.
• Programs may include elements of related work (e.g. maintenance operations) outside the scope of discrete projects

A traditional PMO is responsible (in full or in part) for: 

• Participating in project portfolio management
• Supervising project objectives
• Maintaining standards
• Reporting enterprise project information
• Organizing training
• Project management decisions
• Providing growth for project managers
• Supplying project managers to the organization

The need of an organization to obtain benefits from managing groups of related projects in a coordinated way does not disappear with the transition to agile software development methods. Neither does the need to meet strategic business objectives through managing a portfolio of projects. But the way that these needs are met once an organization transitions to agile methods can change significantly. Supporting and facilitating agile programs while staying true to the Agile Manifesto and agile principles is a key requirement of any agile PMO.

 

Let’s say you are a manager or leader in an agile organization. Your development teams have implemented Scrum and are now working toward release. You’ve got the Scrum of Scrums working so that teams can communicate with each other about cross-team dependencies and impediments on a daily basis. But there’s a gap, isn’t there? As a manager, how do you effectively and efficiently measure progress, manage risk and keep your eye on the big picture across these agile teams? Wouldn’t it be great to have an easy way to communicate budget and schedule information at the program level to the organization? What’s a good way to research and establish best practices, standards and metrics to be shared across teams? When things go wrong, where can your ScrumMasters go for help and advice to support themselves and teammates? Establishing an agile PMO to handle these items can be a useful tactic for filling in that gap.

 

To help us out, here is a working definition of an agile PMO, which is responsible for supporting: 

• an agile transition within an organization
• multiple agile projects within a product lifecycle; and/ or
• multiple agile teams within a large project; and/or
• multiple, unrelated agile projects within a portfolio

As the organization transitions to agile software development methods, the function of the PMO must evolve to meet these responsibilities. That evolution must be tied to the strategy of the overall organization--what works well for one company is not necessarily appropriate for another company. Here are some suggestions that may help.

 

Institute an agile transition team, and have the agile PMO play a significant role on that team. If you are starting on the journey, establishing an agile transition team can be a critical factor in your success. The agile transition team plans and implements the strategy for the organization’s agile transition (using a backlog, iterations, planning meetings, retrospectives and, in general, responding to change) This group monitors and communicates results throughout the organization, and is responsible for removing organizational level impediments. The PMO representative can act as ScrumMaster for the agile transition team. Members should be leaders representing different departments and functions that are impacted by the agile transition. For example, having leaders from development, QA, product development and the PMO is an excellent practice.

 

Have the agile PMO work with the lines of business to manage project throughput. It is important to make sure that the project pipeline does not get “overstuffed”, leading to bottlenecks and project delays. Tom and Mary Poppendieck refer to the Japanese concepts of Muri, Mura, and Muda in their work on Lean Software Development. In the forward of Implementing Lean Software Development, Jeff Sutherland writes that “Muri relates to properly loading a system and Mura relates to never stressing a person, system or process. “ If a team is a system, overloading that system--a group of people--leads to confusion, context switching, and delays.

 

Often I’ve seen managers assign people to multiple teams in the interest of “optimizing” their time allocations without realizing that this is often causing more complexity and context switching; leading to ever longer delays. It is usually better to bring the work to the teams (rather that forming teams around the work) and let them focus on one thing at a time. The agile PMO can serve as a central point to help review and manage this throughput by facilitating discussions and negotiations between business leaders on project prioritization, maintaining a visible backlog of prioritized projects and optimizing the whole in such a way that everyone has insight into where there project falls in the backlog.

 

Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy. As part of optimizing the whole, it is important for there to be a big picture view across products and features. In general, product managers are tasked with defining, prioritizing and communicating the vision and features for their products. When you have a program that encompasses multiple products with multiple product owners and project teams, keeping everything in line with the corporate vision can sometimes be overlooked.

 

Unlike the Scrum of Scrums--which is tactical, i.e. focused on execution--the Meta Scrum is focused on the strategic planning and decisions guiding the program or programs as a whole. Establishing a Meta Scrum with the PMO representative acting as ScrumMaster to plan and facilitate meetings (as well as reporting and tracking decisions and action items) can add significant value in having a program able to rapidly respond to change while staying true to the corporate strategy and objectives.

 

Develop and communicate a standard framework of templates, tools and best practices. It is important for self-organizing teams to do so within a framework of standards in order to optimize the whole. If teams self organize outside of a framework, waste and repetition can easily bog down the program. The agile PMO is a natural place to research and maintain the standards, templates and tools. Individuals within the PMO can spend time scanning the industry for best practices, templates and tools that can help teams increase quality and productivity. Through the inspect and adapt mechanisms in agile development, individual teams will develop their own best practices and templates. The agile PMO can help propagate these across the agile teams.

 

Gather and communicate portfolio level metrics to the organization. The PMO is in an ideal position to aggregate metrics and communicate progress, issues, impediments and decisions to the organization. Choose what to measure and report across the program(s) carefully. Make sure that the information reported is timely, relevant and concise (try not to exceed a 1one-page report.)

 

I like using story points to establish the velocity of individual teams. From a program point of view, however, story points are difficult to use across multiple teams. The nut there is that one team’s story point is not equivalent to another team’s story point. To crack that nut, I use agileEVM to “normalize” to standard project management metrics like the Cost Performance Index and the Schedule Performance Index, as well as the Estimate At Complete in integrated dollars. These metrics can be aggregated across teams to establish progress against the plan for the entire program.

 

I prefer to use the agileEVM metrics in conjunction with other information that is valuable to the audience. That may or may not include metrics on product quality and customer satisfaction, key decisions from the Meta Scrum meeting, program level impediments and progress in removing those, changes in customer expectations, etc. The PMO will work to define what is the critical information and how best to communicate it.

 

Establish an agile CoachingCenter. It is important from an organizational perspective to continue to provide coaching and training to agile teams. Team development and facilitation needs continue after the initial shift to agile methods is completed. In addition, new team members are hired, new practices discovered and implemented. Establishing an agile coaching center of excellence can meet this need.

 

In order to be successful, the center needs to be a legitimate organization with an assigned budget, staff and objectives. The center can be a located within the agile PMO. The center can develop and manage a central agile library, produce various lunch ‘n’ learns and other programs to infuse agile values and knowledge across the organization, and provide proficient, independent facilitators to teams for various retrospectives and other needs. In addition, the center can help the team gather metrics on their agility and health so that the team can take action if the decide to.

 

The role of the PMO will continue to evolve and the organization evolves. Hopefully these suggestions can help you find your way as you begin or continue on your agile journey.

 

Reference:

• To read more on the cost of context switching, check out Johanna Rothman’s “Multiprojecting – progress by illusion”.
• For more information on a the concept of meta scrum, Brent Barton has an article published in the October 2007 edition of AgileJournal.com. Barton’s concept of the Meta Scrum involves the Chief Product Owner as the Product Owner for the Meta Scrum. I am suggesting that we augment his ideas with the involvement of the PMO in the ScrumMaster role for the Meta Scrum group.
• For more information about story point estimation and velocity, start with the Wikipedia entry. From there you can do a quick Google search on the subject. If you prefer a hard copy reference, in his book Agile Estimating and Planning, Mike Cohn does a good job explaining the concepts.
• For a more detailed explanation, see the article that Hubert Smits and I wrote on “Measuring Integrated Progress on Software Development Projects”.

Tamara Sulaiman is managing consultant at Applied Scrum, a project management consulting organization dedicated to the exploration, understanding and implementation of practical applications of agile and Scrum. At Applied Scrum, Sulaiman is focused on coaching teams and organizations transitioning to agile software development. Sulaiman brings more than 20 years of experience in management across a spectrum of industries including: information technology, construction, international development and education to her consulting expertise. She is a Certified Scrum Trainer (CST) and Project Management Professional (PMP).

Posted via email from pierreneis's posterous