2.4 Agile Software Development
2.4.6 Challenges Facing Agile Software Development Methodology
approach to software development, the increasing popularity of agile methodology has culminated in the establishment of the methodology as the de facto methodology for software development (Dingsøyr & Moe, 2014; Scheerer et al., 2014). A possible explanation for this phenomenon could be traced back to Jackson’s (1995) ontological analysis on the state of computing and his reference to the conceptual gaps of understanding between the technological realm and the societal realm and the need for software developers to bridge this gap. According to Boehm and Turner (2003), the agile philosophy of elevating the significance of individuals and interactions over processes and tools is a step in the right direction towards the quest to lessen the gap between the technology and the society in which the technology will be used. A pivotal strategy in this regard is the agile tactic of obtaining maximum input from the customer by suggesting the presence of an on-site customer to provide the development team with accurate user stories and to provide feedback on the evolving system at review meetings thereby ensuring a high level of customer involvement throughout the development life- cycle of the system. This is unlike prescriptive development methodologies such as the Waterfall methodology where customer requirements are established at the beginning of the development effort with very little recourse left to the customer
to subsequently adjust the requirements specifications document in response to a volatile application domain (Abbas et al., 2008).
The benefit of having extensive user involvement in the software development process is confirmed by Bano and Zowghi (2013) and Kundalram (2013) who reported on the positive correlation between user involvement and system success. Congruous to this finding, Morandini et al. (2017) refer to the imperative for software development practices that were observant of changing user requirements because of the dynamic nature of the social context in which these systems function. To a large extent, these requirements resonate quite well with many of the principles underlying the agile philosophy of software development. From a practitioner perspective, the allure of using a methodology that is adaptive and oriented towards satisfying user requirements has been instrumental in ensuring high adoption rates of agile methodology. The popularity of Scrum has largely been attributed to the resilience of the methodology to an unstable requirements elicitation phase. The adjustments that may made to the Product Backlog to factor-in new and changing user requirements is all part of the framework of development practices intrinsic to the Scrum methodology. The academic community has also accepted that agile methodology has generally been instrumental in improving the software process. There is however a concern regarding the lack of empirical evidence in the academic literature attesting to the success of the methodology and the lack of an integrative theory to underpin studies that analyse the success of the methodology (Abrahamsson et al., 2009;
Dybâ & Dingsoyr, 2008; Paulk, 2014)
The current discourse on agile software development has covered a spectrum of agile methods such as the strategy of enlisting an on-site customer to enhance development, pair programming, TDD and code refactoring, minimalist documentation and up-front system designs. These methods have been classified under 2 prominent agile methodologies named Scrum and XP. The distinctive strengths of Scrum is to enable better project management while XP provides software engineering guidance to enhance the quality of the coding effort. There is however, a unanimous acknowledgement that the agile methods are context-bound
to the specific requirements of the project. A framework to guide the contextual applicability of agile methodology is provided in Table 2.4. This framework comprises of contributions by Boehm (2002), who provides an ideal scenario for the optimal implementation of agile methodology (named the ‘Agile sweet-spot’ in Table 2,4) and a counter scenario, (named the ‘Agile bitter-spot’ in Table 2.4) suggested by Kruchten (2004).
Table 2.4: Agile Sweet-spot (Boehm, 2002) and Agile Bitter-spot (Kruchten, 2004)
Aspect Agile Sweet-spot Agile Bitter-spot
System Specifications
Emergent requirements;
rapid and late change to the requirements specifications is expected
Type of project New development projects Maintenance projects Project Duration Shorter development
timeframe; 2 to 3 months Long term project spanning up to 2 years
Location of
Development team
Developers need to be knowledgeable about the process, co-located and collaborative
Development team works in a distributed environment
Size of development team
Development team is small;
15 to 20 developers is optimal
Large development team;
excess of 200 developers
Customer
There is a core need to have a dedicated, on-site
customer who is representative of the application domain
The lack of a representative, on-site customer
Refactoring and Documentation
Refactoring and
documentation should not incur major overhead
A system that needs
extensive documentation to faciltate continuity and communication between team members
According to Turk et al. (2014), knowledge of the context of application for agile methods is pivotal in order to maximise the value obtained from agile methodology. Aligned to this claim, Turk et al. conducted an analysis of the assumptions underlying agile methodology in order to generate a list of conditions that provide guidance with regards to the applicability of agile methods. The conditions identified in the analysis conducted by Turk et al. are congruent with the listing in Table 2.4. The notable addition to this list is a reference to the limited support that agile methodology provides for the development of safety-critical software. This claim is based on the minimal focus on formal software engineering techniques (such as formal specifications, rigorous code path testing, extensive documentation, quality assurance and continuous redesign) in the underlying assumptions of agile methodology.
What has emerged from the preceding discussion is that the successful implementation of agile methodology is intrinsically linked to its context of implementation. In this regard, practitioners have been reliant on anecdotal evidence that is based on intuition and experience reports to develop conditions to provide this guidance (e.g. Boehm, 2002; Kruchten, 2004; Turk et al., 2014). This set of heuristics serve the purpose of providing an informed underpinning to the implementation of agile methodology in order to enable practitioners to obtain immediate benefit. Paulk (2014) does however, warn against the temptation of using these agile heuristics to create a piece-meal variant of XP or Scrum in order to suit the application domain. Such an adaptation should be done on the basis of empirical studies that provide a reliable guide for an informed implementation of the methodology. However, in order to extend the applicability of the methodology to domains where it has been perceived as being inappropriate, a formal unifying Architecture and
Primary objective
A minimalist approach to upfront system architecture;
objective is to meet an immediate need; not much focus on low level
architectural issues.
System is designed for stability and long term maintenance; comprehensive upfront design models are required; expansive upfront detail is expected
framework that incorporates the assumptions underlying the methodology as well as the contexts in which it is deemed appropriate for implementation, is required.