Waste identification as the means for improving communication in globally distributed agile software development

Agile approaches highly values communication between team members to improve software development processes, even though, communication in globally distributed agile teams can be difficult. Literature proposes solutions for mitigating the challenges encountered in these environments. These solutions range from general-level recommendations and practices to the use of communication tools. However, an approach covering the whole development process for identifying challenges, and improving communication in globally distributed agile development projects, is missing. In order to address this, we conducted a case study within a globally distributed agile software development project focused on using the concept of waste as a lens for identifying non-value producing communication elements. In order to achieve this, we constructed a waste identification approach through which we identified five communication wastes, and solutions to mitigate them. These wastes can help companies identify communication issues that are present in their development efforts, while the presented waste identification technique gives them a mechanism for waste identification and mitigation. This work contributes to the scientific community by increasing the knowledge about communication in globally distributed agile development efforts.     

The impact of agile practices on communication in software development

Agile software development practices such as eXtreme Programming (XP) and SCRUM have increasingly been adopted to respond to the challenges of volatile business environments, where the markets and technologies evolve rapidly and present the unexpected. In spite of the encouraging results so far, little is known about how agile practices affect communication. This article presents the results from a study which examined the impact of XP and SCRUM practices on communication within software development teams and within the focal organization. The research was carried out as a case study in F-Secure where two agile software development projects were compared from the communication perspective. The goal of the study is to increase the understanding of communication in the context of agile software development: internally among the developers and project leaders and in the interface between the development team and stakeholders (i.e. customers, testers, other development teams). The study shows that agile practices improve both informal and formal communication. However, it further indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication. The study highlights the fact that hurdles and improvements in the communication process can both affect the feature requirements and task subtask dependencies as described in coordination theory. While the use of SCRUM and some XP practices facilitate team and organizational communication of the dependencies between product features and working tasks, the use of agile practices requires that the team and organization use also additional plan-driven practices to ensure the efficiency of external communication between all the actors of software development.

Collective agility,paradox and organizational improvisation: the development of a particle physics grid

This paper examines systems development in a global collaborative community of high‐energy physics and offers insights and implications for agile systems development in other large scale and distributed settings. The paper studies the ongoing construction of the UK's computing grid for particle physics (GridPP), a grid that is itself part of the world's largest grid, the Large Hadron Collider Computing Grid. We observe in this project a collective, agile and distributed performance through which the Grid is constructed. We express this through the concept of ‘collective agility’ which captures a large distributed performance rather than the more conventional sense of agility as small‐group and deliberate systems development practices. The collective agility of GridPP is analysed as a process of ‘enacted emergence’ expressed through the dynamics of six improvisation paradoxes.     

When agile meets the enterprise

ContextWhile renowned agile methods like XP and Scrum were initially intended for projects with small teams, traditional enterprise environments, i.e. environments where plan-driven development is prevalent, have also become attracted by the promises of a faster time to market through agility. Agile software development methods emphasize lightweight software development. Projects within enterprise environments, however, are typically confronted with a large and complex IT landscape, where mission-critical information is at play whose criticality requires prudence regarding design and development. In many an organization, both approaches are used simultaneously.ObjectiveFind out which challenges the co-existence of agile methods and plan-driven development brings, and how organizations deal with those challenges.MethodWe present a grounded theory of the challenges of using agile methods in traditional enterprise environments, based on a Grounded Theory research involving 21 agile practitioners from two large enterprise organizations in the Netherlands.ResultsWe organized the challenges under two factors: Increased landscape complexity and Lack of business involvement. For both factors, we identify successful mitigation strategies. These mitigation strategies concern the communication between the agile and traditional part of the organization, and the timing of that communication.ConclusionAgile practices can coexist with plan-driven development. One should, however, keep in mind the context and take actions to mitigate the challenges incurred.     

Agile requirements engineering practices and challenges: an empirical study

This paper describes empirical research into agile requirements engineering (RE) practices. Based on an analysis of data collected in 16 US software development organizations, we identify six agile practices. We also identify seven challenges that are created by the use of these practices. We further analyse how this collection of practices helps mitigate some, while exacerbating other risks in RE. We provide a framework for evaluating the impact and appropriateness of agile RE practices by relating them to RE risks. Two risks that are intractable by agile RE practices emerge from the analysis. First, problems with customer inability and a lack of concurrence among customers significantly impact agile development. Second, risks associated with the neglecting non‐functional requirements such as security and scalability are a serious concern. Developers should carefully evaluate the risk factors in their project environment to understand whether the benefits of agile RE practices outweigh the costs imposed by the challenges.     

