BT

Presentation: Technical Lessons Learned Turning the Agile Dials to Eleven

by Abel Avram on Oct 30, 2008 |

 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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Resources that were mentioned by Matthew Cooper

Interesting ideas. I'd be interested in the white paper and the open source projects that were mentioned in the presentation. Any ideas where I can get hold of them?

Re: Resources that were mentioned by Paul King

Hi Matthew,

Here are some relevant links.

Some of the IntelliJ plugins we use:
code.google.com/p/agileplugins/

BDD-style framework incorporating some of the ideas:
code.google.com/p/instinct/

TDD-flavored framework incorporating some of the ideas:
geekscape.org/daisy/geekscape/g2/128.html

Groovy now has some of the ideas baked into the language:
groovy.codehaus.org/

Agile 2008 conference web site from where you can get the conference proceedings:
agile2008.org/
(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.)

Cheers, Paul.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT