Recognizing Software Debt - Beyond Agile Puget Sound

Recognizing So+ware DebtWednesday, November 30, 2011

Chris Sterling Co-‐founder of Agile Advantage and VP of Engineering (www.AgileAdvantage.com) Author of Book “Managing SoAware Debt: Building for Inevitable Change” Consults on soAware technology, Agile technical pracKces, Scrum, and eﬀecKve management techniques CerKﬁed Scrum Trainer Email: chris@agileadvantage.com InnovaKon Games® Trained Facilitator Web: h3p://www.agileadvantage.com Follow me on Twi0er: @csterwa Open Source Developer Blog: h3p://www.ge8ngagile.com Hashtag for presenta:on: #swdebt 2Wednesday, November 30, 2011

Go to ImpedimentMonkey.com!!! Send an email to Louie@impedimentmonkey.com to get invited with your ﬁrst impediment now!!! 3Wednesday, November 30, 2011

Agenda Managing SoAware Debt • ConKnuous IntegraKon • An Overview • Quality Dashboards Types of SoAware Debt Release Management • Technical • The Power of 2 Scripts: • Quality Deploy and Rollback • ConfiguraKon Management • ConKnuous IntegraKon • Design • Automated PromoKon • PlaUorm Experience • Turn On/Off Features Balancing Signal to Noise Exercise • DefiniKon of Done • SoAware Debt Management Strategy • Source Control Management 4Wednesday, November 30, 2011

Managing So+ware Debt An OverviewWednesday, November 30, 2011

THE DISECONOMIES OF SCALE IN SOFTWARE DEVELOPMENT* Project size is easily the most signiﬁcant determinant of eﬀort, cost and schedule [for a soIware project]. * “SoIware Es:ma:on: Demys:fying the Black Art “ – Steve McConnellWednesday, November 30, 2011

Big Ball of Mud “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-‐tape-‐and-‐baling-‐wire, spagheZ-‐code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Informa:on is shared promiscuously among distant elements of the system, oIen to the point where nearly all the important informa:on becomes global or duplicated. The overall structure of the system may never have been well deﬁned. If it was, it may have eroded beyond recogni:on. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the iner:a of the day-‐to-‐day chore of patching the holes in these failing dikes, are content to work on such systems.” * * Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Pa0erns Languages of Programs (PLoP 97/EuroPLoP 97) Mon:cello, Illinois, September 1997Wednesday, November 30, 2011

Wednesday, November 30, 2011

Lack of emphasis on soware quality a2ributes contributes to decayWednesday, November 30, 2011

Types of So+ware DebtWednesday, November 30, 2011

Why not just call it all “ Technical Debt” Technical debt tended to focus more on programming aspects of soIware delivery and leI out full soIware development life cycle Each type of soIware debt can be managed and monitored using diﬀerent tools and approaches Focusing on managing each type of soIware debt simpliﬁes crea:on of an overall strategy that promotes holis:c perspec:ve 11Wednesday, November 30, 2011

Types of SoIware Debt Technical Debt: These are the ac:vi:es that a team or team members do not to do well now that will impede future development if leI as is. Quality Debt: There is a diminishing ability to verify the func:onal and technical quality of soIware: the “Break/Fix” mentality. ConﬁguraHon 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. PlaJorm Experience Debt: The availability and alignment of people to business objec:ves that involve soIware changes is becoming more limited or cost-‐prohibi:ve. 8Wednesday, November 30, 2011

Principle: No maOer what, the cost of addressing so+ware debt increases with Hme.Wednesday, November 30, 2011

Balancing Signal to Noise at ScaleWednesday, November 30, 2011

Balancing Signal Indicators Value Quality Constraints Source: Jim Highsmith (Schedule, Cost, Scope) 15Wednesday, November 30, 2011

DefiniMon of Done -‐ Assert Quality Acceptance defined criteria for each Code checked in with reference to user story US#/Task# Unit tests written and passed Tested on FE Code compiles with no errors and no Integration test written & passes warnings Test code reviewed New code doesn’t break existing code Environment requirements documented Test case review (Dev to review test Interface document updated/added case written) and checked in to SVN Architectural impact assessed and Acceptance criteria verified 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 16Wednesday, November 30, 2011

