Establishing the Agile PMO: Managing variability across Projects and

Portfolios

Ash Tengshe, Scott Noble

Capital One Auto Finance
Ash.tengshe@capitaloneauto.com, scott.noble@capitaloneauto.com

Abstract business value. Not surprisingly, the general perception

of IT in our customer’s minds wasn’t that good. So, the
Our Portfolio Management Office helps to balance the time was ripe for some positive changes to happen.
demand on the firm’s resources from multiple This is the story of how Capital One Auto Finance IT
competing and sometimes inter-dependent projects. division started the Agile journey; the first obstacles,
Traditional Project/Portfolio Management Office the continuing battles, the frequent wins and the
supports the Project/Portfolio Managers. As more and current state. Being a top-down implementation of
more of our Project Managers become Scrum Masters Agile, the interesting bits are in how the message was
and the Portfolio Managers becomes the Group Scrum spread, how an atmosphere of acceptance was created
Master, our Portfolio Management Office needed to and how the central PMO (Portfolio Management
become Agile itself. We converted our Traditional Office) was instrumental rather than detrimental in the
PMO that supported the Project Managers to an Agile spread, acceptance and support of Agile.
PMO that staffed experienced Agile coaches who We think there is lot to share with other companies
supported the different Portfolio and Agile Project embarking on this journey themselves and exchange
Teams. The services included conducting Agile notes with those who have been on this path for a
Training, starting up new Agile teams, encouraging while.
Team Empowerment, transforming existing roles,
artifacts and processes to become more Agile, 2. Our Agile Journey guided by the PMO
capturing metrics across Portfolio and Project Teams
and creating the Management reports. We are sharing It was late 2005 when the CIO, Dick Daniels,
the lessons learned and hopeful that it will benefit who was very supportive of trying out Agile in our
those starting on the Agile adoption journey. company, gave the green signal for hiring an Agile
Coach from outside and starting the first pilot Agile
1. Introduction project. At that time our entire division was using
methodologies based on waterfall and all the
Capital One Auto Finance is the nation’s deliverables, handoffs and reporting structures were
(USA) third largest non-captive auto lender. It is one of based on waterfall or phased approach.
the fastest growing divisions in the Capital One
Umbrella. Our IT Systems are the key to our business 2.1 Hiring an Agile Coach to get started
as every day thousands of loan applications get
evaluated and millions get serviced. IT is the key I (Ash) was hired as a coach to lead the Agile
driver to bringing new business initiatives quickly and adoption effort. It was a Herculean task for me as
reliably to market. We have a separate IT Department before this I was a Scrum Master with Thoughtworks
that is about 500 personnel strong not including and even though that had given me the most valuable
offshore teams. Agile learning experience in my life, one team is
Before we started on the Agile journey, our in-house different and an entire IT division is a different beast
development methodology options were pretty much altogether. I found an able supporter of Agile inside the
waterfall though you could get it in different flavors to existing PMO in Scott Noble. He had already paved
suit your project size. It was routinely looked upon as a the way for the first pilot project to start and was
bloated methodology and the IT Projects that followed excited to work with me on establishing Agile at
it routinely took a long amount of time to deliver COAF.

AGILE 2007
0-7695-2872-4/07 $25.00 © 2007
 excitement of trying something new, something
