unfixing the fixed scope project using agile methodologies to create flexibility in project scope...
TRANSCRIPT
Unfixing the Fixed Scope Project
Using Agile Methodologies to Create Flexibility in Project Scope
Jeff PattonTomax CorporationSalt Lake City, UT
2
We sell fixed-time, fixed scope projects to chain retailers Brick & mortar chain retailers want fixed delivery
dates Busy & slow seasons – high risk installing during
busy seasons Large numbers of physical locations High rollout & training costs Desire to pre-schedule training and rollout resources
Board-of-directors’ signature means fixing scope Cost justification for the project = required ROI Features selected for their ROI Features fixed into original contract bid Although our product is “shrink-wrapped”, most
customers require some custom development – “gaps”
3
The Iron Triangle says you can’t fix all three of Time, Scope and Resources
Time
QualityResourc
esResources & Brook’s Law: “Adding resources to a late project makes it later.”
Quality Scope
4
We decided to focus on understanding scope and tracking progress better. Acquire a Better Understanding
of Scope Employ Interaction Design
Guidelines Usage-Centered Design
Collaborative U-CD Sessions for Requirements Gathering and Scope Definition
Acquire Better Understanding of Ongoing Progress Scrum Style Iteration Followed
by Customer Demonstration XP-Style Velocity Calculation and
“Yesterday’s Weather” Estimation.
Increase Quality to Avoid Rework XP Style Automated Unit-Test Coverage, Refactoring, and
Pair Programming
Collaborative U-CD Session
5
Our techniques unexpectedly improved our prioritizing & measuring progress
Interaction Design Helped With Prioritization
XP Estimation Helped Attach Suitable Value To Features
Iterative Development Helped Us Understand Progress
Role model with high priority roles marked.
6
Still falling behind, we shifted to “phased” delivery (a.k.a. incomplete delivery :-) We concluded that not all the “required”
scope could be completed on time.
We split the delivery into 2 phases! Deliver high-
priority features in phase I
Defer lower priority features to phase II
Ron Jeffries shows ROI For Frequent Release
Total ROI for Early Phases Releases vs. Single Release
-1000
-500
0
500
1000
1 2 3 4 5 6 7 8 9 10 11 12
Month
RO
I in
Th
ou
san
ds
of
Do
llar
s
Single Release
2 Phased Releases
2 Phases, Only 1 Released
7
The customer found more high-priority features; Phase I “succeeded” somehow. We released Phase I, tabled Phase II:
We included the high priority features identified late
We dropped the lowest priority features& no one seemed to notice their absence !
Did we succeed or did we fail? We “failed” to meet our original contract
scope . . . We “succeeded” in the customer’s eyes
(got paid and the customer seems happy.)
8
Success came from collaborating with the customer and decoupling features*We thought we succeeded by tricking** the
customer into changing scope(**”I do not think that means what you think it means”)
Collaborative design & scoping sessions built customer trustThe customers didn’t mind scope changes because they
trusted us and felt involvedDecoupling Features During Development Allowed
Features To Be DroppedWe were able to cut scope late in the release cycle
because we’d successfully decouple feature design
*Alistair Cockburn, 2003**Inigo Montoya, The Princess Bride, 1987
9
Today’s Strategy: Build on collaboration & scope maleability to beat the iron triangle1. Keep Design General And Scope
Soft2. Recognize Customers Aren’t
Adversaries – Establish Trust3. Write A Collaboration Plan
Collaborative Design & Scoping Regular Progress Demonstrations
4. Phase Delivery5. Plan To Drop Features: Decouple
Design
10
Thanks.
Questions?
No animals were harmed during the making of this presentation