The Integration of Agile and the Project

Management Office
Introduction
In the early days of its adoption, the Agile methodology seemed to be diametrically opposed to
the process-driven project management office (PMO), which most often corresponded to a
Waterfall-style planning and delivery methodology. Agile was a more nimble approach to project
management while Waterfall stipulated a rigid, document-driven structure. The same is true
today, but in the past few years, a growing partnership between Agile practitioners and the PMO
has emerged. The two are no longer mutually exclusive. In fact, the discipline of project
management has evolved to actively include both methodologies in the enterprise.
Organizations often see a need for a blended approach to project delivery, moving away from the
traditional project management to a hybrid Agile-Waterfall methodology. Selecting certain
elements from the Agile approach such as writing story-based requirements, holding daily standup meetings or targeting shorter development cycles allows organizations to alter their original
milestone-driven approach to build in more planning and feedback loops, which in turn gives
them more flexibility to react to changes in project requirements. The redefined PMO has begun
to integrate itself into this approach by providing resource support where necessary, by acting in
the role of change enablement, and by clearing roadblocks in the progress of projects and
programs by incorporating elements of the servant-leadership model into day-to-day operations.

Where Agile Makes Sense

The Agile approach is best suited for projects of an experimental nature incorporating new or
untried technology, in which change or refinement of the requirements will be a necessary aspect
of the defined product release. Using Agile for bridge construction, for instance, makes little
sense since the requirements are clear. In order for the bridge to fulfill its function, a set list of
prerequisites is needed from the outset of the project. Last-minute changes simply arent in the
plan. Building a software application, on the other hand, frequently benefits from using the Agile
approach since the desired end-state system may be known, but the details of the technical
solution will have to be determined using a sequence of tightly defined iterative loops, or possibly
parallel project teams working in tandem on a variety of sub-systems.
It would be incorrect to claim that Agile is simply a looser, less disciplined way of running
projects. In fact, on the program level, Agile teams are even more tightly controlled since the
progress of one or more projects is monitored and actively communicated in real-time. Unlike the
traditional approaches in which reporting is done on perhaps a monthly basis, Agile reporting is
in fact continuous and runs in tandem with the six defined levels of Agile planning

Where the PMO Can Play a Part

ESI research indicates that Agile projects tend to be large and complex, emphasising a particular
need for specialist resource support at critical points in the project, a coordination task which the
PMO can naturally fulfill. In fact, in terms of planning, the PMO is heavily involved with the top
three levels of Agile project planning (strategic, portfolio and project planning), while the project
team itself provides the basis for the release, iteration, and daily planning cycles. The illustration
above depicts the top-down and bottom-up interplay of these planning activities.
According to a recent ESI survey on the global state of the PMO, 80 percent of all Agile projects
were medium-to-large in scale with a medium-to-high risk profile. Over half of those surveyed
said their Agile projects were complex in nature. At present the PMOs major role in Agile project
management appears to center around coaching and mentoring support for Agile teams. The
PMO has some way to go in most organizations before fully integrating itself in the Agile
landscape and will most likely take on increasing importance as a resource warehouse,
interproject coordinator, and translator of strategic direction into actionable project objectives.

The Research
According to a PMI/Forrester survey in 2011, about three out of four PMOs still favor the Project
Management Body of Knowledge (PMBOK) as their primary methodology. Reflecting traditional
planning practices, the PMBOK provides an adaptable framework for a wide variety of project
needs. Nonetheless, it is not nearly as flexible as Agile. The 2011 survey also showed that only
one out of three PMOs fully supports Agile, Scrum or Lean practices.
ESIs global PMO study from 2013 revealed that 42 percent claimed their organization delivers
projects using Agile methods while 40 percent claimed they do not. It appears Agile usage is on
the rise, even if it is not as pervasive as many think. All told only 9 percent claimed they used
Agile in over half their projects. Agile is clearly not a silver bullet for all projects.
Not surprisingly, Agile projects are typically IT-related in nature with an even distribution of
projects amongst either the entire enterprise (38 percent), division (24 percent) or department
(29 percent). In the Middle East and Africa (35 percent), Agile was used most commonly for
process improvement projects as compared to the global mean (13 percent).
In many cases, the PMO acts as a centralized coordinating function for a cluster of Agile projects.
The management of a group of projects under Agile offers improved risk management due the
nature of its real-time reporting, offering better insight into the projects status than traditional
project management methods.
The PMO often aggregates information such as the velocity and burn rate of each project,
thereby treating complex projects with many sub-projects like an entire program. Because of its
position as a supervising and coordinating body, the PMO can reallocate resources as necessary
in a nimble, Agile fashion. By helping to determine what the team needs, the PMO acts as a
partner instead of being viewed as an executive body with little idea as to what is happening on
the ground. In this way, the PMO can function as a go-to resource to point teams in the right
direction, gather resources and bring in specialists as required. The PMO has evolved into a
body that orchestrates just in-time management of critical resources that it can shift between
projects, thereby taking a specific Agile approach to its resource allocation.

