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.
The Agile Revolution of IBM
The Agile Revolution of IBMAlan KanTechnical Manager, IBM Software Delivery Solutionsalankan@firstname.lastname@example.org
2 Why we needed to change Making the change– Process– People– Tools Measuring Agile progressAgenda• How Agile is IBM now?• Why did IBM Move to Agile?• Our Journey of Becoming Agile• Process• People• Tools• Measuring the Impact
8cost 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“A large UK bank initiated its APM effort to take a 90:10 ratio for run-the-bank / grow-the-bank down toa 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, 2011Insufficient spend onstrategic projects
10we needed to change Organize differently Develop differently Deliver differently Measure differently
11Respond to fast changingenvironmentReduce process overheadBetter manageoutsourcing / contractorsImprove moraleEnhance qualitywhy move to agile?
17generic iteration definitionsendgamereleaseM1aplandevelopstabilize4 weekswarm-upretrospectiveinitialreleaseplandecompressionM1plandevelopstabilize…plandevelopstabilizesign-offsign-offsign-off4 weeks 4 weeksfix-spit&polishtestfixtest 4 week iterations ⇒ end with an end of iteration demo 8 week milestones ⇒ announced with New & Noteworthy ⇒ retrospective at the endRetrospectiveNew&NoteworthyEnd of iterationdemo
18What is in a practice? Key concepts Work products Tasks Guidance Measurements Tool mentors
19(*) Based on Mike Cohn, Agile Estimating and PlanningStrategyStrategyPortfolioPortfolioProductProductProjectProjectIterationIterationDailyDailyagile planning onion Agile TeamsPlan atInnermostLevel “Required” atall levels
21Leadership Rolelean 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 overisolation or coordination
22people do what you inspect47%100%2006 2009On Schedule Delivery
24lessons for executives• A completion date is not a point in time, it is a probability distribution0 6 12Plans/Resource estimatesScopeProduct features/quality• Scope is not a requirements document, it is a continuous negotiation• A plan is not a prescription, it is an evolving,moving targetActual path and precision of Scope/PlanUncertainty inStakeholderSatisfaction SpaceInitial PlanInitial State
26Leadership RoletoolsOptimizing howpeople work whileminimizing face-to-face interactionsIncreasing controlby integratingworkflows and “forcing”new habitsCollaborationContinuously improvethrough real-timemeasurement andconstant steering.OptimizationProcess Automationkeys across all disciplines
27Leadership RoleNumber of comparisionsHow important left vs rightpair-wise story comparison
28Leadership Rolefast voting and rankingLegend:007 Integrated processtailoring…#1 for OSD directorsdrops to #6 for Rational044 Global Collaboration#1 for IT Tiger Teamdrops to #7 for Rational027 Reporting#1 for IT Accelertor teamremains on top for Rational
29Leadership Roletoolsview plan by business value
30Leadership Roleoverall progress tracking• End of Iteration Demos• Definition of Done• Done Criteria in Plan Items• Risk Tracking in Plan Items• Progress Reporting across Projects (planned)