1. Dollars and Dates
are Killing Agile
Brent Barton But I really
DO have a
& good excuse!
Chris Sterling (in absentia)
Agile 2012
Wed Aug 15, 2012
1
2. Brent Barton
• 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
bbarton@rallydev.com
• Active practitioner delivering value www.rallydev.com.com
using Agile Blog: gettingagile.com
• Previous roles include: CTO, Twitter: @brentbarton
Development Manager, PMO
Manager, Agile Coach, Mentor,
Certified Scrum Trainer,
ScrumMaster, Product Owner
2
3. 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
6. 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
7. Pilot Agile Team Delivered Great Value
Cost
• Employee Satisfaction Savings
• Customer Sat Revenue New
Retention Revenue
• Cost Savings
• New Revenue
• through efficiency
Shareholder
Value Compliance
Value
Employee Customer
Satisfaction Satisfaction
7
8. * This diagram
shows Scrum.
Could be XP,
Kanban, etc
Agile*
8
13. Typical Scaled Outcomes
• 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…)
13
15. Triple Constraints – Recognize Agile does not
make constraints go away
Scope
Schedule Cost
15
16. Is Value Defined in Contracts?
• Time and Materials (T&M)
• Fixed Price
• Cost Plus
Incentive Fee
• IDIQ/Delivery orders
– or task orders
These are
cost-based!
16
17. Balancing Decision Indicators
Strategic
Value
Required to
make good Informs and
Decisions Guides
Quality Constraints
(Schedule, Cost, Scope)
Source: Jim Highsmith
17
18. 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
27. 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
28. 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
29. Definition of Done - Assert Quality
" Acceptance defined criteria for each" Code checked in with reference to
user story US#/Task#
" Unit tests written and passed " Integration test written & passes
" Code compiles with no errors and no " Test code reviewed
warnings
" Environment requirements
" New code doesn’t break existing documented
code
" Interface document updated/added
" Test case review (Dev to review and checked in to SVN
test case written)
" Acceptance criteria verified
" Architectural impact assessed and complete
artifacts updated if necessary
" All P1-P3 bugs for the story are
" Comments in code closed
" Error codes added " Test approves user story
" Code reviewed by peer " Story demonstrated to product
owner and accepted on Target
Platform
29
30. 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
31. Forming the Meta-Scrum
“Establishing and Maintaining Top to Bottom
31
Transparency Using the Meta-Scrum”, AgileJournal
32. Agile Business Roadmap
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
32
34. Traditional Source Control
Code
Management
Complete
Version
1
Integrate
for
Branch
Version
2
Debt
Main
Branch
Death
March
{
Debt
accrues
quickly
within
stabiliza7on
periods
34
35. Flexible Source Control
Management
Version 1
Version 2
Main Branch
{
Not Easy! Must have proper infrastructure to do this.
35
38. Agile Business Roadmap
Year 3:
Incremental Funding
" 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
38
39. Source: Johanna Rothman
“Manage Your Project Portfolio”
http://www.amazon.com/Manage-Your-Project-Portfolio-first/dp/B004SMU0OW
PORTFOLIO MANAGEMENT
DECISIONS:
COMMIT, TRANSFORM, KILL
39
44. Early Warning Signs
Early
Warnings:
• Broken
Builds
• Broken
Automated
Tests
• Broken
Custom
Thresholds
44
45. Early
Warnings:
• Design
Debt
in
Duplica7on
(DRY)
• Technical
Debt
in
Code
Complexity
• Quality
Debt
in
Bug
DB
(Break/Fix)
• Other
Custom
Thresholds
45