A Step By Step Guide for

Implementing Agile
CEB PMO Leadership Council
Please note that the CEB program names referenced in this document have changed since the time of publication.
1 | P a g e

A Step By Step Guide for Implementing Agile
Contents
Introduction ............................................................................................................................................................................................................................... 2
How to Use This Guide ............................................................................................................................................................................................................... 3
Overview Workflow for Managing Agile Projects .................................................................................................................................................................... 4
I. Introducing Agile to the Organization ................................................................................................................................................................................ 5
II. Running an Agile Project ................................................................................................................................................................................................... 7
III. Building the Scalable Agile Processes .............................................................................................................................................................................. 11

2 | P a g e

Introduction

Adoption of Agile development is accelerating. In 2009, 59 percent of organizations were using some Agile; by 2010 that figure had increased to 76 percent. A
shift in demand from back office to customer-facing applications is driving members interest in Agile development , amplified by growth in project demand
while IT staff resources remain flat, increasing experimentation in the business leading to instability in business requirements, and a need to keep pace with
the flexibility offered by software-as-a-service providers.

Although most companies are using some Agile, only 24% have been able to use it broadly. In our 2010 research, we are investigating how organizations are
building necessary skills and scalable processes to help you broaden the scope of your Agile implementation in the project portfolio.

Organizations that are able to scale Agile successfully realize benefits in terms of:
Faster, more frequent realization of business value
Improved software quality due to more predictable, less costly rework
Increased sponsor satisfaction due to the sponsors increased engagement and feedback with the project
Build adjacent resource skills over time due to responsibility-sharing on Agile teams
Increased portfolio-level flexibility and prioritization from the ability to conclude Agile projects without building every last requirement. Completion of
the highest value requirements can deliver the desired business outcome more efficiently.

This practitioner-driven brief provides step-by-step guidance for implementing Agile techniques at your organization across the following stages:
I. Introducing Agile to the Organization
II. Running an Agile Project
III. Building the Scalable Agile Processes
Helping PMOs and project managers to deliver Agile projects without compromising speed, flexibility or business outcomes is a major focus for the Council.
Wed welcome the opportunity to speak with you on how you are adapting your methodology to these changing circumstances, particularly to manage
projects using Agile or other iterative development techniques. Please contact us at kvaziri@executiveboard.com to set up a phone conversation with the
research team.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced
3 | P a g e


How to Use This Guide

We understand that within a single organization, Agile could have many meanings and myths. We use Agile an umbrella term to encompass dozens of
different techniques and disciplines, all aimed at the iterative development of software. Across Agile practices we have seen, common elements include:
1. A cross-functional team in which a development team collaborates with the business representative to evolve and a solution over the
development lifecycle.
2. Production-ready code at the completion of each iteration.
3. A test-driven approach that involves unit testing in each iteration.
4. An openness to business representative feedback and reprioritization.

This brief can serve as a checklist to identify key activities and decision steps that will set enable a successful Agile implementation across the organization. We
have broken down the Agile workflow into 24 key areas across the three stages of implementation.
We have also provided a compilation of our best practice resources for each of the 24 activities, along with tips on what to do and typical mistakes in
broadening the scope of Agile implementation.
We hope that PMOs would include these best practices in their guidance to PMs and their teams for how to run Agile projects. They will also help PMOs in
managing the cultural change around introducing a new methodology, and building the skills portfolio required to be more effective at Agile.


in this document have changed since the time of publication.
Please note that the CEB programnames referenced
4 | P a g e

Overview Workflow for Managing Agile Projects

