Agile Processes in Software Engineering and Extreme Programming

A key challenge organisations face when transitioning to agile delivery methods is that of quickly and effectively learning new ways of working. This study posits that fundamental historical, cultural and behavioural aspects affect the transition and contribute to the poor performance of many agile implementations. In order to address such factors, this study applies a modified Activity Theory (AT) based framework to a case study agile implementation within a large public sector organisation. An activity is closely defined, and six generic activities associated with all agile implementations are identified. These are validated against the agile maturity model literature and a set of evaluation criteria of contradictions, congruences and collaboration is established. Evidence is gathered from participant interviews and the framework is used to surface learning and development obstacles and issues within an expansive learning cycle. The study argues that analysis via this modified AT framework brings original insight. Initial findings indicate that there are relatively few learning and development issues associated with the use of agile tools and techniques themselves and that most problems arise at the interface where the “changed” (more agile) delivery teams meet the organisation’s behavioural norms and practices.

Although a stable team is deemed optimal for agile project success, new team members need to join ongoing agile projects. Newcomers must rapidly assimilate into the organisational and project environment while learning how to contribute effectively to the project and integrate into the team without seriously interrupting project progress. This paper addresses how newcomers integrate into an established agile project team and the challenges newcomers and the team face during this process. This paper is a single case study of a co-located agile project team in a large IT department who regularly onboard inexperienced newcomers. We found a mixture of traditional onboarding practices and specific agile practices contribute to the onboarding process. Onboarding challenges include empowerment and mindset change, accommodating part-timers, conveying agile principles, and adjusting to changes in team composition.

The combined use of User-Centered Design and Lean Startup with Agile Development has been pointed out by the literature as a manner to boost software development. User-Centered Design principles focus on providing tools for developers to better explore user needs and seek for a fitter solution. Lean Startup, on the other hand, supplements the triad combination by bringing the Build-Measure-Learn cycle and the concept of pivoting, either the problem understanding or the proposed solution. This paper reports on a case study of two software teams that have been undergoing the changes and impacts of such combined adoption. We investigated these teams for six months, from the moment that team members were trained on the job to grasp the essence of using the integrated approach inspired on Pivotal Labs proposal to the time they were considered mature enough to share their experiences with others within the organization. Through our in-depth study, we illustrate how this adoption promotes changes regarding to mindset, activities, practices, and techniques. We also report on the ‘team rhythm’ (or work flow) as experienced by the two teams. The paper contributes to current knowledge on the topic reporting on the changes and impacts that teams observed during the combined approach adoption.

Although agile practices are gaining in popularity, there is little evidence showing how particular agile practices, in particular those involving the client, affect the success of outsourced software projects. Data from a matched survey of sponsors and developers in 60 outsourced information systems projects indicate negative effects of continuous analysis and positive effects of joint decision making and continuous integration on project success. Moreover, interaction analyses show that some positive effects are enhanced and negative effects dampened when requirements risk is high. These findings caution against continuous analysis in outsourced projects while they support joint decision making and continuous integration. The findings also empirically substantiate the largely untested assertion that agile practices help cope with changing requirements.

Design Thinking (DT) has been chosen as an approach to support problem-solving by many software development companies. However, there are divergences between the professionals of these companies concerning which techniques are performed, which steps are followed, and the way to implement this approach, as it proposes itself, to be divergent to generate numerous alternatives and, also, convergent, to find a solution. For this reason, aiming to characterize how the software companies have been implemented DT, this paper presents the results of a survey answered by 127 professionals from the Brazilian software industry. The results report a variety of scenarios in which DT has been applied: more than ten different models (sets of steps) are followed by the professionals; more than 50 techniques have been used, mainly, for meeting the needs in the process, according to the context of use and based on previous experiences. We also present 29 computational tools that, according to the respondents, assist the execution of DT, in addition to the integration with agile methods, allowing them to generate ideas and solutions, to explore and understand the problem.

Behaviour Driven Development (BDD) is an agile testing technique that enables software requirements to be specified as example interactions with the system, using structured natural language. While (in theory) being readable by non-technical stakeholders, the examples can also be executed against the code base to identify behaviours that are not yet correctly implemented. Writing good BDD suites, however, is challenging. A typical suite can contain hundreds of individual scenarios, that must correctly specify the system as a whole as well as individually. Despite much discussion amongst practitioners and in the blogosphere, as yet no formal definition of what makes for a high quality BDD suite has been given. To shed light on this, we surveyed BDD practitioners, asking for their opinions on the quality criteria that are important for BDD suites. We proposed, and asked for opinions on, four quality principles, and gave practitioners the option to add more principles of their own. This paper reports on the results of the survey, and presents an approach to defining BDD suite quality.

