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.     

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.     

Mockup-Driven Development: Providing agile support for Model-Driven Web Engineering

ContextAgile software development approaches are currently becoming the industry standard for Web Application development. On the other hand, Model-Driven Web Engineering (MDWE) methodologies are known to improve productivity when building this kind of applications. However, current MDWE methodologies tend to ignore important aspects of Web Applications development supported by agile processes, such as constant customer feedback or early design of user interfaces.ObjectiveIn this paper we analyze the difficulties of supporting agile features in MDWE methodologies. Then, we propose an approach that eases the incorporation of well-known agile practices to MDWE.MethodWe propose using User Interface prototypes (usually known as mockups) as a way to start the modeling process in the context of a mixed agile-MDWE process. To assist this process, we defined a lightweight metamodel that allows modeling features over mockups, interacting with end-users and generating MDWE models. Then, we conducted a statistical evaluation of both approaches (traditional vs. mockup-based modeling).ResultsFirst we comment on how agile features can be added to MDWE processes using mockups. Then, we show by means of a quantitative study that the proposed approach is faster, less error-prone and still as complete as traditional MDWE processes.ConclusionThe use of mockups to guide the MDWE process helps in the reduction of the development cycle as well as in the incorporation of agile practices in the model-driven workflow. Complete MDWE models can be built and generated by using lightweight modeling over User Interface mockups, and this process suggests being more efficient, in terms of errors and effort, than traditional modeling in MDWE.     

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.     

Usability in agile software development: A tertiary study

In the last years the interest in developing research on integration of usability and agile software development has been increasing. The number of systematic literature reviews, systematic mapping studies and non-systematic reviews, related to this thematic has also increased. Nevertheless, there is no analysis on the quality of these published secondary studies, nor is there a consolidated research that brings the answer of how to integrate these two areas. The goal of this paper is to categorize secondary studies related to the integration of usability and agile software development and present a critical analysis on the quality of the selected studies. To accomplish this goal a tertiary study was performed to categorize the related studies selected. Initially 3,065 papers were identified and further narrowed to 14 by applying exclusion criteria and analysis. We classified the selected studies as systematic literature reviews, systematic mapping studies and non-systematic literature reviews to report the data analysis. As a result of this study different forms to integrate usability and agile software development were detected as well as the various challenges that must be overcome for the integration success. Six main categories were identified to represent ways of integrating usability into agile development: processes, techniques, practices, recommendations, principles and different approaches. Regarding to the challenges for the integration seven main categories were also identified: issues related to tests, time, work balance, modularization, feedback, prioritization, and documentation. Although the interest in researching the integration of usability and agile software development has increased in the last years, mostly of the analyzed studies neglected the quality criteria and presented difficulties to use methods to synthetize the research results. Despite this, it has been realized that the integration of usability with agile software development is possible and is strongly aligned with user-centered design. The initial studies indicated a separation of activities and roles into specific tracks with parallel work to treat usability in agile software development, but the trend is no longer to manage and control these activities in separate ways, so new challenges are becoming to appear. Although we have identified several points of tension, the integration does not become unfeasible.     

Improving active participation during enterprise operations modeling with an extended story-card-method and participative modeling software

The COVID-19 pandemic emphasized the need for process automation, using agile software development practices. However, when agile methods are used in scaled contexts, many software development efforts fail, mainly due to lacking requirements engineering practices. When business-oriented software needs to be developed within a scaled context, the story-card method (SCM), developed as part of a previous study, assists in structuring emerging software requirements within a taxonomy that represents enterprise operation. The SCM helps agile team members to develop a common understanding about enterprise operation when they construct the enterprise operation taxonomy. Digital participatory enterprise modeling (PEM) may increase collaboration and understanding among team members, especially when team members are geographically dispersed, when they co-model their understanding of enterprise operations. Using design science research to further evolve the existing SCM, we identified two concerns regarding the existing SCM: (1) The modeling software did not encourage active participation during modeling, and (2) Low quality of the resulting cooperation structure diagram (CSD) that is used to derive an enterprise operation taxonomy, i.e., the need to further extend the existing SCM. As main contribution of this article, we addressed previous deficiencies of the SCM, developing an extended SCM (eSCM), based on principles and guidelines that would encourage online participation during PEM, also providing a comprehensive case to demonstrate the eSCM. As a second contribution, we used survey-feedback from research participants, as well as activity tracking to evaluate whether the modeling tool encouraged active PEM. Our third contribution is to evaluate the quality of the resulting CSDs with suggestions for future improvement.

     

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.     