I. Introducing Agile to the Organization II. Running an Agile Project III. Building the Scalable Agile Processes
1. How do we determine the organizational
need for Agile?
2. How do we gain sponsor buy-in and time
commitment?
3. How do we successfully manage the
required cultural change?
4. Which practices do we retain from the
Waterfall approach?
5. How do we assess Agile pilots readiness to
scale up?
6. Which best practices do we import from
Agile into Waterfall?
7. How do we assess the suitability of a project
for Agile?
8. How do we find an effective PM/Scrum
Master?
9. How do we build teams with the necessary
Agile skills?
10. When are we ready to add non-collocated
members to the team?
11. How do we improve collaboration of non-
collocated teams?
12. How do we rightsize sponsor and SME
input?
13. How do we estimate the total cost and
effort for the project?
14. How do we manage scope creep?
15. How do we deliver to on-time and on-
budget constraints?
16. How do we manage architectural Integrity
despite iterative release?
17. How do we establish the standard
vocabulary of Agile processes?
18. How should we prioritize a portfolio that
includes Agile projects?
19. How should we sequence release at the
portfolio level?
20. How do we roll up metrics from Agile
projects to the portfolio level?
21. How do we adapt portfolio sourcing
decisions for Agile?
22. How do we use Agile to manage products
across the full lifecycle?
23. How do we set an architecture strategy
which enables the Agile strategy?
24. How do we resource testing for Agile
projects?
in this document have changed since the time of publication.
Please note that the CEB programnames referenced
5 | P a g e

I. Introducing Agile to the Organization

1. How do we determine the organizational need for Agile?

Suitability Scorecard for Agile Development
DO determine your readiness for Agile based on
your project portfolio Agile suitability as well as
historical data on amount of functionality rarely
or not used at all. This will help you make a
business case for why Agile might be right for
your organization.
DONT assume Agile is synonymous with
lightweight project management. It actually
provides PMs with fewer optional deliverables
per release.
2. How do we gain sponsor buy-in and time commitment?

Streamlined Business Sponsor Onboarding

Embedding Customers in Rapid Development
Processes
DO train sponsors with PMs and developers on
basics of Agile when and how their input is most
needed.

DONT kick off the project until the project
sponsor nominates a delegate with decision
making authority for day-to-day project
operations. Youd want this delegate to
represent the stakeholder segment that has the
biggest to gain or lose by this projects outcome.

3. How do we successfully manage the required cultural change?

Agile Cultural Change Management

DO focus on understanding project teams
perception of change and anxiety points rather
than simply monitoring adherence to
deliverables and methodology. Focus change
management efforts on PMs and business
sponsors since their roles are affected the most
and are responsible for cascading change to
project teams and the end users.
DONT focus Agile training solely on the technical
aspects of Agile methodology; upskill the teams
on the required soft skills.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced
6 | P a g e

4. Which practices do we retain from the Waterfall approach?

Success Aligned Incentives

DO define the business objectives and high level
design/vision for the project upfront. Creating a
project plan upfront helps the team and business
partners to develop a common understanding of
project success.

DONT Allow Agile teams to neglect planning and
risk management. Agile and Waterfall when
done correctly use the same level of rigor but
applied in different activities or phases of the
lifecycle.

5. How do we assess Agile pilots readiness to scale up?

Agile Cultural Change Management

DO survey pilot Agile teams and key stakeholders
at project close to determine success with Agile
pilot projects and assess the impact of Agile on
the IT ecosystem to determine the scope of Agile
rollout.

DONT broaden the scope of Agile rollout
without considering the project management
maturity level of BUs, their success with pilot
Agile projects, PM familiarity and experience
with Agile, and resource pool structure and skills.

6. Which best practices do we import from Agile into Waterfall?


Project Managing to Business Outcomes

DO re-orient your project management focus
from execution success to business outcomes.
Involve stakeholders early and often, track and
report on value- (and not just execution-) based
progress metrics.

DONT assume your Waterfall PMs are incapable
of managing Agile projects. The best Waterfall
PMs display as much leadership, business
domain knowledge, and stakeholder
management skills as the best Agile PMs.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced
7 | P a g e

II. Running an Agile Project

7. How do we assess the suitability of a project for Agile?

Suitability Scorecard for Agile Development

DO choose Agile for a project that has high
visibility but moderately uncertain requirements
and average technical complexity.

