Communities of practice in a large distributed agile software development organization – Case Ericsson

ContextCommunities of practice—groups of experts who share a common interest or topic and collectively want to deepen their knowledge—can be an important part of a successful lean and agile adoption in particular in large organizations.ObjectiveIn this paper, we present a study on how a large organization within Ericsson with 400 persons in 40 Scrum teams at three sites adopted the use of Communities of Practice (CoP) as part of their transformation from a traditional plan-driven organization to lean and agile.MethodsWe collected data by 52 semi-structured interviews on two sites, and longitudinal non-participant observation of the transformation during over 20 site visits over a period of two years.ResultsThe organization had over 20 CoPs, gathering weekly, bi-weekly or on a need basis. CoPs had several purposes including knowledge sharing and learning, coordination, technical work, and organizational development. Examples of CoPs include Feature Coordination CoPs to coordinate between teams working on the same feature, a Coaching CoP to discuss agile implementation challenges and successes and to help lead the organizational continuous improvement, an end-to-end CoP to remove bottlenecks from the flow, and Developers CoPs to share good development practices. Success factors of well-functioning CoPs include having a good topic, passionate leader, proper agenda, decision making authority, open community, supporting tools, suitable rhythm, and cross-site participation when needed. Organizational support include creating a supportive atmosphere and providing a suitable infrastructure for CoPs.ConclusionsIn the case organization, CoPs were initially used to support the agile transformation, and as part of the distributed Scrum implementation. As the transformation progressed, the CoPs also took on the role of supporting continuous organizational improvements. CoPs became a central mechanism behind the success of the large-scale agile implementation in the case organization that helped mitigate some of the most pressing problems of the agile transformation.     

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.     

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.     

Introducing an agile process to an organization [software development]

The transition from a plan-driven to an agile software development process affects not only the development team members, but also other teams, departments, and management. Any new process will likely attract developers excited to try it while repelling those opposed to change. Thus, how an agile process is introduced into an organization significantly affects its ultimate success.     

Agile methods rapidly replacing traditional methods at Nokia: A survey of opinions on agile transformation

Context

Many organizations have started to deploy agile methods, but so far there exist only a few studies on organization-wide transformations. Are agile methods here to stay? Some claim that agile software development methods are in the mainstream adoption phase in the software industry, while others hope that those are a passing fad. The assumption here is that if agile would not provide real improvement, adopters would be eager at first but turn pessimistic after putting it into practice.

Objective

Despite the growing amount of anecdotal evidence on the success of agile methods across a wide range of different real-life development settings, scientific studies remain scarce. Even less is known about the perception of the impacts of agile transformation when it is deployed in a very large software development environment, and whether agile methods are here to stay. This study aims to fill that gap by providing evidence from a large-scale agile transformation within Nokia. While we have yet to confirm these findings with solid quantitative data, we believe that the perception of the impacts already pinpoints the direction of the impacts of large-scale agile transformation.

Method

The data were collected using a questionnaire. The population of the study contains more than 1000 respondents in seven different countries in Europe, North America, and Asia.

Results

The results reveal that most respondents agree on all accounts with the generally claimed benefits of agile methods. These benefits include higher satisfaction, a feeling of effectiveness, increased quality and transparency, increased autonomy and happiness, and earlier detection of defects. Finally, 60% of respondents would not like to return to the old way of working.

Conclusion

While the perception of the impact of agile methods is predominantly positive, several challenge areas were discovered. However, based on this study, agile methods are here to stay.     

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.     

Agile systems development: Privacy theoretical lens to challenge the full information disclosure paradigm.

Software development requires intense collaboration within, across teams, and with the client. Since the popularization of agile software development in the 2000s, the virtuous effects of transparent collaboration have been emphasized. However, some studies have alluded to concerns with full information disclosure and mentioned that teams may benefit by withholding some information. We used case studies to explore such situations. We adopted a privacy theoretical lens because it is antithetical to the information disclosure lens and offers frames to comprehend how professional information can be retained by individuals, shared to restricted circles or entirely divulged. We found situations when the disclosure paradigm is challenged in agile processes. There is ambiguity in the disclosure message because individual and collective information retention do play a role in agile development. Our findings help refine information systems development philosophies and practices. We also extend our understanding of the communication privacy management theory to a context where full disclosure is preferred to privacy, and where control over privacy depends on allowances granted by a third party, which can generalize to other settings (e.g., social media platforms).     

Linking perceived external prestige and collective identification to collaborative behaviors in R&D teams