Applying agile methods to aircraft embedded software: an experimental analysis

This paper discusses the applicability of agile methods to aircraft embedded software development. It presents the main results of an experiment that combines agile practices from Scrum with model‐based development and distributed development. The experiment consists of the development of an aircraft cockpit display system divided in five distributed teams. Three features are analysed and quantified, using the output artefacts of each team: the artefacts' quality, the adherence to agile methods, and the adherence to standard DO‐178C. The main conclusion of the experiment is that there is a high correlation between the adherence to agile methods and the artefacts' quality, motivating the use of agile methods in aircraft industry. Also, the experiment evinced that agile methods does not specifically address the integration of distributed teams and the hardware/software integration. This lacuna affects the artefacts' quality. The results of the experiment emphasize the importance of concentrating future work in the proposal of specific agile practices for these activities. Copyright © 2017 John Wiley & Sons, Ltd.     

Agile vs. structured distributed software development: A case study

In globally distributed software development, does it matter being agile rather than structured? To answer this question, this paper presents an extensive case study that compares agile (Scrum, XP, etc.) vs. structured (RUP, waterfall) processes to determine if the choice of process impacts aspects such as the overall success and economic savings of distributed projects, the motivation of the development teams, the amount of communication required during development, and the emergence of critical issues. The case study includes data from 66 projects developed in Europe, Asia, and the Americas. The results show no significant difference between the outcome of projects following agile processes and structured processes, suggesting that agile and structured processes can be equally effective for globally distributed development. The paper also discusses several qualitative aspects of distributed software development such as the advantages of nearshore vs. offshore, the preferred communication patterns, and the effects on project quality.     

The use of prototypes to bridge knowledge boundaries in agile software development

Bridging knowledge boundaries among project team members is essential to prevent delays or complete failure of software development projects. Prior researchers have reported that software prototypes can be used to help bridge knowledge boundaries between team members in traditional software development settings, yet their use in an agile development setting remains unexplored. Agile development centers the interactions between team members on emerging representations of the prototype whose properties are prone to change over time. Therefore, we conducted an in‐depth study of an agile development project to enhance our understanding on how software prototypes are used as boundary objects in a distributed team setting. Our analyses of team member interactions during 46 virtual meetings that took place over a period of 6 months revealed four different prototype use practices (exemplifying, contrasting, relating, framing) that were effective in bridging syntactic, semantic, or pragmatic knowledge boundaries. We also provide empirically grounded evidence of how variations in object properties can afford different use practices, how the use practices take advantage of these properties, and how object properties are reshaped through these use practices as different types of knowledge boundaries are bridged. These findings bear important implications for research on prototypes as boundary objects in software development in particular and boundary object use in general.     

Role of collective ownership and coding standards in coordinating expertise in software project teams

Software development is a complex undertaking that continues to present software project teams with numerous challenges. Software project teams are adopting extreme programming (XP) practices in order to overcome the challenges of software development in an increasingly dynamic environment. The ability to coordinate software developers' efforts is critical in such conditions. Expertise coordination has been identified as an important emergent process through which software project teams manage non-routine challenges in software development. However, the extent to which XP enables software project teams to coordinate expertise is unknown. Drawing on the agile development and expertise coordination literatures, we examine the role of collective ownership and coding standards as processes and practices that govern coordination in software project teams. We examine the relationship between collective ownership, coding standards, expertise coordination, and software project technical quality in a field study of 56 software project teams comprising 509 software developers. We found that collective ownership and coding standards play a role in improving software project technical quality. We also found that collective ownership and coding standards moderated the relationship between expertise coordination and software project technical quality, with collective ownership attenuating the relationship and coding standards strengthening the relationship. Theoretical and practical implications of the findings are discussed.     

基于敏捷建模的形式化需求分析方法

软件需求分析是软件生命周期中最关键的一步。传统的需求建模方法主要有两个重大的缺陷：1）非形式化的需求描述常常导致需求的歧义性和不一致性,因而难以确认和验证;2）易变一牲,需求变更及其连锁反应是对项目质量、进度乃至合同履行影响最大的风险因素。本文针对软件需求分析阶段的难点,通过将形式化方法和敏捷建模理论相结合,提出一套基于敏捷建模的形式化需求分析方法。     

