Strengths and barriers behind the successful agile deployment—insights from the three software intensive companies in Finland

The number of success stories being reported concerning agile software development has led to an increase in interest among industries and research communities. The purpose of this paper is to identify strengths and barriers for ‘successful agile deployment’ in the software companies. This knowledge can benefit software companies planning their current strategy for agile deployment. Analysis of 57 developers, architects, project managers, customers, quality managers, and line and product managers in three case companies identifies 71 strengths and 169 barriers of agile deployment. The analysis revealed the importance of management providing the necessary goals and support for agile development. It also indicated the significance of defining a tailored process model and giving developers the freedom to improve their own agile development process continuously during agile deployment. The identified barriers, strengths and recommendations can be used as a checklist for planning and/or monitoring the effectiveness of agile deployment in software companies. By identifying the barriers and strengths of agile deployment, the paper deepens understanding of this highly relevant but relatively under-researched phenomenon and contributes to the literature on agile deployment and software process improvement.     

Perceived barriers to effective knowledge sharing in agile software teams

While the literature offers several frameworks that explain barriers to knowledge sharing within software development teams, little is known about differences in how team members perceive these barriers. Based on an in‐depth multi‐case study of four software projects, we investigate how project managers, developers, testers and user representatives think about barriers to effective knowledge sharing in agile development. Adapting comparative causal mapping, we constructed causal maps for each of the four roles and identified overlap and divergence in map constructs and causal linkages. The results indicate that despite certain similarities, the four roles differ in how they perceive and emphasize knowledge‐sharing barriers. The project managers put primary emphasis on project setting barriers, while the primary concern of developers, testers and user representatives were project communication, project organization and team capabilities barriers, respectively. Integrating the four causal maps and the agile literature, we propose a conceptual framework with seven types of knowledge‐sharing barriers and 37 specific barriers. We argue that to bridge communication gaps and create shared understanding in software teams, it is critical to take the revealed concerns of different roles into account. We conclude by discussing our findings in relation to knowledge sharing in agile teams and software teams more generally.     

Categorization of risk factors for distributed agile projects

ContextOrganizations combine agile approach and Distributed Software Development (DSD) in order to develop better quality software solutions in lesser time and cost. It helps to reap the benefits of both agile and distributed development but pose significant challenges and risks. Relatively scanty evidence of research on the risks prevailing in distributed agile development (DAD) has motivated this study.ObjectiveThis paper aims at creating a comprehensive set of risk factors that affect the performance of distributed agile development projects and identifies the risk management methods which are frequently used in practice for controlling those risks.MethodThe study is an exploration of practitioners’ experience using constant comparison method for analyzing in-depth interviews of thirteen practitioners and work documents of twenty-eight projects from thirteen different information technology (IT) organizations. The field experience was supported by extensive research literature on risk management in traditional, agile and distributed development.ResultsAnalysis of qualitative data from interviews and project work documents resulted into categorization of forty-five DAD risk factors grouped under five core risk categories. The risk categories were mapped to Leavitt’s model of organizational change for facilitating the implementation of results in real world. The risk factors could be attributed to the conflicting properties of DSD and agile development. Besides that, some new risk factors have been experienced by practitioners and need further exploration as their understanding will help the practitioners to act on time.ConclusionOrganizations are adopting DAD for developing solutions that caters to the changing business needs, while utilizing the global talent. Conflicting properties of DSD and agile approach pose several risks for DAD. This study gives a comprehensive categorization of the risks faced by the practitioners in managing DAD projects and presents frequently used methods to reduce their impact. The work fills the yawning research void in this field.     

Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson

In a large organization, informal communication and simple backlogs are not sufficient for the management of requirements and development work. Many large organizations are struggling to successfully adopt agile methods, but there is still little scientific knowledge on requirements management in large-scale agile development organizations. We present an in-depth study of an Ericsson telecommunications node development organization which employs a large scale agile method to develop telecommunications system software. We describe how the requirements flow from strategy to release, and related benefits and problems. Data was collected by 43 interviews, which were analyzed qualitatively. The requirements management was done in three different processes, each of which had a different process model, purpose and planning horizon. The release project management process was plan-driven, feature development process was continuous and implementation management process was agile. The perceived benefits included reduced development lead time, increased flexibility, increased planning efficiency, increased developer motivation and improved communication effectiveness. The recognized problems included difficulties in balancing planning effort, overcommitment, insufficient understanding of the development team autonomy, defining the product owner role, balancing team specialization, organizing system-level work and growing technical debt. The study indicates that agile development methods can be successfully employed in organizations where the higher level planning processes are not agile. Combining agile methods with a flexible feature development process can bring many benefits, but large-scale software development seems to require specialist roles and significant coordination effort.     

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.     

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.     