2.2 Our Agile Strategy different. The results were unknown. We needed a
pilot project.
Agile means a lot of things to lot of people. I
like Diana Larsen’s take on Agile [1]. Something like 2.4 Pilot Project and our first failure
“As long as a team is delivering incremental value
while working in fixed length iterations and then doing One of the Portfolio Managers was an early
retrospectives to improve the delivery…you can call adopter type of fellow. He wanted to try the ‘Agile’
that Agile”. We wanted to take a simple approach. Our thing with his team. We had a team of 5 to coach and
biggest gains were expected from collocation, show results. We got them an Agile room to co-locate.
collaboration, communication and incremental delivery The Product Owner from Marketing was to reside with
of business value. We chose Scrum as a starting point. them for 4 hours every day. We identified a Scrum
Scrum would address all immediate issues of team Master candidate and started coaching him and the
structures, real estate, team roles, customer team on Agile. As we started the Project, we hit one
collaboration, fixed length Sprints, frequent releases to after another obstacle that was a reminder of just how
provide value etc. We would definitely need the much waterfall our environment is and that we are
Extreme Programming side of things one day. We trying to “grow an avocado in Texas” (This is a
decided that day was later. We still think that is a right favorite quote of mine though I have heard second-
approach for a top-down implementation. hand and was credited to Kert Peterson [2]. He says the
The other important thing to remember about our soil has to be fertile and accepting for a seed to grow.
journey was that we had set a clear goal and captured Doing Agile in an extremely waterfall environment is
some good metrics to help us measure how we were like growing an avocado in Texas. It doesn’t grow well
doing. Before we started Agile Projects, we knew what at all.)
our Time-to-Market was and what our Customer- First, the team members weren’t allocated fully to the
Satisfaction rating was. So with Agile, we set a clear Project. One was 25%, one was 50%, another 40% and
goal. Reduce the Time-to-Market or Cycle Time for you get the idea. So what happened was that the
our Projects and Increase the Customer Satisfaction Product Owner would show up in the Agile room and
scores by increasing the collaboration and becoming a none (and I mean NONE) of the project team members
partner in their vision. Having these metrics helped us were around to collaborate. Any remaining excitement
a lot in showing the success of Agile. We highly the customer had soon drained away. The other
encourage anyone beginning their Agile journey to problem was the reporting structure and the
capture some key end-to-end metrics to show the expectations that go with it. Team members were still
increase in value. using the waterfall artifacts along with the Agile ones.
So, while they had a Product Backlog going, they also
2.3 The existing PMO kept the ‘Business Requirements Document’ for CYA
value. Same was the case with the System Spec. and
Interestingly, I was staffed in the COAF the Design Spec and Test Plan and on and on. So the
PMO, Portfolio Management Office. I had never team felt like rather than being Agile they were even
worked in a PMO before and in fact dreaded the slower than before. No wonder. When inquired why
central all-controlling authority that it had come to they felt the need to stick around with the phased
represent in other companies I had worked with before. documentation, they said that their Manager had given
The existing PMO staffed Project Planners, supported them the templates and those needed to be followed.
the Project Management Tools, supported the Portfolio So, we decided the next step was to talk to their
and Project Budget piece, owned the phased/waterfall manager’s and convince them of the non-value add of
methodology along with the templates and artifacts to these documents in the Agile environment. Easier said
be delivered with each phase, trained new Project than done! Some Manager’s were very open to change,
Managers on our tools and methodology etc. It was an others weren’t. We met the Analysis manager and
alien environment for me. Too waterfall like. presented him the book “User Stories Applied” by
So the first thing I looked for is internal acceptance and Mike Cohn [3]. He read it in a few days and
support. If we are going to deploy Agile through the immediately asked the analyst on the project not to
PMO here, are the people in the PMO supportive of the write the large requirement specification and instead to
idea in the first place? To my joy, the answer was an concentrate on getting better at writing User Stories.
astounding “Yes”. We even had one Certified Scrum Good stuff!
Master amongst our ranks! At that time it was the

AGILE 2007
0-7695-2872-4/07 $25.00 © 2007
 Needless to say, the first pilot project did not meet company. Once certified, the Agile coach not only
