Understanding agile software development practices using shared mental models theory

ContextAgile software development is an alternative software development methodology that originated from practice to encourage collaboration between developers and users, to leverage rapid development cycles, and to respond to changes in a dynamic environment. Although agile practices are widely used in organizations, academics call for more theoretical research to understand the value of agile software development methodologies.ObjectiveThis study uses shared mental models theory as a lens to examine practices from agile software methodologies to understand how agile practices enable software development teams to work together to complete tasks and work together effectively as a team.MethodA conceptual analysis of specific agile practices was conducted using the lens of shared mental models theory. Three agile practices from Xtreme Programming and Scrum are examined in detail, system metaphor, stand-up meeting, and on-site customer, using shared mental models theory.ResultsExamining agile practices using shared mental models theory elucidates how agile practices improve collaboration during the software development process. The results explain how agile practices contribute toward a shared understanding and enhanced collaboration within the software development team.ConclusionsThis conceptual analysis demonstrates the value of agile practices in developing shared mental models (i.e. shared understanding) among developers and customers in software development teams. Some agile practices are useful in developing a shared understanding about the tasks to be completed, while other agile practices create shared mental models about team processes and team interactions. To elicit the desired outcomes of agile software development methods, software development teams should consider whether or not agile practices are used in a manner that enhances the team’s shared understanding. Using three specific agile practices as examples, this research demonstrates how theory, such as shared mental models theory, can enhance our understanding regarding how agile practices are useful in enhancing collaboration in the workplace.     

Primavera gets agile: a successful transition to agile development

Primavera Systems provides enterprise project portfolio management solutions that help customers manage their projects, programs, and resources. When we decided to improve how we build software and increase the quality of life for everyone on the team, we found our answer in agile software development. Adopting agile practices is a process of continuous learning and improvement. Primavera's development team is a model for others looking to adopt agile processes.     

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 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.

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.     

Influences on regression testing strategies in agile software development environments

Regression testing is a well-established practice in software development, but in recent years it has seen a change of status and emphasis with the increasing popularity of agile methods, which stress the central role of regression testing in maintaining software quality. The objectives of this article are to investigate regression testing strategies in agile development teams and identify the factors that can influence the adoption and implementation of this practice. We have used a mixed methods approach to our research, beginning with an analysis of the literature to identify research themes related to the adoption of regression testing techniques under agile methodologies, from which we developed an analytical framework for the study. This was followed by three exploratory case studies that we used to exercise the main elements of the framework, develop some key themes of interest, and devise a questionnaire for the final stage of the study, an on-line survey to explore the main issues identified in the case studies across different contexts. Within our specific sample, our results suggest that organizational maturity is a key factor in effective regression testing practices and that the adoption of such practices is helped by a coherent testing philosophy and change management processes. We also found that the return on investment in automated regression testing was positive for our respondents and that adopting these practices in the context of agile methods had been a relatively painless process for the organizations in our survey. We conclude that investing in regression testing tools and processes is likely to be beneficial for organizations. However, further work is needed in assessing how organizational culture impacts on the quality process and the financial outcomes for commercial software development organizations.     

A disciplined approach to adopting agile practices: the agile adoption framework

Many organizations aspire to adopt agile processes to take advantage of the numerous benefits that they offer to an organization. Those benefits include, but are not limited to, quicker return on investment, better software quality, and higher customer satisfaction. To date, however, there is no structured process (at least that is published in the public domain) that guides organizations in adopting agile practices. To address this situation, we present the agile adoption framework and the innovative approach we have used to implement it. The framework consists of two components: an agile measurement index, and a four-stage process, that together guide and assist the agile adoption efforts of organizations. More specifically, the Sidky Agile Measurement Index (SAMI) encompasses five agile levels that are used to identify the agile potential of projects and organizations. The four-stage process, on the other hand, helps determine (a) whether or not organizations are ready for agile adoption, and (b) guided by their potential, what set of agile practices can and should be introduced. To help substantiate the “goodness” of the Agile Adoption Framework, we presented it to various members of the agile community, and elicited responses through questionnaires. The results of that substantiation effort are encouraging, and are also presented in this paper.     

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.     

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.     

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.     

Scaling agile methods

Using agile methods to develop large systems presents a thorny set of issues. If large teams are to produce lots of software functionality quickly, the agile methods involved must scale to meet the task. After all, a small team could create the software if the functionality to be delivered was small and, conversely, could be delivered given we had the time. Scaling agile teams thus becomes an issue if the only option for meeting a system delivery deadline is to have many developers working concurrently.     

Adapting funding processes for agile IT projects: an empirical investigation

Agile software development that provides software development organizations, the ability to respond to changes in turbulent business environments, has been gaining wide adoption. Agile software development projects are characterized by ‘just enough’ planning and lack of upfront commitment to scope, cost, and schedule. These characteristics pose conflicting demands on managers responsible for making funding decisions, because traditional approaches to funding IT projects are often based on well-defined scope, cost, and schedule. These conflicts demand the adaptation of traditional funding processes to suit to agile projects. We draw from Adaptive Structuration Theory to understand the nature of conflicts between traditional IT project funding processes and the dynamic nature of agile projects, and how these conflicts are addressed by practices that are appropriated in the process of social interaction between funding decision makers and development teams. On the basis of a multisite case study, we present a framework that explains how organizations adapt traditional IT funding approaches to accommodate the unique characteristics of agile IT projects.     

Individual empowerment of agile and non-agile software developers in small teams

ContextEmpowerment of employees at work has been known to have a positive impact on job motivation and satisfaction. Software development is a field of knowledge work wherein one should also expect to see these effects, and the idea of empowerment has become particularly visible in agile methodologies, in which proponents emphasise team empowerment and individual control of the work activities as a central concern.ObjectiveThis research aims to get a better understanding of how empowerment is enabled in software development teams, both agile and non-agile, to identify differences in empowering practices and levels of individual empowerment.MethodTwenty-five interviews with agile and non-agile developers from Norway and Canada on decision making and empowerment are analysed. The analysis is conducted using a conceptual model with categories for involvement, structural empowerment and psychological empowerment.ResultsBoth kinds of development organisations are highly empowered and they are similar in most aspects relating to empowerment. However, there is a distinction in the sense that agile developers have more possibilities to select work tasks and influence the priorities in a development project due to team empowerment. Agile developers seem to put a higher emphasis on the value of information in decision making, and have more prescribed activities to enable low-cost information flow. More power is obtained through the achievement of managing roles for the non-agile developers who show interest and are rich in initiatives.ConclusionAgile developers have a higher sense of being able to impact the organisation than non-agile developers and have information channels that is significantly differently from non-agile developers. For non-agile teams, higher empowerment can be obtained by systematically applying low-cost participative decision making practices in the manager–developer relation and among peer developers. For agile teams, it is essential to more rigorously follow the empowering practices already established.     

Large-scale agile transformation at Ericsson: a case study

Many large organizations are adopting agile software development as part of their continuous push towards higher flexibility and shorter lead times, yet few reports on large-scale agile transformations are available in the literature. In this paper we report how Ericsson introduced agile in a new R&D product development program developing a XaaS platform and a related set of services, while simultaneously scaling it up aggressively. The overarching goal for the R&D organization, distributed to five sites at two continents, was to achieve continuous feature delivery. This single case study is based on 45 semi-structured interviews during visits at four sites, and five observation sessions at three sites. We describe how the organization experimented with different set-ups for their tens of agile teams aiming for rapid end-to-end development: from component-based virtual teams to totally cross-functional, cross-component, cross-site teams. Moreover, we discuss the challenges the organization faced and how they mitigated them on their journey towards continuous and rapid software engineering. We present four lessons learned for large-scale agile transformations: 1) consider using an experimental approach to transformation, 2) consider implementing the transformation step-wise in complex large-scale settings, 3) team inter-changeability can be limited in a complex large-scale product — specialization might be needed, and 4) not using a common agile framework for the whole organization, in combination with insufficient common trainings and coaching may lead to a lack of common direction in the agile implementation. Further in-depth case studies on large-scale agile transformations, on customizing agile to large-scale settings, as well as on the use of scaling frameworks are needed.     

Enabling agile adoption practices through network organizations

As distributed organizations increasingly rely on technological innovations to enhance organizational efficiency and competitiveness, interest in agile practices that enable adoption of information technology (IT) based innovations has grown. This study examines the influence of a network organization environment on the ability to develop agile adoption practices. An exploratory case study design was used to investigate the interactions between network structure, social information processing, organizational similarity (homophily), and absorptive capacity during the adoption of a large-scale IT system in two network organization environments within New York State. The data suggest that network organization characteristics and communication processes that reinforced social influence and supported knowledge transfer positively influenced adoption agility. We propose a model of agile adoption practices and discuss implications for the development of theory about network organization characteristics and capabilities to adopt IT-based innovations.     

Successful extreme programming: Fidelity to the methodology or good teamworking?

ContextDeveloping a theory of agile technology, in combination with empirical work, must include assessing its performance effects, and whether all or some of its key ingredients account for any performance advantage over traditional methods. Given the focus on teamwork, is the agile technology what really matters, or do general team factors, such as cohesion, primarily account for a team’s success? Perhaps the more specific software engineering team factors, for example the agile development method’s collective ownership and code management, are decisive.ObjectiveTo assess the contribution of agile methodology, agile-specific team methods, and general team factors in the performance of software teams.MethodWe studied 40 small-scale software development teams which used Extreme Programming (XP). We measured (1) the teams’ adherence to XP methods, (2) their use of XP-specific team practices, and (3) standard team attributes, as well as the quality of the project’s outcomes. We used Williams et al.’s (2004a) [33] Shodan measures of XP methods, and regression analysis.ResultsAll three types of variables are associated with the project’s performance. Teamworking is important but it is the XP-specific team factor (continuous integration, coding standards, and collective code ownership) that is significant. Only customer planning (release planning/planning game, customer access, short releases, and stand-up meeting) is positively related to performance. A negative relationship between foundations (automated unit tests, customer acceptance tests, test-first design, pair programming, and refactoring) is found and is moderated by craftsmanship (sustainable pace, simple design, and metaphor/system of names). Of the general team factors only cooperation is related to performance. Cooperation mediates the relationship between the XP-specific team factor and performance.ConclusionClient and team foci of the XP method are its critical active ingredients.     

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.     

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.     

A dependency taxonomy for agile software development projects

Agile software development is designed to achieve collaborative software development. A supporting pillar of collaboration is effective coordination, which is necessary to manage dependencies in projects. Understanding the dependencies arising in agile software development projects can help practitioners choose appropriate coordinative practices from the large number of practices provided by the various agile methods. To achieve this understanding, this article analyses dependencies in three typical cases of co-located agile software development and presents the dependencies as a taxonomy with decision rules for allocating dependencies into categories. Findings show that knowledge, process, and resource dependencies are present, with knowledge dependencies predominant. In addition, there are agile practices with a coordinative function that address multiple dependencies in these agile software development projects. These practices would be a good choice for coordinating a project and supporting collaboration in agile software projects.