Investigating the environmental antecedents of organizations’ intention to adopt agile software development

Purpose Agile software development (ASD) has emerged as an active research area due to its enormous growth in popularity. The innovative differences between ASD and traditional development include the use of fundamentally different procedures, organizational structures and people, yet organizations still attempt to embrace ASD. Apparently, the underlying factors arousing organizations’ intent to adopt ASD are not well known and have not been well explained in the extant literature. The purpose of this paper is to fill this gap for which the authors propose a conceptual framework based on the business process management (BPM) perspective to identify the environmental stimuli that affect an organization’s ASD adoption. Design/methodology/approach Proposition for a methodology approach is used to construct a theoretical framework based on existing literature and theories in BPM. Findings The framework recognizes external and internal environmental stimuli, including institutional isomorphic forces and interior enablers, such as top management championship, the culture type and resource readiness, which affect organizational ASD adoption decisions. Originality/value This paper consolidates both the internal and external environmental aspects of the stimuli that lead to ASD adoption and offers insight into creating a suitable context for ASD adoption.

Download Full-text

A Framework for Analyzing Structural Mechanisms Deployed to Support Traditional and Agile Methods

Advances in Systems Analysis, Software Engineering, and High Performance Computing - Balancing Agile and Disciplined Engineering and Management Approaches for IT Services and Software Products ◽

10.4018/978-1-7998-4165-4.ch011 ◽

2021 ◽

pp. 205-227

Author(s):

Michal Dolezel ◽

Alena Buchalcevova

Keyword(s):

Software Development ◽

Classification Scheme ◽

Organizational Structures ◽

Agile Software Development ◽

Agile Methods ◽

Two Dimensional ◽

Dimensional Classification ◽

Agile Software ◽

Structural Mechanisms ◽

Development Methods

People rely on structures to make their worlds orderly. This chapter conceptually probes into the problem of the differences between organizational structures deployed in traditional and agile environments. The authors develop an argument that all common forms of organizational entities can be classified by involving a two-dimensional classification scheme. Specifically, they constructed a typology to examine the issues of formal vs. informal authority, and disciplinarity vs. cross-functionality in terms of their significance for traditional and agile software development workplaces. Some examples of concrete organizational forms—including traditional project team, independent test team, self-organizing agile team and developers' community of practice—are discussed. In sum, they argue that by employing this classification scheme, they can theorize the nature of the on-going structural shift observed in conjunction with deploying agile software development methods. They acknowledge that the structures have fundamentally changed, terming the move “democratization” in the software development workplace.

Download Full-text

Ambidexterity in Agile software development: a conceptual paper

Journal of Organizational Effectiveness People and Performance ◽

10.1108/joepp-07-2019-0068 ◽

2021 ◽

Vol ahead-of-print (ahead-of-print) ◽

Author(s):

Carin Lindskog ◽

Monika Magnusson

Keyword(s):

Software Development ◽

Conceptual Framework ◽

Agile Software Development ◽

Project Teams ◽

Social Strategies ◽

Content Type ◽

Task Team ◽

Conceptual Paper ◽

Agile Software ◽

Practical Implications

PurposeThe purpose of this study is to apply the concept of organizational ambidexterity as a conceptual lens to increase the understanding of tensions between exploitation (continuity) and exploration (change) in Agile software development (ASD) project teams, and particularly the balancing (ambidextrous) strategies utilized.Design/methodology/approachA conceptual framework was constructed from interdisciplinary sources on ambidexterity. A literature review of publications on ambidexterity in ASD was then performed, and the results from the selected publications were classified according to an extension of the conceptual framework.FindingsContextual ambidexterity in ASD is affected by the four basic coherent concepts: time, task, team and transition. The study found that most ambidextrous factors and strategies were task and team-related. In addition, a mixture of hard (performance) strategies and soft (social) strategies is needed in order for people/teams to (be able to) become ambidextrous.Practical implicationsTo provide a better understanding of ASD, it is important to identify a broader set of ambidextrous factors and strategies that can impact ASD project teams. The expanded conceptual framework can serve as a basis for future empirical research and provide insights to practitioners on how to strengthen ambidexterity in ASD projects.Originality/valueThe contribution is of great importance for ASD research and practice, as ASD methods are a popular method for managing projects within ASD and in other nonsoftware organizations. In addition, as more and more organizations struggle to deal with rapidly changing environments, interest in the phenomena of paradoxical tensions and the strategy (ambidexterity) to deal with these tensions increase.

Download Full-text

Agile at IBM: software developers teach a new dance step to management

Strategy and Leadership ◽

10.1108/sl-01-2014-0003 ◽

2014 ◽

Vol 42 (2) ◽

pp. 26-29 ◽

Cited By ~ 5