Agile knowledge management: a survey of Indian perceptions

This paper is a pivot step to find out the level of KM adoption of Indian software organizations which are using agile practices for software development. After reviewing the literature it was found although many practitioners believe that KM practices are embodied in agile methodologies but it is not documented efficiently. Survey was used to take perception of agile organizations. KM practices are grouped into seven factors and respondents are taken from Indian software industry. Organizations are divided into different demographics: size, core area, type. Different statistical tests are used to conclude outputs of the questionnaire. It is found that Indian software industry working with agile practices lacks in providing any formal head for KM positioning. Learning and sharing through discussion forms is the most used practices among all respondents of organizations, whereas least accepted practice is dependent upon documents for transfer of knowledge. Indian organizations also lack in appointing a formal head who can provide guidelines for agile practice.     

Management challenges to implementing agile processes in traditional development organizations

Discussions with traditional developers and managers concerning agile software development practices nearly always contain two somewhat contradictory ideas. They find that on small, stand-alone projects, agile practices are less burdensome and more in tune with the software industry's increasing needs for rapid development and coping with continuous change. Managers face several barriers, real and perceived, when they try to bring agile approaches into traditional organizations. They categorized the barriers either as problems only in terms of scope or scale, or as significant general issues needing resolution. From these two categories, we've identified three areas - development process conflicts, business process conflicts, and people conflicts - that we believe are the critical challenges to software managers of large organizations in bringing agile approaches to bear in their projects.     

Control Mechanisms and Agile Methodology Use: Data from the Industry

This research investigates the relationship between the degree of agile methodology use and four types of control mechanisms that are widely used in the management of a software project and its personnel: outcome control, behavioral control, clan control, and self-control. We conducted two studies: a survey of software professionals and a follow-up interview in six organizations. We found the following: 1) software professionals reported high outcome and clan controls regardless of their levels of agile methodology use; 2) the high agile group reported some use of behavioral and self-controls while the low agile group did not; 3) even though behavioral control was minimum in the low agile group, all professionals we interviewed strongly agreed that using established materials and following existing procedures should be standardized practices in software development. Implications of this research are discussed.     

How to steer an embedded software project: tactics for selecting the software process model

Modern large new product developments (NPD) are typically characterized by many uncertainties and frequent changes. Often the embedded software development projects working on such products face many problems compared to traditional, placid project environments. One of the major project management decisions is then the selection of the project's software process model. An appropriate process model helps coping with the challenges, and prevents many potential project problems. On the other hand, an unsuitable process choice causes additional problems. This paper investigates the software process model selection in the context of large market-driven embedded software product development for new telecommunications equipment. Based on a quasi-formal comparison of publicly known software process models including modern agile methodologies, we propose a process model selection frame, which the project manager can use as a systematic guide for (re)choosing the project's process model. A novel feature of this comparative selection model is that we make the comparison against typical software project problem issues. Some real-life project case examples are examined against this model. The selection matrix expresses how different process models answer to different questions, and indeed there is not a single process model that would answer all the questions. On the contrary, some of the seeds to the project problems are in the process models themselves. However, being conscious of these problems and pitfalls when steering a project enables the project manager to master the situation.     

How agile software development methods reduce work exhaustion: Insights on role perceptions and organizational skills

Agile methods are widely used in the software industry as a way to more rapidly develop and deliver new software. They define iterative work processes, advocate self‐organization and openness for change, and prescribe how software developers interact with each other and external stakeholders. Despite their popularity, it is unclear how agile methods influence work exhaustion in software developers and how developer skills play into this effect. On the one hand, agile methods may reduce software developers' work exhaustion by levelling out their workload across the entire duration of a project. On the other hand, agile methods exert a high level of pressure on software developers to continuously deliver working software, create many intensive social interactions, and to frequently adapt to changes. In light of these effects, prior research could not explain why some software developers become less exhausted from using agile methods, whereas others perceive the exact opposite. Based on the job demand‐control model, we develop a theoretical model connecting agile method use to individual developer skills and to two established determinants of employee exhaustion: role conflict and role ambiguity. We tested our research model in a field study among 1894 software developers in 217 project teams that used agile methods. The random coefficient modelling results show that agile method use facilitates the achievement of clear and unambiguous role perceptions and thereby reduces work exhaustion in developers, particularly if developers possess the organizational skills to effectively interact with others in their organization. We highlight implications for theory on the individual‐level effects of software development methods and provide practical insights for software companies.     

