Abstract Many studies of practices involve service exchange, and many service researchers have discovered the central role that sociotechnical practices play in service –in particular, within the service-dominant logic school of thought. In this paper, we propose an analytical lens that builds on this mutual interest to understand complex practices involving service exchange. Practice researchers can gain new insights regarding practices embedded in service ecosystems. At the same time, service researchers can better explain actor behavior by looking deeper at sociotechnical practices. We develop a concept toolbox based on practice and service-dominant logic research literature. We illustrate the usefulness of the toolbox through an interpretative case study of public service to include children with disabilities in leisure activities. Seeing practices as parts of larger multi-stakeholder service ecosystems 1) can help us better explain behavior in those practices and understand how they are affected by other overlapping practices, 2) brings forward the importance of value and how multiple actors need to interact in order to create value for each other, and 3) enriches service-dominant logic with a focus on sociotechnical aspects that are central to many practice studies.

Feedback involves dialogic processes whereby learners make sense of information from various sources and use it to enhance their work or learning strategies. This is an essential catalyst for learning. However, it takes work to achieve, particularly in large-scale courses. In this research-in-progress paper, we critically reflect on our approach to achieving feedback as a process in a large-scale semi-capstone software engineering course. We describe the steps taken over three years to improve feedback and critically reflect on how feedback is done using critical evaluation perspectives of peers, own reflections, students’ perspectives, and theory. Based on these reflections, we discuss four action items planned for this year, including strengthening the community of practice amongst teaching assistants, using relative assessments, improving rubrics, and using technology for feedback. We also discuss how we plan to evaluate these action items.

Abstract To satisfy the need for analytical data in the development of digital services, many organizations use data warehouse, and, more recently, data lake architectures. These architectures have traditionally been accompanied by centralized organizational models, where a single team or department has been responsible for gathering, transforming, and giving access to analytical data. However, such centralized models presuppose stability and are incompatible with agile software development where applications and databases are continuously updated. To achieve more agile forms of data management, some organizations have therefore begun to experiment with distributed data management models such as “data meshes”. Research on this topic is however limited. In this paper, we report findings from a case study of a public sector organization in Norway that has begun the transition from centralized to distributed data management, outlining both the benefits and challenges of a distributed approach.

Abstract Along with the increasing popularity of agile software development, software work has become much more social than ever. Contemporary software teams rely on a variety of collaborative practices, such as pair programming, the topic of our study. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artefacts incorporated in the shared workspace, which the COVID-19 pandemic made unavailable; most software companies around the world were forced to send their engineers to work from home. As software projects and teams overnight turned into distributed collaborations, we question what happened to the pair programming practice in the work-from-home mode. This paper reports on a longitudinal study of remote pair programming in two companies. We conducted 38 interviews with 30 engineers from Norway, Sweden, and the USA, and used the results of a survey in one of the case companies. Our study is unique as we collected the data longitudinally in April/May 2020, Sep/Oct 2020, and Jan/Feb 2021. We found that pair programming has decreased and some interviewees report not pairing at all for almost a full year. The experiences of those who paired vary from actively co-editing the code by using special tools to more passively co-reading and discussing the code and solutions by sharing the screen. Finally, we found that the interest in and the use of PP over time, since the first months of the forced work from home to early 2021, has admittedly increased, also as a social practice.

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.

Abstract Many see retrospectives as the most important practice of agile software development. Previous studies of retrospectives have focused on process and outcome at team level. In this article, we study how a large-scale agile development project uses retrospectives through an analysis of retrospective reports identifying a total of 109 issues and 36 action items as a part of a longitudinal case study. We find that most of the issues identified relate to team-level learning and improvement, and discuss these findings in relation to current advice to improve learning outcome in large-scale agile development.

Offshore oil exploration is concerned with subsea geological reservoirs that are numerous kilometers below the seabed. These reservoirs are knowable only through a knowledge infrastructure of interconnected technologies that are applied to diverse instrument-generated data. Noise, holes, and inaccuracies are inherent in the data, which depend on the technology producing it. We conducted an interpretative case study of data handling work in the exploration unit of a European oil company. Our findings show how data handling involves the skills needed for managing data identities and ownership, a variety of technologies, and contingent negotiations of data needs. We use the notion of repair to analyze this data handling work and discuss how the concept of repair in data handling involves keeping the knowledge infrastructure navigable and attending to countless details. Our research contributes to the literature on repairing infrastructures by considering how repair relates to data work.

The operating context of mobile applications and services is constantly changing. In order to achieve higher levels of usability, mobile applications and services need to adapt to changes in context. This paper argues the need for adaptation enabling middleware that simplifies the development of context aware adaptive applications, and makes it economically and practically feasible to develop such applications. We claim that the traditional approach of simply providing contextual information to applications and let them handle the adaptation can be ineffective. We suggest a holistic approach where context management is an integral part of a more comprehensive adaptation enabling middleware. This paper describes the role and the design of the context management component in such a middleware architecture. The feasibility of the approach is demonstrated in a scenario where proof-of-concept implementations have been developed and evaluated.