“Leagile” software development: An experience report analysis of the application of lean approaches in agile software development

In recent years there has been a noticeable shift in attention from those who use agile software development toward lean software development, often labelled as a shift “from agile to lean”. However, the reality may not be as simple or linear as this label implies. To provide a better understanding of lean software development approaches and how they are applied in agile software development, we have examined 30 experience reports published in past agile software conferences in which experiences of applying lean approaches in agile software development were reported. The analysis identified six types of lean application. The results of our study show that lean can be applied in agile processes in different manners for different purposes. Lean concepts, principles and practices are most often used for continuous agile process improvement, with the most recent introduction being the kanban approach, introducing a continuous, flow-based substitute to time-boxed agile processes.     

Combining service-orientation and software product line engineering: A systematic mapping study

ContextService-Orientation (SO) is a rapidly emerging paradigm for the design and development of adaptive and dynamic software systems. Software Product Line Engineering (SPLE) has also gained attention as a promising and successful software reuse development paradigm over the last decade and proven to provide effective solutions to deal with managing the growing complexity of software systems.ObjectiveThis study aims at characterizing and identifying the existing research on employing and leveraging SO and SPLE.MethodWe conducted a systematic mapping study to identify and analyze related literature. We identified 81 primary studies, dated from 2000–2011 and classified them with respect to research focus, types of research and contribution.ResultThe mapping synthesizes the available evidence about combining the synergy points and integration of SO and SPLE. The analysis shows that the majority of studies focus on service variability modeling and adaptive systems by employing SPLE principles and approaches.In particular, SPLE approaches, especially feature-oriented approaches for variability modeling, have been applied to the design and development of service-oriented systems. While SO is employed in software product line contexts for the realization of product lines to reconcile the flexibility, scalability and dynamism in product derivations thereby creating dynamic software product lines.ConclusionOur study summarizes and characterizes the SO and SPLE topics researchers have investigated over the past decade and identifies promising research directions as due to the synergy generated by integrating methods and techniques from these two areas.     

The agile requirements refinery: Applying SCRUM principles to software product management

Context

Although agile software development methods such as SCRUM and DSDM are gaining popularity, the consequences of applying agile principles to software product management have received little attention until now.

Objective

In this paper, this gap is filled by the introduction of a method for the application of SCRUM principles to software product management.

Method

A case study research approach is employed to describe and evaluate this method.

Results

This has resulted in the ‘agile requirements refinery’, an extension to the SCRUM process that enables product managers to cope with complex requirements in an agile development environment. A case study is presented to illustrate how agile methods can be applied to software product management.

Conclusions

The experiences of the case study company are provided as a set of lessons learned that will help others to apply agile principles to their software product management process.     

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.     

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     

A comparative study of software tools for user story management

ContextUser stories have become widely accepted in agile software development. Consequently, a great number of software tools that provide, inter alia, support for practices based on user stories have emerged in recent years. These tools may have different features and focus in terms of support for agile requirements engineering (RE) concepts and practices.ObjectiveThe present study aims to provide a deep insight into the current capabilities and future trends of software support for agile RE practices based on user stories.MethodA comparative qualitative study of a set of agile software tools has been conducted according to the following criteria: coverage of the key functional requirements, support for basic agile RE concepts and practices, and user satisfaction with the tool. The criteria for tool selection were: diversity of software tools, high rating on the user-stories community Web site (http://www.userstories.com), and availability for review.ResultsThe results show a generally good coverage of key functional requirements related to management of user stories and epics, high-level release planning and low-level iteration planning. On the other hand, user-role modeling and persona support have not been addressed at all, and it has been found that requirements for acceptance testing support were completely covered by only one tool. More importantly, the study has revealed significant differences in the way different tools support agile RE concepts and practices (if at all). Finally, qualitative analysis of user reviews has demonstrated that practitioners prefer tools that are easy to set up, easy to learn, easy to use, and easy to customize, over more sophisticated but simultaneously more demanding tools.ConclusionAlthough the progress that has been made since the inception of these tools is quite clear, there is still room for improvements in terms of support for various agile RE practices within a specific agile process.     

Raising the odds of success: the current state of experimentation in product development

ContextAn experiment-driven approach to software product and service development is gaining increasing attention as a way to channel limited resources to the efficient creation of customer value. In this approach, software capabilities are developed incrementally and validated in continuous experiments with stakeholders such as customers and users. The experiments provide factual feedback for guiding subsequent development.ObjectiveThis paper explores the state of the practice of experimentation in the software industry. It also identifies the key challenges and success factors that practitioners associate with the approach.MethodA qualitative survey based on semi-structured interviews and thematic coding analysis was conducted. Ten Finnish software development companies, represented by thirteen interviewees, participated in the study.ResultsThe study found that although the principles of continuous experimentation resonated with industry practitioners, the state of the practice is not yet mature. In particular, experimentation is rarely systematic and continuous. Key challenges relate to changing the organizational culture, accelerating the development cycle speed, and finding the right measures for customer value and product success. Success factors include a supportive organizational culture, deep customer and domain knowledge, and the availability of the relevant skills and tools to conduct experiments.ConclusionsIt is concluded that the major issues in moving towards continuous experimentation are on an organizational level; most significant technical challenges have been solved. An evolutionary approach is proposed as a way to transition towards experiment-driven development.     

Needs’ elaboration between users,designers and project leaders: Analysis of a design process of a virtual reality-based software

ContextThe participation of users in the design process is recognized as a positive and a necessary element as artifacts suit their needs. Two complementary approaches of users’ involvement co-exist: the user-centered design and the participatory design. These approaches involve learning process from users to designers and vice versa. However, there has no research in design of virtual reality (VR)-based software dealing with how the elaboration of needs is actually distributed in time and among users, designers and project leaders, as well as how it is actually supported by tools and methods.ObjectiveThis paper aims to observe, in a real design project of a virtual reality-based software, how the various stakeholders (users, designers, project leaders) actually participate by sharing and pulling pieces of information from the process of needs elaboration, and how these contributions evolve throughout the decisions made in the course of the project.MethodOur method, based on the observation of the practices in collective design, allows us to collect and analyze the relationship between each possible action (e.g., elicitation), each stakeholder who initiates these actions (e.g., users) and each phase of the design process (e.g., evaluation phase), and the dynamics of the construction of needs.ResultsOur results detail how the elicited needs are dealt with by designers, users and/or project leaders: (1) we show a strong contribution of users in the design, compared to others stakeholders, (2) among the needs elicited by users, most have been validated by the designers, (3) some elicited needs could have been firstly rejected and finally validated and implemented.ConclusionWe identify the reasons which justify and explain our results confronting them to the literature. We underline the conditions have been satisfied in our study in order to involve effectively users in the design of emerging technologies.     

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.     

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.     

Categorization of risk factors for distributed agile projects

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

The state of the art in automated requirements elicitation

ContextIn large software development projects a huge number of unstructured text documents from various stakeholders becomes available and needs to be analyzed and transformed into structured requirements. This elicitation process is known to be time-consuming and error-prone when performed manually by a requirements engineer. Consequently, substantial research has been done to automate the process through a plethora of tools and technologies.ObjectiveThis paper aims to capture the current state of automated requirements elicitation and derive future research directions by identifying gaps in the existing body of knowledge and through relating existing works to each other. More specifically, we are investigating the following research question: What is the state of the art in research covering tool support for automated requirements elicitation from natural language documents?MethodA systematic review of the literature in automated requirements elicitation is performed. Identified works are categorized using an analysis framework comprising tool categories, technological concepts and evaluation approaches. Furthermore, the identified papers are related to each other through citation analysis to trace the development of the research field.ResultsWe identified, categorized and related 36 relevant publications. Summarizing the observations we made, we propose future research to (1) investigate alternative elicitation paradigms going beyond a pure automation approach (2) compare the effects of different types of knowledge on elicitation results (3) apply comparative evaluation methods and multi-dimensional evaluation measures and (4) strive for a closer integration of research activities across the sub-fields of automatic requirements elicitation.ConclusionThrough the results of our paper, we intend to contribute to the Requirements Engineering body of knowledge by (1) conceptualizing an analysis framework for works in the area of automated requirements elicitation, going beyond former classifications (2) providing an extensive overview and categorization of existing works in this area (3) formulating concise directions for future research.