leave alone exceed our goal of reducing Time-to- continues to be a Scrum Master with their Project
market and increasing Customer satisfaction. But we Team, they also have objectives to expand the usage
learned some valuable lessons and had data to prove and effectiveness of Agile in the organization. The
that wrong implementation would cause disasters. Agile coach candidate selection, mentoring, testing and
A few ground rules had to be put in place. Waterfall certification are coordinated through the PMO. The
documentation had to go. Team members had to experienced or Senior Coaches are staffed in the PMO.
allocate full time to a team. Agile is different. Let’s not These coaches work on a ‘Program Backlog’ that
try to put a square peg in a round hole. includes things like starting new Agile teams,
mentoring Scrum Masters to be certified Agile
2.5 Training and Coaching through the PMO Coaches, Coaching Team Members, Training, Audit
Controls, Organization Impediments like approvals,
While we were starting the pilot Project, we artifacts, environments and other constraints etc.
put in place a training and coaching program. The The type of candidate we try to select for the Coaching
training was to be open to all. We started with Agile path is one who displays leadership skills, servant
101 and Agile 102 classes, broken into two because we leader mentality, less command and control behavior
wouldn’t get as many people to come for a long one and is focused on breaking down organizational
day class. The initial classes weren’t full. To build hurdles and carries credibility in the organization. At
interest and awareness, we teamed up with the same time we don’t want them to be too high in the
communications department and created posters, org. chart as they have to be on the team and provide
emailed full page ads to everyone and even started time to the release as well. We do recognize that the
awarding a certificate and 3 credits towards their PMI CIO is the ultimate Scrum Master and in that spirit, our
Project Management certification (bummer). Whatever CIO meets with the PMO Agile Coaches once a quarter
we had to do to get them in the class and understand to understand progress and impediments and help
and discuss the ideas, we did. The classes started being remove them.
full and in one year’s time, 250+ employees had Soon, we plan to have similar certification paths for the
attended the Agile training classes. This was way better Product Owners and Agile Managers.
than expected number. The feedback for the classes
also ranged from good to excellent. We had started Agile Training Frequency Attendees
generating some serious buy-in. People now wanted to Agile 101 Bi-weekly 250+
try this out. Agile 102 Bi-weekly 250+
The Agile Coaching path was a good approach and CSM 2 Day Class Twice/Year 40
something worth sharing too. We had created a Certified Product Owner Planned*
coaching path for people who had a passion for Agile Agile Manager Training Planned*
and a background in Project Management or had Table 1: Agile Training and Coaching through PMO
displayed the right characteristics for being an Agile
Coach or Scrum Master. Our Agile Coach path starts 2.6 Change in Traditional Roles and Authority
by a candidate getting the Scrum Master Certification.
After that he/she is mentored by an experienced Agile The one universal impediment when
Coach on active Agile Projects for a few months. This implementing Agile in a large organization is the
apprenticeship period lasts until the mentoring coach change it brings to people’s roles and the authority they
and another observing coach both decide that the exert in the organization.
candidate has developed enough understanding of One such area is functional managers. I do have to say
Agile and skills to lead a team on his/her own. At that that this is less of a problem in a top-down Agile
time the recommendations are submitted to the Agile adoption because their manager’s have already bought
Center of Excellence (yes, we have this too) and a into the idea. The thing you have to watch out for is
written test and a panel interview is setup. One has to internal resentment or private checkout. We
get 80% on the test and has to generate confidence in approached our functional and resource managers and
the panel on their Agile understanding and abilities so explained to them the Agile philosophy. Instead of just
that they can certify the candidate as an Capital One saying that they don’t get to review and approve
certified Agile Coach. If we continue doing great everything, we showed them how in an incremental
things with Agile, we hope this certification will carry environment, it wouldn’t even be possible for a team to
some weight in the industry☺. Certification has do that. How (and when) do you approve the business
brought focus to Agile knowledge leadership in the requirements when the Product Backlog is a living

AGILE 2007
0-7695-2872-4/07 $25.00 © 2007
 artifact? Instead, they were asked to be more involved business was prioritizing and could check on the status
