BT

The Integration of Agile and the Project Management Office

Posted by Peter Schmidt on Nov 01, 2013 |

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 stand-up 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 aren’t 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 PMO’s 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.

ESI’s 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 project’s 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 Guard’s 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 team’s path. Lean project management requires a more hands-off approach than more traditional PMO’s 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 team’s 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 other’s existence to maximize their respective value to the enterprise without pulling each other down in the mire of conflicting priorities.

About the Author

Peter Schmidt, PMP, ACP, CPL, Services Director, ESI International, has over 20 years of project and program management experience in commercial, government and international projects. His high-level expertise centers on Agile project management, project portfolio management, planning, development and financing; and he brings operational and global consulting expertise that spans a broad range of functional and technology areas in such verticals as IT, energy, finance, housing, transportation, and communication.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Thanks for the integration thoughts by Dennis Rosen

" adopt innovative communication styles,..." - Yes! Collaboration is the key :)

RE: "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..."
Maybe, but I think that most projects will contain elements in each of the domains: simple, complicated, complex, and even chaotic. "Change happens" in any project; the Agile approach is better able to deal with uncertainty.

Article had so much promise but misses the mark in too many places by Steve Barrett

- blended, hybrid waterfall/agile approach
This promotes poor choices from the PMO, fine if integrating two projects using different methodologies, hybrid on the one delivery you are only scratching the surface for the value that agile provides, at the risk it's a failure which impacts further agile adoption, remember Shu-Ha-Ri, don't change the method until you understand the significance.

- The Agile approach is best suited for projects of an experimental nature incorporating new or untried technology,
It's best for all knowledge worker projects where change is a given, over manufacturing work which is repeatable and therefore predictable

- the PMO often aggregates velocity and burn rates
This could encourage the PMO to exhibit the wrong behaviour and use this incorrectly as a productivity measure, the article needs to explain motivations that make this potentially desirable, such as portfolio planning where attempts have been made to normalise estimates across teams

- 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.
Having long lived teams that stay together beyond projects is better, I don't like the idea of the PMO controlling resource allocations, the danger is that established teams are continually broken up so they have to go through forming, storming, norming and performing (if you are lucky) continuously, it also could encourage context switching. The outcome of both is keeping everyone busy but delivering less

- agile certifications
I don't think that would be #1 in my list, certifications do not prove your capability they only (or at least some of them) demonstrate a level of interest and application of effort. I am a PMI-ACP and I myself do not look for it when evaluating whether someone will good in a role, it's just an secondary indicator (a potential feather in the cap)

PMO as a Federation of Scrum Masters by David Etheridge

This is headed in the right direction but needs to go further. PMO must admit the only reliable delivery data is found inside the teams. As such, my PMO is a federation of scrum masters responsible for managing their team's slice of the enterprise portfolio. In the 6 levels of planning above, my scrum masters were already managing the data for levels 3-6, so adding data mgt for levels 1 and 2 added trivial overhead in return for tremendous team empowerment and visibility. (Its all in one system, each level nesting into the next.) In this way teams accept projects into their 12mo plan *exactly* the way they accept stories into their sprints. Execs see the data summarized at levels 1 & 2 which was captured and vetted by the teams/scrum masters themselves. Execs do experiment with higher order scenarios outside the teams but nothing is 'real' until it appears in reports from our common tracking system after being entered/vetted by the teams (scrum masters). This yields remarkable delivery rates because each team is the watchdog over its own roadmap commitments, escalating early and negotiating with stakeholders through the constant change. Stakeholders love the visibility. Teams love delivering on expectations. I'd like to know what you think. tinypmo.wordpress.com/

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT