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.

Challenges of shared decision-making: A multiple case study of agile software development

ContextAgile software development changes the nature of collaboration, coordination, and communication in software projects.ObjectiveOur objective was to understand the challenges of shared decision-making in agile software development teams.MethodWe designed a multiple case study consisting of four projects in two software product companies that recently adopted Scrum. We collected data in semi-structured interviews, through participant observations, and from process artifacts.ResultsWe identified three main challenges to shared decision-making in agile software development: alignment of strategic product plans with iteration plans, allocation of development resources, and performing development and maintenance tasks in teams.ConclusionAgile software development requires alignment of decisions on the strategic, tactical, and operational levels in order to overcome these challenges. Agile development also requires a transition from specialized skills to redundancy of functions and from rational to naturalistic decision-making. This takes time; the case companies needed from one to two years to change from traditional, hierarchical decision-making to shared decision-making in software development projects.     

Operational release planning in large-scale Scrum with multiple stakeholders – A longitudinal case study at F-Secure Corporation

ContextThe analysis and selection of requirements are important parts of any release planning process. Previous studies on release planning have focused on plan-driven optimization models. Unfortunately, solving the release planning problem mechanistically is difficult in an agile development context.ObjectiveWe describe how a release planning method was employed in two case projects in F-Secure, a large Finnish software company. We identify the benefits which the projects gained from the method, and analyze challenges in the cases and improvements made to the method during the case projects.MethodWe observed five release planning events and four retrospectives and we conducted surveys in the first two events. We conducted six post-project interviews. We conjoined the observation notes, survey results and interviews and analyzed them qualitatively and quantitatively.ResultsThe focal point of the method was release planning events where the whole project organization gathered to plan the next release. The planning was conducted by the development teams in close collaboration with each other and with the other stakeholders. We identified ten benefits which included improved communication, transparency, dependency management and decision making. We identified nine challenges which included the lacking preparation and prioritization of requirements, unrealistic schedules, insufficient architectural planning and lacking agile mindset. The biggest improvements to the method were the introduction of frequent status checks and a big visible planning status board.ConclusionThe release planning method ameliorated many difficult characteristics of the release planning problem but its efficiency was negatively affected by the performing organization that was in transition from a plan-driven to an agile development mindset. Even in this case the benefits clearly outweighed the challenges and the method enabled the early identification of the issues in the project.     

A framework to support the evaluation, adoption and improvement of agile methods in practice

Agile methods are often seen as providing ways to avoid overheads typically perceived as being imposed by traditional software development environments. However, few organizations are psychologically or technically able to take on an agile approach rapidly and effectively. Here, we describe a number of approaches to assist in such a transition. The Agile Software Solution Framework (ASSF) provides an overall context for the exploration of agile methods, knowledge and governance and contains an Agile Toolkit for quantifying part of the agile process. These link to the business aspects of software development so that the business value and agile process are well aligned. Finally, we describe how these theories are applied in practice with two industry case studies using the Agile Adoption and Improvement Model (AAIM).     

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.     

Get ready for agile methods, with care

Although many of their advocates consider the agile and plan-driven software development methods polar opposites, synthesizing the two can provide developers with a comprehensive spectrum of tools and options. Real-world examples argue for and against agile methods. Responding to change has been cited as the critical technical success factor in the Internet browser battle between Microsoft and Netscape. But overresponding to change has been cited as the source of many software disasters, such as the $3 billion overrun of the US Federal Aviation Administration's Advanced Automation System for national air traffic control. The author believes that both agile and plan-driven approaches have a responsible center and overinterpreting radical fringes. Agile and plan-driven methods both form part of the planning spectrum. Thus, while each approach has a home ground within which it performs very well, and much better than the other, a combined approach is feasible and preferable in some circumstances     

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.     

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.     

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.     

敏捷软件开发与计划驱动开发的概述比较

人们在设想、确定以及创建软件时,身边的环境不断在变更.敏捷是为了在动荡的业务环境中获益而创造变革和响应变革的能力.极限编程是最著名的敏捷软件开发方法.传统的开发侧重于计划和架构,计划驱动开发关注的是软件的质量和过程的可预见性.计划驱动开发最佳范例是能力成熟度模型.两种表面上有不同观点的方法在争夺着软件开发的主导权,对敏捷软件开发与计划驱动开发进行了概述,并就特征、擅长领域和关键要素等进行比较.     

敏捷需求建模的研究与设计

文章综合研究了敏捷方法与极限编程开发过程,结合需求工程方法,设计提出了基于敏捷思想的敏捷需求建模（Agile Requiremenb Modeling。简称ARM）。敏捷需求建模作为各种敏捷方法在软件需求中的实践补充,能够满足CMMI的目标。可以为中小型软件开发组织的行动指南提供参考。     

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.     

The impact of inadequate and dysfunctional training on Agile transformation process: A Grounded Theory study

ContextTraining is an essential facilitator in moving from traditional to Agile software development.ObjectiveThis paper addresses the importance of adequate and functional training in Agile transformation process, the causes of inadequate and dysfunctional training, and the heuristic strategies that can be used in software companies for dealing with this phenomenon.MethodA Grounded Theory study was conducted with participation of 35 Agile experts from 13 different countries.ResultsThis research discovered that inadequate and dysfunctional training was one of the critical issues that affected Agile transformation process. This study shows that comprehensive and functional training is not often provided to support Agile transformation. This paper shows the primary causes of inadequate and dysfunctional training, its adverse consequences on the transformation process, and the heuristic and ad-hoc treatments as the strategies used by Agile teams to cope with this challenge.ConclusionComprehensive training is important in Agile transformation process. Inadequate and dysfunctional training causes several challenges and problems for software companies and development teams when moving to Agile. Several ad-hoc strategies identified by this study can be employed to help software teams and companies facing similar problems.     

