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.

No abstract

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.