Editing Agile software development (section)

==Methods==
[[File:SoftwareDevelopmentLifeCycle.jpg|thumb|right|Software development life cycle support<ref name="Abrahamsson2002">{{cite tech report|first=Pekka|last=Abrahamson|first2=Outi|last2=Salo|first3=Jussi|last3=Ronkainen|first4=Juhani|last4=Warsta|name-list-style=vanc|title=Agile software development methods: Review and analysis|number=478|institution=[[VTT]]|year=2002|url=http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf}}</ref>]]
[[File:Unified_Process_Model_for_Iterative_Development.svg|thumb|right|[[Agile unified process]] (AUP) is based on [[unified process]] (an iterative and incremental software development process framework).]] 
Agile software development methods support a broad range of the [[software development life cycle]].<ref name="Abrahamsson2002" /> Some methods focus on the practices (e.g., [[Extreme programming|XP]], [[The Pragmatic Programmer|pragmatic programming]], agile modeling), while some focus on managing the flow of work (e.g., Scrum, Kanban). Some support activities for requirements specification and development (e.g., [[Feature-driven development|FDD]]), while some seek to cover the full development life cycle (e.g., [[Dynamic systems development method|DSDM]], [[Rational Unified Process|RUP]]).

Notable agile software development frameworks include:
{| class="wikitable"
! Framework
! Main contributor(s)
|-
| [[Adaptive software development]] (ASD) || [[Jim Highsmith]], Sam Bayer
|-
| [[Agile modeling]] || [[Scott Ambler]], [[Robert Cecil Martin]]
|-
| [[Agile Unified Process|Agile unified process]] (AUP) || [[Scott Ambler]]
|-
| [[Disciplined agile delivery]] || [[Scott Ambler]]
|-
| [[Dynamic systems development method]] (DSDM) ||Jennifer Stapleton
|-
| [[Extreme programming]] (XP) || [[Kent Beck]], [[Robert Cecil Martin]]
|-
| [[Feature-driven development]] (FDD) || [[Jeff De Luca]]
|-
| [[Lean software development]] || Mary Poppendieck, Tom Poppendieck
|-
| [[Lean startup]] || [[Eric Ries]]
|-
| [[Kanban (development)|Kanban]] || [[Taiichi Ohno]]
|-
| [[Rapid application development]] (RAD) || [[James Martin (author)|James Martin]]
|-
| [[Scrum (software development)|Scrum]] || [[Ken Schwaber]], [[Jeff Sutherland]]
|-
| [[Scrumban]] ||
|}

