2.4 Agile Software Development
2.4.2 Agile Software Development Methodology
model by suggesting that the traditional methodologies did not adequately cope with the “…turbulence of business demands and fluctuating advances in technology” (p. 3). These unpredictable traits of a changing, modern society rendered it almost impossible to anticipate a complete set of the requirements early in the project lifecycle.
Prioritising project manoeuvrability with respect to shifting requirements, shifting technology, and a
shifting understanding of the situation. (Cockburn, 2002) Emergent, iterative and exploratory; not confined by
formal rules; learning through experimentation and introspection, constantly reframing of the problem and its solution
(Dybâ & Dingsoyr, 2009)
Adaptive, iterative, incremental, and people oriented (Abbas et al., 2008)
As indicated in Table 2.1, the elements of dynamism, simple design and quick delivery of working software that underpinned most of the agile methods was a reason for the software engineering community to feel upbeat about the prospect of obviating the dilemma regarding the changeability and invisibility10 that plagued the software development community. The strong focus on providing the customer with a quick, working, initial version of the software system as well as the iterative nature of development provided a measure of confidence that changing customer requirements could easily be accommodated. However, according to Boehm and Turner (2003), agile methods flounder on handling complexity and to some extent conformity. They claim that agile methods are suitable for small projects where there is less complexity. Also, the dynamism inherent in agile methods do not auger well for the desire to impart obedience and order to the software development process. These statements are a serious indictment on the prospect of the newly introduced agile methodology to achieve success levels that could match up to the hype and enthusiasm that these methods initially generated. However, before conducting a critique of the preceding statement, it is only fitting that an incursion into the advent and formalisation of agile methods be undertaken in order to obtain a deeper insight into the philosophical and operational aspects of agile methodology.
10 A reference to Fred Brooks’ indictment on the software crisis in Brooks (1987)
According to Abbas et al. (2008) as well as Dingsøyr et al. (2012), the term agile methodology is used to collectively refer to lightweight software development methods such as Extreme Programming, Scrum, Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD), Crystal, and Adaptive Software Development (ASD). Each of these methods is centered on core principles listed in Table 2.2. In an effort to consolidate the principles espoused by each of the agile methods listed above, a group of 17 software practitioners, who were instrumental in promoting the use of lightweight software development methods in the late 1990’s, put together the Manifesto for Agile Software Development (see Fowler & Highsmith, 2001) that documented their shared philosophy of software development (Misra et al., 2012). The Agile Manifesto, consisting of a set of 12 principles, is holistically based on the core principles listed in Table 2.2. The divergence from traditional software development methodology, interpreted from the original set of 12 principles, is also presented in Table 2.2.
Table 2.2: Core Principles of Agile Manifesto and Divergence from Tradition Core Principles of Agile
Manifesto Divergence from Traditional Practice
Preference is given to individuals and interactions over processes and tools.
An inclination towards a non-prescriptive methodology that is responsive to the social dynamics of the development environment rather than a process; system development is driven by a “self-organising” software development team.
Working software is prioritized over comprehensive
documentation
Software is developed incrementally over shorter time scales using smaller designs;
The focus is on developing specific features of the system thereby facilitating customer collaboration; working software is regarded as the primary measure of progress.
Customer collaboration is valued more than contract negotiation
System developers maintain a high level of interactivity with the business
stakeholders.
Responding to change over following a plan
The lightweight development demeanour enhances the prospect of accommodating changing requirements even late in the development cycle. The rationale is to enable change in order to provide the customer with a competitive advantage.
Cohn, one of the contributors to the Agile Manifesto, makes reference (see Cohn, 2004) to the software development process model that prevailed during the mid-1990 as a ‘mix’ of the following techniques:
Extensive collaboration with end users culminating in informal documents that captured the essence of what the end user desired in the system
Sketching of screen interfaces on paper;
Prototyping;
Coding small parts of the system that would be demonstrated to a representative set of end users.
Cohn (2004) claimed that extensive upfront requirements gathering and documentation can be counter-productive. He cited the inaccuracies of the English language as a pivotal aspect that could compromise efforts at capturing accurate user requirements of a system. These sentiments are an endorsement of the philosophy of maintaining a lightweight, adaptive approach to software development that is enshrined in the Agile Manifesto. Cohn suggests that the agile oriented practice of capturing user requirements as a set of user stories, which entails a short description of the required functionality from the perspective of the user or the customer of the software (Cohn, 2004) is more effective in bridging the gap between the end user and the developer. The technique of documenting user requirements as a set of user stories is more closely aligned to agile methodology in contrast with the technique of compiling a comprehensive user requirements document used for prescriptive process models such as the Waterfall approach or the technique of use case modelling, intrinsic to the UP. The point of departure
regarding these requirements documentation techniques is that user stories are lightweight in the sense that it captures a minimal set of requirements that become the focus of a single iteration of an agile based software project. In order to contextualise the iterative techniques used by agile methods, an overview discussion of these methods will be presented in the subsequent sections. The discussion will be structured around the listing of agile methods presented in Abbas et al. (2008) and Dingsøyr et al. (2012).