Charting Coordination Needs in Large-Scale Agile Organisations with Boundary Objects and Methodological Islands

Large-scale system development companies are increasingly adopting agile methods. While this adoption may improve lead-times, such companies need to balance two trade-offs: (i) the need to have a uniform, consistent development method on system level with the need for specialised methods for teams in different disciplines (e.g., hardware, software, mechanics, sales, support); (ii) the need for comprehensive documentation on system level with the need to have lightweight documentation enabling iterative and agile work. With specialised methods for teams, isolated teams work within larger ecosystems of plan-driven culture, i.e., teams become agile “islands”. At the boundaries, these teams share knowledge which needs to be managed well for a correct system to be developed. While it is useful to support diverse and specialised methods, it is important to understand which islands are repeatedly encountered, the reasons or factors triggering their existence, and how best to handle coordination between them. Based on a multiple case study, this work presents a catalogue of islands and the boundary objects between them. We believe this work will be beneficial to practitioners aiming to understand their ecosystems and researchers addressing communication and coordination challenges in large-scale development

In search of the origins and enduring impact of agile software development

The Agile Manifesto is a philosophical touchpoint for all agile software development (ASD) methods. We examine the manifesto and some of its associated agile methods in an effort to identify the major impacts of ASD. We have encountered some difficulty in delineating agile and non-agile software processes, which is partially the result of terminological confusion. It is clear from the volume of published research that ASD has made a significant contribution, and we have identified two lasting and important impacts. Firstly, the reduction in iteration durations and secondly, the push for reduced levels of documentation (especially in relation to software requirements). Other aspects of the Agile Manifesto may not have exerted a significant impact; for example, the use of tooling to automate processes has become central to continuous software engineering (CSE) and may not be wholly congruent with the manifesto. Furthermore, many organisations may still rely on business contracts despite calls in the manifesto for greater levels of informal customer collaboration

Boundary objects in agile practices: Continuous management of systems engineering artifacts in the automotive domain

Automotive companies increasingly include proven agile methods in their plan-driven system development. The adoption of agile methods impacts not only the way individuals collaborate, but also the management of artifacts like requirements, test cases, safety documentation, and models. While practitioners aim to reduce unnecessary documentation, there is a lack of guidance for automotive companies with respect to what artifacts are needed and how to manage them. To close this knowledge gap and create practical guidelines, we conducted a design-science study together with 53 practitioners from six automotive companies. Using interviews, surveys, and focus groups, we analyzed categories of artifacts and practical challenges to create applicable guidelines to collaboratively manage artifacts in agile automotive contexts. Our findings indicate that different practices are required to manage artifacts that are shared among different teams within the company (boundary objects) and those that are relevant within a specific team (locally relevant artifacts)

Effect of Time-pressure on Perceived and Actual Performance in Functional Software Testing

Background: Time-pressure is an inevitable reality of software industry that influences the performance of software engineers. It may result in adverse effects on software quality or distort the perception of performance on executed tasks to differ from actual performance. Objective: We aim to investigate the effect of timepressure on perceived and actual performance of software testers in the context of functional software testing. Method: We performed two controlled experiments with 87 graduate students in two academic terms. We assessed actual performance in terms of coverage (i.e. percentage of test cases correctly identified) and perceived performance using NASA-TLX. We have an independent factorial design for our experimental study. Results: The results reveal a significant effect of time-pressure on actual performance. However, we could not observe a significant effect of time-pressure on the perceived performance of the participants for the task undertaken. We also observed a significant negative correlation between actual and perceived performance when controlled for time-pressure and experimental session factors. Conclusion: Time-pressure affects the actual performance in a testing task but the perception of accomplishment by the testers is sustained irrespective of time-pressure, indicating an over-estimation issue. Perception of performance should be adjusted to align with reality to account for the effect of time pressure. This will lead to better self estimates of performance.Academy of Finland Projec

Catching up with Method and Process Practice: An Industry-Informed Baseline for Researchers

Software development methods are usually not applied by the book.companies are under pressure to continuously deploy software products that meet market needs and stakeholders\u27 requests. To implement efficient and effective development processes, companies utilize multiple frameworks, methods and practices, and combine these into hybrid methods. A common combination contains a rich management framework to organize and steer projects complemented with a number of smaller practices providing the development teams with tools to complete their tasks. In this paper, based on 732 data points collected through an international survey, we study the software development process use in practice. Our results show that 76.8% of the companies implement hybrid methods.company size as well as the strategy in devising and evolving hybrid methods affect the suitability of the chosen process to reach company or project goals. Our findings show that companies that combine planned improvement programs with process evolution can increase their process\u27 suitability by up to 5%

Agile software development – Do we really calculate the costs? A multivocal literature review

Agile software development methods, in their various different forms, have become the basis for most software projects in today’s world. The methodology is present in almost all organisations today. However, despite the popularity, failure rates in software projects remain high. This paper identifies why agile methodologies have become so successful. In addition, the paper discusses certain factors that may often be overlooked in organisations that have adopted agile methods, such as rework, maintainability, adoption, turnover rates and the potential costs associated with each. The research carried out was a multivocal literature review (MLR). Multiple white and grey literature which was deemed to be relevant was selected. 32 contributions from white literature were selected for use in the review as well as 8 from grey literature sources. We find that while agile has many advantages, organisations may overlook the potential downsides of using an agile methodology. If not managed or implemented correctly, organisations risk taking on more hidden and expensive costs, for example in relation to rework. It is important that organisations are sufficiently trained in agile methods in order to succeed