Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

Spotify tailoring for promoting effectiveness in cross-functional autonomous squads

Organisations tend to tailor agile methods to scale employed practices to have cross-functional autonomous teams while promoting sustainable creative and productive development at a constant pace. Thus, it is important to investigate how organisations tailor agile practices to get the balance right between teams' autonomy and alignment. Spotify model is originally introduced to facilitate the development of music streaming services in a very large-scale project with a Business-to-Consumer (B2C) model. However, developing a large-scale mission-critical project with a Business-to-Business (B2B) model is not essentially supported by the Spotify model. Thus, embracing Spotify model for such projects should be concerned about the question of how Spotify practices are adjusted to promote the effectiveness of cross-functional autonomous squads in a mission-critical project with B2B model? In this paper, we conduct a longitudinal embedded case study, which lasted 21 months during which 14 semi-structured interviews were conducted. The Grounded Theory (GT) is adopted to analyse the collected data. As a result, we identify practices and processes that promote effectiveness in cross-functional autonomous squads, which have never been discussed in terms of Spotify model before. We also present Spotify Tailoring by highlighting modified and newly introduced practices by the organisation in which the case study was conducted

Influential factors of aligning Spotify squads in mission-critical and offshore projects – a longitudinal embedded case study

Changing the development process of an organization is one of the toughest and riskiest decisions. This is particularly true if the known experiences and practices of the new considered ways of working are relative and subject to contextual assumptions. Spotify engineering culture is deemed as a new agile software development method which increasingly attracts large-scale organizations. The method relies on several small cross-functional self-organized teams (i.e., squads). The squad autonomy is a key driver in Spotify method, where a squad decides what to do and how to do it. To enable effective squad autonomy, each squad shall be aligned with a mission, strategy, short-term goals and other squads. Since a little known about Spotify method, there is a need to answer the question of: How can organizations work out and maintain the alignment to enable loosely coupled and tightly aligned squads? In this paper, we identify factors to support the alignment that is actually performed in practice but have never been discussed before in terms of Spotify method. We also present Spotify Tailoring by highlighting the modified and newly introduced processes to the method. Our work is based on a longitudinal embedded case study which was conducted in a real-world large-scale offshore software intensive organization that maintains mission-critical systems. According to the confidentiality agreement by the organization in question, we are not allowed to reveal a detailed description of the features of the explored project

Detecting Coordination Problems in Collaborative Software Development Environments

Software development is rarely an individual effort and generally involves teams of developers collaborating to generate good reliable code. Among the software code there exist technical dependencies that arise from software components using services from other components. The different ways of assigning the design, development, and testing of these software modules to people can cause various coordination problems among them. We claim\ud that the collaboration of the developers, designers and testers must be related to and governed by the technical task structure. These collaboration practices are handled in what we call Socio-Technical Patterns.\ud The TESNA project (Technical Social Network Analysis) we report on in this paper addresses this issue. We propose a method and a tool that a project manager can use in order to detect the socio-technical coordination problems. We test the method and tool in a case study of a small and innovative software product company

Digital maturity variables and their impact on the enterprise architecture layers

This study examines the variables of digital maturity of companies. The framework for enterprise architectures Archimate 3.0 is used to compare the variables. The variables are assigned to the six layers of architecture: Strategy, Business Environment, Applications, Technology, Physical and Implementation and Migration. On the basis of a literature overview, 15 “digital maturity models” with a total of 147 variables are analyzed. The databases Scopus, EBSCO – Business Source Premier and ProQuest are used for this purpose

Collaborative Environments. Considerations Concerning Some Collaborative Systems

It is obvious, that all collaborative environments (workgroups, communities of practice, collaborative enterprises) are based on knowledge and between collaboration and knowledge management there is a strong interdependence. The evolution of information systems in these collaborative environments led to the sudden necessity to adopt, for maintaining the virtual activities and processes, the latest technologies/systems, which are capable to support integrated collaboration in business services. In these environments, portal-based IT platforms will integrate multi-agent collaborative systems, collaborative tools, different enterprise applications and other useful information systems.collaboration, collaborative environments, knowledge management, collaborative systems, portals, knowledge portals, agile development of portals

Aligning an ISO/EIC 42010 System Architecture Model and Agile Practice

The ISO/EIC 42010 system architecture description standard evolved over a number of years with substantial practitioner inputs. It presents a high level, top-down view of requirements that may be interpreted as needed for different applications. Agile system development methods have proved effective in practice, but represent a bottom up view drawing on user stories. The question considered in this paper is how they might be harmonised. Experience from using these tools over several years in practical masters degree student projects has been used to explore this question. We suggest a logical compatibility lies in their core themes: stakeholder needs (who) frame architecture descriptions (what) and the associated rationale (why). A particular interpretation of ISO/EIC 42010 and a model outlining the evolution of architecture in an agile environment are presented. Several suggestions for future research are made

The Impact of Requirements on Systems Development Speed: A Multiple-Case Study in Automotive

Automotive\ua0manufacturers have historically adopted rigid\ua0requirements\ua0engineering processes. This allowed them to meet safety-critical\ua0requirements\ua0when producing\ua0a\ua0highly complex and differentiated product out of the integration of thousands of physical and software components. Nowadays, few software-related domains are as rapidly changing as the\ua0automotive\ua0industry.\ua0In\ua0particular, the needs of improving\ua0development\ua0speed\ua0are increasingly pushing companies\ua0in\ua0this domain toward new ways of developing software.\ua0In\ua0this paper, we investigate how the goal to increase\ua0development\ua0speed\ua0impacts how\ua0requirements\ua0are managed\ua0in\ua0the\ua0automotive\ua0domain. We start from\ua0a\ua0manager perspective, which we then complement with\ua0a\ua0more general perspective. We used\ua0a\ua0qualitative\ua0multiple-case\ua0study, organized\ua0in\ua0two steps.\ua0In\ua0the first step, we had 20 semi-structured interviews, at two\ua0automotive\ua0manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists.\ua0In\ua0the second step, we validated our results with 12 more interviews, covering nine additional respondents and three recurring from the first step.\ua0In\ua0addition to validating our qualitative model, the second step of interviews broadens our perspective with technical experts and change managers. Our respondents indicate and rank six aspects of the current\ua0requirements\ua0engineering approach that\ua0impact\ua0development\ua0speed. These aspects include the negative\ua0impact\ua0of\ua0a\ua0requirements\ua0style dominated by safety concerns as well as decomposition of\ua0requirements\ua0over many levels of abstraction. Furthermore, the use of\ua0requirements\ua0as part of legal contracts with suppliers is seen as hindering fast collaboration. Six additional suggestions for potential improvements include domain-specific tooling, model-based\ua0requirements, test automation, and\ua0a\ua0combination of lightweight upfront\ua0requirements\ua0engineering preceding\ua0development\ua0with precise specifications post-development. Out of these 12 aspects, seven can likely be addressed as part of an ongoing agile transformation. We offer an empirical account of expectations and needs for new\ua0requirements\ua0engineering approaches\ua0in\ua0the\ua0automotive\ua0domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical\ua0systems