The goal of the survey was to explore what agile teams were doing as part of their initiation efforts,
something in Disciplined Agile Delivery (DAD) we refer to as the Inception phase and in Scrum as "Sprint 0".
2013 Agile Project Initiation Survey Results
Some findings include:
- The average agile team invests 4.6 weeks performing up-front Inception activities such as initial modeling, planning, team building, and so on. This is up from 3.9 weeks in the 2009 Agile Project Initiation survey, I suspect because organizations are now applying agile in more complex situations and because we're seeing more structured/mature organizations adopting agile techniques since 2009.
- Figure 1 summarizes the likelihood that agile teams will perform common project initiation tasks. As you can see, the vast majority of agile teams do in fact do some sort of up front modeling and planning.
- Figure 2 depicts the strategies taken by agile teams regarding modeling the initial requirements. As Figure 1 shows, 91% of agile teams invest some time in up-front requirements modeling.
- Figure 3 depicts the strategies taken by agile teams regarding modeling the initial architecture. As Figure 1 shows, 92% of agile teams invest some time in up-front architecture modeling.
- Figure 4 depicts the strategies taken by agile teams regarding initial cost estimation. As Figure 1 shows, 86% of agile teams invest some time in initial cost estimation.
- Figure 5 depicts the strategies taken by agile teams regarding initial scheduling. As Figure 5 shows, 92% of agile teams invest some time in initial scheduling.
Figure 1. Likelihood that an agile team performs common Inception activites.
Figure 2. Initial approach to requirements on agile project teams.
Figure 3. Initial approach to architecture on agile modeling teams.
Figure 4. Initial approach to estimating on agile project teams.
Figure 5. Initial approach to scheduling on agile project teams.
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
with questions. Better yet, if you publish,
please let me know so I can link to your work.
- People didn't know the purpose of the survey, so that likely removed
some bias. My strategy for these sorts of surveys is to send out a short
survey every few months entitled "State of the Agile Union, DATE" but to not
indicate what the topic of the survey actually is.
- This survey suffers from the
fundamental challenges faced by all surveys.
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
- 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
- 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.