1. Unfixing the Fixed Scope Project Using Agile Methodologies to Create Flexibility in Project Scope Jeff Patton Tomax Corporation Salt Lake City, UT Jpatton@tomax.com

2. 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. 3 The Iron Triangle says you can’t fix all three of Time, Scope and Resources Time Quality Resources Resources & Brook’s Law: “Adding resources to a late project makes it later.” Quality Scope

4. 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. 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. 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

7. 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. 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 trust The customers didn’t mind scope changes because they trusted us and felt involved Decoupling Features During Development Allowed Features To Be Dropped We 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. 9 Today’s Strategy: Build on collaboration & scope maleability to beat the iron triangle 1.Keep Design General And Scope Soft 2.Recognize Customers Aren’t Adversaries – Establish Trust 3.Write A Collaboration Plan  Collaborative Design & Scoping  Regular Progress Demonstrations 4.Phase Delivery 5.Plan To Drop Features: Decouple Design

10. 10 Thanks. Questions? No animals were harmed during the making of this presentation