An old presentation I gave in 2004 on the subject of using eXtreme Programming values and principles to improve a broken analysis approach within a large programme of work. This is a Return of Experience, with examples and supporting data.

1. “eXtreme Analysis:
the road to Extreme Business Value”
XP Day
Thursday, 25th November 2004
Olivier Lafontan
Olivier.lafontan@egg.com

2.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

3. Profitable online
bank
More than 3
million customers
Highest traffic
financial portal in
Europe
79% owned by
Prudential
Operating in France –
La carte egg
Currently ranked as
the world’s largest
pure online bank
“We're an online financial services
provider, launched in 1998 with the
purpose of helping customers to
understand and manage their money
more effectively.
Introduction

4.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

5. Issue: “from the
money movement
request by a
customer up to the
moment we
confirm that
movement to
them, things can
go wrong and
sometimes do…
We have ways of
resolving all
issues of money
movement actually
going wrong.
However, this
exception process
is long, costly and
generates bad
customer
experience.”
Project Context
Project description Project Outcome Teams Budget Status
Acquire
Customers
Service
Customers
Develop
Customers
Egg: Process Mapping Level 1
Manage Customer Details
Manage Money Movements
Manage Servicing Enquiries
Service Customers: Process Mapping Level 2
Manage Money Movements: Process Mapping Level 3
Customers egg
Egg/customers
Request
Money
Movement
Resolve problems during Money Movements
Capture
Money
Movement
Request
Perform
Money
Movement
Confirm
Money
Movement
Project
description:
“We need to
ensure that from
the request to the
actual
confirmation, ALL
money
movements
happen correctly
and the first time
round. This will
eliminate time and
money spent on
the exception
process, and will
also improve our
customers’
experience of our
financial
services.”

6. Project Context
Project description Project Outcome Teams Budget Status
OPERATIONAL COST REDUCTION… by
Reducing number of Money Movements going wrong
Reducing cost of Resolving Exceptions when something goes wrong
Allowing customers to view a lot more on the web and not having to ring call centre
CUSTOMER EXPERIENCE IMPROVEMENT… by
Getting rid of Money Movements going wrong
Keeping customers informed a lot more of their money transfers
Reducing time to Resolve exceptions when they do occur
The primary stated outcome by Programme Management was
OPERATIONAL COST REDUCTION, with an upfront target for the project to
deliver 120 Full Time Equivalent’s (FTE’s) savings in operational costs.

7. Project Context
Project description Project Outcome Teams Budget Status
1 Project Manager
3 process architects
14 Business Analysts
Business
1 Outcome Manager
Total: 19 people
KeyUsersandCustomers
Grand Total for team: 35 people
Working in XP mode
IT
1 Project Manager
1 Solution Engineer Leader
12 Solutions engineers
2 QA specialists
Total: 16 people

8. Project Context
Project description Project Outcome Teams Budget Status
No actual budget figure will be
given in this case study as it is
sensitive information.
However, it was a multi-million
pound project.

9. Project Context
Project description Project Outcome Teams Budget Status
About 15 stories were delivered and
implemented LIVE from work done on
1st process analysed.
Resource plan in place to upsize the
IT Delivery team to 54 Solution
Engineers.
At which point I came in and replaced the IT Project Manager in charge
Altogether, there
were 82 sub-
processes to
review…
1 process analysed
generated 92
stories…

10.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

11. Issues we faced
Altogether, there were 82 sub-processes to review…
1 process analysed generated 92 stories…
About 15 stories were delivered and implemented LIVE
from work done on 1st process analysed.
Resource plan in place to upsize the IT Delivery team
to 54 Solution Engineers.
Facts
Mmmh. If all processes generate as many stories, we can expect a
total of 7544 stories… in 328 months time! (92 stories were written in
4 months…)
Without looking at our velocity, it looked like we did not have the
capacity to deliver stories as fast as they were produced. At this
rate, we will deliver all stories (7544) in 2011 months (in a given
period of time, we are delivering 6.13 less stories than were
written!!!)
Derived assumptions
“Gulp. Maybe I should not have accepted that
project. I’ll be doing this for life!”
Facts and assumptions Issues - Summary

12. Issues we faced
Facts and assumptions Issues - Summary
“Either we find a solution to these issues, or this
project will be a disaster…”
Out of these 5 issues, 3 were directly related to the way the analysis (getting your
story straight) was being performed. Issue number 4 also relate to the lack of capacity
from the Customer to pick the right stories to implement.

13.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

14. A solution: eXtreme Analysis
On http://c2.com/cgi/wiki?ExtremeProgrammingSystem, Ron Jeffries describes eXtreme
Programming. Some of what he says is in the left column below. What I mean by eXtreme
Analysis is in the right column.
Introduction What does it mean in practice?