Author(s):

Robert M. Randall

Keyword(s):

Software Development ◽

Traditional Approach ◽

Agile Software Development ◽

Software Systems ◽

Content Type ◽

The Future ◽

Agile Approach ◽

Development Approach ◽

Agile Software ◽

Marketing Teams

Purpose – Explains how companies that are seeking to implement rapid innovation can adopt the Agile software development approach. In Agile, self-organizing teams work in short cycles called “sprints” and develop the features to enable the product to continuously evolve in the light of the experience they gain and through customer feedback. Design/methodology/approach – For insight into how Agile is being implemented at a leading software services firm with clients in hundreds of industries, Strategy & Leadership asked Rob Purdie, Agile Practice Lead for the IBM Design Lab, how Agile software development methods were contributing to the success of IBM's key digital marketing initiatives. Findings – The traditional approach to software development is to define, design, develop and test everything – before delivering anything. With Agile, managers can reduce waste by prioritizing features based on relative business value, evaluating and re-designing as the project proceeds. Practical implications – Agile requires leaders and teams to work and learn through problems, designs and options in an open and transparent environment. It places new demands on technical leaders in terms of negotiation and planning skills. Originality/value – Managers outside the software industry should note that Agile/Scrum is likely to be increasingly essential to the future of product development and manufacturing. Nowadays many products for consumers and businesses include embedded software systems, so developing products in the future will require deeper collaboration across multiple engineering disciplines and marketing teams and familiarity with the Agile approach.

Download Full-text

Conceptualizing open agile software development life cycle (OASDLC) model

International Journal of Quality & Reliability Management ◽

10.1108/ijqrm-08-2013-0127 ◽

2015 ◽

Vol 32 (3) ◽

pp. 214-235 ◽

Cited By ~ 2

Author(s):

Subhas C. Misra ◽

Virender Singh

Keyword(s):

Life Cycle ◽

Software Development ◽

Conceptual Model ◽

Best Practice ◽

Agile Software Development ◽

Software Project ◽

Content Type ◽

Development Life Cycle ◽

Software Development Life Cycle ◽

Agile Software

Purpose – Software development life cycle (SDLC) has always been the core methodology for any software engineer that depicts the entire development process which an organization is bound to utilize to achieve successful software. The purpose of this paper is to bring forth a conceptual model after analysing the best practices in SDLC, and extracting the best out of agile methodologies and the open source software, thereby bringing forward an optimised structure. Design/methodology/approach – The OASDLC is hypothesized specifically for “Brihaspati” project and is formulated keeping in mind the gaps and limitations posed by existing SDLC models. OASDLC is further put to test for achieving lower costs and efforts involved. The tests are further substantiated by means of hypothesis validation through execution of a survey based research. Findings – It has been observed that the present conceptual model further optimizes the efforts involved while adopting such a practice. Originality/value – This paper proposes a novel SDLC model so as to achieve a best practice for a software project. On analysing the issues involved such as tight budget and timelines, it led the authors to formulate a newer concept “Open Agile Software Development Life Cycle model” (OASDLC).

Download Full-text

Age stereotypes in agile software development – an empirical study of performance expectations

Information Technology and People ◽

10.1108/itp-07-2015-0186 ◽

2018 ◽

Vol 31 (1) ◽

pp. 41-62 ◽

Cited By ~ 6

Author(s):

Uta Schloegel ◽

Sebastian Stegmann ◽

Alexander Maedche ◽

Rolf van Dick

Keyword(s):

Software Development ◽

Age Groups ◽

Agile Software Development ◽

Social Dimension ◽

Performance Expectations ◽

Age Stereotypes ◽

Content Type ◽

Older Employees ◽

Agile Software ◽

Job Role

Purpose Research on agile software development (ASD) has so far primarily focused on processes and tools. Recently, researchers have started to investigate the social dimensions of ASD. The authors contribute to this and examine the largely invisible psychological factor of age stereotypes as one important social dimension of ASD. Driven by demographic change, employees of different age groups will need to work closely together in ASD in the future. However, age stereotypes can hinder many aspects of communication, cooperation and coordination in these self-managed teams. The purpose of this paper is to identify and differentiate age stereotypes in ASD. Design/methodology/approach A quantitative survey at the individual level was conducted with 464 employees in two software development companies. The authors developed an age stereotype model for ASD and developed two scales to measure performance expectations (PEs) in ASD. Findings Employees in ASD show a bias in general PEs, favoring middle-aged employees over both younger and older employees. The perceived PE of a developer decreases over working life. Furthermore, the data show a complex interplay of age and job role in both the research participants and the group evaluated. Younger developers hold the strongest negative age stereotypes and older developers suffer most from stereotypes. Practical implications Management should enact formal or informal measures against stereotypes when an older or younger employee joins a team of members of other age groups, or when a new team is formed. In addition, the authors propose human resources to create permeable career paths. Originality/value The study extends the stereotype content model by adding additional age groups and including job role as a moderating variable. It identifies obstacles in daily employee interactions in agile development, and proposes ways of incorporating invisible psychological aspects in ASD-specific theories.