Agile Software Development: Ad Hoc Practices or Sound Principles?

Management and organization theories help explain why agility is needed in software development and how to achieve it. Even though the effectiveness of some specific agile practices is not yet fully established, the agile approach is consistent with the sound principles grounded in management and organization theories discussed here. Our analysis helps understand the validity and applicability of the agile approach. It also highlights some of the challenges faced by agile development. Also, this analysis highlights several opportunities to fine-tune and understand the applicability and relevance of agile methods in different project contexts. Finally, rather than focusing attention on whether there is anything new with agile methods, it's more useful to understand the conditions under which specific agile practices are likely to be effective     

Development of an atomic‐broadcast protocol using LOTOS

In this article we report on the development of a group‐communication service using the formal specification language LOTOS, and present our experience in using publicly available tools for this purpose. The service implements atomic broadcast through a Two‐Phase‐Commit protocol, providing at‐least‐once delivery semantics and with no restriction on message delivery order. First we wrote an informal specification describing the desired properties from the service, the interfaces with the underlying network layer and the upper user layer, and the protocol to be used by the service. Then we developed the formal specification of the protocol in LOTOS. After validating the formal specification and thus having a certain confidence in its adequacy with respect to the informal specification, we derived test cases from the formal specification and implemented the service using the Concert/C distributed programming language. While testing the implementation, we found that most errors were related to unspecified features or bugs in the execution environment. From this experience, we draw our conclusions on the usefulness of software development based on formal techniques. Copyright © 1999 John Wiley & Sons, Ltd.     

How do development actors do “ICT for development”? A strategy‐as‐practice perspective on emerging practices in Ghanaian agriculture

This paper examines how development actors within the Ghanaian agricultural sector enact information and communication technology (ICT) in their day‐to‐day outreach practices with smallholder farmers. We draw on an in‐depth qualitative case study, informed by the theoretical perspective of “strategy‐as‐practice” to answer the research question: “what ICT‐mediated strategic practices are used by development actors in the Ghanaian agriculture sector?” The research findings reveal that (1) the activities of development actors are meshed within a network of interdependencies; (2) the enacted strategic practices reflect the trade‐off between novelty of content and novelty of the technologies used to deliver it; and lastly, (3) the praxis of development actors for doing ICT for development consists of hybrid strategies, combining bottom‐up approaches consistent with farmers' indigenous smallholder logic, with top‐down imperatives framing agriculture “as a business” and nurturing value‐chain integration. Consequently, our research points to the impact of ICT initiatives as step‐wise and attained over the long term, rather than disruptive and attained in the immediate term.     

基于敏捷建模的形式化需求分析方法

软件需求分析是软件生命周期中最关键的一步。传统的需求建模方法主要有两个重大的缺陷:1)非形式化的需求描述常常导致需求的歧义性和不一致性,因而难以确认和验证;2)易变性,需求变更及其连锁反应是对项目质量、进度乃至合同履行影响最大的风险因素。本文针对软件需求分析阶段的难点,通过将形式化方法和敏捷建模理论相结合,提出一套基于敏捷建模的形式化需求分析方法。     

Risks to Effective Knowledge Sharing in Agile Software Teams: A Model for Assessing and Mitigating Risks

We present an empirically grounded and theoretically informed model for the assessment and mitigation of risks to effective knowledge sharing in agile development. The model is anchored in empirical insights from four agile projects across two software companies and in extant research on risk‐strategy analysis and knowledge sharing in software development. We develop the model as part of the long‐standing tradition of presenting risk management models dedicated to specific issues in software development and confirm its practical usefulness in one of the software companies studied. The model offers concepts and processes to assess a project's knowledge sharing risk profile and articulate an overall resolution strategy plan to mitigate the risks. The results highlight how different knowledge sharing risk management profiles can lead to different project performance outcomes. We conclude with a discussion of research opportunities that the results offer software development scholarship. © 2016 John Wiley & Sons Ltd