dollars and dates are killing agile
DESCRIPTION
Agile teams speak in points and iterations, but project and business managers think in terms of dollars and dates. This conceptual and language barrier makes strategic business planning, funding, and progress management a significant challenge for sustained large-scale Agile. This session will include multiple case studies from large-scale Agile adoptions that we were part of and have supported over the past 7 years and how Agile values/principles went beyond just the development organizational boundaries into strategic planning and management.TRANSCRIPT
Dollars and Dates are Killing Agile
Brent Barton &
Chris Sterling (in absentia) Agile 2012
Wed Aug 15, 2012
But I really DO have a
good excuse!
1
• Product Line Director, Rally Software
• Formerly President, Agile Advantage, Inc. (acquired by Rally in 2012)
• Passionate about business being able to take advantage of what Agile has to offer
• Active practitioner delivering value using Agile
• Previous roles include: CTO, Development Manager, PMO Manager, Agile Coach, Mentor, Certified Scrum Trainer, ScrumMaster, Product Owner
Brent Barton
[email protected] www.rallydev.com.com Blog: gettingagile.com Twitter: @brentbarton
2
Agenda " What is Business Value? " How are Dollars and Dates Killing Agile? " An Agile Business Roadmap
– Year 1: Reduce Carryover – Year 2: Optimize Portfolio – Year 3: Incremental Funding
" Questions & Answers
3
Value
4
An Agile Story…
Hi Mom!
5
Executive Feedback from Sonia
This is the best, simplest, easiest to use application we have ever gotten in
both Customer Care and the Retail Stores! Whatever you all did, I want more of that!
6
Value
Cost Savings
New Revenue
Compliance
Customer Satisfaction
Employee Satisfaction
Shareholder Value
Revenue Retention
• Cost Savings
Pilot Agile Team Delivered Great Value
• Employee Satisfaction • Customer Sat
• New Revenue • through efficiency
7
Agile
* This diagram shows Scrum. Could be XP, Kanban, etc
* 8
Value
Agile
What’s In-Between?
9
Demand
CFO Cost Constraints
Human Resources People Constraints
Rhythm of the Business
Portfolio/Budget
Value
10
Value Demand
Portfolio/Budget
Agile
Perfection Goes Here
11
? Conclusion: (Except in cases of Perfection) Adaptive Planning Stresses Strategic Portfolio Planning
12
• Business cannot take advantage of what Agile offers
• It is decided that Agile can’t scale • Suboptimal results • Agile is restarted several times
– (this time it will be different…)
Typical Scaled Outcomes
13
OK, SO WHAT SHOULD WE DO?
14
Triple Constraints – Recognize Agile does not make constraints go away
Scope
Schedule Cost 15
• Time and Materials (T&M) • Fixed Price • Cost Plus
Incentive Fee • IDIQ/Delivery orders
– or task orders
Is Value Defined in Contracts?
These are cost-based!
16
Value
Constraints (Schedule, Cost, Scope)
Quality
Balancing Decision Indicators
Source: Jim Highsmith
Strategic
Required to make good Decisions
Informs and Guides
17
Complexity Requires Adaptive Planning
• It is not possible to completely specify an interactive system. Wegner’s Lemma, 1995
• Uncertainty is inherent and inevitable in software development processes and products. Ziv’s Uncertainty Principle, 1996
• For a new software system the requirements will not be completely known until after the users have used it. Humphrey’s Requirements Uncertainty Principle, c. 1998
18
Focus on value delivery,
informed by constraints and quality
Tip
19
THE AGILE BUSINESS ROADMAP
20
" Identify issues sooner " Make decisions earlier " Demonstrate progress frequently " Focus on quality
Agile Business Roadmap Year 1: Reduce carryover
21
Planning for the Whole Organization
Program Roadmap – Holistic view of Software, Hardware and Operations
© 2009-2010,
Program Roadmap
" Areas of functionality/capabilities on top " Place associated user stories vertically
Story Map
24
Story Map " Draw line that represents viable release
– Customer features above the line are “in” – Dotted line represents negotiability
25
PATTERNS FOR SCALING AGILE DELIVERY 26
Component Teams " “Component Team” structure " Separate Product Backlog " Managing dependencies is
often serialized " Problematic integration issues
are typically faced if multiple components are required to release
" Use an “Integration Team” to pull components together
" Causes more rework than “Feature Team” structure
27
Feature Teams " “Feature Team” structure " Uses common Product
Backlog " Integration is done in parallel " Requires high levels of
communication across teams to resolve integration issues
" Forces Product Owners to be more coordinated
" Sprints should be synchronized " Cross team fertilization is a
requirement to successfully deliver in parallel
28
Definition of Done - Assert Quality " Acceptance defined criteria for each
user story �
" Unit tests written and passed �
" Code compiles with no errors and no warnings �
" New code doesn’t break existing code �
" Test case review (Dev to review test case written) �
" Architectural impact assessed and artifacts updated if necessary�
" Comments in code �
" Error codes added�
" Code reviewed by peer �
" Code checked in with reference to US#/Task# �
" Integration test written & passes �
" Test code reviewed�
" Environment requirements documented �
" Interface document updated/added and checked in to SVN �
" Acceptance criteria verified complete �
" All P1-P3 bugs for the story are closed �
" Test approves user story �
" Story demonstrated to product owner and accepted on Target Platform�
29
Release Definition of Done " Every release should have clear quality
criteria " With a “Release Definition of Done” you can
understand targets better " Measure the gap between the teams’
Definition of Done and a Release Definition of Done. – This gap is a source of
quality issues and represents significant risk to schedule
30
Forming the Meta-Scrum
“Establishing and Maintaining Top to Bottom Transparency Using the Meta-Scrum”, AgileJournal
31
Year 2: Optimize Project Portfolio " Identify emergent value " Compare performance across portfolio " Increase overall value/cost ratio " Lower cost of compliance " Deliver smaller batches " Reduce stabilization periods " Coordinate across groups
Agile Business Roadmap
32
PROCESS AUTOMATION & OPTIMIZATION WITH ADDITION OF APPROPRIATE “SLACK” 33
Traditional Source Control Management
Main Branch Debt
Death March { Debt accrues quickly within stabiliza7on periods
Version 1 Branch
Integrate for Version 2
Code Complete
34
Flexible Source Control Management
Main Branch Version 1 Version 2 {
Not Easy! Must have proper infrastructure to do this.
35
Continuous Integration
36
37
" Safe-fail environment " Use experimentation as a competitive advantage " Combat competitive threats " Integrate technical & customer feedback promptly " Aggressively use commit/transform/kill for portfolio optimization " Pull initiatives through teams rather than pushing resources to projects
Agile Business Roadmap Year 3: Incremental Funding
38
PORTFOLIO MANAGEMENT DECISIONS: COMMIT, TRANSFORM, KILL
Source: Johanna Rothman “Manage Your Project Portfolio” http://www.amazon.com/Manage-Your-Project-Portfolio-first/dp/B004SMU0OW
39
Value
Constraints (Schedule, Cost, Scope)
Quality
Balancing Decision Indicators
Source: Jim Highsmith
40
Estimates are Unreliable and Still Useful
" Estimate using relative size " Affinity Estimating technique*
Affinity Es7ma7ng How-‐To: hJp://www.geMngagile.com/2008/07/04/affinity-‐es7ma7ng-‐a-‐how-‐to/
41
Portfolio Level Interactions
42
Transform
43
Early Warning Signs
Early Warnings: • Broken Builds • Broken Automated Tests • Broken Custom Thresholds
44
Early Warnings: • Design Debt in Duplica7on (DRY) • Technical Debt in Code Complexity • Quality Debt in Bug DB (Break/Fix) • Other Custom Thresholds
45
Quality – Technical Excellence Enhances Agility*
Build Monitors
Target Hardware
Collaboration
Interaction Design
46
Project Portfolio Kill?
Early Warnings: • When transform and re-‐”commit” is not a valid op7on: • “Kill” should be an op7on on the table MORE
47
• Thank you! • Questions & Answers
48