Agile Cadences and Technical Debt: 2015 Open Research
 |
This open research into agile cadences and technical debt was performed in early 2015 until under the title “2015 Q1 Agile State of the Art Survey”. The survey was announced in my Twitter feed, and several LinkedIn discussion forums (Disciplined Agile Delivery, Agile and Lean Software Development, Agile CMMI, and Scrum Practitioners ). |
The Survey Results
Some findings include:
- Figure 1 shows that two-thirds of agile teams have a two week iteration length.
- Figure 2 shows that the majority of agile teams release internally, into either a demo or a testing environment, at least once an iteration.
- Figure 3 shows that half of agile teams release into production at least once a month.
- Figure 4 depicts the prevalence of technical debt avoidance strategies being taken by agile teams.
- Figure 5 depicts the prevalence of technical debt removal strategies being taken by agile teams.
- Figure 6 depicts the prevalence of technical debt funding strategies being taken by agile teams.
- Figure 7 explores how aware of technical debt issues are certain groups within an organization.
Figure 1. Iteration lengths on agile teams.
Figure 2. Iternal release cadences on agile teams.
Figure 3. Production release cadences on agile teams.
Figure 4. Technical debt avoidance strategies.
Figure 5. Technical debt removal strategies.
Figure 6. Technical debt funding strategies.
Figure 7. Technical debt awareness.
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.
Discussion of the Results
- 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 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.