in the planning and review meetings and to have a of the completed or in-progress Projects.
conversation with their direct reports every Sprint to Each Portfolio also put in place 2-3 Agile teams in
understand their obstacles, helping them be fast and place for the entire year. The core team members were
efficient and enabling their growth as a Team Member. fixed and some specialists could be added for any
The people who refer themselves as ‘Tech Lead’ or Release or Sprint as required. These Agile Teams were
‘Lead something’ are another barrier to being an fully cross-functional units with analysis, development
effective Agile team. The PMO coached the team and testing skills. Also at this time, a dedicated test
members that they can still be leaders based on their environment or region was created for each portfolio
actions and don’t have to carry the title with them. The team. These teams were soon called ‘Release Teams’.
key initiative in creating a level playing field was the Each team had their own Product Backlog that was fed
increased focus on ‘Team based performance’. We from the Portfolio Backlog. The Release teams
realized that HR did not prevent us from moving “pulled” from the Portfolio Backlog as they had
towards team based vs. Individual performance capacity in their Sprints.
appraisals. All we really had to do was generate the The trick with the Portfolio Backlog was to have one
buy-in from the Management and increase the weight Product Owner for that backlog. This was tough
on team based performance objectives in the goals and because the Portfolio Backlog contained Projects from
development plans of our employees. different sub-teams in the line of business that had
Some key artifacts the PMO produced that would help different stakeholders and interests. For one Portfolio,
the teams were a new and lean ‘Approval Matrix’ that the line of business sponsor assigned one person in
would show the artifacts and who has the approval charge of the Project prioritization and in case of
authority. Needless to say, the Agile matrix looked another Portfolio a committee of three customers was
much lighter than the Waterfall one and most required to do the prioritization every month.
approvals rested within the team, either with the
Product Owner or the Scrum Master. Be wary of
people who will put up walls based on excuses of
‘audit’ and ‘manager direction’ to not become a true
‘Team Member’. Understand the segregation of duties Team 1 Product Backlog
control well to be able to reply to these people
knowledgeably.

2.7 Creating Portfolio Work Control System

Portfolio Backlog Team 2 Product Backlog
Once the Agile teams started understanding Figure 1: Portfolio Backlog “pull” system in action
the methodology better and delivering value frequently
to the customers, our next task was to drive higher The way we solved the problem of too many Projects
Portfolio efficiency. The different customer facing in flight at the same time and thus facing environment
Portfolio groups each had multiple Projects going on at bottlenecks was by creating a scheduled Release
any given time. Because of this, there was a resource process. So, now we had a standard ‘Project’ process,
crunch and people used to be split up across Projects. one where the Project is a Backlog of User Stories and
Also, there was a lot of work-in-progress with less Releases are when the Customer decides that they have
focus on completing any one Project. Also, due to the a working releasable set of features ready. We also had
randomness of the implementations, the test and pilot a ‘Scheduled Releases’ process where a team has a
environments experienced spikes of usage and became scheduled release every 2 months to production and the
a roadblock quite often. Frequent Production changes Customer can prioritize what is important to be
were not enjoyed by the Business customers either. released in the next 2 months. Of course, this process
To address all these issues, we came up with a Lean- works for us because there are a large set of small
Agile 1-2 punch idea. Each Portfolio created a enhancement type Projects in our Portfolio. This kind
‘Portfolio Backlog’ that has as line items ‘Projects’ of scheduled Release process eliminates the need to
that the customers were prioritizing. Along with create a new Project for each of these enhancement
Projects, the Portfolio Backlog could also have one off type efforts and carry the overhead of paperwork,
enhancement requests or maintenance type items. The controls and activities involved in a Project. There
beauty was that this gave the line of business executive were many small enhancement type items that the
sponsor a consolidated view of the Projects their line of customers wanted IT to do but were not prioritized

AGILE 2007
0-7695-2872-4/07 $25.00 © 2007
 earlier. This was due to them not being large enough to understand value delivered per Sprint or Release or
