PPM and Agile:

Realizing the Best of

BothWorlds
This white paper discusses the challenges of
integrating agile methods into a PPM framework
and how to deliver executive visibility into agile
projects without disrupting the culture and work
practices of an agile team.

WHITE PAPER
Contents
1. The Rise of Agile Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The Challenge: Integrating PPM and Agile Processes. . . . . . . . . . . . . . . . . . . . 4

2. Three Common Fallacies About Agile and PPM . . . . . . . . . . . . . . . . . . . . 5

Fallacy #1: Agile Projects Dont Provide Enough ExecutiveVisibility . . . . . . . . . 5

Fallacy #2: Agile Projects Dont Have Reliable Scheduled Finish Dates. . . . . . 5

Fallacy #3: Agile and Traditional Practices Arent Compatible. . . . . . . . . . . . . . 5

3. A PPM Framework that Integrates AgileMethods . . . . . . . . . . . . . . . . . . 6

Developing Standard Cross-Project Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Calibrating Metrics across Programs and Portfolios. . . . . . . . . . . . . . . . . . . . . 8

Creating a Single Source of Truth for Executive Reporting. . . . . . . . . . . . . . . 8

4. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 2
1. The Business Drivers for Agile Development

Waterfall and iterative approaches are giving ground to

much lighter, delivery-focused methods based on the
principles of the Agile Manifesto.
Forrester Research, 20101

THE RISE OF AGILE DEVELOPMENT

Agile development practices were introduced in the mid-1990s and have grown steadily
in popularity since the Agile Manifesto1 was published in 2001. Agile methods are
designed to adapt quickly to changing realities, whereas more traditional methods focus
on planning the future in detail. The introduction to the agile manifesto reads as follows:

We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left
more.

The agile manifesto continues to outline twelve principles, including a focus on customer
satisfaction, frequent software delivery, close cooperation between business people and
developers, and creating an empowered culture with motivated individuals.

In a recent survey completed by Forrester Research and Dr. Dobbs2, 35% of

respondents stated that Agile most closely reflects their development process, a number
that increases to 45% if you include other iterative approaches. Scrum is the most
popular agile methodology, however its common to find software development teams
mixing and matching specific agile practices to find a process that works for them.
Whether its introducing a daily stand-up meeting, writing story-based requirements,
targeting shorter iterations or assigning a product owner, the goal of agile techniques
is to create a culture of continuous feedback and a focus on delivering high quality
software that meets customer needs.

1 Visit agilemanifesto.org to read the original Agile Manifesto.

2 Forrester/Dr. Dobbs Global Developer Technographics Survey, 2010.

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 3
Organizations that have successfully adopted agile practices typically subscribe to the
following principles of agile development:

Empowered, self-organizing and self-motivated teams. Agile methods

encourage a more collaborative environment that is transparent and accountable.
Teams often develop a strong culture where individual contributors become true team
players. Roles are more fluid and there is a strong emphasis on self-organization
and managing responsibilities as a team. In addition, a bottom-up decision-making
process is favored where the team is empowered to make decisions.
Active user collaboration to guide requirements. Business users are expected to
work on a daily basis as part of the agile team. This ensures continuous feedback and
avoids the pitfall of a requirements vacuum where the development team delivers
functionality that does not meet business requirements.
A responsive, efficient development process (with less risk). Agile teams
embrace change and respond to new information, which is counter to traditional
project management goals of controlling change and keeping to a plan. The use of
a product backlog to prioritize work and delivering software iteratively helps avoid
unnecessary work and identify risks of project failure early in the process.
A focus on high quality, working software. Software is built and tested
continuously, often with automated processes, to catch defects early in the
development life cycle. Agile teams favor delivering software early and often
to ensure requirements can be validated. Working software is valued over
comprehensive documentation, which keeps the team focused on the end deliverable
rather than work products that are a means to an end in the development process.

THE CHALLENGE : INTEGRATING PPM AND AGILE PROCESSES

Many project portfolios now includes a mix of project types and methodologies, such as
traditional waterfall projects, agile-based projects, six-sigma projects and stage-gate
projects for new product development. Project management leaders have, for the most
part, embraced agile practices and have attempted to redefine their roles to focus less
on planning and controlling agile projects, and more on providing an environment to
allow agile projects to succeed.

However, even with this willingness to adopt agile, integrating agile projects into a
PPM framework has proved challenging for many organizations. Project managers
are being faced with different (and often conflicting) methodologies, metrics, and
controls. In addition, some teams are adopting hybrid processes that include elements
of waterfall and agile methodologies and are confused about how to rationalize
seemingly incompatible methods. To solve these challenges, PMOs require an updated
framework that incorporates agile practices, provides clarity to project teams on how to
communicate project health, and provides predictability and accountability to executive
stakeholders.

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 4
2. Three Common Fallacies About Agile and PPM
The agile movement has had a significant influence on best practices for project
management. However, some agile ideas about embracing change, just-in-time
planning, and eliminating hierarchical decision making have led to some misconceptions
about the compatibility of agile projects with PPM processes. Below are three common
agile fallacies (and why they are untrue) that have led to concerns over how to monitor
and control an agile project as part of a project portfolio.

