 |
Agile Practices and
Principles Survey Results:
July 2008
|
 |
| |
|
|
 |
This survey was performed the last week of July 2008 and there was
337 respondents.
The survey was announced on the Extreme Programming (XP), Test-Driven
Development (TDD), Scrum Development, Agile Modeling, and Agile
Databases mailing lists. The goal was to find out what agile
developers were actually doing to compare it with what’s being talked
about.
|
|
Some findings include:
- The easier practices, particularly those around
project management,
seem to have a higher adoption rate than the more difficult
practices (such as
TDD)
- Following
coding standards is a bit more
popular than following
database or
UI standards, but all three types
are reasonably common. I expected a higher adoption rate of all
three and think that there’s some room for improvement.
- Adopting pair programming is hard in many organizations
because of management’s lack of understanding of the
benefits of non-solo work. I suspect that the low adoption
of TDD is a result of the low adoption of pair programming
(harder practices like TDD take time and support to learn).
- For all the talk about TDD that we see in the agile
community, it’s nowhere near as popular as doing a
bit of up-front modeling, which we rarely hear
anything positive about.
- Practices with poor tooling support, such as
database refactoring and
database testing, aren’t as
popular as practices with better tooling support
such as code refactoring and developer testing.
- It’s interesting to see that the majority of teams
are doing up front
requirements envisioning
as you can see in Figure 1.
- It’s very interesting to see that the majority of
agile teams are doing some front
architecture
envisioning as you can see in
Figure 2.
- The preferences for hotter
communication
strategies over colder ones seems to hold
- Many people indicated the use of overview
documentation and
diagrams as an effective
form of communication, yet indicated that
detailed documentation was not very
effective (both within the team and with
stakeholders)
Figure 1. Requirements practices on agile projects.
Figure 2. Architecture and design practices on agile
projects.
You may use this data
as you see fit, but may not sell it in whole or in part.
You may publish summaries of the findings, but if you do
so you must reference the survey accordingly (include
the name and the URL to this page). Feel free to
contact me
with questions. Better yet, if you publish,
please let me know so I can link to your work.
Links to Other Articles/Surveys
- My other surveys
Why Share This Much Information?
I'm sharing the results, and in particular the source data, of my surveys for
several reasons:
- Other people can do a much better job of analysis than I can. If
they publish online, I am more than happy to include links to their
articles/papers.
- Once I've published my column summarizing the data in DDJ, I really
don't have any reason not to share the information.
- Too many traditionalists out there like to use the "where's
the proof" question as an excuse not to adopt agile techniques. By
providing some evidence that a wide range of organizations seem to be
adopting these techniques maybe we can get them to rethink things a bit.
- I think that it's a good thing to do and I invite others to do the same.