Release DefiniMon of Done Every release should have clear quality criteria With a “Release Defini:on of Done” you can understand targets be0er Measure the gap between the teams’ Defini:on of Done and a Release Defini:on of Done. • This gap is a source of quality issues and represents significant risk to scheduleWednesday, November 30, 2011

TradiMonal Source Control Management 18Wednesday, November 30, 2011

TradiMonal Source Control Management Main Branch 18Wednesday, November 30, 2011

TradiMonal Source Control Management Code Complete Version 1 Integrate for Branch Version 2 Main Branch 18Wednesday, November 30, 2011

TradiMonal Source Control Management Code Complete Version 1 Integrate for Branch Version 2 Debt Main Branch Death March 18Wednesday, November 30, 2011

TradiMonal Source Control Management Code Complete Version 1 Integrate for Branch Version 2 Debt Main Branch Death March { Debt accrues quickly within stabilizaHon periods 18Wednesday, November 30, 2011

Flexible Source Control Management 19Wednesday, November 30, 2011

Flexible Source Control Management Main Branch 19Wednesday, November 30, 2011

Flexible Source Control Management Version 1 Main Branch 19Wednesday, November 30, 2011

Flexible Source Control Management Version 1 Version 2 Main Branch 19Wednesday, November 30, 2011

Flexible Source Control Management Version 1 Version 2 Main Branch { Not Easy! Must have proper infrastructure to do this. 19Wednesday, November 30, 2011

ConMnuous IntegraMon 20Wednesday, November 30, 2011

Quality Dashboard -‐ Sonar 21Wednesday, November 30, 2011

Early Warning Signs Early Warnings: •Broken Builds •Broken Automated Tests •Broken Custom Thresholds 25Wednesday, November 30, 2011

Early Warning on Quality Dashboard Early Warnings: •Design Debt in Duplica:on (DRY) •Technical Debt in Code Complexity •Quality Debt in Bug DB (Break/Fix) •Other Custom Thresholds 26Wednesday, November 30, 2011

Release Management StrategyWednesday, November 30, 2011

“If releases are like giving birth, then you must be doing something wrong.” -‐ Robert BeneﬁeldWednesday, November 30, 2011

Case Study: Enterprise Agile AdopMon 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 29Wednesday, November 30, 2011

The Power of 2 Scripts: Deploy & Rollback 30Wednesday, November 30, 2011

Scaling ConMnuous IntegraMon End-‐to-‐End & Load/Stress Integrated Component ValidaHon Component ValidaHon 31Wednesday, November 30, 2011

Automated PromoMon to Environments 32Wednesday, November 30, 2011

The value of technical aspects in an applica:on or its surrounding infrastructure is the cost of not addressing them. 29Wednesday, November 30, 2011

Describe as Abuse User Stories Implement Security for User Information * From “User Stories Applied” presented by Mike Cohn Agile 2006 30Wednesday, November 30, 2011

Describe as Abuse User Stories Implement Security As a Malicious Hacker I want to steal credit card for User Information information so that I can make fraudulent charges * From “User Stories Applied” presented by Mike Cohn Agile 2006 30Wednesday, November 30, 2011

Some PotenMal Abusers • Malicious Hacker • Mass of users • SQL injector • Disgruntled employee • Naïve API user • ImpaBent clicker • Denial-‐of-‐service (DoS) aFacker • Sleazy user 31Wednesday, November 30, 2011

SoIware Quality A0ributes Deﬁned 32Wednesday, November 30, 2011

SoIware Quality A0ributes Ra:ng Tool 33Wednesday, November 30, 2011

Put SoIware Debt on Product Roadmap * Image from Dean Leﬃngwell’s blog -‐ h0p://scalingsoIwareagility.wordpress.com/ 34 38Wednesday, November 30, 2011

Exercise: So+ware Debt Management StrategyWednesday, November 30, 2011

Thank you! QuesHons & AnswersWednesday, November 30, 2011

Come see us at AgileAdvantage.com 41Wednesday, November 30, 2011

http://www.gettingagile.com	1118
http://paper.li	13
http://www.linkedin.com	11
http://tweetedtimes.com	1

Recognizing Software Debt - Beyond Agile Puget Sound

by Chris Sterling on Nov 30, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 1,143

Statistics

Recognizing Software Debt - Beyond Agile Puget Sound — Presentation Transcript