User stories are popular for conveying requirements in agile software projects. Despite existing quality criteria, authors make formal mistakes that result in “bad” user story quality. If developers have insufficient experience in balancing quality problems, the creation of a shared mental model is impossible, thus increasing the risk of impacts on the project’s success. This article provides a work-in-progress research model to set these variables in relation and establish a systematic method to uncover answers regarding their correlation. Details on the effects support research in agile requirements engineering to gain a better understanding of cognitive processes in the comprehension of user stories. In addition, insights can help to develop design recommendations and AI tools to improve user stories. A first evaluation of the model provides promising insights into the behavior and forms a basis for future research.

Today, product development organizations are adopting agile methods in units outside the software development unit, such as in sales, market, legal, operations working with the customer. This broader adoption of agile methods has been labeled large-scale agile transformation and is considered a particular type of organizational change, originating in the software development units. So far, there is little research-based advice on conducting such transformations. Aiming to contribute towards providing relevant research advice on large-scale agile transformation, we apply a research-based framework for evaluating organizational agility on a product development program in a maritime service provider organization. We found that doing a large-scale agile transformation involves many significant challenges, such as having a shared understanding of the problem, getting access to users, and getting commitment to change that needs to be done. In order to overcome such challenges, we discuss the need for a holistic and integrated approach to agile transformation involving all the units linked to software development.

Agile methods are designed for handling uncertainty as well as reducing risks in product development through transparency, inspection, and adaptation. Applying an effective risk management is in the nature of agile methods. However, when multiple agile teams work on the same product, a higher coordination effort is required and more formal practices are applied. The objective of this paper is to study how risk management can be improved in a scaled agile environment. Therefore, we conducted a case study in a large-sized ecommerce company and interviewed several project managers. The results show that there are differences for risk management in terms of two contexts. On the one hand, informal risk management is rated as good enough for one autonomous team. On the other hand, more formal approaches are needed, when several teams work on the same requirement. Furthermore, a tool for the support of risk management in a scaled agile environment is presented. We can conclude that hybrid development approaches consisting of agile practices and traditional practices, are beneficial, when several teams work in parallel.

With the growing interest of adopting agile methods in offshored process, many companies realized that the use of agile methods and practices in companies located outside the location of early adopters of agile methods may be challenging. India, the main destination of offshoring contracts, have received particular attention, due to the big cultural differences. Critical analysis of related studies suggests that impeding behaviors are mostly rooted in the hierarchical culture of Indian organizations and related management behavior of command-and-control. But what happens in distributed projects with a more empowering onshore management? In this paper, we present the findings from a multiple-case study of DevOps teams with members from a mature agile company located in Sweden and a more hierarchical offshore vendor from India. Based on two focus groups we list culturally different behaviors of offshore engineers that were reported to impede agile ways of working. Furthermore, we report the findings from surveying 36 offshore team members from five DevOps teams regarding their likely behavior in situations reported to be problematic. Our findings confirm a number of previously reported behaviors rooted in cultural differences that impede the adoption of agile ways of working when collaborating with offshore engineers. At the same time, our survey results suggest that among the five surveyed teams there were teams that succeeded with the cultural integration of the offshore team members. Finally, our findings demonstrate the importance of cultural training especially when onboarding new team members.

A number of qualitative studies find that team leadership is one essential success factor for evolving into a mature agile team. One such qualitative study suggests the 9-Factor Theory of Scrum Master roles, which claims that the Scrum Master performs a set of 9 leadership roles which are transferred to the team over time [14].

We aimed at conducting a quantitative exploration that examines the presence and change of the 9-Factor Theory in relation to team maturity. We conducted an online survey with 67 individuals at the conglomerate Robert Bosch GmbH. Descriptive statistics reveal that the Scrum Master and the agile team score differently on the 9 factors and that the Scrum Master role is most often distributed in teams that had been working between 3 and 5 months in an agile manner. Yet, we also find that the leadership roles predominantly remain with one dedicated Scrum Master.