Project management in plan-based and agile companies

Agile methods are a recent set of development techniques that apply a human-centered approach to software production. The agile approach aims to deliver high-quality products faster, producing satisfied customers. We conducted an empirical study to investigate whether agile methods change and improve project management practices in software companies. Survey results show that adopting agile methods appears to improve management of the development process and customer relationships. This article has given a first analysis of the advantages and disadvantages of adopting agile methods from a project management perspective.     

Combining agile methods with stage-gate project management

We encountered cultural changes and different management and engineering viewpoints in a study of three large software development organizations that started using agile methods. Case studies at three large software product companies show the benefits and pitfalls of integrating agile methods with stage-gate management models.     

A model of job satisfaction for collaborative development processes

Modern software development relies on collaborative work as a means for sharing knowledge, distributing tasks and responsibilities, reducing risk of failures, and increasing the overall quality of the software product. Such objectives are achieved with a continuous share of the programmers’ daily working life that inevitably influences the programmers’ job satisfaction. One of the major challenges in process management is to determine the causes of this satisfaction. Traditional research models job satisfaction with social aspects of collaborative work like communication, work sustainability, and work environment.This study reflects on existing models of job satisfaction in collaborative environments, creates one for modern software development processes, and validates it with a retrospective comparative survey run on a sample of 108 respondents. In addition, the work investigates the impact on job satisfaction and its model of the agile practice of Pair Programming that pushes job sharing to the extreme. With this intent, the questionnaire also collected feedback from pair programmers whose responses were used for a comparative analysis. The results demonstrate that Pair Programming has actually a strong positive effect on satisfaction, work sustainability, and communication.     

Risks and risk mitigation in global software development: A tertiary study

ContextThere is extensive interest in global software development (GSD) which has led to a large number of papers reporting on GSD. A number of systematic literature reviews (SLRs) have attempted to aggregate information from individual studies.ObjectiveWe wish to investigate GSD SLR research with a focus on discovering what research has been conducted in the area and to determine if the SLRs furnish appropriate risk and risk mitigation advice to provide guidance to organizations involved with GSD.MethodWe performed a broad automated search to identify GSD SLRs. Data extracted from each study included: (1) authors, their affiliation and publishing venue, (2) SLR quality, (3) research focus, (4) GSD risks, (5) risk mitigation strategies and, (6) for each SLR the number of primary studies reporting each risk and risk mitigation strategy.ResultsWe found a total of 37 papers reporting 24 unique GSD SLR studies. Major GSD topics covered include: (1) organizational environment, (2) project execution, (3) project planning and control and (4) project scope and requirements. We extracted 85 risks and 77 risk mitigation advice items and categorized them under four major headings: outsourcing rationale, software development, human resources, and project management. The largest group of risks was related to project management. GSD outsourcing rationale risks ranked highest in terms of primary study support but in many cases these risks were only identified by a single SLR.ConclusionsThe focus of the GSD SLRs we identified is mapping the research rather than providing evidence-based guidance to industry. Empirical support for the majority of risks identified is moderate to low, both in terms of the number of SLRs identifying the risk, and in the number of primary studies providing empirical support. Risk mitigation advice is also limited, and empirical support for these items is low.     

Coordination in co-located agile software development projects

Agile software development provides a way to organise the complex task of multi-participant software development while accommodating constant project change. Agile software development is well accepted in the practitioner community but there is little understanding of how such projects achieve effective coordination, which is known to be critical in successful software projects. A theoretical model of coordination in the agile software development context is presented based on empirical data from three cases of co-located agile software development. Many practices in these projects act as coordination mechanisms, which together form a coordination strategy. Coordination strategy in this context has three components: synchronisation, structure, and boundary spanning. Coordination effectiveness has two components: implicit and explicit. The theoretical model of coordination in agile software development projects proposes that an agile coordination strategy increases coordination effectiveness. This model has application for practitioners who want to select appropriate practices from agile methods to ensure they achieve coordination coverage in their project. For the field of information systems development, this theory contributes to knowledge of coordination and coordination effectiveness in the context of agile software development.     