Research efforts have long been directed at understanding variations in collaborative behaviors among work teams with burgeoning interest in teams operating in knowledge-intensive settings. One of the largely unexplained issues is how does team image and collective identification facilitate collaborative behaviors. Here, survey data were collected from nineteen highly technical work teams engaging in software development in an R&D division of a multinational NASDAQ firm involved in multimedia communications and information processing technology. The relationships between perceived external prestige, collective team identification and team collaborative behaviors were examined. The results of the team-level analyses suggest that perceived external prestige augments collective team identification (measured at Time 1), which in turn engenders a high degree of collaboration and interaction within the team (measured at Time 2). When past team performance was controlled for, the results consistently supported the hypothesized model.     

敏捷组织的复杂适应性及其行为模式研究

从CAS理论出发,分析了敏捷软件开发方法的复杂适应性,指出敏捷开发组织是一个复杂适应性系统,并建立敏捷开发组织的个体与环境关系的回声模型以及主体行为模式的刺激-反应模型,为敏捷软件开发方法的运行机制和持续改进提供理论依据。     

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.     

Effects of task complexity on individual creativity through knowledge interaction: A comparison of temporary and permanent teams

Using the interactionist’s perspective of creativity, this paper proposes a new research model of creativity manifestation to explore how factors affecting individual creativity depend on team characteristics. We investigated the antecedents of creativity in the literature—task complexity, team member exchange, and knowledge sharing—and then examined the relationships and differences between temporary and permanent teams. To maximize practical implications, we studied two team types like project task force (PTF) and research and development (R&D) teams in the Information and Communication Technology (ICT) industry in Korea, where strong creativity is required for team performance. PTF teams operate with a clear mission to be completed on a deadline, while R&D teams create scientific enhancements for existing products. The proposed structural model was tested empirically with cross-sectional data from 289 professionals from the two team types. Results indicated that, in the case of PTF teams, task complexity had an indirect relationship with individual complexity through knowledge interaction among team members, while for R&D teams, task complexity was directly associated with individual creativity, and indirectly associated with the creativity through team member exchange. Thus, team characteristics must be considered together with task complexity and knowledge interactions in order to achieve team goals more effectively by maximizing each member’s creativity.     

Technological innovation and the formation of Japanese technology: the case of the machine tool industry

This paper focuses on how “Japanese technology” was formed in the Japanese machine tool industry, and presents how Japanese machine tool builders competed in R&D and the innovation process in the domestic and international markets. During the competition for the innovation of computerised numerically-controlled (CNC) tools, drastic changes occurred in the ranking of individual firms. Prior to the transformation, the traditional “Big 5” companies occupied the largest market share. After the innovation, however, the “Big 3” firms which had not been big in size at their origins increased their market share. This paper explains how this change stemmed from different attitudes towards R&D and innovation.     

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     

Performance on agile teams: Relating iteration objectives and critical decisions to project management success factors

ContextWhile project management success factors have long been established via the golden triangle, little is known about how project iteration objectives and critical decisions relate to these success factors. It seems logical that teams’ iteration objectives would reflect project management success factors, but this may not always be the case. If not, how are teams’ objectives for iterations differing from the golden triangle of project management success factors?ObjectiveThis study identifies iteration objectives and the critical decisions that relate to the golden triangle of project management success factors in agile software development teams working in two-week iterations.MethodThe author conducted semi-structured interviews with members across three different agile software development teams using a hybrid of XP and Scrum agile methodologies. Iteration Planning and Retrospective meetings were also observed. Interview data was transcribed, coded and reviewed by the researcher and two independently trained research assistants. Data analysis involved organizing the data to identify iteration objectives and critical decisions to identify whether they relate to project management success factors.ResultsAgile teams discussed four categories of iteration objectives: Functionality, Schedule, Quality and Team Satisfaction. Two of these objectives map directly to two aspects of the golden triangle: schedule and quality. The agile teams’ critical decisions were also examined to understand the types of decisions the teams would have made differently to ensure success, which resulted in four categories of such decisions: Quality, Dividing Work, Iteration Amendments and Team Satisfaction.ConclusionThis research has contributed to the software development and project management literature by examining iteration objectives on agile teams and how they relate to the golden triangle of project management success factors to see whether these teams incorporate the golden triangle factors in their objectives and whether they include additional objectives in their iterations. What’s more, this research identified four critical decisions related to the golden triangle. These findings provide important insight to the continuing effort to better assess project management success, particularly for agile teams.     

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.     

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.     

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 Methodologies: Organizational Adoption Motives,Tailoring, and Performance

Today, organizations tailor the practices from several agile methodologies to serve their particular environment. But are there situations that drive how an organization should tailor methodologies in a particular manner? This article places 12 commonly used agile development practices into a typology based upon whether they are primarily project management focused or software development approach focused and examines how organizations’ motivations for adopting agile impact the practices they adopt. Finally, it explores how a fit between an organization’s motives for agile method adoption and the tailored agile practices it adopts may lead (or not lead) to differences in project performance.     

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.