Agile Software Development

When the agile manifesto was published in 2001 it marked the start of the avalanche of the agile approach in the software development.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- Individuals and interactions over processes and tools,

- Working software over comprehensive documentation,

- Customer collaboration over contract negotiation,

- Responding to change over following a "plan." http://www.agilemanifesto.org/

The wording of the manifesto indicates a shift of the focus, perhaps even a sharp turn of the practice, compared to then existing structured practices and defined processes. However, it cannot be considered as a declaration of a new philosophy in the software development, but more a shift in the emphasis towards principles already emerged in the pre-agile era. That said, the significance of this declaration has turned out to be industry trembling. It is the shift that a growing number of organizations are eager to follow. The manifesto has become the most referenced description of what agile is.

In the background for manifesto several methodologies were evolving, which with the manifesto were started to call as the agile methodologies. The most often referred ones are those described in the book of Highsmith (2002), Agile software development ecosystem. These are: Scrum (Schwaber, 1996; Schwaber & Beedle, 2002), Dynamic systems development method (DSDM, 1997), Crystal (Cockburn, 2002), Feature driven development (FDD) (Coad et al 1999; Palmer & Felsing, 2002), Lean development (Charette, 2002), Extreme programming (XP) (Beck, 2000), and Adaptive software development (ASD) (Highsmith, 2000). Abrahamsson, Warsta, Siponen and Ronkainen (2003) adds also Agile modeling (AM) (Ambler, 2002), Internet speed development (ISD) (Baskerville &Pries-Heije, 2001), and Pragmatic programming (PP) (Hunt & Thomas, 2000) to the list. All of these have their own application area and unique emphasis in approach.


This diversity has led to need to generate means to put these methodologies onto same continuum. Which created a large number of categorizing factors. Kettunen (2009) lists 11 sources each proposing a different classification criterion. Highsmith (2002) proposes 6 minimum practices that a methodology should contain if called as agile. Abrahamsson et al (2003) proposes additional 6 perspectives to analyze what an agile methodology may contain. Overall, it seems unlikely, that there would be one common view and one common interpretation of what agile software development is and what practices and methods it consists of. On the other hand, this diversity gives every applier the opportunity to compose his own agile methodology fully suited to his needs (Highsmith, 2002).