Acquiring and sharing tacit knowledge in software development teams: An empirical study

ContextSharing expert knowledge is a key process in developing software products. Since expert knowledge is mostly tacit, the acquisition and sharing of tacit knowledge along with the development of a transactive memory system (TMS) are significant factors in effective software teams.ObjectiveWe seek to enhance our understanding human factors in the software development process and provide support for the agile approach, particularly in its advocacy of social interaction, by answering two questions: How do software development teams acquire and share tacit knowledge? What roles do tacit knowledge and transactive memory play in successful team performance?MethodA theoretical model describing the process for acquiring and sharing tacit knowledge and development of a TMS through social interaction is presented and a second predictive model addresses the two research questions above. The elements of the predictive model and other demographic variables were incorporated into a larger online survey for software development teams, completed by 46 software SMEs, consisting of 181 individual team members.ResultsOur results show that team tacit knowledge is acquired and shared directly through good quality social interactions and through the development of a TMS with quality of social interaction playing a greater role than transactive memory. Both TMS and team tacit knowledge predict effectiveness but not efficiency in software teams.ConclusionIt is concluded that TMS and team tacit knowledge can differentiate between low- and high-performing teams in terms of effectiveness, where more effective teams have a competitive advantage in developing new products and bringing them to market. As face-to-face social interaction is key, collocated, functionally rich, domain expert teams are advocated rather than distributed teams, though arguably the team manager may be in a separate geographic location provided that there is frequent communication and effective use of issue tracking tools as in agile teams.     

Processes versus people: How should agile software development maturity be defined?

Maturity in software development is currently defined by models such as CMMI-DEV and ISO/IEC 15504, which emphasize the need to manage, establish, measure and optimize processes. Teams that develop software using these models are guided by defined, detailed processes. However, an increasing number of teams have been implementing agile software development methods that focus on people rather than processes. What, then, is maturity for these agile teams that focus less on detailed, defined processes? This is the question we sought to answer in this study. To this end, we asked agile practitioners about their perception of the maturity level of a number of practices and how they defined maturity in agile software development. We used cluster analysis to analyze quantitative data and triangulated the results with content analysis of the qualitative data. We then proposed a new definition for agile software development maturity. The findings show that practitioners do not see maturity in agile software development as process definition or quantitative management capabilities. Rather, agile maturity means fostering more subjective capabilities, such as collaboration, communication, commitment, care, sharing and self-organization.     

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.     

Process fusion: An industrial case study on agile software product line engineering

This paper presents a case study of a software product company that has successfully integrated practices from software product line engineering and agile software development. We show how practices from the two fields support the company’s strategic and tactical ambitions, respectively. We also discuss how the company integrates strategic, tactical and operational processes to optimize collaboration and consequently improve its ability to meet market needs, opportunities and challenges. The findings from this study are relevant to software product companies seeking ways to balance agility and product management. The findings also contribute to research on industrializing software engineering.     

Agile business process development: why,how and when—applying Nonaka’s theory of knowledge transformation to business process development

The traditional way of business process development is via creating a detailed model of a business process in question, acquiring an IT-system to support it, and then implementing it in the organizational practice. Acquiring a system can be done via designing and manufacturing it by the business itself, or via commissioning it to somebody else. Alternatively, a generic system can be bought and configured according to the business process model created. The traditional approach has a number of risks that become visible only during the latest phase of introducing the system in the organizational practice, e.g., when it becomes clear that the system does not fit the business and/or people who work in it. These risks could be mitigated by using an agile approach to the development of business processes. In agile approach: (a) the phases of process modeling, IT-system design, and manufacturing are merged into one, and (b) instead of using one big cycle, a series of smaller development cycles is used. The paper discusses what is needed to implement the agile approach, and in which business situations the agile approach is the most appropriate. Examples of tools to support agile development are presented and analyzed. The results presented in the paper have been achieved based on the knowledge transformation perspective along the lines suggested by Nonaka in SECI model. The modification of this model has been used to understand the risks and requirements connected to a particular process development strategy.     

Study on the mechanism of customers' participation in knowledge sharing

