Presentation: Technical Lessons Learned Turning the Agile Dials to Eleven
In this presentation filmed during Agile 2008, Craig Smith and Paul King present what happens when one tries to be super Agile. Practically, they employed most currently used Agile practices on several projects, then they experimented with new ideas leading them to better results, increased productivity and quality.
Watch: Technical Lessons Learned Turning the Agile Dials to Eleven (31 min.)
Craig and Paul started a project using a largely accepted set of Agile practices:
- 100% code coverage from unit tests
- All production code paired and test-driven
- Minimal design up front but an appreciation for when such design made sense
- Customer focused outcomes
- Full continuous integration
- Daily pair rotation
- Continuous improvement through retrospectives
- High levels of automation
- Light-weight metrics to monitor progress
After getting good results from applying these practices, Craig and Paul started introducing new practices:
Code Coverage. Each project has a coverage build which runs several times a day which breaks if coverage is not at 100%.
TDD and Pair Programming. All production code is pair programmed using TDD. Some tasks such as build and tool enhancements are not paired.
Test code size. Each project has an evolved agile framework which reduces the amount of test code which must be written. In the early stages of writing tests the ratio of test code to production code was between 1.5 to 2 lines of test code for each line of production code. With the current test framework, the ratio is approximately 1:1.
Auto Components. IDE support is used to create components which include interfaces, concrete classes and their tests; test classes are pre-initialized with code that checks class properties.
Code Size Metrics. Method size is limited to 10 lines, class complexity limited to 5 and the number of parameters to any method is limited to 5.
Auto null checking and class property checking.
No Duplication. The Simian duplication detection tool is used to detect duplication and has a threshold level set to 4 lines of duplication. Any duplication breaks the build.
These practices and others helped Craig and Paul to lower defect rates, obtain maintainable code and better overall quality, and product delivery in time.
Resources that were mentioned
Re: Resources that were mentioned
Here are some relevant links.
Some of the IntelliJ plugins we use:
BDD-style framework incorporating some of the ideas:
TDD-flavored framework incorporating some of the ideas:
Groovy now has some of the ideas baked into the language:
Agile 2008 conference web site from where you can get the conference proceedings:
(I couldn't find a link just now but if you contact them I am sure they will give you the details. If you have no luck, get back in touch and I can see what I can do.)