This is a 45 minute presentation I will be delivering at a company-wide meeting to discuss: * How push-button release was used to help entire enterprise go from 6 month to 1 week release cycles * How a "No Defect" team policy with ATDD drives greater productivity

1. Towards a Push-Button Release
Chris Sterling
CTO at AgileEVM Inc.
Web: www.AgileEVM.com
Email: chris@agileevm.com
Blog: www.GettingAgile.com
Follow Me on Twitter: @csterwa
Hash Tag for Presentation: #swdebt
Wednesday, July 13, 2011

2. Chris Sterling – CTO at AgileEVM Inc.
Author of Book “Managing
Software Debt: Building for
Inevitable Change”
Consults on software technology,
Agile technical practices, Scrum,
and effective management
techniques
Certified Scrum Trainer Email: chris@sterlingbarton.com
Web: http://www.agileevm.com
Blog: http://www.gettingagile.com
Innovation Games® Trained Follow me on Twitter: @csterwa
Facilitator
Open Source Developer
© 2011 2
Wednesday, July 13, 2011

3. Reducing Configuration Management Debt
“If releases are like giving birth, then you must be doing something wrong.”
- Robert Benefield
3
Wednesday, July 13, 2011

4. Case Study: Enterprise Agile Adoption
180+ person “Web 2.0” product organization
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
Transitioned to Agile methods on 15 teams in 3 months
Changed release management strategy, added XP technical practices, and
implemented Scrum product development framework for scaled
coordination
Able to release every week to users within 4 months
Used streamlined deployment environment process to validate product
changes daily using Continuous Integration and automated promotions
© 2011 4
Wednesday, July 13, 2011

5. The Power of 2 Scripts: Deploy and Rollback
© 2011 5
Wednesday, July 13, 2011

6. Automated Promotion to Environments
© 2011 6
Wednesday, July 13, 2011

7. Static Code Analysis to Identify Software Debt Early
© 2011 7
Wednesday, July 13, 2011

8. The Effect of a “No Defect” Mindset
“What he needs is some way to pay back. Not some way to borrow more.”
- Will Rogers
8
Wednesday, July 13, 2011

9. Case Study: Field Support Application
2000+ users access application each day
Application supports multiple perspectives and workflows
from Field Support Operations to Customer Service
Team of 5 people delivering features on existing Cold Fusion
platform implementation
Migrating Architecture to Spring/Hibernate in slices while still
delivering valuable features
36 2-week Sprints, 33 production releases, and only 1 defect
found in production
So, what was the defect you say? Let me tell you…
© 2011 9
Wednesday, July 13, 2011

10. Can We Afford a “No Defect” Policy?
This team worked on legacy codebase inherited from another
vendor
Other vendor had been slowing down month after month and cost
of development was increasing
In first iteration this team was able to deliver more than other
vendor was able to in previous 2 months
After 24 iterations this team was 10 times faster delivery than1st
iteration
Acceptance Test-Driven Development and Continuous Integration
were greatest technical factors to support team in these results
Can you afford not to have a “No Defect” policy?
© 2011 10
Wednesday, July 13, 2011

11. Acceptance Test-Driven Development
© 2011 11
Wednesday, July 13, 2011

12. Managing Software Debt
“Promises make debt, and debt makes promises.” - Dutch Proverb
12
Wednesday, July 13, 2011

13. Types of Software Debt
Technical Debt: These are the activities that a team or team members
choose not to do well now and will impede future development if left
undone.
Quality Debt: There is a diminishing ability to verify the functional and
technical quality of software.
Configuration Management Debt: Integration 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 writing from scratch.
Platform Experience Debt: The availability of people to work on software
changes is becoming limited or cost-prohibitive.
© 2011 13
Wednesday, July 13, 2011

14. Thank you
Questions and Answers
14
Wednesday, July 13, 2011