=== Agile software development practices ===
Agile software development is supported by a number of concrete practices, covering areas like requirements, design, modeling, coding, testing, planning, risk management, process, quality, etc. Some notable agile software development practices include:<ref name="Agile Practices Guide">{{cite web|url=http://guide.agilealliance.org/ |title=Guide to Agile Practices |publisher=the Agile Alliance |url-status=dead |archive-url=https://web.archive.org/web/20140209152034/http://guide.agilealliance.org/ |archive-date=9 February 2014}}</ref>
{| class="wikitable"
! Practice
! Main contributor(s)
|-
|[[Acceptance test-driven development]] (ATDD) || Ken Pugh
|-
| [[Agile modeling]] || [[Scott Ambler]]
|-
| [[Agile testing]] || Lisa Crispin, Janet Gregory 
|- 
|[[Scrum (development)#Product backlog|Backlogs]] (Product and Sprint)|| [[Ken Schwaber]], [[Jeff Sutherland]]
|- 
|[[Behavior-driven development]] (BDD) || Dan North, Liz Keogh
|- 
|[[Continuous integration]] (CI) || [[Grady Booch]]
|- 
|[[Cross-functional team]] ||
|-
|[[Stand-up meeting|Daily stand-up / Daily Scrum]]
|[[Jim Coplien|James O Coplien]]
|- 
|[[Domain-driven design]] (DDD) || Eric Evans
|-
| [[Iterative and incremental development]] (IID) ||
|-
|[[Pair programming]] || [[Kent Beck]]
|-
|[[Planning poker]] || James Grenning, [[Mike Cohn]]
|-
|[[Refactoring]] || [[Martin Fowler (software engineer)|Martin Fowler]]
|-
|[[Retrospective]] || Esther Derby, Diana Larsen, Ben Linders, Luis Gonçalves
|-
|[[Scrum (development)|Scrum events]] (sprint planning, sprint review and retrospective) || [[Ken Schwaber]], [[Jeff Sutherland]]
|-
| [[Specification by example]] ||
|-
|[[Story-driven modeling]] || Albert Zündorf
|-
| [[Test-driven development]] (TDD) || [[Kent Beck]]
|-
|[[Timeboxing]] ||
|-
| [[User story]] || [[Alistair Cockburn]] 
|-
| [[Velocity (software development)|Velocity tracking]] ||
|}

====Acceptance test-driven development====
{{Excerpt|Acceptance test-driven development|only=paragraph}}

====Agile modeling====
{{Excerpt|Agile modeling|only=paragraph}}

====Agile testing====
{{Excerpt|Agile testing|only=paragraph}}

====Backlogs====
{{Excerpt|Product backlog|only=paragraph}}

====Behavior-driven development====
{{Excerpt|Behavior-driven development|only=paragraph}}

====Continuous integration====
{{Excerpt|Continuous integration|only=paragraph}}

====Cross-functional team====
{{Excerpt|Cross-functional team|only=paragraph}}

====Daily stand-up====
{{Excerpt|Stand-up meeting|only=paragraph}}

===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>

=== Large-scale, offshore and distributed ===
Agile software development has been widely seen as highly suited to certain types of environments, including small teams of experts working on [[greenfield project]]s,<ref name="boehm2004">{{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|pages=55–57|author2-link=Richard Turner (software)}}</ref><ref name="beck1999">{{cite book|last=Beck|first=K.|author-link=Kent Beck|title=Extreme Programming Explained: Embrace Change|publisher=Addison-Wesley|location=Boston, MA|year=1999|isbn=978-0-321-27865-4}}</ref> and the challenges and limitations encountered in the adoption of agile software development methods in a large organization with [[Legacy system|legacy infrastructure]] are well-documented and understood.<ref>{{cite web|last=Evans|first=Ian |title=Agile Delivery at British Telecom|url=http://www.methodsandtools.com/archive/archive.php?id=43| access-date =21 February 2011}}</ref>

In response, a range of strategies and patterns has evolved for overcoming challenges with large-scale development efforts (>20 developers)<ref name="ambler2006"/><ref name="sstc2007">Schaaf, R.J. (2007). Agility XL [http://www.sstc-online.org/Proceedings/2007/pdfs/RJS1722.pdf Systems and Software Technology Conference 2007] {{webarchive|url=https://web.archive.org/web/20160313105019/http://sstc-online.org/proceedings/2007/pdfs/rjs1722.pdf |date=13 March 2016 }}, Tampa, FL</ref> or distributed (non-colocated) development teams,<ref name="BridgingTheDistance">{{cite web|url=http://www.drdobbs.com/architecture-and-design/184414899 |title=Bridging the Distance |publisher=Sdmagazine.com |access-date=1 February 2011}}</ref><ref name="AgileOffshore">{{cite web|first=Martin |last=Fowler |url=http://www.martinfowler.com/articles/agileOffshore.html |title=Using an Agile Software Process with Offshore Development |publisher=Martinfowler.com |access-date=6 June 2010}}</ref> amongst other challenges; and there are now several recognized frameworks that seek to mitigate or avoid these challenges.

There are many conflicting viewpoints on whether all of these are effective or indeed fit the definition of agile development, and this remains an active and ongoing area of research.<ref name="ambler2006">W. Scott Ambler (2006) [http://www.drdobbs.com/184415491 Supersize Me] in Dr. Dobb's Journal, 15 February 2006.</ref><ref name="oopsla2002">Agile Processes Workshop II Managing Multiple Concurrent Agile Projects. Washington: OOPSLA 2002</ref>

When agile software development is applied in a distributed setting (with teams dispersed across multiple business locations), it is commonly referred to as [[distributed agile software development]]. The goal is to leverage the unique benefits offered by each approach. Distributed development allows organizations to build software by strategically setting up teams in different parts of the globe, virtually building software round-the-clock (more commonly referred to as follow-the-sun model). On the other hand, agile development provides increased transparency, continuous feedback, and more flexibility when responding to changes.

=== Regulated domains ===
Agile software development methods were initially seen as best suitable for non-critical product developments, thereby excluded from use in regulated domains such as [[medical device]]s, pharmaceutical, financial, nuclear systems, automotive, and avionics sectors, etc. However, in the last several years, there have been several initiatives for the adaptation of agile methods for these domains.<ref name="Cawley2010">{{Cite book|date = 2010|isbn = 978-3-642-16415-6|pages = 31–36|series = Lecture Notes in Business Information Processing|volume = 65|first1 = Oisín|last1 = Cawley|first2 = Xiaofeng|last2 = Wang|first3 = Ita|last3 = Richardson| title=Lean Enterprise Software and Systems | chapter=Lean/Agile Software Development Methodologies in Regulated Environments – State of the Art |editor-first = Pekka|editor-last = Abrahamsson|editor2-first = Nilay|editor2-last = Oza|doi=10.1007/978-3-642-16416-3_4|hdl = 10344/683}}</ref><ref name="McHugh2014">{{Cite book|date = 2014-11-04|isbn = 978-3-319-13035-4|pages = 190–201|series = Communications in Computer and Information Science|volume = 477|first1 = Martin|last1 = McHugh|first2 = Fergal|last2 = McCaffery|first3 = Garret|last3 = Coady| title=Software Process Improvement and Capability Determination | chapter=An Agile Implementation within a Medical Device Software Organisation |editor-first = Antanas|editor-last = Mitasiunas|editor2-first = Terry|editor2-last = Rout|editor3-first = Rory V.|editor3-last = O'Connor|editor4-first = Alec|editor4-last = Dorling| display-editors = 3|doi=10.1007/978-3-319-13036-1_17|url = https://arrow.dit.ie/cgi/viewcontent.cgi?article=1152&context=scschcomcon}}</ref><ref>{{Cite book|last1=Wang|first1=Yang|last2=Ramadani|first2=Jasmin|last3=Wagner|first3=Stefan|title=Product-Focused Software Process Improvement |chapter=An Exploratory Study on Applying a Scrum Development Process for Safety-Critical Systems |date=2017-11-29|series=Lecture Notes in Computer Science|language=en|volume=10611|pages=324–340|arxiv=1703.05375|doi=10.1007/978-3-319-69926-4_23|isbn=9783319699257|bibcode=2017arXiv170305375W|s2cid=4585465}}</ref><ref name="SafeScrum">{{cite web|url=http://www.sintef.no/safescrum |title=SafeScrum - SINTEF |publisher=Sintef.no |access-date=2019-03-26}}</ref><ref>Thor Myklebust, Tor Stålhane, Geir Kjetil Hanssen, Tormod Wien and Børge Haugset: Scrum, documentation and the IEC 61508-3:2010 software standard, http://www.sintef.no/globalassets/ec-61508-documentation-and-safescrum-psam12.pdf</ref>

There are numerous standards that may apply in regulated domains, including [[ISO 26262]], [[ISO 9000]], [[ISO 9001]], and [[ISO/IEC 15504]].
A number of key concerns are of particular importance in regulated domains:<ref name="Fitzgerald2013">{{Cite book|date = May 2013|pages = 863–872|doi = 10.1109/ICSE.2013.6606635|first1 = B.|last1 = Fitzgerald|first2 = K.-J.|last2 = Stol|first3 = R.|last3 = O'Sullivan|first4 = D.|last4 = O'Brien| title=2013 35th International Conference on Software Engineering (ICSE) | chapter=Scaling agile methods to regulated environments: An industry case study |isbn = 978-1-4673-3076-3|hdl = 10344/3055|s2cid = 192403}}</ref>

* [[Quality assurance]] (QA): Systematic and inherent quality management underpinning a controlled professional process and reliability and correctness of product.
* Safety and security: Formal planning and risk management to mitigate safety risks for users and securely protecting users from unintentional and malicious misuse.
*[[Traceability]]: Documentation providing auditable evidence of regulatory compliance and facilitating traceability and investigation of problems.
* [[Verification and validation]] (V&V): Embedded throughout the software development process (e.g. user requirements specification, functional specification, design specification, code review, unit tests, integration tests, system tests).