DONT choose Agile for projects that will be
difficult to disaggregate into discrete or testable
stories. Remember that your people are often
your biggest bottleneck. If a PM is not
comfortable with Agile techniques, they will
default to Waterfall even when Agile/Iterative is
better suited for project context.

8. How do we find an effective PM/Scrum Master?

Project Manager Leadership Accelerator

Attributes of High-Performing Project Managers

Agile Cultural Change Management


DO rely on your best Project Managers to build
the Scrum Master/Product Owner pipeline. What
makes a PM effective (ability to manage
dependencies, stakeholder management, and
managing high performing teams) is not very
different from what makes a Scrum Master or
Product Owner effective.
DONT use PMs with command and control
behavior in the Scrum Master role. The Agile PM
should play the coach and enabler role, not the
taskmaster role.
in this document have changed since the time of publication.
Please note that the CEB programnames referenced
8 | P a g e

9. How do we build teams with the necessary Agile skills?


Standardizing Agile Flexibility

DO establish a Matchmaking Wall in a common
area where teams looking for coaching and
teams off erring coaching in specific areas could
find one another.
DONT focus on the technical capabilities of new
Agile teams at the expense of competency in
Agile project management and teamwork.
10. When are we ready to add non-collocated members to the team?

Managing Agile Work for Distributed Teams
DO add non-collocated resources to already-
established teams when the team demonstrates
stable velocity, is able to effectively
communicate, has an engaged product owner,
and fully understands business objectives for the
project.
DONT add more than one non-collocated
resource to the team at a time. There is evidence
that with addition of each non-collocated
resource velocity will have a dip before it
stabilizes again.

11. How do we improve collaboration of non-collocated teams?

Increasing Virtual Team Productivity
Making Agile Development Work for Distributed
Teams


DO measure level of teams understanding of
project goals, timelines, roles and responsibilities
to assess virtual team effectiveness. This will
enable you to enhance collaboration based on
team maturity and level of team distribution.

DONT perceive co-location as the prerequisite
for Agile. While co-location will make adoption of
Agile much easier, it is not an insurmountable
hurdle.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced
9 | P a g e

12. How do we rightsize sponsor and SME input?

Streamlined Business Sponsor Onboarding

Embedding Customers in Rapid Development
Processes
DO assess sponsors suitability to steward the
Agile project at kickoff based on historical data
on pattern of engagement.

DONT assume sponsors know when and how to
provide input because they attended the Agile
training. Refresh their memory at project start
using a short onboarding guide.

13. How do we estimate the total cost and effort for the project?

Predictable Agile Delivery

Estimation and Testing in an Agile Environment

DO assign percentage confidence level to the
estimates based on worst case, most likely, best
case scenarios. If confidence is less than 80%
suggest prototyping to improve estimates.
Otherwise assign a risk-adjusted contingency to
the project.
DONT rely on one estimation technique for the
project. Make sure the team is comfortable with
multiple methods (Poker estimation,
triangulation, etc) to help them produce better
estimates.

14. How do we manage scope creep?

Predictable Agile Delivery

DO define scope at a high level to secure
funding, but periodically revisit the relevance of
the business case and enforce prioritization of
backlog. Frontload pieces of functionality that
users can react to (e.g., interface, data displays,
reports) to address the I know it when I see it
nature of the client needs articulation. Allowing
users early on to see what capabilities they are
DONT treat all scope creep as bad. Good scope
change will help you build something that will be
more relevant to user needs and hence higher
user adoption and benefits realization. What you
need to protect your project from is effort creep:
building something that wont get used.
in this document have changed since the time of publication.
Please note that the CEB programnames referenced
10 | P a g e

Specialized Project Scoping

getting reduces rework costs since functionality
has not yet been integrated with many systems.
Build buy-in and create evangelists.
15. How do we deliver to on-time on-budget constraints?

Predictable Agile Delivery

DO build contingency buffers into the plan,
report velocity-adjusted estimates, and complete
rework before reporting completion of a feature
to set realistic expectations for total cost and
duration.
DONT use different people for effort estimation
over the course of the project. That way you can
predict velocity after the first few sprints.