Download Full-text

ACSESim: Agile and Lean software development in practice

Emerald Emerging Markets Case Studies ◽

10.1108/eemcs-02-2017-0025 ◽

2018 ◽

Vol 8 (1) ◽

pp. 1-25

Author(s):

Andries Maritz ◽

Fatima Hamdulay

Keyword(s):

Software Development ◽

Knowledge Work ◽

Agile Software Development ◽

Point Of View ◽

Development Environment ◽

Lean Thinking ◽

Content Type ◽

Software Development Environment ◽

Agile Software ◽

The Impact

Subject area Agile software development, Knowledge workers and Lean thinking as a management system Study level/applicability The case lends itself to students of business management, or aspiring consultants, who have been exposed to operations management in general and Lean thinking specifically. It is an advanced case study, assuming prior knowledge in these subjects and approaches the subject matter from an organisational development point of view, rather than a pure operations point of view. It is thus well suited to an elective on operational excellence on an MBA or in executive education courses in Lean thinking Case overview The case starts with Mark, manager of a software development team, hearing that he will have budget for two new developers who will join his team in the coming year. While the extra help could be useful, he was considering what the impact of new people would be on the productivity of the team, which he felt was already stretched. Mark continues to consider the entire development chain and how code changes were implemented to ACSESim’s (the company’s primary product) graphical user interfaces. Having recently been acquired by an American company, he was also under pressure to start to adopt some of the parent company’s systems, which would constitute a fairly disruptive, but necessary, change, particularly for future collaborations with other developers in the parent company. With two new developers, experience taught Mark that development could slow down owing to training efforts. To minimise disruption, he was wondering about how to get the new developers up-to-speed quickly and streamline their operations within a changing corporate environment. The case highlights the different mechanisms that were in place at ACSESim, including the use of issue trackers; Kanban boards; version control software; automated systems; stand-up meetings, etc. Each of these mechanisms is discussed briefly and shows the value they added to the development practices that were in place. This also allows students to understand Agile practices and what Lean thinking might mean in a knowledge work environment and then to consider what the proposed changes might mean and how they could be deployed. Expected learning outcomes To gain an understanding of how Lean and Agile principles can be applied in a software development environment and Lean knowledge work in general To consider the best way to manage new hires so that they can become productive in a Lean or Agile software development environment, whilst dealing with pressures to migrate to new systems. Supplementary materials Teaching notes are available for educators only. Please contact your library to gain login details or email [email protected] to request teaching notes. Subject code CSS: 9: Operations and Logistics.

Download Full-text

Collaborative security risk estimation in agile software development

Information and Computer Security ◽

10.1108/ics-12-2018-0138 ◽

2019 ◽

Vol 27 (4) ◽

pp. 508-535 ◽

Cited By ~ 2

Author(s):

Inger Anne Tøndel ◽

Martin Gilje Jaatun ◽

Daniela Soares Cruzes ◽

Laurie Williams

Keyword(s):

Software Development ◽

Software Security ◽

Risk Estimation ◽

Agile Software Development ◽

Easy Access ◽

Agile Development ◽

Security Risk ◽

Content Type ◽

Agile Software ◽

Agile Teams

PurposeToday, agile software development teams in general do not adopt security risk-assessment practices in an ongoing manner to prioritize security work. Protection Poker is a collaborative and lightweight software security risk-estimation technique that is particularly suited for agile teams. Motivated by a desire to understand why security risk assessments have not yet gained widespread adoption in agile development, this study aims to assess to what extent the Protection Poker game would be accepted by agile teams and how it can be successfully integrated into the agile practices.Design/methodology/approachProtection Poker was studied in capstone projects, in teams doing a graduate software security course and in sessions with industry representatives. Data were collected via questionnaires, observations and group interviews.FindingsResults show that Protection Poker has the potential to be adopted by agile teams. Key benefits include good discussions on security and the development project, along with increased knowledge and awareness. Challenges include ensuring efficient use of time and gaining impact on the end product.Research limitations/implicationsUsing students allowed easy access to subjects and an ability to collect rich data over time, but at the cost of generalizability to professional settings. Results from interactions with professionals supplement the data from students, showing similarities and differences in their opinions on Protection Poker.Originality/valueThe paper proposes ways to tackle the main obstacles to the adoption of the Protection Poker technique, as identified in this study.

Download Full-text