Boundary artefacts are shared artefacts that support collaboration by allowing different groups to interpret the same information in different ways. Software development activities benefit from them, as a single artefact can support stakeholders across different organisational boundaries. When these artefacts contain inconsistencies, such as incorrect information, practitioners’ trust in them may decrease, leading to inefficiencies in task execution. This study developed and evaluated a guideline to support the creation of boundary artefacts in software engineering contexts. We conducted a longitudinal, multi-phase study embedded in an industrial setting. The guideline was developed based on a literature review and prior findings from a previous case study and was then submitted for practitioner evaluation. A post-implementation analysis of the guideline was carried out after a period without researcher intervention. Our guideline consists of 10 principles grouped into three categories: (1) Scope: stakeholders, boundaries, and terminology; (2) Structure: artefact format, transference, granularity, and additions; and (3) Management: evaluation, ownership, governance, and integration. Practitioner evaluations suggested that these principles support the creation of reliable, predictable, and functional boundary artefacts. However, practitioners also noted challenges during use, including the time-consuming nature of the activity and difficulties in understanding the concept of boundary artefact. Overall, the guideline was well received. After the non-intervention period, it was adopted as a standard by the partner company for artefacts such as security testing, standards documentation, and requirements specifications. Adoption challenges persisted, including cultural barriers and comprehension issues. Further applications across different artefacts could clarify how the principles influence their reliability, functionality, and predictability.

Boundary Artefacts (BAs) support software development activities in many aspects because it carries lots of information in the same object that can be used and interpreted by several social groups within an organisation. When the BAs are inconsistent regarding their content, such as many meanings or lack of contextual information, their efficiency is reduced because stakeholders won’t trust them. This study aimed to understand the implications of differences in the perception of trust on software projects and their influence on stakeholders’ behaviour. We conducted an exploratory case study to observe the creation and utilisation of one specific BA and the implications of differences in trust and their influence on stakeholders’ behaviour. : Our investigation has shown that practitioners adding and adjusting existing content do not entirely understand the stakeholders’ needs. Together with the partial management of the content, trust is impacted. When the content of BAs does not meet the trust factors, specifically reliability and predictability, the stakeholders can’t execute their tasks appropriately, and several implications affect the software development project. Additionally, they create workarounds to supply their needs. The differences in trust in BAs affect software projects in different areas of the organisation and interfere with the task execution of various stakeholders. The decrease in trust results from inconsistencies in the content associated with the lack of management of the BA. A structured strategy for representing and managing a BA’s content seems appropriate to increase trust levels and efficiency.

Abstract Large-scale software engineering is a collaborative effort where teams need to communicate to develop software products. Managers face the challenge of how to organise work to facilitate necessary communication between teams and individuals. This includes a range of decisions from distributing work over teams located in multiple buildings and sites, through work processes and tools for coordinating work, to softer issues including ensuring well-functioning teams. In this case study, we focus on inter-team communication by considering geographical, cognitive and psychological distances between teams, and factors and strategies that can affect this communication. Data was collected for ten test teams within a large development organisation, in two main phases: (1) measuring cognitive and psychological distance between teams using interactive posters, and (2) five focus group sessions where the obtained distance measurements were discussed. We present ten factors and five strategies, and how these relate to inter-team communication. We see three types of arenas that facilitate inter-team communication, namely physical, virtual and organisational arenas. Our findings can support managers in assessing and improving communication within large development organisations. In addition, the findings can provide insights into factors that may explain the challenges of scaling development organisations, in particular agile organisations that place a large emphasis on direct communication over written documentation.