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

Acupuncture for dry eye syndrome after refractive surgery: study protocol for a randomized controlled trial

Agile software development is increasingly adopted by companies evolving and maintaining software products to support better planning and tracking the realization of user stories and features. While convincing success stories help to further spread the adoption of Agile, mechatronics-driven companies need guidance to implement Agile for non-software teams. In this comparative case study of three companies from the Nordic region, we systematically investigate expectations and challenges from scaling Agile in organizations dealing with mechatronics development by conducting on-site workshops and surveys. Our findings show that all companies have already successfully implemented Agile in their software teams. The expected main benefit of successfully scaling agile development is a faster time-to-market product development; however, the two main challenges are: (a) An inflexible test environment that inhibits fast feedback to changed or added features, and (b) the existing organizational structure including the company\u27s mind-set that needs to be opened-up for agile principles

Improving Requirements-Test Alignment by Prescribing Practices that Mitigate Communication Gaps

The communication of requirements within software development is vital for project success. Requirements engineering and testing are two processes that when aligned can enable the discovery of issues and misunderstandings earlier, rather than later, and avoid costly and time-consuming rework and delays. There are a number of practices that support requirements-test alignment. However, each organisation and project is different and there is no one-fits-all set of practices. The software process improvement method called Gap Finder is designed to increase requirements-test alignment. The method contains two parts: an assessment part and a prescriptive part. It detects potential communication gaps between people and between artefacts (the assessment part), and identifies practices for mitigating these gaps (the prescriptive part). This paper presents the design and formative evaluation of the prescriptive part; an evaluation of the assessment part was published previously. The Gap Finder method was constructed using a design science research approach and is built on the Theory of Distances for Software Engineering, which in turn is grounded in empirical evidence from five case companies. The formative evaluation was performed through a case study in which Gap Finder was applied to an on-going development project. A qualitative and mixed-method approach was taken in the evaluation, including ethnographically-informed observations. The results show that Gap Finder can detect relevant communication gaps and seven of the nine prescribed practices were deemed practically relevant for mitigating these gaps. The project team found the method to be useful and supported joint reflection and improvement of their requirements communication. Our findings demonstrate that an empirically-based theory can be used to improve software development practices and provide a foundation for further research on factors that affect requirements communicatio

Inoculating an agile company with user-centred design: an empirical study

We present an empirical study on facilitating the adoption of user-centred design (UCD) in small Agile companies. To this end, we introduced a curated set of qualitative design practices in an Agile organisation, engaging developers in a lightweight series of workshops. Our results suggest that the approach followed enhanced internal communication and promoted a concrete shift towards a more user-centred perspective. However, the presence of a predominant non-Agile customer seems to have limited potential benefits. © The Author(s) 2017

Scaling Agile Beyond Organizational Boundaries: Coordination Challenges in Software Ecosystems

The shift from sequential to agile software development originates from relatively small and co-located teams but soon gained prominence in larger organizations. How to apply and scale agile practices to fit the needs of larger projects has been studied to quite an extent in previous research. However, scaling agile beyond organizational boundaries, for instance in a software ecosystem context, raises additional challenges that existing studies and approaches do not yet investigate or address in great detail. For that reason, we conducted a case study in two software ecosystems that comprise several agile actors from different organizations and, thereby, scale development across organizational boundaries, in order to elaborate and understand their coordination challenges. Our results indicate that most of the identified challenges are caused by long communication paths and a lack of established processes to facilitate these paths. As a result, the participants in our study, among others, experience insufficient responsivity, insufficient communication of prioritizations and deliverables, and alterations or loss of information. As a consequence, agile practices need to be extended to fit the identified needs

Exploratory Comparison of Expert and Novice Pair Programmers

We conducted quasi-experiment comparing novice pair programmers to expert pair programmers. The expert pairs wrote tests with a higher instruction, line, and method coverage than the novice pairs and changed the given program skeleton to a larger extent. However, the expert pairs were also slower than the novice pairs. The pairs within both groups switched keyboard and mouse possession frequently. Furthermore, most pairs did not share the input devices equally but rather had one partner who is more active than the other

What an Agile Leader Does: The Group Dynamics Perspective

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

Integrating cancer survivors' experiences into UK cancer registries: design and development of the ePOCS system (electronic Patient-reported Outcomes from Cancer Survivors)

BACKGROUND: Understanding the psychosocial challenges of cancer survivorship, and identifying which patients experience ongoing difficulties, is a key priority. The ePOCS (electronic patient-reported outcomes from cancer survivors) project aims to develop and evaluate a cost-efficient, UK-scalable electronic system for collecting patient-reported outcome measures (PROMs), at regular post-diagnostic timepoints, and linking these with clinical data in cancer registries. METHODS: A multidisciplinary team developed the system using agile methods. Design entailed process mapping the system's constituent parts, data flows and involved human activities, and undertaking usability testing. Informatics specialists built new technical components, including a web-based questionnaire tool and tracking database, and established component-connecting data flows. Development challenges were overcome, including patient usability and data linkage and security. RESULTS: We have developed a system in which PROMs are completed online, using a secure questionnaire administration tool, accessed via a public-facing website, and the responses are linked and stored with clinical registry data. Patient monitoring and communications are semiautomated via a tracker database, and patient correspondence is primarily Email-based. The system is currently honed for clinician-led hospital-based patient recruitment. CONCLUSIONS: A feasibility test study is underway. Although there are possible challenges to sustaining and scaling up ePOCS, the system has potential to support UK epidemiological PROMs collection and clinical data linkage