Interdependencies between projects are a focal point for the PMO. Whether for an Agile or more
traditional project, the PMO is responsible for program and portfolio cost management and
planning. It acts as the financial intermediary and financial buffer, setting aside necessary
reserves to cover potential risks.
Hybrid projects such as the US Coast Guards Response Boat-Medium development program
represent a great example of the concert between Agile and Waterfall. While the hull of the ship
was built based upon a set of fixed requirements and a traditional project management
approach, the ship-board electronic systems were developed using Agile approaches. This tactic
helped in saving development time and cost as the parallel approach to the sub-projects within
the overall program led to faster overall results in the development of this vessel.

The Solution
If Agile is so essential for certain types of projects, how can the PMO optimize its support?
Formalizing industry practices such as certifications that reflect the increasing need for Agile skill
sets is one step toward bringing the traditional PMO and Agile practitioners together. Industry
standards have been raised to recognize the different and somewhat higher skill sets that an
Agile project requires. By the beginning of 2013, over 2000 Agile project management
certifications (PMI-ACP) had already been granted in just 18 months since it was first introduced,
illustrating the general recognition that some specialized form of training and certification was
needed across all communities of the PMI.
Another PMI report entitled "The High Cost of Low Performance" indicates that high-performing
organizations provide well-structured, consistent training opportunities for project managers,
which directly and positively impact project success. In terms of on-time, on-budget, within-scope

project delivery, the success rate of those organizations surveyed that offered professional
development for its project management professionals far exceeded that of their counterparts
who did not provide such learning opportunities. As the Agile PMP becomes more prevalent, we
predict PMOs will become more involved in ensuring PMs receive the training they need in this
area too.
The PMO must also show a willingness to forfeit some level of control by stepping out of the way
of the Agile teams path. Lean project management requires a more hands-off approach than
more traditional PMOs are accustomed to. A give and take needs to take place in order for both
Agile teams and the PMOs that support them to work together.

Summary
In the end, Agile teams and PMOs need one another more than ever. Although they may work at
a different operational focus from one another, they can learn to collaborate if they keep the
successful delivery of working products by means of the project delivery teams in mind. When
both parties adopt innovative communication styles, enormous roadblocks can be overcome.
Recognizing the immense value of transparency and access to outside resources can contribute
greatly to the Agile teams acceptance of the PMO itself. In addition, the PMO must recognize its
critical place as a change agent and strategic enabler in the overall scheme of things. It cannot
be all things to all people, and most every enterprise will need to develop a unique definition of
how the PMO will add the greatest value to the successful delivery of products and projects.
Finally, the PMO must remain current on evolving best practices in the industry to stay on top of
what is needed to deliver successful projects today and into the future.
Agile and the PMO can indeed coexist. With the right mix, they can enrich each others existence
to maximize their respective value to the enterprise without pulling each other down in the mire of
conflicting priorities.

WHAT IS AN AGILE PMO?

Background
I recently saw a question on a LinkedIn discussion group asking: What is an Agile
PMO? There are many people in the Agile community who might say that there
is no role for a PMO in an Agile/Lean environment and that the whole concept of a
PMO is inconsistent with Agile. That opinion is based on a stereotype that the role of
the PMO is heavily associated with controlling and enforcing rigid waterfall-style
policies for selecting and managing the execution of projects and programs. In that
kind of environment, a PMO might require:

Very thorough and detailed upfront planning to justify the ROI on projects
to support rigorous project/product portfolio management decisions

Rigid control of project execution to ensure that projects meet their cost
and schedule goals and deliver the expected ROI

There is no doubt that some PMOs have played that kind of role to some extent in
the past; however, it is a stereotype to believe that is the only possible role for a
PMO to play.

Understanding the Truth About Agile versus Waterfall

The key to understanding this issue is to first understand that there isnt a binary and
mutually exclusive choice between an Agile approach and what people sometimes
refer to as Waterfall. For more on that, check out my recent post onLearning the
Truth About Agile versus Waterfall. It is better to think of this as a range of
alternatives between heavily plan-driven at one extreme and heavily adaptive at the
other extreme that looks something like this:

And, the right approach is to fit the methodology to your projects and business
environment rather than going in the other direction and attempting to force-fit your
projects and business to some kind of canned approach whatever it might be (Agile
or not). For more on that, check out my blog post on Making Agile Work for Your
Business.

Whats the General Role of a PMO in Any Organization?

I believe the general role of any PMO is to align the selection and execution of
projects and programs with the organizations business goals which includes
Project/Product Portfolio Management, providing oversight of project execution and
the overall interface for management and reporting of projects and programs to
senior management and the business, and finally to provide coordination, guidance,
and training to project teams as needed in the organizations methodologies and
standards for project management.

Those general functions probably dont change in an Agile/Lean project environment,

but how a PMO performs those functions may change significantly depending on
the organizations overall strategy for implementing an Agile transformation.

Some organizations may choose to implement a relatively complete topto-bottom Agile transformation for their business Dean Leffingwells Scaled
Agile Framework (SAFe) is an example of such a model. However, that can be
a very ambitious and gut-wrenching change for many organizations and it
may also may not be the best solution

I think it is a mistake to believe that you have to force a company to do an

extensive, top-to-bottom Agile transformation in order to adopt an Agile
process at the development level and there are many ways to adapt an agile
development process to a company whos overall business may not be totally
compatible with an agile approach at the enterprise level.

If you accept the notion that you need to tailor the approach to fit your business, it
should be evident that the design of a PMO should be consistent with that approach
and there isnt a single canned solution for what an Agile PMO is. However, I think
that there are some general guidelines that should be useful.

What Does a Traditional PMO Look Like?

A traditional PMO organization that is oriented around a heavily plan-driven
approach might look something like this:

The emphasis in this kind of organization is typically on planning and control of

projects and this kind of organization would be consistent with a heavily plan-driven
approach. But how does that role change as an organization moves towards more of
an adaptive approach?

What Does a More Adaptive PMO Model Look Like

I think a more adaptive version of a PMO organization might look something like this:

The source of the above material is from my book Making Sense of Agile Project
Management published in 2011 by Wiley.
Heres what I think some of the key differences are as an organization moves
towards more of an adaptive approach:

The role of the PMO becomes more of an advisory role and a consultative
role rather than a controlling role. The function of the PMO should be to put in
place well-trained people coupled with the right process and tools to make the
process most effective and efficient and to keep it well-aligned with the
companys business

The primary responsibility for providing direction to projects shifts more to

the business side represented by the Product Owner in the projects and there
is a much more of a closer coupling with the business side to put more
emphasis on providing business value rather than simply managing project
costs and schedules

The role of the functional organizations also changes to providing more of

an advisory function as the resources are more committed to project teams
and the project teams become more self-organizing

This model can be a very big change for many businesses because it puts a lot more
responsibility on the business side of the organization to provide direction to projects
and the business organization may not be well-prepared to take on that
responsibility. It also relies much more heavily on self-organizing teams.
For those reasons and others, a totally adaptive approach may not be the right
approach for all businesses and even if it is, it may take time to migrate an existing
organization to that kind of approach. Fortunately, there are many ways to develop a
hybrid approach to blend a traditional plan-driven approach with a more adaptive
approach to fit a given business and project environment.

