Zen and the Art of Software Quality Jim Highsmith Director, Agile Practice & Fellow Cutter Consortium ©2009 Jim Highsmith
Agile Books by Jim Highsmith
NEW RELEASE © 2009 Jim Highsmith
2
“There is no more Normal” “Without exception, all of my biggest mistakes occurred because I moved too slowly.” --John Chambers, Cisco CEO, Business Week, March 23, 2009. “There is no more Normal.”
“He [Chambers] also radically changed the way he managed, turning a command-and-control hierarchy into a more democratic organizational structure.”
© 2009 Jim Highsmith
3
Strategic Agility Adapting to Change over Conforming to Plans Conform
Bu S t sin ra es te gy s
Value
Business Week,
The Case for Agile
Adapt
“There is no more Normal”
World View
March 23, 2009. Ex St ecu ra ti te on gy
of e r su ess a Me ucc S
Business Goals Organization
Product Backlog
Process
Product Management Team Product Roadmap
CAPABILITY 1
CAPABILITY 2
Feature 1
Feature 2
Feature 3
Story 4
Story 7
Release Management Team Release Plan
Feature Team Story 1 Story 1
Quality © 2009 Jim Highsmith
Constraints
Story 4
Story 7
Story 2
Story 5
Story 8
Story 2 Story 3
Story 5 Story 6
Story 8 Story 9
Story 3
Story 6
Story 9
Iteration Plan
Agile Values
4
A Measure of Success
“I recently asked a colleague [CIO] whether he would prefer to deliver a project somewhat late and over-budget but rich with business benefits or one that is on-time and underbudget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on-time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not.”
Cutter Sr. Consultant Helen Pukszta © 2009 Jim Highsmith
5
Mixed Messages
Conform to Plan
© 2009 Jim Highsmith
Be Flexible
6
Measuring Agile Success Measurement concepts Quality Value The Agile Triangle
© 2009 Jim Highsmith
7
Measurement Concepts
© 2009 Jim Highsmith
8
A Waterfall Failure
In Artful Making, Harvard Business School Professor and Cutter Fellow Rob Austin and coauthor Lee Devin discuss a US $125 million IT project disaster in which the company refused to improvise and change from the detailed plan set down prior to the project’s start. “Plan the work and work the plan” was their implicit mantra. And it led them directly to a costly and destructive course of action.… We’d all like to believe that this kind of problem is rare in business. It’s not.”
© 2009 Jim Highsmith
9
Standish Reports Standish Group “Chaos Reports”
• 1994 — 82% challenged or failures • 2001 — 72% challenged or failures • 2009 — 68% challenged or failures Definition of project “success”
• Successful: on time, on budget, all specified features; • Challenged: completed and operational, but over budget, late, and with fewer features and functions than initially specified; • Failed: canceled before completion or never implemented.
The Standish data are NOT a good indicator of poor software development performance. However, they ARE an indicator of systemic failure of our planning and measurement processes. © 2009 Jim Highsmith
10
Our Current Environment Conformance to Plan (schedule, scope, cost) is the norm for
measuring success. Schedule is more important than customer value. Our measures restrict agility and innovation.
© 2009 Jim Highsmith
11
Conceptual Background Sources Beyond Budgeting: How Managers Can Break Free from the
Annual Performance Trap (2003), Jeremy Hope and Robin Fraser. Measuring and Managing Performance in Organizations (1996),
Rob Austin.
© 2009 Jim Highsmith
12
Conceptual Background “Budgets have since been hijacked by a generation of financial engineers that have used them as remote control devices to ‘manage by the numbers.’ They have turned budgets into fixed performance contracts that force managers at all levels to commit to delivering specified financial outcomes, even though many of the variables underpinning those outcomes are beyond their control.” -- Jeremy Hope and Robin Fraser
© 2009 Jim Highsmith
13
Beyond Budgeting: Principles Provide a governance framework based on clear principles and
boundaries. Create a high-performance climate based on relative success. Give people freedom to make local decisions that are consistent
with governance principles and the organization’s goals. Place the responsibility for value-creating decisions on frontline
teams. Make people accountable for customer outcomes. Support open and ethical information systems.
© 2009 Jim Highsmith
14
Conceptual Background Measuring and Managing Performance in Organizations (1996),
Rob Austin: “If there is a single message that comes from this book, it is that trust, honesty, and good intentions are more efficient in many social contexts than verification, guile, and self-interest.”
© 2009 Jim Highsmith
15
Austin — How Measurement Systems Become Dysfunctional Step 1: Measurement system installed. Step 2: Performance tends to improve while people figure out the system. Step 3: People, under pressure, focus on measurement goals rather than outcomes. (Always a disconnect between the desired outcome and the measurement. Example: (1) productivity; lines of code. Step 4:
Metric
Performance measurement
Desired Outcome
Time © 2009 Jim Highsmith
16
Dysfunctional Measurement Systems
“the implementation of more sophisticated measures caused more sophisticated dysfunctional reactions.” Those being measured “can increase their rewards if they can successfully obliterate the correlation between true output and measured performance.” -- Austin
© 2009 Jim Highsmith
17
Agile Measurement — Goals To focus on desired strategic or tactical outcomes. To encourage teams to perform at a high levels of output.
© 2009 Jim Highsmith
18
The Agile Iron Triangle
Traditional Iron Triangle Scope
Cost
© 2009 Jim Highsmith
Schedule
Agile Iron Triangle Cost
Scope
Schedule
19
Changing to Outcomes
The Traditional Iron Triangle
The Agile Triangle
Scope
Value
Cost
© 2009 Jim Highsmith
Schedule
Quality
Constraints (scope, cost, schedule)
20
The Agile Triangle Value (Releasable Product)
Quality (Reliable, Adaptable Product)
© 2009 Jim Highsmith
Constraints (cost, schedule, scope)
21
Quality
© 2009 Jim Highsmith
22
Delivering Legendary Quality What is Quality? How do we manage for Quality? How do we measure Quality? How do we measure success
in Agile organizations?
© 2009 Jim Highsmith
23
What is Quality?
“Quality is the continuing stimulus which causes us to create the world in which we live.” “Quality… you know what it is, yet you don’t know what it is.” Robert Pirsig, Zen and the Art of Motorcycle Maintenance (1974)
© 2009 Jim Highsmith
24
The Dichotomy of Quality Intrinsic or Extrinsic? • Does quality exist in the things we observe or is it subjective, existing only in the eye of the observer?
The “House of Cards”
“You take your analytic knife, put the point directly on the term Quality and just tap, not hard, gently, and the whole world splits, cleaves, right in two—hip and square, classic and romantic, technological and humanistic—and the split is clean.” —Robert Pirsig
Zen and the Art of Motorcycle Maintenance (1974)
© 2009 Jim Highsmith
25
What is Quality? “Quality is conformance to user requirements.”
—Phillip Crosby, Quality is Free (1980s) “Quality is the absence of defects that would make software stop completely
or produce unacceptable results.” —Capers Jones, Applied Software Measurement (1991) “Quality is achieving excellent levels of fitness for use, conformance to
requirements, reliability, and maintainability.” —Watts Humphrey, Managing the Software Process (1980s) “Quality is value to some person.”
—Jerry Weinberg, Quality Software Management (1992) “Quality is customer expectations delivered.”
—Internal company definition
© 2009 Jim Highsmith
26
The Dichotomy of Quality A false dichotomy?
Extrinsic Quality = Value Total Quality Intrinsic Quality = Quality
© 2009 Jim Highsmith
27
Is Intrinsic Quality Important? Leading edge enterprises employ technologies that can approach
99% cumulative defect removal rates. The norm for US firms is a cumulative defect removal rate of 75%. A cumulative defect removal rate of 95% on a project appears to
be a nodal point where several other benefits accrue. For projects of similar size and type, these projects: • have the shortest schedules. • have the lowest quantity of effort in terms of person-months • have the highest levels of user satisfaction after release. • —Capers Jones, Applied Software Measurement (1991) Remember this number
© 2009 Jim Highsmith
28
Instruments Co. From Technology to Customer Focus Overhaul the entire product development process Average results from 6 before- and 6 after-Agile projects
Project Cost Project Schedule Cumulative Defects Staffing
© 2009 Jim Highsmith
Previous Performance
Current Performance
Percent Improvement
$2.8 Million
$1.1 Million
-$1.7M (-61%)
18 months
13.5 months
-4.5 mo (-24%)
2,270
381
-1889 (-83%)
18
11
-7 (-39%)
Source: Michael Mah, Cutter Consortium and QSM Associates29
Software Company I Team about 35 people > 1million LOC, >17,000 automated tests
Industry Average
Current Performance
Project Cost
$3.5 Million
$2.2 Million
-$1.3M (-37%)
Project Schedule
12.6 months
7.8 months
-4.8 mo (-38%)
2,890
1,450
1,440 (-50%)
35
35
na
Cumulative Defects Staffing
Improvement
Source: Michael Mah, QSM Associates © 2009 Jim Highsmith
30
Software Company II
Team about 100 people, highly distributed team
Database: 7,300 projects, 500+organizations, 18 countries: PI among the very highest recorded Industry Average
Current Performance
$5.5 Million
$5.2 Million
-$.3M (-5%)
15 months
6.3 months
-8.7 mo (-58%)
Cumulative Defects
713
635
78 (-11%)
Staffing
40
92
+52 (+130%)
Project Cost Project Schedule
Improvement
Source: Michael Mah, Cutter Consortium and QSM Associates © 2009 Jim Highsmith
31
Productivity Productivity Indexes Index (PI) Industry values
Information
Business Scientific System
Engineering
Process Control Telecommunications Command and Control Real Time
Real Time
Avionics Microcode 0
2
Provided by BMC Software, Inc. 32 © 2009 Jim Highsmith
4
6
8
10
12
14
16
18
20
22
24
26 28
Productivity Index (PI) w/ ±1 Standard Deviation 32
Why is Technical Quality so Important? The Impact of code quality on testing Error Location Dynamics Error Feedback Ratio Technical Debt
© 2009 Jim Highsmith
33
The Impact of Code Quality on Testing
Development: 10 days, 4 people, 4 KLOC, 1 d/KLOC
Development: 10 days, 4 people, 4 KLOC, 15 d/KLOC
Test time= 2 days
How long to test? Assume ½ day to find & fix per defect.
Test time= 30 days
Outcome: no time to finish testing, technical debt increases!
© 2009 Jim Highsmith
34
Error Location Dynamics
64 56
Difficult errors take longer to find:
48 40
Errors Located
1 hr/d to 50 hr/d
32 24 16 8 0 0
2
4
6
8
10
12
Time
© 2009 Jim Highsmith
35
Error Feedback Ratio The Thetime timeto tofinish finishremoving removingerrors errors isiscritically dependent on the critically dependent on theerror error feedback ratio. The three simulations feedback ratio. The three simulations differ differonly onlyinintheir theirfeedback feedbackratios. ratios. AA20% difference in feedback 20% difference in feedbackratio ratio leads to an 88% difference in leads to an 88% difference in completion completiontime, time,but butthe thenext next10% 10% increase increaseleads leadsto toaa112% 112%increase. increase.
ERROR FEEDBACK: Errors put into a system when attempting to correct other faults. ERROR FEEDBACK RATIO: The number of problems created per fix. EFR = ERRORS CREATED / ERRORS RESOLVED © 2009 Jim Highsmith
36
Technical Debt
Cost of Change (CoC)
Customer Responsiveness
Actual CoC
Once on far right of curve, all
choices are hard If nothing is done, it just gets
worse In applications with high
technical debt, estimating is nearly impossible Product Release
Technical Debt Optimal CoC
1 2 3 4 5 6 7 8 Years © 2009 Jim Highsmith
Only 3 strategies
• Do nothing, it gets worse • Replace, high cost/risk • Incremental refactoring, commitment to invest
37
Why Intrinsic Quality is so Important The impact of code quality on testing—potential exponential
increases in testing time Error location dynamics—difficult errors take much more time Error feedback ratio—bad fixes can cause catastrophic dynamics Technical Debt—the above create a vicious cycle of increasing
technical debt, increased pressure, and further quality degradation
© 2009 Jim Highsmith
38
Agile Virtuous Cycle Technical agility creates a virtuous cycle of ever higher quality
code and tests. Improves schedules. Reduces costs.
© 2009 Jim Highsmith
39
Value
© 2009 Jim Highsmith
40
Value Strategies Define a releasable product Manage the value-cost ratio Calculate Feature/Story Value
© 2009 Jim Highsmith
41
Reducing Cost and Scope Paul Young, VP Business Capabilities & Integration, MDS Sciex. Presentation at 2005 Information Management Forum. For a project, there might be a user requirements list of between 50
and 200 items. They tell their users, “Which three to you want to do first? We’re going to give them all to you, but they’re going to come out one at a time. Which three do you want first?”
“The most interesting thing I learned—I was totally shocked by
this—was by the time you get to number 20, nobody is interested in the remaining 80 anymore. They would say: Forgot about that stuff. We didn’t know what we were talking about when we wrote that.”
“If you had hired a service provider like xyz to build all those
requirements, that would just be putting money in the middle of a room and setting it on fire.”
© 2009 Jim Highsmith
42
Features and Functions Always or Often Used: 20% Always 7% Often 13% Sometimes 16%
Never Used 45% Rarely Used 19%
Never or Rarely Used: 64% © 2009 Jim Highsmith
Standish Group Study, reported by CEO Jim Johnson, XP2002
43
Traditional Value Curve
Value Cost Ratio Curve (Traditional)
Vaule Captured vs Cost Expended
120 100
100 90
80
80 70
60
Value %
60 50
40
Cost %
50
40 30
20
20 10 5
0 1
5 2
5 3
10
5 4
5
6
25
20
15
7
8
9
10
Development Phases
© 2009 Jim Highsmith
44
Agile Value Curve Strategies Most valuable first
Value Cost Ratio Curve (Agile)
Vaule Captured vs Cost Expended
120
Evolve features
100 90
85
80
70
Value %
60
55
40
Determine right cut-
80
75
60
100
98 90
95
off
Cost %
50
40 30
20
20 15
10 5
0 1
2
3
4
5
6
7
8
9
10
Iteration
Where is the right cut-off point? © 2009 Jim Highsmith
45
Reducing Marginal Functionality
Capability Feature 1 Feature 2 Feature 3 Story 1 Story 2
Story 3
Story 4
Story 5
Story 6
Marginal Value Optimal
Minimal Agent processes a special retail sale.
Agent processes a special retail sale.
2 © 2009 Jim Highsmith
Expansive Agent processes a special retail sale.
4
8 46
Achieving Predictability & Flexibility
Capability Short description & must have, won’t have bullet points
Features/Stories Breadth—Now or Later Depth—Simple to Extensive F1
Value points help determine
Later Simplest Basic Nominal Extensive
F2
x
F3
F4 x
F5
F6
x x x x
In many requirements processes there isn’t a strategy for determining relative importance of requirements which leads to requirements bloat. © 2009 Jim Highsmith
47
Value Point Calculations Value-driven planning
• • • • • •
Focus of agile development Value background Qualitative vs quantitative Calculating value points Relative versus absolute Calculating monetary value points
© 2009 Jim Highsmith
“If you don’t have time to estimate value, we don’t have time to estimate cost!”
48
Capability-level Value Capabilities assigned a weight—1-4 Weight based on value determination
• Purpose alignment model (qualitative) • Benefit-cost analysis • MoSCoW Calculate % of total for each capability (e.g. 6 caps, 24 CVPs, Cap
3 is 4 CVPs, therefore Cap 3 is 16.7% of the total value of the product) Adding all the VPs for all the stories in Cap 3, they cannot exceed
16.7% of the total VPs for the product.
© 2009 Jim Highsmith
49
Story-level Value Calculation Product/customer team determines Use “planning poker” Use standard values—1,2,3,5,8,13 Total cannot exceed capability allocation
© 2009 Jim Highsmith
50
Value Points to Value Dollars Depends on company needs Value points will be good enough for most product companies Value dollars will be desired by many internal IT and government
organizations
© 2009 Jim Highsmith
51
Stories with Value Points As a sales associate, the ability to calculate the total amount of the sale.
C-5
V-13
As a sales supervisor, the ability to Verify the adequacy of the Customer’s Credit Rating. Rating.
C-3
V-2
As a sales executive, the ability to view all sales by product type, geographic region, and sales associate.
V-11
C-8
Story Points are a calculation of cost. Value Points are an allocation of revenue. © 2009 Jim Highsmith
52
Value and Priority Value and Priority are different Priority determinants
• • • • •
Planning themes Financial value Risk mitigation Technical dependency Resource Dependency
Some NCF stories should be prioritized on a cost allocation basis
© 2009 Jim Highsmith
53
The New Challenge Martin Curley, Director IT Innovation, Intel Corporation
Innovation
Demand Compliance
Business Value
Security Workload Cost Reduction
© 2009 Jim Highsmith
54
Business Value Maturity Model (Intel)
Level 5 Level 4 Level 3 Level 2 Level 1
© 2009 Jim Highsmith
Optimized Value Options/Portfolio Mgt Simple ROI & IT Business Case Discipline
Total Cost of Ownership No or Ad Hoc Practices
55
Intel’s 17 Standard Measures of Value Days of inventory reduction
Scrap reduction
Days of receivables outstanding
Risk avoidance
Headcount reduction
Time-to-Market
Headcount productivity
Opening new markets
System end-of-life
Optimizing existing markets
Materials discounts Capital, hardware, and software
avoidance Unit cost avoidance Factory uptime © 2009 Jim Highsmith
Cross selling Vendor-of-choice
Intel White Paper: Defining the Value of E-business: Seventeen Standard Measures 56
The Agile Triangle
© 2009 Jim Highsmith
57
The Agile Triangle Value (Releasable Product)
Quality (Reliable, Adaptable Product)
Constraints (cost, schedule, scope)
A traditional project manager focuses on following the plan with minimal changes, whereas an agile leader focuses on “adapting successfully to inevitable changes. © 2009 Jim Highsmith
58
Traditional Gantt Chart — What Does It Emphasize?
ID 1
Task Name 1 Secure Financing
4
2 Form Corporation
8
3 File for State Approvals
Qtr 1, 1994
Qtr 2, 1994
Qtr 3, 1994
Qtr 4, 1994
Qtr 1, 1995
17
5 Systems Selection and Acquisition
23
6 Hire FFCS Staff
39
7 Develop Field Sales Manual & Forms
44
8 Develop Field Sales Training Material
0%
49
9 Develop Insurance Products for FFCS
0%
55
10 Form Customer Council
56
11 Develop FFCS Accounting Procedures
64
12 Obtain Legal Representation in Each State
69
13 Determine Maximum Finance Rate Permissible in Each State
74
14 Develop Field & Operational Incentive Plans
82
15 Custom Printing Implementation
83
16 Select Priority States
84
17 Vendor System Implementation
85
18 Develop FFCS Internal Procedures
98
19 Reforecast First Year Operating Projections
100% 100% 0% 0%
0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
158 21 Telecommunications
0%
168 22 Develop Internal, Management and Field Sales Reporting
0%
181 23 HO Product Interfaces Testing
0%
182 24 Vendor System Preview
184 26 Vendor System Installation and Training
© 2009 Jim Highsmith
Qtr 4, 1995
63%
4 Form Market Council
183 25 FFCS Systems Running in 'Mock' Mode for Testing
Qtr 3, 1995
100%
13
108 20 Server and Communications Network
Qtr 2, 1995
100%
0% 0% 0%
59
A Parking Lot Diagram — What Does It Emphasize? Establish Product Catalog (PC) PS
Establish Product
PS
Establish Product Attributes
PS
Establish Product Attribute Groups
Establish Network Arrangement (NW)
PS
PS
Establish Templates
LT
Establish Autodesign Mapping
LT
Establish Site
LT
Establish Node
Establish Network Element
LT
Establish Equipment
(12)
(15)
(12)
(7)
(6)
(11)
(14)
(9)
100%
100%
100%
100%
100%
100%
100%
100%
100%
Nov 2000
Dec 2000
Dec 2000
Oct 2000
Oct 2000
Oct 2000
Dec 2000
Oct 2000
Nov 2000
Establish DesignJMProduct (DP) JM JM Establish Products and Models
Establish Design Items For Models
Explode Design Model
Establish Diversity (DV) PS LT
LT
Establish Diversity Levels
Generate Constraints
Check Constraints for A Pathing Point
PS
Generate and Resolve Order Activities
Run Autodesign
(16)
(13)
(24)
(26)
(19)
(19)
(20)
(13)
(17)
100%
42%
100%
89%
1%
100%
Oct 2000
Oct 2000
Dec 2000
Jan 2001
Inter-System Pathing (XP) PS
PS
PS
PS
PS
A-Z One Hop
A-Z 2 Hops
A-Z Multiple Hops
Establish Pathing
Comply with Diversity Constraints
(14)
(21)
(22)
(19)
(13)
100%
100%
89%
100%
Dec 2000
Dec 2000
Dec 2000
Dec 2000
Mar 2001
JM
Mar 2001
JM
Route through Bearer System
Protected Route
Autodesign Transport Shortfall
(33)
(20)
(16)
(25)
(8)
(14)
© 2009 Jim Highsmith KEY:
0% Feb 2001
Work In Progress
Feb 2001
Users (UM) JM
Apr 2001
Attention
Mar 2001
Apr 2001
System Selection (SS) PS
Establish Cost
PS
PS
Select Bearer System
Logical Bearer Systems (13)
(7)
(7)
100%
100%
100%
Nov 2000
Dec 2000
Dec 2000
JM
Satisfy Transport Item
Apr 2001
Apr 2001
(11)
Hubbing
Apr 2001
Dec 2000
Establish User
Protection
Physical Design
0%
1%
(4)
Intra-System PathingJM(SP) JM
JM
PS
JM
Generate and Track Site Events
(9)
Oct 2000
Establish Order (OM) JM JM
Capture Details
100%
Feb 2001
(15)
Apr 2001
C A
Establish CIX Trail Design
Establish Trails (TR) LT C
PS
A
Lookup CI Trail Design
Retest Trail Diversity
Save Trail Design
(18)
(10)
(15)
(23)
100%
100%
Dec 2000
Apr 2001
Full Completion
Apr 2001
Apr 2001
Apr 2001
Courtesy Progress Bar
Jeff DeLuca 60
The Declaration of InterDependence
We increase return on investment by making continuous flow of value our focus.
We deliver reliable results by engaging customers in frequent interactions and shared ownership.
We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
We boost performance through group accountability for results and shared responsibility for team effectiveness.
We improve effectiveness and reliability through situational specific strategies, processes and practices. ©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.
www.APLN.com
© 2009 Jim Highsmith
61
The Product Development Lifecycle
Product Initial Product Conceptualization Development
Continuing Product Development
Product Roadmap Product Backlog CAPABILITY 1
R 1.0
R 2.0
R 3.0
…
I1 I2 I3 … Releases
CAPABILITY 2
Iterations
© 2009 Jim Highsmith
Feature 1
Feature 2
Feature 3
Story 1 Story 1
Story 4 Story 4
Story 7 Story 7
Story 2 Story 2
Story 5 Story 5
Story 8 Story 8
Story 3 Story 3
Story 6 Story 6
Story 9 Story 9
Continuous Flow of Value
62
Delivering Continuous Value
Customer Satisfaction
Functionality User Experience
Total Value Works as specified Technical Quality
© 2009 Jim Highsmith
Adaptable
63
Schedule
Quality
Co ns tra in ts
Co st
Beyond Scope, Schedule, Cost
Scope
• Weak link to value • Limiting • Divides customers and dev • Inflexible • Short time horizon • Looks backward © 2009 Jim Highsmith
Value • Strong link to value • Expansive • Unites customers and dev • Flexible • Long time horizon • Looks forward 64
Strategic Questions Why couldn’t we release this product today? What is our value-cost ratio? What is the product quality? Are we within acceptable constraints?
© 2009 Jim Highsmith
65
Project Performance Goals Value
• Meet or exceed customer value expectations • Value “chunks” are delivered in a release timebox Quality
• All known defects are repaired • Defect levels through development are less than ½ industry average • Technical debt remains low Constraints
• Scope: all planned major value-generating capabilities are delivered. Story scope varies by mutual agreement • Cost: actual costs are within agreed to limits (limits can change by mutual agreement during the project) • Schedule: actual schedule is within agreed to limits (limits can change by mutual agreement during the project) © 2009 Jim Highsmith
66
Releasable Product Product vision Project objectives Business objectives Capabilities/Features Project Data Sheet Project Name: CRM Development Project Start Date: 1/1/2010 Clients: Marketing Call Center Sales Accounting
Timebox schedule
Project Leader: Braxton Quivera Product Manager: Roger Jones Executive Sponsor: Andrian Poledra Quality Objectives: Defects: 25% under industry average All Severity 1 & 2 defects fixed Comprehensive automated testing implemented Overall McCabe Cyclomatic Complexity < 10 Quality Assessment > 4 (reliability & adaptability)
Project Objective Statement: The objective is to build a web-based CRM application that includes sales tracking, order management, Sales Management, and Marketing. The system needs to be operational by 9/30/09 and cost less than $2.5 million.
Performance Guidelines: Call Center volume of 3,500 calls per day Worldwide web access <1/2 day training required
Business Objectives: Better customer service Reduce paperwork More accurate order processing Overall ROI > 14%
Architecture Guidelines: Integrate effectively with ERP system Maximize reusable components
Product Roadmap R 1.0
R 2.0
R 3.0
…
I1 I2 I3 … © 2009 Jim Highsmith
67
Strategic Agility Adapting to Change over Conforming to Plans Conform
Bu S t sin ra es te gy s
Value
Business Week,
The Case for Agile
Adapt
“There is no more Normal”
World View
March 23, 2009. Ex St ecu ra ti te on gy
of e r su ess a Me ucc S
Business Goals Organization
Product Backlog
Process
Product Management Team Product Roadmap
CAPABILITY 1
CAPABILITY 2
Feature 1
Feature 2
Feature 3
Story 4
Story 7
Release Management Team Release Plan
Feature Team Story 1 Story 1
Quality © 2009 Jim Highsmith
Constraints
Story 4
Story 7
Story 2
Story 5
Story 8
Story 2 Story 3
Story 5 Story 6
Story 8 Story 9
Story 3
Story 6
Story 9
Iteration Plan
Agile Values
68
![DOWNLOAD [PDF] Zen and the Art of Motorcycle ...](https://p.pdfkul.com/img/300x300/download-pdf-zen-and-the-art-of-motorcycle-_5a0ebec41723dd3da709ebb2.jpg)
