No abstract
Agile software development (ASD) promotes working software over comprehensive documentation. Still, recent research has shown agile teams to use quite a number of artefacts. Whereas some artefacts may be adopted because they are inherently included in an ASD method, an agile team decides itself on the usage of additional artefacts. However, explicit rationales for using them remain unclear. We start off to explore those rationales, and state our primary research question as: What are rationales for agile teams to use artefacts? Our research method was a multiple case study. In 19 agile teams we identified 55 artefacts and concluded that they in general confirm existing research results. We introduce five rationales underlying the usage of artefacts in ASD: (1) Adoption of ASD leads to agile artefacts, (2) teaminternal communication leads to functional and technical design artefacts, (3) quality assurance leads to test-related artefacts, (4) agile teams impose governance on their own activities, and (5) external influences impose user-related material. With our contribution we substantiate the theoretical basis of the Agile Manifesto in general and contribute to the current research with regard to the usage of artefacts in ASD in particular. Agile teams themselves may from this research extract guidelines to use more or less comprehensive documentation.
While there is a plethora of literature on IT Sourcing (ITS) strategy, little is known about the impact of large-scale agile frameworks on these strategies. Empirical evidence suggests that application of agile frameworks has an impact on governance and processes in large organisations including ITS strategies. Yet, the effects of such frameworks remain unrevealed. This research investigates the impact of agile frameworks on ITS decisions and the way organisations configure their ITS strategies. The research first studies literature to realise that there is a lack of empirical research on ITS strategies in organisations that use agile frameworks. Then, through a systematic literature review, ten different dimensions of ITS are identified and used as the required construct for a multiple-case study at six Netherlands-based organisations. The results reveal that four dimensions, namely sourcing model, location, pricing model, and relational governance are mostly affected by agile frameworks. Furthermore, after more than three years of utilising agile frameworks, case organisations still have not discovered a proper optimum point for these dimensions. The results also uncover that organisations are not fully aware of the impact of agile transformation on the process of ITS decision-making. This process may remain intact for years, resulting in continuous experimentation and trial and error of ITS strategies. We conclude that organisations should recognise the effects of agile frameworks to make ITS decisions accordingly. Additionally, adhering to a more rational and structured decision-making process helps organisations to more efficiently find proper optimum points for the dimensions of ITS strategy.
Context: Agile software development (ASD) uses 'agile' artefacts such as user stories and product backlogs as well as 'non-agile' artefacts, for instance designs and test plans. Rationales for incorporating especially non-agile artefacts by an agile team mainly remain unknown territory. Goal: We start off to explore influences on artefacts usage, and state our research question as: To what extent does maturity relate to the usage of artefacts in ASD in software product organizations? Method: In our multiple case study 14 software product organizations were visited where software product management maturity was rated and their artefacts usage listed. Results: We found maturity to be negatively correlated with the non-agile/all artefacts ratio. In other words, the more mature software product management is, the fewer non-agile artefacts are used in ASD. Conclusions: This suggests that an organizational factor influences an agile team in its artefacts usage, contradictory to the concept of self-organizing agile teams.
In Scrum, teams working collaboratively on interdependent pieces of software face alignment issues as they need to coordinate their work. Organisations aim to minimise time to market of their products, which makes it relevant to identify how alignment issues affect time to market. Currently, empirical evidence of the effect of implementing alignment activities on delivering software is scarce. This research aims to identify those alignment activities that shorten the time to market of backlog items. First, examination of key concepts led to a grounded choice of alignment activities taken into account. Use of alignment activities in development of features was identified by sending feature owners a close-ended questionnaire on the alignment of their collaborating Scrum teams. The cycle times of backlog items were measured by using the application programmable interface of the agile tool used for tracking backlog items. Results show that when user stories were developed using a shared Definition of Ready, process and lead time decreased significantly. Process and lead time also differed between user stories implementing a different number of shared feedback sessions, where using two shared feedback sessions per sprint resulted in the lowest process and lead time.
Abstract-According to the Scrum process framework a Scrum team should have all necessary competencies to accomplish its work. Fragmented and anecdotal evidence hints at Scrum teams still needing additional, external competencies. To contribute to theories on Scrum team composition and practitioner's concerns in staffing a Scrum team we investigated Scrum teams' cross-functionality: To whom do Scrum teams turn for additional competencies, which competencies are involved and how are Scrum teams aware of additional competencies they need? To this extent we analysed the communication in three Scrum teams during one of their Sprints. Our results show that additional competencies are called for, not only on an ad hoc basis, but also on a structural basis. To include those structural competencies the notion of an extended Scrum team is introduced.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.