Modeling and Documentation: 2013 Open Research
 |
This open research into modeling and documentation in IT 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. |
The Survey Results
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.
Downloads
|
|
|
What You May Do With This Information
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
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.