Overall Summary
The role of the PMO should be aligned with supporting whatever that overall strategy
is. For example,

The PMO may still be the focal point for Project/Product Portfolio
Management, but a more agile approach might be used to perform that
function. Instead of very rigorous upfront planning that might be required to
analyze project ROI to support a more traditional, plan-driven project/product
portfolio management approach, a more dynamic decision-making process
might be used at that level with a much more limited amount of upfront
planning and less detailed ROI analysis.

In the other functions related to managing the execution of projects, the

PMO probably would probably delegate more responsibility to project teams
and play more of a facilitative and consultative role to support the project
teams rather than playing a controlling role.

In summary,

Agile certainly forces some rethinking of the role of a PMO but it doesnt
necessarily make the whole concept of a PMO obsolete and irrelevant, and

There are a wide range of strategies an organization can choose for

implementing an Agile transformation at an enterprise level and it isnt
necessarily a binary choice between a pure Waterfall approach from top-to-

bottom or a totally Agile approach from top-to-bottom. You have to choose

the right approach to fit the business rather than attempting to force-fit the
business to some kind of textbook approach.

The important thing to recognize is that this is not a one size fits all decision. What
is the right approach for one company may not be the best approach for another.

The Roles of the Project Management Office

in Scrum
A project management office (PMO) that is engaged in and supportive
of transitioning to Scrum can be a tremendous boon. Members of the
PMO often view themselves as protectors and supporters of a
practice, so a PMO can help implement and spread agile project
management across the organization. However, when the PMO is not
properly involved, it can be a source of resistance as it tries to defend
the current process, rather than improve it.
The natural response of most people in the PMO is to resist the
transition to Scrum, because much of the change is both personally
and professionally frightening. Scrum scatters traditional project
management responsibilities among the ScrumMaster, product owner,
and the team, leaving project managers questioning their role. The
absence of the PMO in most Scrum and agile literature adds to the
natural concerns of PMO members.
In this article, we will ease those fears by looking at the type of work
performed by PMOs in organizations that have successfully
transitioned to Scrum. We will look at the contributions and work of the
PMO in three areas: people, projects, and process.

The Project Management Office And People

Although its called the project management office, the PMO has
tremendous influence on the people involved in a Scrum transition. An
agile PMO should do the following:
Develop a training program. There is much to adopting Scrum that
will be new and unfamiliar to many team members. The PMO can be
of tremendous assistance in putting together a training program,
selecting outside trainers to deliver the training, or delivering the
training themselves.
Provide coaching. Beyond training people, individual and smallgroup coaching is incredibly helpful. In a training class, the instructor
says, Heres how to do a sprint planning meeting, for example, and
perhaps runs the class through an exercise to practice it. With
coaching, someone with deep experience sits with the team and helps
team members through their own real sprint planning meeting (or
whatever skill is being coached). Early on, members of the PMO
might not have these skills themselves, but they should focus on
acquiring them from outside coaches and then do the hands-on
coaching themselves.
Select and train coaches. A successful Scrum initiative will
eventually lead to more coaching needs than the PMO can manage
on its own. Members of the PMO should identify and develop coaches
by watching the scrum teams they help and then providing training or
assistance to help selected individuals become skilled coaches.
These coaches usually retain their current jobs but are given
additional responsibilities, such as spending up to five hours per week
helping a specific team.
Challenge existing behaviors. When the organization begins to

adopt Scrum, the members of the PMO look for scrum teams who are
falling back into old habits or whose old habits are preventing them
from becoming agile. Later, members of the Project Management
Office can remind teams that Scrum is about continuous improvement
and can help prevent the onset of complacency.
The Project Management Office And Projects

Although some project-oriented responsibilities go away with the

