Instruction manuals

Choice of Agile Methodologies in Software Development: A Vendor Perspective

Published
of 17
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Description
Journal of International Technology and Information Management Volume 25 Issue 1 Article Choice of Agile Methodologies in Software Development: A Vendor Perspective Sriram Rajagopalan Indian Institute
Transcript
Journal of International Technology and Information Management Volume 25 Issue 1 Article Choice of Agile Methodologies in Software Development: A Vendor Perspective Sriram Rajagopalan Indian Institute of Technology Madras Saji K. Mathew Indian Institute of Technology Madras Follow this and additional works at: Part of the Business Intelligence Commons, E-Commerce Commons, Management Information Systems Commons, Management Sciences and Quantitative Methods Commons, Operational Research Commons, and the Technology and Innovation Commons Recommended Citation Rajagopalan, Sriram and Mathew, Saji K. (2016) Choice of Agile Methodologies in Software Development: A Vendor Perspective, Journal of International Technology and Information Management: Vol. 25: Iss. 1, Article 3. Available at: This Article is brought to you for free and open access by CSUSB ScholarWorks. It has been accepted for inclusion in Journal of International Technology and Information Management by an authorized administrator of CSUSB ScholarWorks. For more information, please contact Choice of Agile Methodologies in Software Development S. Rajagopalan & S. K. Mathew Choice of Agile Methodologies in Software Development: A Vendor Perspective Sriram Rajagopalan Saji K Mathew Department of Management Studies, Indian Institute of Technology Madras INDIA ABSTRACT The purpose of this research was to develop understanding about how vendor firms make choice about agile methodologies in software projects and their fit. Two analytical frameworks were developed from extant literature and the findings were compared with real world decisions. Framework 1 showed that the choice of XP for one project was not supported by the guidelines given by the framework. The choices of SCRUM for other two projects, were partially supported. Analysis using the framework 2 showed that except one XP project, all others had sufficient project management support, limited scope for adaptability and had prominence for rules. Keywords: Agile, software, vendor perspective INTRODUCTION Software methodology has been understood as a model used to plan, design, test and control the processes for developing an information system, furnished with one or more techniques. In this context, model refers to a logical description of processes, which can be sequential or iterative (Matković & Tumbas, 2010). A methodology has a direct relationship with managing project complexity. Use of methodology has also implications for usability, maintainability, adaptability, reliability and portability of the software being developed. Further, adopting an incorrect methodology could result in slippages, lack of communication and administrative overheads, leading to customer dissatisfaction. A recent study has reported a significant relationship between supplier (vendor) satisfaction and the choice of methodology (Wright, 2013). In the past two decades, fast paced evolution of software methodologies has effected significant improvements in software quality (Huo et al., 2004). During late 1990 s, agile methodologies became prevalent to address some shortcomings of traditional methodologies like heavy documentation, lack of productivity, reliability and simplicity (Cho, 2009).Agile alliance, in response to more process driven traditional methodologies, stresses upon people, communication and customer priorities (Beck et al., 2001). Also, different agile methodologies has exhibited flexibility to working within constraints, without demanding major upfront investments, while being adaptable to changing market conditions(mohammad et al., 2013). Inspite of their widespread use in the last 15 years, agile methodologies have also shown many limitations. Some notable limitations include dependence on run-time tacit knowledge rather than International Information Management Association, Inc ISSN: Printed Copy ISSN: On-line Copy Journal of International Technology and Information Management Volume 25, Number more documented information, lack of traceable and proved implementation guidelines for mission critical projects, lack of adequate support for repetitive and large scale projects and team requirement of highly talented, self-motivated individuals with a high degree of implementation freedom (Cho, 2009).The outcomes of projects developed using agile methodologies are dependent mainly on organisational factors like customer commitment, decision time, team location and composition, corporate culture and people factors like competency and selfmotivation ( Vinekar et al., 2006). In order to address various concerns, several methodologies within the agile category evolved; Abrahamsson et al. (2010) identifies ten of them as truly agile. While there is considerable interest in the IT industry to adopt newer methods fostering agility, guidelines in choosing the right methodologies, based on relevant factors, remain scanty (Wright, 2013; Coram & Bohner, 2005).What are the key determinants in the choice of agile methodologies in order to meet project goals? Are these factors identified in extant literature followed in practice? How are decisions on the choice of agile methodologies taken in practice? Prior research has provided some frameworks for analysing characteristics of agile methods. For example, Qumer and Henderson-Sellers (2008) identifies four dimensions for analysing agility of various agile methods. Drawing on these studies, our research seeks to develop a normative understanding about the choice of agile methodologies and compare the findings with the actual choices and their rationale. Following a case study method, we analyse five software projects executed by three vendor organisations. The insights from this study would serve to inform practising managers on the choice of agile methodology and would also contribute to the body of knowledge in agile methods, where empirical studies have been found to be limited (Dyba & Dingsoyr, 2008). The remaining part of this paper is organised as follows: Section 2 gives a review of literature on agile methods and their choices, Section 3 describes the methodology followed in our study, Section 4 gives the detailed analyses of our case data and Section 5 ends with conclusions. Foundations LITERATURE REVIEW The fundamentals of agile methodology- incremental and iterative, go six decades back, when researchers worked on the principle of separating design, implementation and testing (Larman & Basili, 2003). The implementation phase was characterised by generations of systems of codes and functional sub specifications, so that there were intermediate check points for validation and verification against the final expected product. Two decades later, evolutionary project management evolved as one of the key incremental and iterative practice. Scholars thus approached complex systems by reductionism, breaking down the system into small units, each one having a small well defined goal or prototype, totalling to larger goal and every prototype having sufficient provision for retreat (Nerur & Balijepally, 2007; Dingsoyr et al., 2007; Wright, 2013). During the and evolution of agile methodology and the community surrounding it, the movement has benefitted from conceptual foundations in other disciplines such as architecture, Socio technical systems, soft systems methodology, support congruence and transitional organization (Nerur et al., 2010).The key characteristics of agile methodologiesgreater autonomy, decision-making discretion and adaptive understanding, have a theoretical International Information Management Association, Inc ISSN: Printed Copy ISSN: On-line Copy Choice of Agile Methodologies in Software Development S. Rajagopalan & S. K. Mathew background, which is consistent with problem-framing, problem-solving approaches in architecture and strategic management (Nerur & Balijepally, 2007). Comparison of agile methodologies Though there are many agile methodologies which have evolved by tailoring various principles and processes, there are only few which are commonly used. Despite the differences, all agile methods are focused mainly on business problems and their solutions in the shortest time-frame, with very frequent releases to business user community amidst their dynamically changing priorities. Here, the process is a low key affair and communication is high key, relying on smaller, very closely knitted highly motivated teams (Strode, 2006). The differences among the agile methods are in their purpose they solve, based on the demand or customer needs. Some of them focuses more on practises and others on management aspects. Also, there are significant differences among the agile methods in the extent of coverage for phases of the software life cycle. They also differ in the team composition they recommend, to bring efficiency in the respective methodology-usage for the given purpose. Abrahamsson et al. (2010) compare and contrast 10 agile methodologies using six dimensions. Table 1 gives a summary of this analysis with phases of life cycle they support and constraints of its usage. Qumer and Henderson-Sellers (2008) developed a similar framework for comparing agile methodologies based on their agility characteristics. Using a four dimensional framework of scope, features, agile values and processes, they analysed six agile methods. The authors finally arrive at a degree of agility index that could guide choice of an agile method for a given project. Geambasu et al. (2011) also developed an extant view of agile methods by using factors derived from literature. Role of the customer ADOPTING AGILE METHODOLOGIES The customer plays a very important role in agile projects with key responsibilities to drive the project, interact constantly with business users and provide requirements and participate in retrospection to test the intermediate deliverable and its compliance (Martin et al., 2009). However, customer may fail to keep these practises on sustainable pace due to the dynamic nature of projects. Hence, the customer s role is essentially not played by a single person but there are pseudo roles assumed by different people to drive the project effectively, known by role labels such as the technical liaison, negotiator, customer coach, skill specialists for designer, tester and quality facilitator. Agile methodology Characteristics Phases of life cycle supported Usage constraints International Information Management Association, Inc ISSN: Printed Copy ISSN: On-line Copy Journal of International Technology and Information Management Volume 25, Number ASD Promotes adaptive paradigm, derives principles from radical software AM Crystal Agile modelling agility and rapid in producing sufficiently advanced models to support acute design. Family of methods to be chosen suitable for the business needs with rules of thumb for tailoring. Flexible and configurable process Requirements, design, code, unit test, integration test, system test, acceptance test It is more about concepts and culture rather than inpractice None It does not work independently but work within other methods as supplement Design, coding, unit test, integration test, system test Lack of support for mission-critical systems, distributed teams, scalability, insistence on only collocation. DSDM Provides control framework for rapid application. Keeps time and resources as constant and adjust the functionality to be developed Project inception, requirements, design, code, unit test, integration test, system test, acceptance test, system in use Availability issue to wider audience XP Customer focused and close customer participation, short iterations and short release, continuous re-factoring. Requirements, design, code, unit test, integration test, system test Lack of attention on management practises FDD More emphasis on quality, frequent and tangible deliveries and accurate monitoring of project progress. Very short iterations Requirements, design, code, unit test, integration test, system test Focused mainly on design and implementation ASP The Agile Software Process model focuses on accelerated with flexibility to include volatile requirements Requirements, design, code, unit test, integration test, system test, acceptance test Unable to predict effort upfront and threat of loss of focus due to changing requirements. PP Pragmatic programming more of pragmatic perspective with a set of best practises None Does not define any concrete methodology to develop a system International Information Management Association, Inc ISSN: Printed Copy ISSN: On-line Copy Choice of Agile Methodologies in Software Development S. Rajagopalan & S. K. Mathew SCRUM Focuses on flexibility, adaptability, productivity, through small, selfmotivated teams. Integrated project management process to overcome deficiencies in the process Requirements specification, integration test Coding and all testing process not defined completely. Table 1. Comparison of Agile Methodologies. Martin et al. (2009) summarise customer effectiveness in agile projects based on three practices:(i) real customer involvement extent of direct involvement of all stakeholders, (ii) whole team skills and perspectives required for the team to create a sense of team-ness and (iii) energised work working effectively and productively. In line with above, some empirical studies have suggested new customer-focused practices which include customer s apprentice, programmer on-site, use of contextual enquiry, programmer holiday, road show, customer pairing, customer boot camp, big picture up-front and re-calibration (Beyer et al., 2004; Takats & Brewer, 2005). Organisational culture and deployment of agile methods Siakas and Siakas (2007) studied the close relationship between organisational culture and agile method usage and showed how agile approach forms distinct cultures of its own. They also propose four different types of organisational culture as clan, democratic, hierarchical and disciplined. Agile methodologies are more suited for organisations following democratic culture. Iivari and Huisman (2007) proposed a competing value model, a two dimensional model, focussing on values as core constituents of organisation culture. The model help analyse culture based on two contrasting aspects change (flexibility and spontaneity) vs. stability (control, continuity and order) and internal focus (integration and maintenance of Socio technical system) vs. external focus (competition and interaction with organisation environment). Four types of culture evolved group culture concerned with human relationship and flexibility, al culture, which is more future oriented, rational culture, more achievement oriented and hierarchical culture, focused on order, routine and regulations. Iivari and Iivari (2010) used the competing value model in the context of agile methods and posited that agile methods and hierarchical culture are incompatible. Further agile method implementation in hierarchical organisation is still possible through combination of complementary features of different types of methodologies. However, this might result in heavier implementation leading to loss of agility. DECISION FACTORS IN CHOOSING AGILE METHODOLOGIES Some studies have focused on agile methodologies and their impact on project management, especially project success. Chow et al. (2008) identified factors that can serve to guide in the selection of agile methodologies for projects in organisations with specific characteristics. Further, the authors summarised 6 key dimensions of agile methodologies with specific attributes to guide selection of a specific methodology. These dimension covers delivery strategies (short delivery cycles), software engineering techniques (simple design, rigorous re-factoring techniques, strong testing strategy), team capability (highly competent teams, adaptive management style, strong International Information Management Association, Inc ISSN: Printed Copy ISSN: On-line Copy Journal of International Technology and Information Management Volume 25, Number training mechanism), project management process (strong requirement management, configuration management, communication management processes), team environment (team location, self-organised teams) and customer involvement (strong relationship with customers, customer having full authority). Wan et al. (2010) highlight aspects of organisational agility namely innovation, rapid response to change, initiative and learning that are key determinants while selecting agile methodologies. Similarly, Lindvall et al. (2002) suggested project size, highly competent personnel, criticality, reliability and safety issues as key aspects in selecting projects suitable for agile methodologies. In summary, our survey of literature shows that agile methodologies have been studied in relation with project management, organisational culture and specific project characteristics. Although several studies have been conducted in these three streams of research, empirical evidence to guide choice of methodologies are still scanty, as also reported by a research review in this area (Dyba & Dingsoyr, 2008).Some scholars have suggested frameworks that are useful in comparing agile methodologies based on their characteristics; these frameworks complement and inform methodological studies in agile (Geambasu et al., 2011; Abrahamsson et al., 2010; Qumer & Henderson-Sellers, 2008). However, studies that map project characteristics to agile methodology characteristics to provide an analytical framework for decisions on methodologies still need more attention. Further, empirical evidence to compare pragmatic choices with normative choices have not been found in prior studies to the best of our knowledge. Our study addresses this gap by developing an analytical framework from extant literature and using it to develop a normative view of agile methodology choice and then further compare it with actual decisions. RESEARCH METHODOLOGY The purpose of our study is to develop understanding about decisions made regarding the choice of specific agile methodology. We chose multi case study method as most appropriate for our research as theoretical studies have been very limited in this area (Edmondson and McManus 2007). We follow a deductive case study approach, as we could identify useful frameworks that could be synthesised for analysing qualitative data (Yin, 2013). Data sources and sampling Following the principles of deductive multi-site case study approach (Yin, 2013), we chose three organisations to collect data for our study. A brief profile of the organisations with the projects pertaining to each organisation is given in Table 2 below. Our sample consisted of two large firms with over 100,000 employees and one small firm with about 100 employees. One large organisation we studied was headquartered in the United States and the other two were based in India. All the three firms had business focus on IT and IT consulting. This profile of the firms provided sufficient diversity as well as similarity at the organisational level in line with the recommendations for multiple case studies (Yin, 2013). Since our unit of analysis was software projects, we applied criteria following the guidelines of replication logic in the choice of projects. We chose to study five projects from three organisations including large projects (largest: 1600 KLOC / person hrs) and relatively small projects (smallest: 300 KLOC / person hrs). We also ensured that the agile methods International Information Management Association, Inc ISSN: Printed Copy ISSN: On-line Copy Choice of Agile Methodologies in Software Development S. Rajagopalan & S. K. Mathew chosen for the projects were also sufficiently diverse: two projects involved SCRUM with pair programming, another two with SCRUM and one with XP. Respondents were chosen based on fulfilling three criteria: (a) minimum 10 years of experience in s
Search
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks