Search

Non‐functional requirements define qualities of the software system that ensure effectiveness while embedding any constraints and restrictions on the design. A challenge rises with agile implementation in handling non‐function requirements in regulated environments. Thus, a practitioner's perceptions of agile method tailoring are described in relation to inter‐team boundaries and non‐functional requirements. The research comprises 18 practitioner interviews from two multinational agile software development companies. Interviews were recorded, transcribed, and analysed using an approach informed by grounded theory and information flow models were used to compare and contrast interactions of processes. It was discovered that one of the case study companies managed non‐functional requirements as artefacts in their agile methodology, while the other company reverts to conventional plan‐based software development practices of documentation, timeline estimations, and safety critical requirements. This research creates a detailed comparison of these contrasting approaches. The main contribution of this study is a set of proposed recommendations to deal with non‐functional requirements in a regulated environment using agile techniques. The introduction of two new artefacts, Documentation Work Item and Safety Critical Work Item, is recommended and it is accompanied with an illustrative example, to transform the handling of documentation and safety critical requirements in a more agile way. [ABSTRACT FROM AUTHOR]

The maturity of organisations is measured using process assessment models like the International Organization for Standardization (ISO)/IEC 33001. Product quality is refined with internal and external product quality characteristics based on models like the ISO/IEC 25010. With the shift from the Tailorism‐driven process orientation to a more people‐centric organization, the process and product quality dimensions have to be extended by the teamwork quality (TWQ) dimension. For the sake of systematic organization development, this new third quality dimension needs to be integrated into existing quality frameworks to achieve a holistic quality approach. This article introduces agile TWQ as the method of choice. It explains its design, implementation and evaluation in the large enterprise context of the Volkswagen AG. It provides insights into the effectivity of this approach in heterogeneous multi‐team settings, as well as into its strengths, weaknesses, and limitations. [ABSTRACT FROM AUTHOR]

Agile methods are widely used in the software industry as a way to more rapidly develop and deliver new software. They define iterative work processes, advocate self‐organization and openness for change, and prescribe how software developers interact with each other and external stakeholders. Despite their popularity, it is unclear how agile methods influence work exhaustion in software developers and how developer skills play into this effect. On the one hand, agile methods may reduce software developers' work exhaustion by levelling out their workload across the entire duration of a project. On the other hand, agile methods exert a high level of pressure on software developers to continuously deliver working software, create many intensive social interactions, and to frequently adapt to changes. In light of these effects, prior research could not explain why some software developers become less exhausted from using agile methods, whereas others perceive the exact opposite. Based on the job demand‐control model, we develop a theoretical model connecting agile method use to individual developer skills and to two established determinants of employee exhaustion: role conflict and role ambiguity. We tested our research model in a field study among 1894 software developers in 217 project teams that used agile methods. The random coefficient modelling results show that agile method use facilitates the achievement of clear and unambiguous role perceptions and thereby reduces work exhaustion in developers, particularly if developers possess the organizational skills to effectively interact with others in their organization. We highlight implications for theory on the individual‐level effects of software development methods and provide practical insights for software companies. [ABSTRACT FROM AUTHOR]

Corporations increasingly engage with open source software communities in the co‐creation of software. This collaboration between corporate professionals and open source software community members is strikingly different from the early days of software development where for‐profit firms attempted to dominate and control the industry while attempting to throttle the success of independent developers offering an alternative, open source option. While many metaphors like trading zones, common pool resources and ecosystems have helped understand the phenomenon, the metaphors do not portray what the industry was like before and after the transition. We adopt a postcolonial metaphor as an analytical lens to examine such collaboration based on qualitative data gathered over three years from executives, managers and developers within corporations that engage in open source software development. Drawing on these insights, we then theorize a "Third Design Space," based on the concept of the third space proposed by Bhabha. This metaphor encourages the cultivation of a new design environment, creation of new design associations and circulation of shared design resources. Together these practices and behaviours make it possible to nurture innovative methods and new rituals for designing software with results and methods that represent a distinct departure from the competitive and proprietary past, even creating innovative artefacts that could not have been created without the Third Design Space. [ABSTRACT FROM AUTHOR]

