Managing Software Debt - Quality Debt Focus for QASIG Seattle

Managing So)ware Debt Workshop

Tuesday, May 8, 2012

First Things First...

2

@csterwa

#swdebt


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


http://www.AgileEVM.com


mailto:[email protected]


http://chrissterling.gettingagile.com/




http://www.gettingagile.com




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


Managing So)ware Debt OverviewLet me tell you a potenKally familiar story…



Lack of emphasis on so'ware quality a2ributes contributes to decay


Principle: No maTer what, the cost of addressing soBware debt increases with Kme.


Types of So)ware DebtTechnical, Quality, ConfiguraKon Management, Design, and Pla\orm Experience


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


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


AsserGng QualityTeams must focus on asserKng sustainable quality to support future customer needs in a Kmely manner


DefiniGon of DoneSoBware developments assert what finished, working soBware entails to support predictable delivery into the future


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


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


Case Study: Test AutomaKon Reduces Cost of Change


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


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


The Agile Regression TesKng Triangle*

19

* The Agile Triangle has been modified from Mike Cohn’s original version



19


Automated Unit TestsMake up largest por.on ofregression tests and aredeveloped by programmers



19



Integra5on TestsAutomated &Exploratory



19



Integra5on TestsAutomated &Exploratory

Smoke++ TestsRisk-‐based UI &API AutomatedTests


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


http://www.stickyminds.com/s.asp?F=S17232_COL_2

http://www.stickyminds.com/s.asp?F=S17232_COL_2

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



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?



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/


Acceptance Test-‐Driven Development

24


Release Management“If releases are like giving birth, then you must be doing something wrong.” -‐ Robert Benefield


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


The Power of 2 Scripts: Deploy & Rollback

27


TradiKonal Source Control Management

28



28

Main Branch



28

Main Branch

Version 1Branch

Integrate forVersion 2

CodeComplete



28

Main BranchDebt

Death March

Version 1Branch


CodeComplete



28

Main BranchDebt

Death March {Debt accrues quickly within stabiliza5on periods

Version 1Branch


CodeComplete


Flexible Source Control Management

29



29

Main Branch



29

Main Branch

Version 1



29

Main Branch

Version 1 Version 2



29

Main Branch

Version 1 Version 2{Not Easy! Must have proper infrastructure to do this.


Scaling ConKnuous IntegraKon

30

ComponentValida5on

Integrated ComponentValida5on

End-‐to-‐End &Load/Stress


Automated PromoKon to Environments

31


Advanced Quality AsserGons Using Automated Tools and Dashboards


ConKnuous IntegraKon

33


34

Quality Dashboard -‐ Sonar


35



36



37



Early Warning Signs

38

Early Warnings:•Broken Builds•Broken Automated Tests•Broken Custom Thresholds


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


The “No Defect” Mindset“What he needs is some way to pay back. Not some way to borrow more.” -‐-‐ Will Rogers

39


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


http://www.infoq.com/presentations/agile-quality-canary-coalmine

http://www.infoq.com/presentations/agile-quality-canary-coalmine

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


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


Thank you!QuesKons and Answers[Time permiong]


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














Economy & Finance

Managing Software Debt - Quality Debt Focus for QASIG Seattle