Knowledge has replaced capital and energy as an important resource to enable a company to gain a competitive advantage. Knowledge sharing is the core content of knowledge management and the source of knowledge innovation. As an important resource of the company, the customer plays a vital role in the process of knowledge sharing. Therefore, research on the mechanism of customers' participation in knowledge sharing is especially important. In this paper, from the perspective of knowledge sharing between customers and enterprises, a customer participation model of a knowledge‐sharing mechanism is built based on three aspects: subjective influencing factors of knowledge sharing, objective influencing factors of knowledge sharing, and environmental influencing factors of knowledge sharing. On the basis of 222 valid questionnaires, the theoretical model was verified by using the experimental data analysed by the SPSS and AMOS software. The research shows the following: with respect to the objective influencing factors of knowledge sharing, the timeliness, scarcity, complexity, and economy of knowledge will affect the sharing cost and the expected return of knowledge sharing. With respect to the subjective factors, the sharing ability, the sharing cost, and customer loyalty will affect the knowledge‐sharing behaviour by influencing the knowledge‐sharing willingness. With respect to the environmental influencing factors, technical support and incentive mechanisms can indirectly affect knowledge‐sharing behaviour. In addition, on the one hand, customer loyalty can enhance the knowledge‐sharing ability and sharing willingness. On the other hand, knowledge‐sharing behaviour can enhance customer loyalty and thus form a virtuous cycle.     

Closing the gap: towards a process model of post-merger knowledge sharing

Abstract.  We develop a process model of post-merger knowledge sharing based on distributed cognition, a systems perspective and path dependence. The framework conceptualizes knowledge sharing by layers of management choice and employee appropriation of knowledge resources seen as knowledge as content and knowledge as connection. We use the framework to study a merger of two polymer companies. The study reveals that mergers represent a discontinuity in knowledge sharing. Yet, chosen strategies often mirror the learned knowledge-sharing practices of one of the merged companies and match poorly with the post-merger knowledge-sharing needs. Five factors emerged contribute to this knowledge gap: (a) the nature of the merger; (b) a lack of shared context; (c) the incompatibility of existing knowledge systems; (d) the tacit dimension of knowledge; and (e) time pressures of the merger. Our study shows that, employees enacted knowledge new sharing practices that differed significantly from the official strategy to close to the post-merger knowledge gap.     

Knowledge sharing practices as a facilitating factor for improving organizational performance through human capital: A preliminary test

Organizational knowledge sharing, argued to be able to improve organizational performance and achieve competitive advantage, is often not induced successfully. How organizations should encourage and facilitate knowledge sharing to improve organizational performance is still an important research question. This study proposes and examines a model of organizational knowledge sharing that improves organizational performance. Organizational knowledge sharing practices are argued to be able to encourage and facilitate knowledge sharing, and are hypothesized to have a positive relationship with organizational human capital (employee competencies), which is hypothesized to have a positive relationship with organizational performance. Two organizational antecedents (innovation strategy and top management knowledge values) are hypothesized to lead to the implementation of organizational knowledge sharing practices. The hypotheses were examined with data collected from 256 companies in Taiwan. All the hypotheses are supported. This study has both theoretical and practical implications.     

Interpretative case studies on agile team productivity and management

ContextThe management of software development productivity is a key issue in software organizations, where the major drivers are lower cost and shorter time-to-market. Agile methods, including Extreme Programming and Scrum, have evolved as “light” approaches that simplify the software development process, potentially leading to increased team productivity. However, little empirical research has examined which factors do have an impact on productivity and in what way, when using agile methods.ObjectiveOur objective is to provide a better understanding of the factors and mediators that impact agile team productivity.MethodWe have conducted a multiple-case study for 6 months in three large Brazilian companies that have been using agile methods for over 2 years. We have focused on the main productivity factors perceived by team members through interviews, documentation from retrospectives, and non-participant observation.ResultsWe developed a novel conceptual framework, using thematic analysis to understand the possible mechanisms behind such productivity factors. Agile team management was found to be the most influential factor in achieving agile team productivity. At the intra-team level, the main productivity factors were team design (structure and work allocation) and member turnover. At the inter-team level, the main productivity factors were how well teams could be effectively coordinated by proper interfaces and other dependencies and avoiding delays in providing promised software to dependent teams.ConclusionTeams should be aware of the influence and magnitude of turnover, which has been shown negative for agile team productivity. Team design choices remain an important factor impacting team productivity, even more pronounced on agile teams that rely on teamwork and people factors. The intra-team coordination processes must be adjusted to enable productive work by considering priorities and pace between teams. Finally, the revised conceptual framework for agile team productivity supports further tests through confirmatory studies.