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.     

Effective communication,collaboration, and coordination in eXtreme Programming: Human‐centric perspective in a small organization

Effective communication, collaboration, and coordination are important contributing factors in achieving success in agile software development projects. The significance of the workplace environment and tools are immense in effective communication, collaboration, and coordination among people performing software development. In this article, we study how the workplace environment and the effective use of tools like whiteboards, status boards, and so forth for exchanging information improved communication, collaboration, and coordination without compromising the ability to do individual work by developers in a small‐scale software development organization. Based on experience and an extensive literature review of communication, collaboration, coordination, and the significance of these in the workplace environment, a survey questionnaire was developed to collect data and observe the effect of these in a small software development organization. Our study indicated appropriate workspace environment has a positive effect on communication, collaboration, and coordination in small organizations developing software using eXtreme Programming (XP). © 2009 Wiley Periodicals, Inc.     

Determinants for Successful Agile Collaboration between UX Designers and Software Developers in a Complex Organisation

ABSTRACT

Agile and User-centered design processes have been reported to frequently putting contradictory demands on people working within these methodological frameworks. The current research addresses this point by focussing on the crucial relationship between software developer and designer. An online survey, a contextual inquiry, and a diary study were employed with 107 developers and designers in a large media organization to determine the factors for success in agile development cycles. The results from the survey show that while developers and designers have similar levels of satisfaction with agile processes, there are differences in the factors predicting those ratings. Developers are happier with the wider teamwork but want more access to and close collaboration with designers, while the latters’ concern was the quality of the wider teamwork. Additional contextual inquiries and a diary study with pairs of designers and developers reflected the survey findings that close cooperation (and proximity) was essential for improving communication, reducing inefficiencies, and avoiding suboptimal products being released. However, organizational processes, the setup of the work environment, and managerial traditions meant that this close collaboration and localized decision-making was found difficult to maintain. Results from the survey, the contextual inquiry, and the diary study found six factors for success from collaborations emerged.     

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.

Understanding the attitudes,knowledge sharing behaviors and task performance of core developers: A longitudinal study

ContextPrior research has established that a few individuals generally dominate project communication and source code changes during software development. Moreover, this pattern has been found to exist irrespective of task assignments at project initiation.ObjectiveWhile this phenomenon has been noted, prior research has not sought to understand these dominant individuals. Previous work considering the effect of team structures on team performance has found that core communicators are the gatekeepers of their teams’ knowledge, and the performance of these members was correlated with their teams’ success. Building on this work, we have employed a longitudinal approach to study the way core developers’ attitudes, knowledge sharing behaviors and task performance change over the course of their project, based on the analysis of repository data.MethodWe first used social network analysis (SNA) and standard statistical analysis techniques to identify and select artifacts from ten different software development teams. These procedures were also used to select central practitioners among these teams. We then applied psycholinguistic analysis and directed content analysis (CA) techniques to interpret the content of these practitioners’ messages. Finally, we inspected these core developers’ activities as recorded in system change logs at various points in time during systems’ development.ResultsAmong our findings, we observe that core developers’ attitudes and knowledge sharing behaviors were linked to their involvement in actual software development and the demands of their wider project teams. However, core developers appeared to naturally possess high levels of insightful characteristics, which became evident very early during teamwork.ConclusionsProject performance would likely benefit from strategies aimed at surrounding core developers with other competent communicators. Core developers should also be supported by a wider team who are willing to ask questions and challenge their ideas. Finally, the availability of adequate communication channels would help with maintaining positive team climate, and this is likely to mitigate the negative effects of distance during distributed developments.     

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.     

Performance Alignment Work: How software developers experience the continuous adaptation of team performance in Lean and Agile environments

ContextCompanies increasingly strive to adapt to market and ecosystem changes in real time. Gauging and understanding team performance in such changing environments present a major challenge.ObjectiveThis paper aims to understand how software developers experience the continuous adaptation of performance in a modern, highly volatile environment using Lean and Agile software development methodology. This understanding can be used as a basis for guiding formation and maintenance of high-performing teams, to inform performance improvement initiatives, and to improve working conditions for software developers.MethodA qualitative multiple-case study using thematic interviews was conducted with 16 experienced practitioners in five organisations.ResultsWe generated a grounded theory, Performance Alignment Work, showing how software developers experience performance. We found 33 major categories of performance factors and relationships between the factors. A cross-case comparison revealed similarities and differences between different kinds and different sizes of organisations.ConclusionsBased on our study, software teams are engaged in a constant cycle of interpreting their own performance and negotiating its alignment with other stakeholders. While differences across organisational sizes exist, a common set of performance experiences is present despite differences in context variables. Enhancing performance experiences requires integration of soft factors, such as communication, team spirit, team identity, and values, into the overall development process. Our findings suggest a view of software development and software team performance that centres around behavioural and social sciences.     

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.     

A teamwork model for understanding an agile team: A case study of a Scrum project

ContextSoftware development depends significantly on team performance, as does any process that involves human interaction.ObjectiveMost current development methods argue that teams should self-manage. Our objective is thus to provide a better understanding of the nature of self-managing agile teams, and the teamwork challenges that arise when introducing such teams.MethodWe conducted extensive fieldwork for 9 months in a software development company that introduced Scrum. We focused on the human sensemaking, on how mechanisms of teamwork were understood by the people involved.ResultsWe describe a project through Dickinson and McIntyre’s teamwork model, focusing on the interrelations between essential teamwork components. Problems with team orientation, team leadership and coordination in addition to highly specialized skills and corresponding division of work were important barriers for achieving team effectiveness.ConclusionTransitioning from individual work to self-managing teams requires a reorientation not only by developers but also by management. This transition takes time and resources, but should not be neglected. In addition to Dickinson and McIntyre’s teamwork components, we found trust and shared mental models to be of fundamental importance.     

Test-Driven Development in Large Projects

Test-driven development (TDD) is a key practice for agile developers because it involves writing test cases ahead of the code, which can improve design. The TDD process works well for projects in which a collocated team develops a small to medium system, but it can be challenging for large systems, especially those involving geographically distributed teams. The main obstacle is the degree of integration: when the team must integrate many individual classes developed at distributed sites, the coordination and communication grows exponentially with the number of individual developers and sites. This does not mean that TDD is ineffective for large-scale geographically distributed projects, but developers must take care to account for its focus on unit testing and its failure to rigorously address communications issues during system and integration testing. In this article, suggestions to scale up TDD are presented with two large-scale global software development projects at a major corporation and a recent meeting to exchange global software development best practices with a Fortune 500 company     

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.     

Becoming agile together: Customer influence on agile adoption within commissioned software teams

Despite the ongoing expansion of agile practices beyond software firms, agile adoption remains risky, challenging, and poorly understood. Although agile practices emphasize self-organization and customer collaboration, we know little about how customers influence agile adoption within self-organizing teams. Here, we analyze how a commissioned software team engaged in customer collaboration during agile adoption at a Danish IT service provider. Our case study shows that the software team's transition to self-organized teamwork practices, agile planning routines, and active customer engagement was mutually dependent on the customer's trust in the software team and flexible collaborative routines. As a result, we advance a theoretical perspective of customer influence on agile adoption within commissioned software teams, implying that both software teams and customers need to navigate a contradictory tension between self-organization and collaboration to become agile together.     

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.     

Leveraging distributed software development

The Internet has been changing the way people collaborate on software development, offering certain advantages but also creating new requirements. Internet based collaboration does make a wider base of talent available, but the development cycles running at Internet speeds require maintaining higher levels of precision. From a project management perspective, communication is a key factor in Internet based development. Internet based collaboration requires effective team communication. The authors point out that when a development team isn't communicating well, it is nearly impossible to create and validate design solutions and manage the team's deliverables. So while Internet collaboration offers a number of advantages, the friction created by distributed (therefore delayed) communication typically increases the overhead associated with sharing project information. And the technology itself, including system interoperability and the synchronous or asynchronous collaboration tools, can create problems in a distributed development environment. As the complexities of distributed collaborative development environments increase, frameworks designed for such environments will become essential. The authors describe one such framework called SoftDock, and the new technologies it exploits. It lets developers analyze, design, and develop software from component models     