15. A solution: eXtreme Analysis
Introduction What does it mean in practice?
In effect, that meant changing a few things
We will do everything following 4 principles:
simplicity, communication, feedback and courage
Team values
• The whole analyst team (17 people), will stop analysing
everything for the sake of analysing: they will analyse what
will generate customer stories that carry value – ONLY.
This is driven by the Outcome Manager and the stories he
produces.
• We will implement a heart beat for this process
• We will only plan and do what we can do
• We will work at a sustainable pace
New team core practices were also implemented
Sounds familiar?

16.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

17. Implementation
Run Planning Game: to Mapping Level 3
Outcome
Manager
Analysts Outcome
Manager
Present
Outcome
Stories
Estimate
Analysis
Tasks
Break
down
into
Analysis
Tasks
Set
Team
Velocity
Plan
Iteration
Entire
Team
Run
Analysis
Iteration 1
Run
Analysis
Iteration n
Write
outcome
Stories
Start
Iteration
Run
Analysis
Planning
Game
Write
Customer
Stories
Day 1
Run Stand
Up
Meeting
Day 2
Write
Customer
Stories
Day n
Run Stand
Up
Meeting
Day n+1
Run Show
and Tell:
Validate
Customer
Stories
Run
Iteration
Retrospec
tive
Close
Iteration,
go to next
Iteration
Run Analysis Iteration 1: to Mapping Level 2
Outcome of Analysis iteration…
A pack of
stories
with value!
that we can
take to the
Delivery
Planning
Game.

18.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

19. Results
We managed to run 3 Analysis
iterations of 2 weeks each….
63.5 FTEsTOTAL BUSINESS VALUE ANALYSED
… that produced 199 stories.
ALL carrying Business Value!
Total
Business
Value of:
57.6 FTEs
The “do the simplest thing that
could possibly work” also
produced 3 stories that did not
need IT resources to implement…
Total
Business
Value of:
5.9 FTEs
On getting your story straight… On the overall XP Project…
In comparison to the first 4 months of analysis, this shows that:
It took us 2.6 times less time…
to analyse/find 31.7 times more Business Value.

20. Results
On getting your story straight… On the overall XP Delivery (1)…
Outcome
Grouped stories per
dependency group (AREA),
Estimated ALL 199 stories,
Ordered AREAS per
effort/value ratio,
And…

21. Results
On getting your story straight… On the overall XP Delivery (2)…
A story/AREA/effort/Business Value profile of the project
(effort/value ratio)

22. Results
On getting your story straight… On the overall XP Delivery (3)…
Value/Iteration mapping (effort/value ratio)
Which allowed us to make the following points
and recommendations to the steering committee:

23. Results
On getting your story straight… On the overall XP Delivery (4)…
• There is not as much Business Value in this project as first thought (reminder: 120
FTEs was the target, we only managed to find and write stories for 57.6 FTEs)
• We have ordered the Story Areas per Value/effort ratio
• We can deliver 100% of 57.8 FTEs value in 10 iterations @ current team velocity,
but it might not be the best thing to do…
Points made to steering group:
All these recommendations were implemented with the following
results:
1. During delivery, we discovered additional business value in the
stories which brought the overall delivered Value to 62 FTEs.
2. We only used 2/3rd of the Budget in the end (overall actual project
expenditure).
3. Putting aside the first 4 months, we actually only used ½ the initial
agreed budget, for ½ the Business Value…
• Plan and budget for 5 iterations: this will generate 80% of the 57.8 FTEs we have
found
• Don’t waste another 5 iterations on the remaining 20% (as there are no MMF in
there…)
• Run the non technical stories implementation using Agile principles…
Recommendations made to steering group:

24.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

25. Retrospective
• The heart beat worked really well: the entire Analyst team enjoyed the management
discipline as much as we do (don’t we?)
• Simplicity, feedback, communication and courage (aggressiveness) worked well outside
IT (why not?)
• Defining outcome stories up front along with acceptance tests clarified the exact point at
which an Analysis story was delivered
• Working from stories themselves, they got better at writing stories for us ;-)
• There are Outcome smells, just like there are code smells
• Can’t estimate it? SPIKElyse it ;-)
What worked for us in XA
• Analysis task break down: we did not have enough time to become really good at it >>
the outcome stories estimates were not always accurate
• Analysts were a bit confused by the 2 roles they had to play on the project: 1 Outcome
Analyst and 2 XP Customer
• Tracking estimates and velocity was hard to achieve
• There was a lack of Business documentation (operations manuals, audit, …)
What did not work for us in XA
• Management principles from XP seem to work well for upfront value analysis. XP has
technical practices, what would the equivalent techniques be for upfront value analysis?
Puzzles for XA

26.  Introduction
 Project Context
 Issues we faced
 A solution:eXtreme Analysis
 Implementation
 Results
 Retrospective
 Q&A’s
Content

27. Q&As
Thank You for listening…
Any questions?

28. Appendices