软件开发生命周期法比较之敏捷与传统

敏捷开发是近十年来兴起的软件开发模式,2012年11月第七届中国敏捷软件开发大会在北京、深圳、上海三地举办,为国内外敏捷实践者提供了开放的交流平台。从软件开发生命周期的角度分析比较了敏捷方法与传统方法的优劣,并提出敏捷方法在实践中的改进建议。     

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.     

Making the leap to a software platform strategy: Issues and challenges

ContextWhile there are many success stories of achieving high reuse and improved quality using software platforms, there is a need to investigate the issues and challenges organizations face when transitioning to a software platform strategy.ObjectiveThis case study provides a comprehensive taxonomy of the challenges faced when a medium-scale organization decided to adopt software platforms. The study also reveals how new trends in software engineering (i.e. agile methods, distributed development, and flat management structures) interplayed with the chosen platform strategy.MethodWe used an ethnographic approach to collect data by spending time at a medium-scale company in Scandinavia. We conducted 16 in-depth interviews with representatives of eight different teams, three of which were working on three separate platforms. The collected data was analyzed using Grounded Theory.ResultsThe findings identify four classes of challenges, namely: business challenges, organizational challenges, technical challenges, and people challenges. The article explains how these findings can be used to help researchers and practitioners identify practical solutions and required tool support.ConclusionThe organization’s decision to adopt a software platform strategy introduced a number of challenges. These challenges need to be understood and addressed in order to reap the benefits of reuse. Researchers need to further investigate issues such as supportive organizational structures for platform development, the role of agile methods in software platforms, tool support for testing and continuous integration in the platform context, and reuse recommendation systems.     

Using CMMI together with agile software development: A systematic review

BackgroundThe search for adherence to maturity levels by using lightweight processes that require low levels of effort is regarded as a challenge for software development organizations.ObjectiveThis study seeks to evaluate, synthesize, and present results on the use of the Capability Maturity Model Integration (CMMI) in combination with agile software development, and thereafter to give an overview of the topics researched, which includes a discussion of their benefits and limitations, the strength of the findings, and the implications for research and practice.MethodsThe method applied was a Systematic Literature Review on studies published up to (and including) 2011.ResultsThe search strategy identified 3193 results, of which 81 included studies on the use of CMMI together with agile methodologies. The benefits found were grouped into two main categories: those related to the organization in general and those related to the development process, and were organized into subcategories, according to the area to which they refer. The limitations were also grouped into these categories. Using the criteria defined, the strength of the evidence found was considered low. The implications of the results for research and practice are discussed.ConclusionAgile methodologies can be used by companies to reduce efforts in getting to levels 2 and 3 of CMMI, there even being reports of applying agile practices that led to achieving level 5. However, agile methodologies alone, according to the studies, were not sufficient to obtain a rating at a given level, it being necessary to resort to additional practices to do so.     

High-Speed Software Development Practices: What Works, What Doesn't

Increasingly short software development cycles have forced software companies and engineers to strike a balance between informal development--in Internet-time--and more traditional agile and plan-driven methods. The authors review six common practices and how they are blended to maximize time-sensitive development.     

Agile product-line architecting in practice: A case study in smart grids

ContextSoftware Product Line Engineering implies the upfront design of a Product-Line Architecture (PLA) from which individual product applications can be engineered. The big upfront design associated with PLAs is in conflict with the current need of “being open to change”. To make the development of product-lines more flexible and adaptable to changes, several companies are adopting Agile Product Line Engineering. However, to put Agile Product Line Engineering into practice it is still necessary to make mechanisms available to assist and guide the agile construction and evolution of PLAs.ObjectiveThis paper presents the validation of a process for “the agile construction and evolution of product-line architectures”, called Agile Product-Line Architecting (APLA). The contribution of the APLA process is the integration of a set of models for describing, documenting, and tracing PLAs, as well as an algorithm for guiding the change decision-making process of PLAs. The APLA process is assessed to prove that assists Agile Product Line Engineering practitioners in the construction and evolution of PLAs.MethodValidation is performed through a case study by using both quantitative and qualitative analysis. Quantitative analysis was performed using statistics, whereas qualitative analysis was performed through interviews using constant comparison, triangulation, and supporting tools. This case study was conducted according to the guidelines of Runeson and Höst in a software factory where three projects in the domain of Smart Grids were involved.ResultsAPLA is deployed through the Flexible-PLA modeling framework. This framework supported the successful development and evolution of the PLA of a family of power metering management applications for Smart Grids.ConclusionsAPLA is a well-supported solution for the agile construction and evolution of PLAs. This case study illustrates that the proposed solution for the agile construction of PLAs is viable in an industry project on Smart Grids.     

Integrating agile software development into stage-gate managed product development

Agile methods have evolved as a bottom-up approach to software development. However, as the software in embedded products is only one part of development projects, agile methods must coexist with project management models typically of the stage-gate type. This paper presents a qualitative case study of two large independent software system projects that have used eXtreme Programming (XP) for software development within contexts of stage-gate project management models. The study is comprised of open ended interviews with managers as well as practitioners, followed by a structured, fully traceable, qualitative analysis. We conclude that it is possible to integrate XP in a gate model context. Key issues for success are the interfaces towards the agile subproject and management attitudes towards the agile approach. Editor: Marvin Zelkowitz