FALL ACY #1:

AGILE PROJECTS DONT PROVIDE ENOUGH EXECUTIVEVISIBILIT Y
A large part of the popularity of agile is the belief that teams should be empowered to
make business decisions rather than relying on executive stakeholders for approval.
Empowering a team, however, does not mean they shouldnt provide timely executive
status reporting. The struggle many agile teams face is the requirement to provide status
reporting in a format that executives are comfortable with, but is inconsistent with agile
practices. For example, a requirement that an agile team maintains a separate task plan
to enable reporting on metrics such as percentage complete can negatively impact
the benefits of an agile approach. Instead, executives need to learn how to interpret
project status from an agile team rather than impose reporting requirements that are not
consistent with agile.

FALL ACY # 2 :
AGILE PROJECTS DONT HAVE RELIABLE SCHEDULED FINISH DATES
Although agile teams shy away from providing guaranteed delivery dates (given the
cone of uncertainty around a project), its a fallacy that an agile project cant provide a
scheduled finish date. If an executive hears that an agile team is only prepared to give
estimated delivery dates for the next couple of iterations, it should raise a warning flag
about the teams capability to build a credible releaseplan.

Its true that agile teams use just-in-time estimation for iterations and focus on
delivering business value incrementally, however release and roadmap planning is used
for longer range estimates. The use of epics (large stories) and themes (groups of
stories) can be used to estimate work that is still requires detailed scoping. To be able
to estimate with some degree of reliability, an agile team will need to have some degree
of normalization around the size of stories and understand their velocity (story points
delivered in an iteration).

FALL ACY # 3 :
AGILE AND TRADITIONAL PRACTICES ARENT COMPATIBLE
Its true that some agile practices have fundamental differences with some traditional
project management practices, for example the planning and executing process groups
in the Project Management Institutes (PMI) Project Management Book of Knowledge
(PMBOK). However, its untrue the two types of practices cant be combined to create a
powerful project management framework. For instance, agile practices are usually silent
on project intake or project initiation processes, and traditional practices for project cost,
communications and risk management are often more mature than the corresponding

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 5
 practices in agile. An experienced project manager can add practices from the PMBOK
or similar methodologies to support agile projects without disrupting the culture and
work practices of an agile team.

In the next section will discuss how to build a common PPM framework that provides
common metrics across both agile and traditional projects and enables agile projects to
be first class citizens of a project portfolio.

3. A PPM Framework that Integrates AgileMethods

A PPM framework typically includes processes for project intake and selection, project
approval and initiation, and project and portfolio monitoring, along with templates,
artifacts and metrics for the different methodologies used within an organization.
Anexample PPM framework is shown in Figure 1.

Business Prioritization and

Decision Criteria Resource Capacity

Active and Proposed Funded

Proposed Work Projects Projects

Reallocate Resources Traditional Projects

Remove Completed Projects Portfolio Health
Cancel Projects and Value Contribution
Sunset products Agile Projects
Exception Iteration Iteration Iteration
Management Actions Management

Figure 1, A Typical PPM Framework

Integrating an agile project methodology into a PPM framework is no different than

integrating a more traditional project methodology, with four exceptions:

1. Agile teams work best when executives and project managers dont stifle the agile
process. Imposing unnecessary stakeholder reviews, checkpoints and data capture
requirements on an agile project will reduce the effectiveness of the team. Of course,
if major decisions need to be made with executive input or the agile project has
dependencies on other projects, stakeholder meetings will be necessary, but these
should be the exception, not the rule.
2. Agile projects measure progressing story points complete or business value
delivered. This is a fundamentally different way of tracking progress than using a task
plan and measuring task hour completion. In addition, a project manager assigns

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 6
 tasks to owners in a traditional project, whereas agile teams are often self-organizing,
so tasks may be reassigned at any time by the team to ensure project delivery is
on track. This difference requires that metrics for project health and percentage
complete are tracked differently from projects based on task hours.
3. Given the task assignments within an agile team are dynamic, its unwise to assign a
resource part-time to an agile team as this breaks the self-organizing model. Instead
its better to treat agile teams as a unit and assign resources to them full-time (with
the exception of resources such as technical architects and DBAs, which are typically
spread over multiple projects).
4. Finally, regular reviews of agile projects are more focused on working software than
reaching pre-determined milestones or delivering project documentation. Reviews
should be tailored to the type of project to ensure they are valuable to the team.

DEVELOPING STANDARD CROSS-PROJECT METRICS

Once the differences with agile projects are understood, developing a PPM framework
with standard metrics that apply to both agile and traditional projects is important.
The five common metrics that enable executives to get visibility into project status,
regardless of the delivery method, are outlined below:

Scheduled Finish Date. Planned finish date is the estimate made at the inception
of a project for the planned delivery date, whereas scheduled finish date is the
estimate of a project finish date at any given point in time based on current data. For
a traditional project, this is based on the task plan and critical path for the project. For
an agile project, it is based on the release plan. Given a cone of uncertainty exists
regardless of project methodology, the accuracy of scheduled finish dates should be
comparable for both traditional and agile projects. Comparing scheduled finish date to
planned finish date will give an indication of the teams ability to estimate delivery dates
accurately.
Percentage Complete. Percentage complete provides an indication of project
progress. Percentage complete for a traditional project is calculated by summing
the hours for completed tasks and dividing by the total task hours for a project. In
contrast, an agile project progress is measured by story points delivered. Percentage
complete is calculated by story points accepted divided by total story points for a
project.
Scope Changes. Percentage complete gives an indication of progress, but does
not show if the scope is changing on a project. For traditional projects this is typically
represented by the number of change requests. For an agile project, it is typically
measured by the change in total story points over time.
Actual Cost vs. Budget. Both traditional and agile projects have capital and
operational expenses that are tracked. Actual cost vs. budgeted cost should be
reported, regardless of the project methodology. However, its not appropriate to
ask an agile team to track time at a task level to calculate resource costs. Instead,
resources should be dedicated to an agile team and costs calculated accordingly.
Project Health. Project health is a summary metric that indicates if a project is on
track, needs attention or is in trouble. This metric varies by organization and is
calculated using conditional logic based on the four metrics above, as well as other

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 7
 data such as outstanding issues. One of the simplest ways to calculate project health
is to compare actual percentage complete with the expected percentage complete
based on the start date and scheduled finish date (assuming the velocity of work
delivery across the project timeframe is uniform). A project health status of needs
attention or in trouble is often triggered when projects are not delivering business
value, there are significant scope changes, costs exceed budget or there are major
unresolved issues on the project.

Providing these metrics in a dashboard format using a PPM system enables executives
to quickly identify projects that require focus or intervention, regardless of the project
management methodology employed for its execution.

CALIBRATING METRICS ACROSS PROGRAMS AND PORTFOLIOS

These metrics provide a good way to provide a common scorecard for project
execution. One challenge to consider, however, is calibration across projects, programs
and portfolios. For projects based on task hours, calibration is not an issue because the
unit of progress is the same (hours). However, for agile projects, the unit of progress is
typically story points, and the definition of a story point may vary from project to project
based on how an agile team estimates work.

A common calibration technique is to bring agile teams together on a quarterly

basis and normalize story point size by picking sample stories of different sizes and
comparing effort. This can be done by comparing ideal days for a given story and
calibrating across different teams to provide guidance on story point size. If a scrum of
scrums exists, this technique will mostly resolve calibration issues at a program level.

A more challenging problem is when agile projects and traditional projects are combined
into a single program. Reporting on percentage complete on a program when the
underlying projects are using different units, such as task hours and story points, can
lead to inconsistent results. In this case, finding a common metric across projects
is advisable, such as function points or business value points. This requires an
organization with a high degree of PPM maturity, a well-defined methodology and strong
training programs to educate program and project managers.

CREATING A SINGLE SOURCE OF TRUTH FOR EXECUTIVE REPORTING

A Project Portfolio Management system is the best way to provide a single source of
truth for executive reporting and decision-making on a project portfolio. Integrating
agile projects provides three major benefits:

1. It provides complete transparency into agile project execution and avoids the issue of
a team sugar-coating project status if things are not going well.
2. It enables a common reporting framework to be enacted in the tools to ensure
consistency in project reporting.
3. It avoid manual data entry into the PPM system.

For mature agile teams, agile tool integration provides a way to use specialized agile
project management tools, while still enabling a single source of truth for project
portfolio reporting.

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 8
4. Conclusion
The rise of agile development practices is driving many benefits to organizations
by creating a culture of continuous feedback and a focus on delivering high quality
software that meets customer needs. Although some fallacies around agile development
exist, it should not deter PMOs and executives from encouraging agile adoption in their
organizations where appropriate. Project managers and PMOs should carefully consider
which projects are suitable for agile methodologies. They should also develop a PPM
framework that applies to both agile and traditional projects to enable executives to get
visibility into project status, regardless of the delivery method.

ABOUT DAPTIV
Founded in 1997, Daptiv is the leading provider of on-demand Project Portfolio Management
(PPM) solutions. Daptiv has helped thousands of companies improve their strategic planning and
business execution by offering adaptable PPM solutions and expert professional services. Daptivs
customers include world-class organizations such as Beam, Chase, Coach, Harvard University,
Honeywell, InterContinental Hotels Group, and Virgin Australia. For more information about
Daptivs PPM solutions, please visit www.daptiv.com.

1008 western avenue | suite 500 | seattle WA 98104 daptiv.com sales 1.888.621.8361 9