Bridging knowledge boundaries among project team members is essential to prevent delays or complete failure of software development projects. Prior researchers have reported that software prototypes can be used to help bridge knowledge boundaries between team members in traditional software development settings, yet their use in an agile development setting remains unexplored. Agile development centers the interactions between team members on emerging representations of the prototype whose properties are prone to change over time. Therefore, we conducted an in‐depth study of an agile development project to enhance our understanding on how software prototypes are used as boundary objects in a distributed team setting. Our analyses of team member interactions during 46 virtual meetings that took place over a period of 6 months revealed four different prototype use practices (exemplifying, contrasting, relating, framing) that were effective in bridging syntactic, semantic, or pragmatic knowledge boundaries. We also provide empirically grounded evidence of how variations in object properties can afford different use practices, how the use practices take advantage of these properties, and how object properties are reshaped through these use practices as different types of knowledge boundaries are bridged. These findings bear important implications for research on prototypes as boundary objects in software development in particular and boundary object use in general. [ABSTRACT FROM AUTHOR]

Industry in all sectors is experiencing a profound digital transformation that puts software at the core of their businesses. To react to continuously changing user requirements and dynamic markets, companies need to build robust workflows that allow them to increase their agility in order to remain competitive. This increasingly rapid transformation, especially in domains such as Internet of things or cloud computing, poses significant challenges to guarantee high-quality software, since dynamism and agile short-term planning reduce the ability to detect and manage risks. In this study, the authors describe the main challenges related to managing risk in agile software development, building on the experience of more than 20 agile coaches operating continuously for 15 years with hundreds of teams in industries in all sectors. They also propose a framework to manage risks that consider those challenges and supports collaboration, agility, and continuous development. An implementation of that framework is then described in a tool that handles risks and mitigation actions associated with the development of multi-cloud applications. The methodology and the tool have been validated by a team of evaluators that were asked to consider its use in developing an urban smart mobility service and an airline flight scheduling system. [ABSTRACT FROM AUTHOR]

Software development organisations are interested in adopting new agile methods and techniques. However, they often do not have the time and resources to explore available approaches or to customise them to the current situation at the project or organisational levels. As software companies are usually dealing with significant pressure and have to demonstrate productivity, time for software process improvement (SPI) is very limited. Using serious collaborative games can be helpful for the deployment of certain best practices recommended by agile methods. With the objective of facilitating SPI in organisations, the authors propose a ready-to-use collaborative game toolbox that is oriented for practical use in project team meetings. The set of collaborative games included in the toolbox have been designed for agile teams, regardless of the maturity level, to innovate and improve communication and cohesion, and to bring business value out of agile ceremonies. [ABSTRACT FROM AUTHOR]

Nowadays computer games are applied beyond entertainment. Gamification, the application of game elements in non-game environments supports behavioural studies in different disciplines including software engineering, the area in which collaborative work has become a fundamental key. The most used gamification elements in software development environments were analysed from two perspectives: (i) team building or reinforcement activities; and (ii) regarding a set of people's interactive styles. Then, interactive styles with software engineering roles were related in order to be able to identify scenarios that conform a model to build highly effective teams. The three analyses together allow identifying proper gamification elements for modelling scenarios to support the creation of highly effective teams in the software development domain. [ABSTRACT FROM AUTHOR]

We present an empirically grounded and theoretically informed model for the assessment and mitigation of risks to effective knowledge sharing in agile development. The model is anchored in empirical insights from four agile projects across two software companies and in extant research on risk-strategy analysis and knowledge sharing in software development. We develop the model as part of the long-standing tradition of presenting risk management models dedicated to specific issues in software development and confirm its practical usefulness in one of the software companies studied. The model offers concepts and processes to assess a project's knowledge sharing risk profile and articulate an overall resolution strategy plan to mitigate the risks. The results highlight how different knowledge sharing risk management profiles can lead to different project performance outcomes. We conclude with a discussion of research opportunities that the results offer software development scholarship. © 2016 John Wiley & Sons Ltd [ABSTRACT FROM AUTHOR]

As information systems development (ISD) organisations face increasing market demands, strategies such as agile development have been used to help address these demands. Now, as information systems (IS) research in agile development is gaining in theoretical rigour, this study explores the use of mindfulness as a theoretical framework to examine ISD agility. At its core, the mindfulness theoretical concept promotes a focus on 'continuous attention to detail' and 'vigilance to minimise errors and respond effectively to unexpected events'. Incorporating a sixteen month ongoing longitudinal case study of an ISD organisation, this research provides an insight into the practice of what we term 'doing' agile and 'being' agile, while also providing a number of theoretical contributions around the value of mindfulness for ISD agility. [ABSTRACT FROM AUTHOR]