Software Development at Scale: 2014 Open Research
 |
This open research into software development at scale was performed during the Spring of 2014 and there was 231 respondents. The survey was announced in my Feburary 2014 DDJ article The Non-Existent Software Crisis: Debunking the Chaos Report and on Twitter. The primary goals of the survey were to find out what levels of scale were being faced by teams and to see how successfull teams were by paradigm. We looked at several factors as called out in the way of working (WoW) tailoring factors. My detailed analysis was published on DrDobbs.com under the title Software Development is Very, Very Hard: Even for those who know it’s hard . |
The Survey Results
Some findings include:
- Figure 1 shows the relative breakdown of the approaches taken by development teams. Roughly half of respondents work on teams following a mostly agile approach.
- Figure 2 depicts the scaling complexities faced by software development teams.
- Figure 3 shows how agile teams, on average, compare against non-agile teams when it comes to addressing common success factors.
- Agile teams, on average, are a bit larger than traditional teams
- Agile teams are less likely to be geographically distributed than non-agile teams
- Figure 4 shows that the majority of agile teams are geographically distributed in some way
- Agile teams, on average, address greater domain complexity (e.g. they take on harder problems) than traditional teams
- Agile teams face the same level of technical complexity as non-agile teams
- Agile teams are just as likely to face compliance issues as non-agile teams
Figure 1. The paradigm primarily followed by software development teams.
Figure 2. Scaling complexities faced by development teams.
Figure 3. How Agile compares, by succcess factor.
Figure 4. How geographically distributed are Agile teams?
|
|
|
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.
Discussion of the Results
- People didn’t know the purpose of the survey, so that likely removed some bias. My strategy for the DDJ surveys is to send out a short survey every two months entitled “State of the IT Union, DATE” but to not indicate what the topic of the survey actually is (other than an IT topic of
course). - This survey suffers from the fundamental challenges faced by all surveys.
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 r eason 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.