Introducing knowledge redundancy practice in software development: Experiences with job rotation in support work

ContextJob rotation is a widely known approach to increase knowledge redundancy but empirical evidence regarding introduction and adoption in software development is scant. A lack of knowledge redundancy is a limiting factor for collaboration, flexibility, and coordination within teams and within the organization.ObjectiveThe scientific objective of this investigation was to explore benefits and challenges with improving knowledge redundancy among developers participating in job rotation. There were two practical objectives; (a) to establish customer support as a legitimate organizational function that would shield developers from support enquiries, and (b) to contribute to improved flexibility in project staffing by enabling overlapping product experience among developers.MethodWe used action research to integrate organizational change with scientific inquiry. During a period of eighteen weeks, nine developers rotated to customer support. We collected data throughout the period of collaboration; in meetings, from comprehensive interviews, and from customer support work logs.ResultsPerceptions of reduced efficiency and unnecessary redundancy outweighed benefits of shielding and learning about different products. Although there were strong indications of increased knowledge redundancy, the benefits were not sufficient to justify job rotation. Job rotation was abandoned after the trial period.ConclusionsJob rotation can contribute to improved knowledge redundancy. Benefits of knowledge redundancy include innovation stemming from integration of different knowledge domains and improved appreciation of organizational concerns. However, knowledge redundancy incurs a collective cost that must be amortized and legitimized by the organization. An adoption process that accommodates open and trustful discussion among all involved stakeholders is therefore encouraged.     

How to reduce the UX bottleneck – train your software developers

Usability and user experience (UX) methods come from academic environments, where industrial conditions such as time and resources are not of prime importance. Furthermore, usability and UX methods originate from a time when almost all software developments followed a traditional approach, such as the waterfall model. These two facts entail that existing methods often are too resource demanding and complex to apply directly into today’s agile, industrial environments. In this paper we make the claim that methods must be updated and tailored in order to be applicable within the agile, industrial development framework of today. We pursue a solution to simplify well-known methods and to train software developers to perform the UX work. To do this, three methods are modified via an iterative process together with the development of supporting materials. Software developers in three companies are trained in the methods to assess the approach. We find that it indeed is feasible to update and tailor existing usability and UX methods to fit into an agile, industrial environment. Furthermore, we show that it is possible to train developers to perform the usability and UX methods via one-day, in-situ sessions using an ‘instructor’-teaching approach. The training is based on hands-on exercises and real-life tasks. This further boosts the developers’ confidence in performing UX work and promises a better consideration of UX in the development phases. We evaluate our approach through observations of the developers performing the UX tasks on their own at a later point in time.     

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.     

Information Alignment and Task Coordination in Organizations: An ‘Information Clutch’ Metaphor

Abstract

Despite their rising popularity, distributed teams face a number of collaboration challenges that may potentially hinder their ability to productively coordinate their resources, activities, and information, often in dynamic and uncertain task environments. In this paper, we focus principally on the criticality of information alignment for supporting coordinated task performance in complex operational environments. As organizations become more expertise, geographically, and temporally distributed, appropriate alignment and coordination among distributed team members becomes more critical for minimizing the occurrence of information flow failures, poor decision-making, and degraded team performance. We first describe these coordination processes using the metaphor of an ‘information clutch’ that allows for smooth transitions of task priorities and activities in expert teams. We then present two case study examples that illustrate the potentially significant impact of information sharing and information alignment on productivity and coordination in organizations. We conclude with a discussion of future directions in this area.     

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.     

Developer social networks in software engineering:construction,analysis,and applications

With the increasing popularity of Internet, more and more developers are collaborating together for software development. During the collaboration, a lot of information related to software development, including communication and coordination information of developers, can be recorded in software repositories. The information can be employed to construct Developer Social Networks （DSNs） for facilitating tasks in software engineering. In this paper, we survey recent advances of DSNs and examine three fundamental steps of DSNs, namely construction, analysis, and applications. We summarize the state-of-the-art methods in the three steps and investigate the relationships among them. Furthermore, we discuss the main issues and point out the future opportunities in the study of DSNs.