Editing Agile software development (section)

=== Adaptive vs. predictive ===
Development methods exist on a continuum from ''adaptive'' to ''predictive''.<ref name="boehm2004App">{{cite book|last=Boehm|first=B.|author-link=Barry Boehm|author2=R. Turner|title=Balancing Agility and Discipline: A Guide for the Perplexed|publisher=Addison-Wesley|location=Boston, MA|year=2004|isbn=978-0-321-18612-6|author2-link=Richard Turner (software)}} Appendix A, pages&nbsp;165–194</ref> Agile software development methods lie on the ''adaptive'' side of this continuum. One key of adaptive development methods is a [[Rolling Wave planning|''rolling wave'']] approach to schedule planning, which identifies milestones but leaves flexibility in the path to reach them, and also allows for the milestones themselves to change.<ref>{{cite book | title=Agile and Iterative Development: A Manager's Guide | last=Larman | first=Craig | year=2004 |page=253 | chapter=Chapter 11: Practice Tips | publisher=Addison-Wesley Professional |  isbn=9780131111554 | chapter-url=https://books.google.com/books?id=76rnV5Exs50C&q=adaptive%20predictive%20%22rolling%20wave%22&pg=PA253 | access-date=14 October 2013}}</ref>

''Adaptive'' methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team has difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method is about what will happen on that date. An adaptive team cannot report exactly what tasks they will do next week, but only which features they plan for next month. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.

''Predictive'' methods, in contrast, focus on analyzing and planning the future in detail and cater for known risks. In the extremes, a predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive methods rely on effective early phase analysis, and if this goes very wrong, the project may have difficulty changing direction. Predictive teams often institute a [[change control board]] to ensure they consider only the most valuable changes.

[[Risk analysis (engineering)|Risk analysis]] can be used to choose between adaptive (''agile'' or ''value-driven'') and predictive (''plan-driven'') methods.<ref name="PMBridgeToAgility">{{Cite book |last1=Sliger |first1=Michele |last2=Broderick |first2=Stacia |title=The Software Project Manager's Bridge to Agility |publisher=Addison-Wesley |year=2008 |isbn=978-0-321-50275-9 |page=46 }}</ref> [[Barry Boehm]] and [[Richard Turner (computer scientist)|Richard Turner]] suggest that each side of the continuum has its own ''home ground'', as follows:<ref name="boehm2004"/>

{| class="wikitable"
|+ Home grounds of different development methods
|-
! style="width: 33%" | Value-driven methods (agile)
! style="width: 33%" | Plan-driven methods (waterfall)
! [[Formal methods]]
|-
| Low criticality
| High criticality
| Extreme criticality
|-
| Senior developers
| Junior developers(?)
| Senior developers
|-
| Requirements change often
| Requirements do not change often
| Limited requirements, limited features, see [[Wirth's law]]{{Clarify|date=December 2015}}
|-
| Small number of developers
| Large number of developers
| Requirements that can be modeled
|-
| Culture that responds to change
| Culture that demands order
| Extreme quality
|}