Agile Practices
The survey explored the effectiveness of various practices on agile projects, both agile and not-so-agile, to determine what is actually working in practice. The results are listed in Table 2, with the most effective practices listed first. The score is the average taken from respondents who responded with a numerical score; the applicable values were 1 to 5, with 5 being very effective, and values of "Don't Know" and "Not Applicable" were not taken into account to calculate the average.
Practice | Average Score out of 5 |
Iterative Development | 4.38 |
Regular Delivery of Working Software | 4.19 |
Configuration Mgmt | 4.06 |
Whiteboard Modeling | 4.01 |
Customer Tests | 3.94 |
TDD | 3.91 |
Daily Stand Ups | 3.88 |
Active Stakeholder Participation | 3.88 |
Coding Standards | 3.83 |
Code Refactoring | 3.81 |
Prove Architecture Early | 3.80 |
Simple Design | 3.78 |
Flexible Architectures | 3.74 |
Evolutionary Design | 3.70 |
Self Organizing Teams | 3.61 |
Initial Agile Arch Modeling | 3.60 |
Initial Agile Req Modeling | 3.57 |
Regular Status Reports | 3.54 |
Independent Testing | 3.53 |
Architectural Spikes | 3.52 |
Paper-Based Modeling | 3.43 |
Code Inspections | 3.43 |
Pair Programming | 3.40 |
Database Testing | 3.37 |
Database Refactoring | 3.31 |
Model Reviews | 3.14 |
CASE Modeling | 3.03 |
I want to share a few observations. First, the high-scoring practices really don't come as a surprise, particularly iterative development and regular delivery of working software. Once again, the agile rhetoric seems to hold. Second, every practice that I asked about was rated above average, although I didn't explore many traditional practices such as detailed up-front modeling and detailed up-front planning because they were covered by questions about the effectiveness of work products. Third, pair programming didn't rate as well as I had expected, probably because many organizations often don't give it sufficient time to take root on a project team. In a conversation with Laurie Williams and Bill Krebs, two people who have done research into pair programming, we decided that the survey should have distinguished between promiscuous pairing where you swap pairs regularly and nonpromiscuous pairing. We suspect that promiscuous pairing would do much better. Fourth, I was a bit disappointed in how database refactoring and database testing did, although, to be fair, this is likely a reflection of the current lack of tool support for these concepts. Tooling is quickly getting better, so I expect the rankings of these practices to rise in future surveys.
The survey also asked about average iteration length on agile projects. Five percent of respondents indicated the last agile project they were on had iterations of less than one week, 17 percent one week, 32.6 percent two weeks, 12.5 percent three weeks, 21 percent four weeks, 10.4 percent five or more weeks, and only 1.4 percent indicated that they didn't do iterations at all. So, it seems that the vast majority of agile teams do reasonably short iterations of between one and four weeks.