The document summarizes IBM's transition to Agile development practices. It discusses why IBM needed to change, how it made the transition in terms of process, people, and tools, and how it measures progress. Key points include that IBM transitioned from a maintenance-focused to innovation-focused model, adopted Agile practices like iterations and daily stand-ups, provided extensive training to people, developed tools to facilitate Agile workflows, and uses metrics to track business and development health. The transition helped IBM improve quality, on-time delivery, and better manage a global workforce.
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
The Agile Revolution of IBM
1. The Agile Revolution of IBM
Alan Kan
Technical Manager, IBM Software Delivery Solutions
alankan@nz1.ibm.com
alan@alankan.net
2. 2
Why we needed to change
Making the change
– Process
– People
– Tools
Measuring Agile progress
Agenda
• How Agile is IBM now?
• Why did IBM Move to Agile?
• Our Journey of Becoming Agile
• Process
• People
• Tools
• Measuring the Impact
3. 3
a globalteam US 10,400
Canada 3, 354
Latin America 303
EMEA 4,713
AP 8,153
Japan 282
Total 27,106*
Toronto,Ottawa,
Montreal, Vancover,
Victoria
Edinburgh
London/Staines
Milton Keynes
Hursley
Warwick
Haifa/Rehovot
Beijing
Shang Hai
Yamato
Taipei
LaGaude
Paris
Pornichet
Toulose
Beaverton
Kirkland
Seattle
Almaden
Agoura Hills
Costa Mesa
El Segundo
Foster City
San Francisco
SVL/San Jose
Las Vegas
Rochester
Minneapolis
Boulder
Denver
Lenexa,KA
Tucson
Pheonix
Austin
Dallas
Bedford, MA
Bedford, NH
Cambridge
Lexington
Littleton, MA
Waltham, MA
Westford – 528
Cork
Dublin
Galway
Boeblingen
Bangalore
Gurgaon
Hyderabad
Mumbai
Pune
Cairo
Rome -
Gold Coast
Sydney
Canberra
Fairfax
Raleigh
Charlotte
Lexington,
KY
Atlanta
Boca Raton
Tampa
Perth
Krakow
Warsaw
Sao Paulo
Malaysia
Delft – 61
Stockholm
Malmo
New York, NY
Pittsburg
Piscataway
Poughkeepsie
Princeton
Somers
Southbury
Helsinki
El Salto
Hong Kong
Singapore
74 Acquisitions
89 Labs
1198 products
506 releases / year
92% Growth Since 2001
10,000 resources from
acquisitions
# customers - 11, 867
% Efficiencies – 7% YoY
Growth Market 8,878 (33%)
Major Market 18,227 (67%)
4. 4
Practices we adopted
Iterative
Development
API
first
end
game
retrospectives
always have
a client
continuous
integration
community
involvement
new &
noteworthy
adaptive
planning
continuous
testing
consume your
own output
drive with
open eyes
validate
reduce stress
learn
attract
to latest
transparency
validate
update
feature
teams
show progress
enable
validate
live
betas
feedback
sign
off
End of iteration
demos/reviews
Ranked
Product Backlog
Burndown User Stories
Daily Standup
independent
testing
exploratory
testing
Definition of
Done
PMC
TDD
Planning Poker
5. Leadership Role
Note: Goals are either internal IBM statistics or industry benchmarks.
Metric Goal
2006
Measurement
2011 Measurement
Maintenance / Innovation 50/50 42% / 58% 31% / 69%
Customer Touches / Product 100 ~10 ~ 400
Customer Calls -5% YoY ~ 135,000
~100,000 (-19% since
2009)
Customer Defect Arrivals -5% YoY ~ 6,900 ~2200
On Time Delivery 65% 47% 94%
Defect Backlog 3 Months 9+ Months 3 months
Enhancements Triaged 85% 3% 100%
Enhancements into Release 15% 1% 21%
Customer Sat Index 88% 83% 88%
Beta Defects Fixed Before GA 50% 3% 95%
Rational’s rewards
8. 8
cost of poor quality
$25/defect $100/defect $16,000 per defect$450/defect $241,000 per defect$158,000 per defect
Total Dollars Spent on Escapes
Trend of Percentages in each Area over time
Trend of Spend on L3 versus Technical Debt
Trend of Spend vs Revenue
9. 9
“A large UK bank initiated its APM effort to take a 90:10 ratio for run-the-bank / grow-the-bank down to
a more reasonable 40:60 ratio. Dell shifted its maintenance-to-innovation ratio from 80:20 to 50:50.”
The Application Portfolio Management Landscape — Combine Process And Tools To Tame The Beast, Phil Murphy, Forrester Research, Inc. April 15, 2011
Insufficient spend on
strategic projects
10. 10
we needed to change
Organize differently
Develop differently
Deliver differently
Measure differently
11. 11
Respond to fast changing
environment
Reduce process overhead
Better manage
outsourcing / contractors
Improve morale
Enhance quality
why move to agile?
17. 17
generic iteration definitions
endgame
release
M1a
plan
develop
stabilize
4 weeks
warm-up
retrospective
initialreleaseplan
decompression
M1
plan
develop
stabilize
…
plan
develop
stabilize
sign-off
sign-off
sign-off
4 weeks 4 weeks
fix-spit&polish
test
fix
test
4 week iterations ⇒ end with an end of iteration demo
8 week milestones ⇒ announced with New & Noteworthy ⇒ retrospective at the end
Retrospective
New&Noteworthy
End of iteration
demo
18. 18
What is in a practice?
Key concepts
Work products
Tasks
Guidance
Measurements
Tool mentors
19. 19
(*) Based on Mike Cohn, Agile Estimating and Planning
StrategyStrategy
PortfolioPortfolio
ProductProduct
ProjectProject
IterationIteration
DailyDaily
agile planning onion
Agile Teams
Plan at
Innermost
Level
“Required” at
all levels
21. 21
Leadership Role
lean training evolution
• Poppendieck collaboration
– Two day Disciplined Agile Workshop (9000+ trained)
• Additional focused workshops
– Leading Agile Teams & Project Management
• Deep dives on practices
– “show me how its done right in SWG today”
• Lean Series
– Complements Agile curriculum
• Collaborative leadership workshop
– Focused on middle management and executives to enable collaboration over
isolation or coordination
22. 22
people do what you inspect
47%
100%
2006 2009
On Schedule Delivery
24. 24
lessons for executives
• A completion date is not a point in time, it is a probability distribution
0 6 12
Plans/Resource estimates
Scope
Product features/quality
• Scope is not a requirements document, it is a continuous negotiation
• A plan is not a prescription, it is an evolving,
moving target
Actual path and precision of Scope/Plan
Uncertainty in
Stakeholder
Satisfaction Space
Initial PlanInitial State
26. 26
Leadership Role
tools
Optimizing how
people work while
minimizing face-to-
face interactions
Increasing control
by integrating
workflows and “forcing”
new habits
Collaboration
Continuously improve
through real-time
measurement and
constant steering.
OptimizationProcess Automation
keys across all disciplines
28. 28
Leadership Role
fast voting and ranking
Legend:
007 Integrated process
tailoring…
#1 for OSD directors
drops to #6 for Rational
044 Global Collaboration
#1 for IT Tiger Team
drops to #7 for Rational
027 Reporting
#1 for IT Accelertor team
remains on top for Rational
30. 30
Leadership Role
overall progress tracking
• End of Iteration Demos
• Definition of Done
• Done Criteria in Plan Items
• Risk Tracking in Plan Items
• Progress Reporting across Projects (planned)
40. 40
Leadership Role
tools
doing More with Less
Capacity
2003 2004 2005 2006 2007 2008 2009*
HC/ProductGA
SWGRevenuein$$’s
HC / Product GA
SWG Revenue
41. 41
Leadership Role
Note: Goals are either internal IBM statistics or industry benchmarks.
Metric Goal
2006
Measurement
2011 Measurement
Maintenance / Innovation 50/50 42% / 58% 31% / 69%
Customer Touches / Product 100 ~10 ~ 400
Customer Calls -5% YoY ~ 135,000
~100,000 (-19% since
2009)
Customer Defect Arrivals -5% YoY ~ 6,900 ~2200
On Time Delivery 65% 47% 94%
Defect Backlog 3 Months 9+ Months 3 months
Enhancements Triaged 85% 3% 100%
Enhancements into Release 15% 1% 21%
Customer Sat Index 88% 83% 88%
Beta Defects Fixed Before GA 50% 3% 95%
Rational’s rewards
Self introduction – I help my customers to leverage IBM technology to deliver high quality software faster. Been in IBM for 5 years, met some great people such as Scott Ambler, Mike O’Rouke, Scott Rich, etc. The information of this presentation primarily come from talking to them.
IBM has 3 primary lines of business - hardware, software and services. We are talking about software group here. Size is big, but learnings are applicable to any organisations
In 2006, dominantly using waterfall, RUP, and the Eclipse Way. Setup Agile COE in 2006, and management has invested $5m/year over 2006 and 2008. Primary differentiator between Agile and iterative = the use of User Stories, Ranked Product Backlog, reprioritise at each iteration, Daily Standup. Also adapted other common agile practices: iterative, reflect, adapt, incremental, feedback Practices inspired by agile practices, scrum, xp, some custom ones, that work for us
Rewards have been significant On time delivery Enhancements Triaged, and Enhancements into release Maintenance/Innovation
IBM has acquired a lot of companies for the talents. Have problem with geographically distributed teams being less effective. But no point forcing people to relocate because they will leave. So we have to work with it.
GDD and distintegrated teams becomes quality problems. IBM figures on the slide.
Quality problem means we spend a lot of resource in maintenance (bug fixing) that could have been doing innovative projects (new products). The implication is that if we are behind our competitors on innovation, that means they will have a new product before we do. Eventually they have a few products and features that we don’t, and we can’t catch up. Big problem that has senior management attention – losing our competitive advantage!
Decided we need change in 2006.
Why Agile? Cost of change is lower – getting into Agile is easier, getting out is easier.
Good to have appropriate tools, trained up scrum masters, and people that know what they are doing. But also important is the right process, enforcement, nurturing, trust level from management to create a success agile environment.
50%+ of teams failed because of water scrum fall -> recognised that we need to do more than just changing dev teams.
Dr Dobbs (Scott Ambler) found that effective agile teams are on the left of the scale. Mike O’Rouke found we are on the right on every count. Process-wise, use DAD. IBM has no way to deal with the situation using current tools -> need some new tools
IDT Process is the process followed by all hardware, software and service product creation. Funding, scope, release date determined upfront, if changes, ask for forgiveness (more $). Over 50% of product development team come back for forgiveness -> obviously the model is not working too well. This convinced management to change. changed to unlock scope to 70/30, keep others constant.
Generic iteration defnitions across teams in one product. Not generic across ibm.
Document our best practice to share with other teams
Agile = need to move fast. PMO idea and using excel to do status report after iterations don’t work too well. Most PMs can’t make it to agile. Need real time planning in tool, things like integration points, upgrades, migrations, still with PMs.
Poppendieck – train the trainer with DAD Agile leadership and PM training for existing PMs Deep dive such as forced check-in, continuous build, TDD and coding for testers
2006 to 2008, we added on time delivery as a KPI to people, impacting performance review and bonus 2009 = 100% on time. But quality went down. So we added quality as another KPI. 2011 = 94% on time. But better quality.
CFO mindset of offshoring -> need to convince them productivity level changes and therefore success rate of project changes dramatically. Don’t outsource for cost, hire the best talent from diff locations.
Can’t just fund and walk away. They need to be there with us Customers are happy with the 70/30 arrangement
3 key success factors Collaboration – traceable conversation to context (story/task) to help with distributed teams Automation – forcing habits, putting in process Optimisation – real time reporting to help managers to remove impediments quickly
Let’s say the team is largely based in Europe. The NZ guys need to wake up at 2am to do planning poker. It is not fun, and has less quality input from members. This system helps geo distributed teams to do planning poker by pairwise comparison + comment
System aggregates the voting and ranks user stories. Not the end of it. But it is a much better baseline to talk. Most of the time everyone agrees.
One source of truth
Capture done critiera with user story
Key is auditable (know when it is suggested) and actionable.
If independent test team needs to connect to our user stories and create test cases from there to ensure traceability, they can. Based on Jazz platform.
If they use Rational tools, then built in integration tried and tested.
One way that we are looking at organizing metrics around business and operational objectives, with direct exec-level input. Too many, only ended up with 10.
These are what senior management look at. Revenue by Distinguished Engineer – up a bit Employee/Revenue – down heaps = they need less people to make a dollar of revenue.
HC/Product GA = we only need half as many people now to create a product compared to 2006.
Defect Backlog Beta Defects Fixed before GA
Author Note: Mandatory Rational closing slide (includes appropriate legal disclaimer). Graphic is available in English only.