change to an agile PMO, some responsibilities remain, including the
following:
Assist with reporting. In most organizations large enough to have a
PMO, there is usually something like a meeting or weekly report on
the status of each project with the department head. If this is a
meeting, it should be attended by appropriate project personnel, such
as the product owner or ScrumMaster. If it is a weekly, standardized
status report, the PMO can assist in preparing the report.
Assist with compliance needs. Many projects need to comply with
standards (ISO 9001, Sarbanes-Oxley, and so on) or with
organization-specific rules, such as those for data security. An agile
PMO can assist teams by making them aware of such needs, advising
them on how to comply, and serving as a central clearinghouse for
tips and shared knowledge on compliance and similar matters.
Manage the inflow of new projects. One of the most important
responsibilities of an agile PMO is to assist in managing the rate at
which new projects flow into the development organization. As
described in chapter 10 of Succeeding with Agile [1], it is important to
limit work to capacity. Otherwise, work piles up, leading to a litany of
problems. For each project completed, a new project of the same size

can be started. The agile PMO can serve as gatekeeper and help the
organization resist the temptation to start projects too quickly.
The Project Management Office And Process

As keepers of the process, members of the PMO will work closely with
the organizations ScrumMasters to make sure Scrum is implemented
as well as it can be. These process-related activities include the
following:
Assist in establishing and collecting metrics. As it did before
becoming agile, the PMO can identify and collect metrics. Scrum
teams are even more leery of metrics programs than traditional
teams, so this is an area where the PMO should proceed cautiously.
One thing an agile PMO should collect is information on how well
teams are doing at delivering value.
Reduce waste. The PMO should aggressively help the team
eliminate all wasteful activities and artifacts from its process. An agile
PMO should avoid introducing documents, meetings, approvals, and
so on unless absolutely necessary. It should also help teams look for
things that they are doing that might not be adding value.
Help establish and support communities of practice. A community
of practice is a group of liked-minded or like-skilled individuals. One of
the most important things an agile PMO can do is to help encourage
the formation of these communities and then support them after they
begin. Not only do communities of practice help Scrum spread
through the organization, they also help spread any good idea from
one team to another.
Create an appropriate amount of consistency across teams. Most
teams, especially Scrum ones, bristle at the thought of consistency

enforced through dictate. The best type of consistency across teams

comes from most or all teams agreeing that a particular practice is a
good idea. The agile PMO facilitates this by making sure good ideas
spread rapidly among teams. Two practices they can use for this are
communities of practice and shared coaches.
Provide and maintain tools. In general, tool decisions should be left
to individual teams whenever possible. On occasion, a community of
practice might decide that there are sufficient benefits to choosing one
tool for all projects. As a last resort, tool decisions can sometimes be
made by the PMO, although this should be extremely rare. But, the
agile PMO can assist teams by acquiring the appropriate tools and
performing any configuration or customization necessary.
Coordinate teams. Because they work with individuals from many
different teams, PMO members are vital in coordinating the work of
separate teams. Someone from the PMO will often be the first to
notice when the work of two teams starts to diverge or overlap. PMO
members can provide value to teams by alerting teams to these
situations when they occur.
Model the use of Scrum. Through their intensive exposure to Scrum,
most agile PMOs quickly realize Scrums usefulness as a generalpurpose project management framework. At that point, many PMOs
choose to use Scrum itself to run the PMO. They plan monthly sprints,
conduct daily scrums, and so on just like any other team.
Work with other groups. The PMO can be of great assistance to
teams in working with other groups, especially human resources and
facilities. A PMO can help explain to the facilities group the negative
impact of spreading a team across two floors or of having
programmers and testers from the same team sitting separately. A

good PMO will work with human resources to remove from the annual
review process questions that discourage teamwork.
Renaming the Project Management Office

Many PMOs choose to rename themselves to better match their

revised role. Though there is no one standard name, I have heard
these most frequently: Scrum center of excellence, Scrum
competence center, Scrum office, and development support.
Many people have become cynical and suspicious of name changes
and of well-crafted names. That cynicism will be directed at the PMO if
it is renamed but remains otherwise unchanged. So, whatever it's
called, the PMO that supported the organization's sequential
development process will need to change more than just its name to
succeed with Scrum.
A PMO often has tremendous political clout and project experience.
Though an adversarial relationship might work for a while, teams that
have a PMO on board with Scrum not only avoid a possible source of
resistance but also benefit from having a powerful ally. When
possible, in transitioning to agile, choose t make friends rather than
enemies.