16. How do we manage architectural Integrity despite iterative release?

Match Process to Project

DO estimate technical debt incurred by the
project by damaging EA and add it to the total
cost of the project.







DONT allow the architecture impacts emerge as
the project unfolds; instead try to figure out as
much as possible upfront.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced
11 | P a g e

III. Building the Scalable Agile Processes

17. How do we establish the standard vocabulary of Agile processes?

Standardizing Agile Flexibility
DO create an overall Agile competency model
that encompasses all skills and techniques of
iterative techniques, but take a flexible approach
to standardizing Agile skills.
DONT mandate that all teams use all practices in
the Agile competency model; rather, provide this
taxonomy as a toolkit for that helps them align
and rightsize methodology based on project
context.

18. How should we prioritize a portfolio that includes Agile projects?

Standardizing Agile Flexibility

Scrum-Based Agile Development
DO continually revisit the tradeoff between time
to market for (Agile or Waterfall) project
proposals and the effort/value needed to build
the tail end of requirements in the Agile story
backlog to inform prioritization conversations.

DONT give the prioritization authority only to
the business sponsor. Establish broader
governance above the individual business
sponsors to inform enterprise prioritization
conversations.

19. How should we sequence release at the portfolio level?

Standardizing Agile Flexibility
DO break down projects into benefit release
streams and reevaluate the value of benefits
after each release to frequently reprioritize
scope and control delivery risk across the
portfolio.
DONT just focus on assessing the project
delivery risk. Instead track project
interdependencies to objectively determine
whether to delay, monitor, review, or expedite
projects within a portfolio.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced
12 | P a g e


Program Interdependency Visualization
20. How do we roll up metrics from Agile projects to the portfolio level?

Predictable Agile Delivery

Leading Indicators of Project Benefit Realization

DO use program-level financial health metrics as
well as Agile specific metrics such as burn down
rate (plan versus actual) to flag executives about
potential risks and opportunities. Many
organizations use Earned Value methods to
standardize reports to senior management on
project health, irrespective of development
methodology.
DONT use sponsor satisfaction and execution
metrics such as schedule and budget compliance
as the only indicators of success for Agile
projects..Instead, identify and embed leading
indicators of value delivery within agile sprint
lifecycles and use them as trigger points for
reviews and reprioritization

21. How do we adapt portfolio sourcing decisions for Agile?


Managing Agile Work for Distributed Teams
DO add global resources incrementally based on
the team maturity and when the team velocity
has been stabilized. Treat additions to the
standing team as permanent investments, and
not as temporary enhancements to a project.
DONT just rely on time and material contracting
for longer-term contracts, given the uncertain
scope of Agile work. Instead use team velocity as
a benchmark metric to measure impact of
external resources on overall velocity and
determine a fixed contracting fee.
22. How do we use Agile to manage products across the full lifecycle?

Managing Agile Work for Distributed Teams
DO take a full lifecycle view to manage Agile
projects as products. Treat maintenance and
enhancements as requirements in the story
backlog.

DONT allow project teams to recreate
documentation. Instead, reuse and maintain one
version of the documentation during the entire
lifecycle of a product or program.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced
13 | P a g e


23. How do we set an architecture strategy which enables the Agile strategy?

Service-Oriented Architecture
DO build the enterprise architecture in reusable
and pretested components that are organized for
access/applicability and governed to drive
adoption/reuse.

DONT let the legacy environment limit the Agile
approach by neglecting to update their
interfaces.

24. How do we resource testing for Agile projects?

Centralized, Risk-Based Testing

DO estimate the probability of finding errors and
the total testing effort in FTE hours by taking into
account both the complexity of the test cases
and the testing environment.
DONT try to test everything at every iteration.
Instead, quantify the risk exposure to reduce the
testing coverage and inform the tradeoff
between testing cost and effort.

in this document have changed since the time of publication.
Please note that the CEB programnames referenced