Based on our results we suggest to group the 9-Factor Theory into three clusters: the Scrum Master is rather linked to psychological team factors (1), while the team tends to be linked to rather product-related factors (2). Organizational factors (3) are less often present.

Our practical implications suggest an extension of the Scrum Master description. Furthermore, our study lays groundwork for future quantitative testing of leadership in agile teams.

When large industrial organizations change to (or start with) an agile approach to operations, managers and some employees are supposed to be “agile leaders” often without being given a clear definition of what that comprises when building agile teams. An inductive thematic analysis was used to investigate what 15 appointed leaders actually do and perceive as challenges regarding group dynamics working with an agile approach. Team maturity, Team design, and Culture and mindset were all categories of challenges related to group dynamics that the practitioners face and manage in their work-life that are not explicitly mentioned in the more process-focused agile transformation frameworks. The results suggest that leader mitigation of these three aspects of group dynamics is essential to the success of an agile transformation.

Artificial Intelligence (AI) solutions are becoming increasingly common in software development endeavors, and consequently exert a growing societal influence as well. Due to their unique nature, AI based systems influence a wide range of stakeholders with or without their consent, and thus the development of these systems necessitates a higher degree of ethical consideration than is currently carried out in most cases. Various practical examples of AI failures have also highlighted this need. However, there is only limited research on methods and tools for implementing AI ethics in software development, and we currently have little knowledge of the state of practice. In this study, we explore the state of the art in startup-like environments where majority of the AI software today gets developed. Based on a multiple case study, we discuss the current state of practice and highlight issues. The cases underline the complete ignorance of ethical consideration in AI endeavors. We also outline existing good practices that can already support the implementation of AI ethics, such as documentation and error handling.

Software startups develop innovative products for which there are typically no customers to refer to elicit requirements. Often, these companies develop a set of features without a better understanding of customer needs. An experiment-based approach to validate hypotheses about the customer and market could increase their chance of success or, at least, accelerate their realization of the product worthlessness. The first step of an experiment-based approach is to elicit hypotheses to guide experiments. Software startups base their products on business assumptions, but there is a lack of understanding of how these assumptions are formed and how teams could elicit hypotheses systematically. To fill this gap, we performed an empirical study consisted of two steps. First, we explored based on which assumptions startups define their products using a multiple case study. The results indicate that these companies developed their products based on founders’ assumptions derived from their previous experience. Second, we investigated cognitive mapping as a tool to elicit hypotheses systematically with two software startups. The results indicate that this approach can serve as the basis of a method to elicit hypotheses in early-stage software startups.

Test-Driven Development (TDD) is an incremental approach to software development. Despite it is claimed to improve both quality of software and developers’ productivity, the research on the claimed effects of TDD has so far shown inconclusive results. Some researchers have ascribed these inconclusive results to the negative affective states that TDD would provoke. A previous (baseline) experiment has, therefore, studied the affective reactions of (novice) developers—i.e., 29 third-year undergraduates in Computer Science (CS)—when practicing TDD to implement software. To validate the results of the baseline experiment, we conducted a replicated experiment that studies the affective reactions of novice developers when applying TDD to develop software. Developers in the treatment group carried out a development task using TDD, while those in the control group used a non-TDD approach. To measure the affective reactions of developers, we used the Self-Assessment Manikin instrument complemented with a liking dimension. The most important differences between the baseline and replicated experiments are: (i) the kind of novice developers involved in the experiments—third-year vs. second-year undergraduates in CS from two different universities; and (ii) their number—29 vs. 59. The results of the replicated experiment do not show any difference in the affective reactions of novice developers. Instead, the results of the baseline experiment suggest that developers seem to like TDD less as compared to a non-TDD approach and that developers following TDD seem to like implementing code less than the other developers, while testing code seems to make them less happy.

Testing is an important phase of every software system, as it can reveal defects early and contribute to achieving high software quality. In this process of quality assurance, organizations are usually relying on one testing technique. However, a combination of techniques may prove more beneficial to the organization, as it might give the chance to discover a larger number of defects early. In order to examine the above, in the current work we present a survey on the use of system testing methodologies. We have gathered data from 252 individuals that reveal current trends in testing, such as whether requirements are used in the test case definition and whether the testing techniques used are affected by parameters, such as years of experience, whereas we examine the combination of smoke testing and regression testing. We also demonstrate an industrial use case, where this combination was applied, reducing the number of defects identified by the customer.