Managing So)ware Debt Workshop
Tuesday, May 8, 2012
First Things First...
2
@csterwa
#swdebt
Tuesday, May 8, 2012
Chris Sterling
Co-‐founder & CTO of Agile Advantage www.AgileAdvantage.com
Author of Book “Managing SoBware Debt: Building for Inevitable Change”
Consults on soBware technology, Agile technical pracKces, Scrum, and effecKve management techniques
InnovaKon Games® Trained Facilitator
CerKfied Scrum Trainer
Open Source Developer
3
Email: [email protected] Web: h<p://www.agileadvantage.comFollow me on TwiTer: @csterwaBlog: h<p://www.ge?ngagile.comHashtag for presentaKon: #swdebt
Tuesday, May 8, 2012
Agenda
Managing So)ware Debt Overview
So)ware Debt Types• Technical• Quality• Configura=on Management
• Design• Pla@orm Experience
Asser=ng Quality• Defini=on of Done• Test Automa=on
• The “3 Amigos” PaHern
• Test-‐Driven Design
Monitoring Quality• The Power of 2 Scripts• Con=nuous Integra=on• Automated Promo=on
• Advanced Quality Metrics Trending and Analysis
Wrap Up• So)ware Debt Management Strategy
• The “No Defect” Mindset
4
Tuesday, May 8, 2012
Managing So)ware Debt OverviewLet me tell you a potenKally familiar story…
Tuesday, May 8, 2012
Tuesday, May 8, 2012
Lack of emphasis on so'ware quality a2ributes contributes to decay
Tuesday, May 8, 2012
Principle: No maTer what, the cost of addressing soBware debt increases with Kme.
Tuesday, May 8, 2012
Types of So)ware DebtTechnical, Quality, ConfiguraKon Management, Design, and Pla\orm Experience
Tuesday, May 8, 2012
Technical debt tended to focus more on programming aspects of soBware delivery and leB out full soBware development life cycle
Each type of soBware debt can be managed and monitored using different tools and approaches
Focusing on managing each type of soBware debt simplifies creaKon of an overall strategy that promotes holisKc perspecKve
Why not just call it all “Technical Debt”
10
Tuesday, May 8, 2012
Types of SoBware Debt
Technical Debt: These are the ac=vi=es that a team or team members take shortcuts on now that will impede future development if le) as is.
Quality Debt: There is a diminishing ability to verify the func=onal and technical quality of so)ware: the “Break/Fix” mentality.
Configura5on Management Debt: Integra=on and release management become more risky, complex, and error-‐prone.
Design Debt: The cost of adding features is increasing toward the point where it is more than the cost of wri=ng from scratch.
Pla:orm Experience Debt: The availability and alignment of people to business objec=ves that involve so)ware changes is becoming more limited or cost-‐prohibi=ve.
8
Tuesday, May 8, 2012
AsserGng QualityTeams must focus on asserKng sustainable quality to support future customer needs in a Kmely manner
Tuesday, May 8, 2012
DefiniGon of DoneSoBware developments assert what finished, working soBware entails to support predictable delivery into the future
Tuesday, May 8, 2012
DefiniKon of Done -‐ Assert QualityAcceptance 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#
Tested on FE
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
14
Tuesday, May 8, 2012
Release DefiniKon of Done
Every release should have clear quality criteria
With a “Release DefiniKon of Done” you can understand targets beTer
Measure the gap between the teams’ DefiniKon of Done and a Release DefiniKon of Done.• This gap is a source of quality issues and represents significant risk to schedule
Tuesday, May 8, 2012
Case Study: Test AutomaKon Reduces Cost of Change
Tuesday, May 8, 2012
Manual Regression TesKng
TesKng was taking 75 person hours during 2 full test runs consisKng of:• Comprehensive manual regression tesKng
• Data conversion and validaKonCost for tesKng was $17,000 each iteraKon
17
Tuesday, May 8, 2012
Introducing Fit into TesKng Process
ABer 8 iteraKons team had introduced healthy amount of Fit fixtures and automated tests
Reduced 70+ hour test runKme down to 6 hours which now included:• Fit automated regression tesKng
• Data conversion and validaKon automated with Fit fixtures
Reduced cost of tesKng each iteraKon from $17,000 to $7,000
18
Tuesday, May 8, 2012
The Agile Regression TesKng Triangle*
19
* The Agile Triangle has been modified from Mike Cohn’s original version
Tuesday, May 8, 2012
The Agile Regression TesKng Triangle*
19
* The Agile Triangle has been modified from Mike Cohn’s original version
Automated Unit TestsMake up largest por.on ofregression tests and aredeveloped by programmers
Tuesday, May 8, 2012
The Agile Regression TesKng Triangle*
19
* The Agile Triangle has been modified from Mike Cohn’s original version
Automated Unit TestsMake up largest por.on ofregression tests and aredeveloped by programmers
Integra5on TestsAutomated &Exploratory
Tuesday, May 8, 2012
The Agile Regression TesKng Triangle*
19
* The Agile Triangle has been modified from Mike Cohn’s original version
Automated Unit TestsMake up largest por.on ofregression tests and aredeveloped by programmers
Integra5on TestsAutomated &Exploratory
Smoke++ TestsRisk-‐based UI &API AutomatedTests
Tuesday, May 8, 2012
The “3 Amigos” Pa<ern*Quickly get testers, coders, and business on the same page before building based on a requirement
* The Three Amigos paHern originally coined by George DinwiddiehHp://www.s=ckyminds.com/s.asp?F=S17232_COL_2
Tuesday, May 8, 2012
The Three Amigos PaTern
21
As a Shopper I want to receive updates on incredible deals that are located near my home so that I can save money on my purchases
Acceptance Criteria:•Save Shopper’s location•Ask Shopper if they want to receive localized deals daily•Send notification of incredible deals to Shoppers located within 10 miles each morning•Allow Shopper to stop receiving localized deals
Tuesday, May 8, 2012
The Three Amigos PaTern
22
As a Shopper I want to receive updates on incredible deals that are located near my home so that I can save money on my purchases
•What areas of the applica=on will this affect?•What is the overall design? (UI, API, UX, etc…)•What are the details test cases for this user story and it’s acceptance criteria?•What about nega=ve test condi=ons?•What about boundary condi=ons?•How might we put exis=ng func=onality at risk?
Tuesday, May 8, 2012
The Three Amigos PaTern
23
At minimum include tester, coder & business rep in discussion
Should only take 30 minutes to 1 hour for user stories
Focus on clarificaKon and design through testable inputs/
Tuesday, May 8, 2012
Acceptance Test-‐Driven Development
24
Tuesday, May 8, 2012
Release Management“If releases are like giving birth, then you must be doing something wrong.” -‐ Robert Benefield
Tuesday, May 8, 2012
Case Study: Enterprise Agile AdopKon
180+ person “Web 2.0” product organiza=on
Waterfall SDLC that development uses to deliver in 6 month release cycles
Want to use Agile methods to be more responsive to users and keep up with other “Web 2.0” companies
Transi=oned to Agile methods on 15 teams in 3 months
Changed release management strategy, added XP technical prac=ces, and implemented Scrum product development framework for scaled coordina=on
Able to release every week to users within 4 months
Used streamlined deployment environment process to validate product changes daily using Con=nuous Integra=on and automated promo=ons
26
Tuesday, May 8, 2012
The Power of 2 Scripts: Deploy & Rollback
27
Tuesday, May 8, 2012
TradiKonal Source Control Management
28
Tuesday, May 8, 2012
TradiKonal Source Control Management
28
Main Branch
Tuesday, May 8, 2012
TradiKonal Source Control Management
28
Main Branch
Version 1Branch
Integrate forVersion 2
CodeComplete
Tuesday, May 8, 2012
TradiKonal Source Control Management
28
Main BranchDebt
Death March
Version 1Branch
Integrate forVersion 2
CodeComplete
Tuesday, May 8, 2012
TradiKonal Source Control Management
28
Main BranchDebt
Death March {Debt accrues quickly within stabiliza5on periods
Version 1Branch
Integrate forVersion 2
CodeComplete
Tuesday, May 8, 2012
Flexible Source Control Management
29
Tuesday, May 8, 2012
Flexible Source Control Management
29
Main Branch
Tuesday, May 8, 2012
Flexible Source Control Management
29
Main Branch
Version 1
Tuesday, May 8, 2012
Flexible Source Control Management
29
Main Branch
Version 1 Version 2
Tuesday, May 8, 2012
Flexible Source Control Management
29
Main Branch
Version 1 Version 2{Not Easy! Must have proper infrastructure to do this.
Tuesday, May 8, 2012
Scaling ConKnuous IntegraKon
30
ComponentValida5on
Integrated ComponentValida5on
End-‐to-‐End &Load/Stress
Tuesday, May 8, 2012
Automated PromoKon to Environments
31
Tuesday, May 8, 2012
Advanced Quality AsserGons Using Automated Tools and Dashboards
Tuesday, May 8, 2012
ConKnuous IntegraKon
33
Tuesday, May 8, 2012
34
Quality Dashboard -‐ Sonar
Tuesday, May 8, 2012
35
Quality Dashboard -‐ Sonar
Tuesday, May 8, 2012
36
Quality Dashboard -‐ Sonar
Tuesday, May 8, 2012
37
Quality Dashboard -‐ Sonar
Tuesday, May 8, 2012
Early Warning Signs
38
Early Warnings:•Broken Builds•Broken Automated Tests•Broken Custom Thresholds
Tuesday, May 8, 2012
39
Early Warnings:•Design Debt in Duplica=on (DRY)•Technical Debt in Code Complexity•Quality Debt in Bug DB (Break/Fix)•Other Custom Thresholds
Early Warning on Quality Dashboard
Tuesday, May 8, 2012
The “No Defect” Mindset“What he needs is some way to pay back. Not some way to borrow more.” -‐-‐ Will Rogers
39
Tuesday, May 8, 2012
Ken Schwaber “For every [dollar] of compe==ve advantage gained by cuung quality, it costs $4 to restore it; and so)ware is an organiza=onal asset and decisions to cut quality must be made by execu=ve management and reflected in the financial statements.”hHp://www.infoq.com/presenta=ons/agile-‐quality-‐canary-‐coalmine
Tuesday, May 8, 2012
Case Study: Field Support ApplicaKon
2000+ users access applica=on each day
Applica=on supports mul=ple perspec=ves and workflows from Field Support Opera=ons to Customer Service
Team of 5 people delivering features on exis=ng Cold Fusion pla@orm implementa=on
Migra=ng Architecture to Spring/Hibernate in slices while s=ll delivering valuable features
36 2-‐week Sprints, 33 produc=on releases, and only 1 defect found in produc=on
So, what was the defect you say? Let me tell you…
40
Tuesday, May 8, 2012
Can We Afford a “No Defect” Policy?
This team worked on legacy codebase inherited from another vendor
Other vendor had been slowing down month aBer month and cost of development was increasing
In first iteraKon this team was able to deliver more than other vendor was able to in previous 2 months
ABer 24 iteraKons this team was 10 Kmes faster delivery than1st iteraKon
Acceptance Test-‐Driven Development and ConKnuous IntegraKon were greatest technical factors to support team in these results
Can you afford not to have a “No Defect” policy?
41
Tuesday, May 8, 2012
Thank you!QuesKons and Answers[Time permiong]
Tuesday, May 8, 2012
Chris Sterling
Co-‐founder & CTO of Agile Advantage www.AgileAdvantage.com
Author of Book “Managing SoBware Debt: Building for Inevitable Change”
Consults on soBware technology, Agile technical pracKces, Scrum, and effecKve management techniques
InnovaKon Games® Trained Facilitator
CerKfied Scrum Trainer
Open Source Developer
45
Email: [email protected] Web: h<p://www.agileadvantage.comFollow me on TwiTer: @csterwaBlog: h<p://www.ge?ngagile.comHashtag for presentaKon: #swdebt
Tuesday, May 8, 2012