Working software over comprehensive documentation – Rationales of agile teams for artefacts usage

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.

DevOps in an ISO 13485 Regulated Environment

“…Laukkarinen et al [17] also conclude that the development team could use continuous delivery internally and produce documentation for regulatory inspection, a view supported in the multiple-case study carried out by Wagenaar et al [28]. They identified that mostly test-related artifacts are shared in this way.…”

“…Merging requirements for records (process evidence) and DevOps artifacts should be established by an organization. In this sense, Wagenaar et al [28] identified 55 agile artifacts in 19 agile teams. The artifacts were mostly results of internal governance in teams and seldom a result of external requirements.…”

Can We Design Software as We Talk?

“…The agile movement have proposed user stories as a minimal but complete language for the specification of software requirements [4]. This language has been proven to be successful and widely adopted by software developers [5]. software requirements are collected during RE sessions in the shape of pictures, flip chart notes, documentation etc.…”

What Makes Agile Test Artifacts Useful?

“…Nevertheless, Agile practitioners have increasingly changed their attitude towards documentation [22] and are producing a variety of artifacts that are not inherent to ASD [2,16,23]. According to Wagenaar et al [24], practitioners need additional artifacts for four reasons: i) they provide team governance, ii) they are useful for internal communication, iii) they are needed by external parties, and iv) they are useful for quality assurance. For the latter reason, a range of additional artifacts (e.g., Acceptance tests) are commonly created to perform comprehensive software testing.…”

“…Currently, we understand which test artifacts Agile teams introduce (or should introduce) on their own initiative [2] and why they are needed [24]. However, empirical research on how Agile test artifacts are designed in practice and, more specifically, which properties make them useful for quality assurance remains sparse.…”