Retrofitting Agile
From AgileOpenNorthwest
Contents |
Retrofitting Agile Development to an Existing Code Base and Team
Co-hosted by Bruce Winegarden, Will Shaver
Participants: Derek Christman, Doug Shanks, Mikey Meneley, Paul Cooley, Jeremy Lightsmith
We discussed special challenges using Agile Development with legacy code and established teams.
What are the desired outcomes for adopting Agile Development? What are the observed characteristics?
Before / After Agile “Makeover” Pictures
We compared our retrofit experiences on 8 different agile projects using a comparison table and then used the observed similarities to conclude with some minimum recommended Agile practices.
Minimal Agile Practices to Retrofit
- Product Owner Always Available On-Demand
- Short Iterations or Sprints
- Daily Standup or Scrum meetings
- Iteration or Sprint Retrospective w/ Actions that actually happen
- Acceptance Test required to count as “done”
- Build Integration must be continuous or at least daily
- Test Coverage with Fast Feedback
Before / After Agile Comparison Table
|
|
SyncroSpec |
FindView |
Centric |
Specialty CAD |
Nike |
Conway |
Imprev |
Grain Millers |
BP |
|
Products |
1 |
1 |
3 |
2 |
1 |
2 |
|
|
|
|
Programming Language(s) |
Java |
Java |
C, C++, .NET Java, AJAX, XML |
FORTRAN, C, C++ |
Java, JSP, XML |
Java, JSP, DB2, Cogen>Cobal generator |
Java, PHP |
PHP |
Java |
|
Lines of code |
200,000 |
100,000 |
>500,000 300,000 |
>1,000,000 ea |
75,000 |
1,000,000 |
|
|
|
|
Size of Dev Team |
3-8 |
3 |
16 |
25 |
4 |
12 |
5 |
5 |
4 |
|
Age B.A.Years |
0 |
3 years |
5-10 years |
10-20 years |
6 |
|
|
|
|
|
Cycles |
|
|
|
|
|
|
|
|
|
|
Sprint Iteration Cycle in Weeks |
2 week |
2 week |
6-8 week milestones ->2 |
4 week |
4 week |
3 week |
2 week |
2-3 days |
4 weeks |
|
Production Release Cycle in Months |
3 month |
6 ->3 |
6 -> 6 |
12 -> 6 |
6-12 |
2-3 mo |
2 week |
2-3 days |
6 mo |
|
Communication |
|
|
|
|
|
|
|
|
|
|
Communication among developers |
Constant (Chatter) Face to Face (F2F) Pairing |
Infrequent -> Daily Go Dark ->Ask For Help(A4H) |
Infrequent ->Daily Go Dark ->A4H
|
Infrequent ->Daily Go Dark ->A4H “One of most notable improvements” |
Go Dark -> A4H |
Go Dark -> F2F |
Go Dark -> F2F |
|
Low -> F2F pairing |
|
Communication across organization w/ PM, QE, HF, Tech Pubs |
Tight Dev-QE Tight PM-Dev |
+Dev-QE +PM-Dev
|
+PM-Dev ~Dev-QE & TP No HF |
+Dev-QE +PM-Dev ? HF |
|
|
A.A.Interactions are all F2F |
|
Analysts, PM, & Dev all F2F DOC-QA pairing |
|
Visibility and Trust in Progress Status |
High |
Low -> High |
Low –> Med Still slipped delivery commitments |
Med -> High More realistic estimates |
High-High |
Low->High |
Low->High |
High-High |
|
|
Top Goal for migrating to Agile Dev |
Time to market w/ sustainable and extensible product |
Take university research to commercial code |
Get better at meeting customer commitments for time and content |
New functions meet customer needs and expectations |
Mandate to lower cost and raise productivity |
Go faster |
Raise quality & more reliable delivery |
Better code maintenance |
Came w/ contract development contract |
|
Practices |
|
|
|
|
|
|
|
|
|
|
Product or Feature Owner |
On-Demand |
OTW - OnD |
OTW - OnD |
OTW - OnD |
|
|
|
|
|
|
Co-Location |
Co-located xp lab environment |
Moved for co-location |
No change, 3 sites mostly by product, with 2-3 distributed |
8 of 25 distributed, setup video cams for daily Scrum |
|
|
|
|
|
|
Code Reviews or Pairing |
First 2 years pair-programming, then as needed |
Pairing on critical, complex, or confusing code |
No change |
Achieved goal for 100% code review |
|
|
|
|
|
|
Velocity w/ Acceptance Test (or Demo) |
Yes |
Yes |
Spotty, lots of carry over |
Yes |
|
|
|
|
|
|
Build Integration |
Continuous |
Continuous |
Weekly |
Daily |
Weekly |
Continuous |
Continuous |
|
|
|
Unit Testing |
40% of total lines of code |
20% of total lines of code |
unit tests for several core behavior modules |
No |
Just started w/ unit tests. ~3% coverage, Not TDD |
Unit tests for all new code |
Unit tests for all new code |
Unit tests for new code |
|
|
Automated Functional Tests |
50% coverage |
20% coverage |
20% coverage |
> 4,000 tests, no significant change A.A. |
Manual QA plan |
Automated functional test for new |
Manual functional tests w/ test plan performed Daily |
Immediately deployed to users |
|
|
Add Covering Tests before Changing Code |
Occasionally recognized need to beef up tests before changes. Usually assumed coverage was adequate. |
Most unit test coverage driven by coverage for changes or adding new classes |
Not a common practice. Only done for selected core modules |
Common developer practice before Agile to extend automated test suite |
No |
Yes |
Yes |
|
|
|
Modularize to Reduce Dependencies |
Constant Refactoring |
Selective Refactoring |
Rewrite & Rearchitect
|
Wrappers Refactor only for major changes |
|
|
|
|
|
|
Fear Factor Changing Old Code |
Low |
High ->Low |
Very High->High |
Med->Med |
High |
Med->Low |
Med->High |
|
|