be Projects. These now found their way into the Sprint something like that until the entire Project is delivered.
capacity and got delivered. Also, the scheduled
Releases meant that the Customer could anticipate a Metric
production release from each team every 2 months. By Time-to-Market
staggering the Teams, there was a Release every month Customer Satisfaction
for the Customer and a new Release was about to start Value Delivered per Release
within the next 30 days that could work on their new Table 2: Recommended End-to-End Metrics
requirements. This has worked beautifully for us and is
highly recommended if you have lot of small 2.9.2 Roll up of metrics to Executive Management
enhancement type of work.
As mentioned in the paragraph above, the key
2.9 Metrics: Backing up the Success Story metrics like Business Value, TTM and Customer
Satisfaction can be rolled up to the Executive
2.9.1 Measure stuff that matters Management for periodic review. The problem starts
when one rolls up the ‘Agile’ metrics like Velocity or
We started with a goal to reduce our Time-to- Drag Factor. This is because these metrics are localized
Market and increase our Customer Satisfaction. After in the context of the particular Team and Project. Here
40+ Agile Projects completed in the last one and half I would advise taking the approach suggested by Mike
years, we can confidently say that we have achieved Cohn in his ‘Agile estimating and planning’ classes
what we set out to do. Though the journey has just where he asks different teams to use different scales for
begun, the numbers so far are impressive. Our Story Points thus rendering any comparison pointless.
Customer Satisfaction is very high. We survey our Well, still, we had two demands from stakeholders that
customers after and during every active Project and use we wanted to meet. One was from the IT Management.
a standard scale for scoring the Projects. All our Agile They wanted to understand if there was a way that they
Project customers surveyed so far have reported 100% could know which teams are doing better and which
customer satisfaction with the Project planning, ones are struggling relatively. And second was from
execution, cost management, collaboration and results. our Customers who said that since scope can be
This is highly encouraging for us. It validates our negotiated in Agile to meet the time and cost, how do
initial belief that “Customer Collaboration over we know we did well or didn’t. My first reply is
Contract Negotiation” [4] will bring about great results. always to ask “Did you get the value you expected out
The other metric Time-to-Market has seen great results of the Project?” According to me that is the best metric
and controversy too. We now deliver our Projects to have. We also do use Function Points, which is
faster by 50% using the Agile methodology. This great interesting because most Agile folks think it is not
result is because of increased focus on delivering value compatible with the Story Points type of Agile
on the current Project than spending time planning the estimation techniques. We use FP to initially take swag
next one. Dedicated teams and focused Product Owner at size and cost so that the Portfolio can prioritize the
are the largest contributors. Project in the Portfolio Backlog. This is done even
before the Team gets their hands on the Project. So, it
Time-to-Market Customer Satisfaction does not interfere with the Agile estimation techniques
Improvement Rating but it does give us a better handle on the initial
50% 100% estimate and also on the ‘size’ of the scope delivered. It
Figure 2: Agile Success Story through Metrics is also one of the metrics (along with TTM, Customer
Satisfaction and Value Delivered) that can be rolled up
Not that we didn’t have other metrics. We have plenty. to the Management. It may even help show that Agile
Some Project level metrics we have or had at one time is delivering software faster than our other waterfall
with Agile are Velocity, Function Point Productivity, based approaches.
Drag Factor trend, Stretch Factor, Commitment Index,
Volatility Index etc. Remember though that we never 3. Conclusion
lost focus on the two that matter to us. We would love
to have a ‘Value Delivered’ metric added to the two we The bottom line message of this experience
have as end-to-end metrics but right now we are not report is that anyone starting their Agile journey,
there. That is because the Project value is not broken specially in a top-down approach, should leverage their
down to the Epic/Story level and hence it is hard to PMO. The PMO is looked upon as the guiding body in

AGILE 2007
0-7695-2872-4/07 $25.00 © 2007
 terms of Project, Program or Portfolio Management. champion from senior management who will sponsor
Working with the PMO you can create a training the effort. From our experience we can say that the
program, mentor Agile Coaches and train the current support that the folks on the ground will need as you
Project Managers. PMO can retool the current Project transition to Agile can be best provided by an Agile
Management toolkit to be more Agile compatible. It PMO. Ultimately, deploying Agile successfully in an
has the authority or the influence to get rid of detailed organization depends on many different factors. Don’t
Project Schedules and Gantt Charts and to make the let the PMO be a hurdle in that journey, make it a
timesheets easier to manage. PMO can run efforts to partner!
lean the documentation while ensuring that adequate
controls and governance practices are being followed 10. References
by Projects. The PMO can look into the right kind of
metrics to be captured and can put processes in place to [1] Diana Larsen, FutureWorks Consulting, Notes from
roll it up to the Executive Management. In summary, online blog
the PMO is a very effective group through which you [2] Kert Peterson, kertpeterson.com, Notes from his Certified
can bring agility to the organization. What you will Scrum Master Training Class
need is the right kind of people in the PMO who have [3] Mike Cohn, User Stories Applied, Addison Wesley
an open mindset and a will to make things better for Professional, March 1, 2004
[4] Agile Alliance, Agile Manifesto, Snowbird, UT, 2001
the Organization. It should also have a strong

AGILE 2007
0-7695-2872-4/07 $25.00 © 2007