Editing Agile software development (section)

===Method tailoring===
In the literature, different terms refer to the notion of method adaptation, including 'method tailoring', 'method fragment adaptation' and 'situational method engineering'. Method tailoring is defined as:

{{Blockquote
|text=A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.
|author=Mehmet Nafiz Aydin et al.
|source=An Agile Information Systems Development Method in use<ref name="Aydin2004">{{cite journal | last1 = Aydin | first1 = M.N. | last2 = Harmsen | first2 = F. | last3 = Slooten | last4 = Stagwee | first4 = R. A. | year = 2004 | title = An Agile Information Systems Development Method in use | journal = Turk J Elec Engin | volume = 12 | issue = 2| pages = 127–138 }}</ref>}}

Situation-appropriateness should be considered as a distinguishing characteristic between agile methods and more plan-driven software development methods, with agile methods allowing product development teams to adapt working practices according to the needs of individual products.<ref>{{Cite book|title=The Paradox of Agile Transformation: Why trying too hard to be Agile stops organisations from becoming truly agile|last=Morris|first=David|publisher=University of Auckland|year=2015|location=NZ|doi=10.13140/RG.2.2.32698.08640}}</ref><ref name="Aydin2004" /> Potentially, most agile methods could be suitable for method tailoring,<ref name="Abrahamsson2002" /> such as [[Dynamic Systems Development Method|DSDM]] tailored in a [[Capability Maturity Model|CMM]] context.<ref name="Abrahamsson2003">Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. ''Proceedings of ICSE'03'', 244-254</ref> and XP tailored with the ''Rule Description Practices'' (RDP) technique.<ref>{{cite book|title=Proceedings of the 2008 international workshop on Scrutinizing agile practices or shoot-out at the agile corral (APOS '08)|last1=Mirakhorli|first1=M.|last2=Rad|first2=A.K.|last3=Shams|first3=F.|last4=Pazoki|first4=M.|last5=Mirakhorli|first5=A.|s2cid=9528636|publisher=ACM|year=2008|isbn=978-1-60558-021-0|pages=23–32|chapter=RDP technique: a practice to customize xp|doi=10.1145/1370143.1370149}}</ref> Not all agile proponents agree, however, with Schwaber noting "that is how we got into trouble in the first place, thinking that the problem was not having a perfect methodology. Efforts [should] center on the changes [needed] in the enterprise".<ref>Schwaber, K (2006) Scrum is hard and disruptive.</ref> Bas Vodde reinforced this viewpoint, suggesting that unlike traditional, large methodologies that require you to pick and choose elements, Scrum provides the basics on top of which you add additional elements to localize and contextualize its use.<ref>Vodde, B (2016) The Story of LeSS. Closing Keynote. Scrum Australia, Melbourne. April, 2016.</ref> Practitioners seldom use [[Software development process|system development methods]], or agile methods specifically, by the book, often choosing to omit or tailor some of the practices of a method in order to create an in-house method.<ref>Lagstedt, A., and Dahlberg, T. (2018). Understanding the Rarity of ISD Method Selection – Bounded Rationality and Functional Stupidity. PACIS 2018 Proceedings. 154. https://aisel.aisnet.org/pacis2018/154.</ref>

In practice, methods can be tailored using various tools. Generic process modeling languages such as [[Unified Modeling Language]] can be used to tailor software development methods. However, dedicated tools for method engineering such as the Essence Theory of Software Engineering of [[SEMAT]] also exist.<ref>Park, J. S., McMahon, P. E., and Myburgh, B. (2016). Scrum Powered by Essence. ACM SIGSOFT Software Engineering Notes, 41(1), pp. 1–8.</ref>