Artefacts in Agile Team Communication

Abstract

Agile software development (ASD) has become standard in software development. ASD methods share a preference for face-to-face communication rather than formal comprehensive documentation. As agile teams are independent in their internal processes they can decide on, whether or not, to use documentation artefacts. Their decisions elaborate the Agile Manifesto’s second statement: “Working software over comprehensive documentation”. Therefore, our main research question is: What is the role of artefacts in communication in agile software development teams? The hypothesis underlying this research is that artefacts have proven their value in traditional software development and that agile teams will carry over some of this value to their current practices. In first instance the use of artefacts in agile teams was investigated through interviewing team members in three agile teams in a case study. Its conclusions demonstrated the basic validity of our hypothesis. The teams did use artefacts and we partially confirmed previous findings and complemented them with additional artefacts. Having established the blend of traditional and agile artefacts does not shine light on reasons for using them. In a holistic view we first investigated the existence of a relation between maturity of an agile team’s ASD and its use of artefacts. Evidence was found for maturity to be negatively correlated with the non-agile/all artefacts ratio. In a follow-up study we explicitly investigated rationales for the use of artefacts. In fourteen agile teams interviews were held with prominent team members to discuss the use of artefacts and the motivation for using them. Agile teams stated five groups of rationales, among which one for agile artefacts and four for traditional artefacts, for instance to promote internal team communication. Formal and informal communication in ASD are often regarded as two distinct end points, resembling the distinction between explicit and tacit knowledge. This distinction is recognized not to be a black and white one and this raised the question whether or not agile teams also experience intermediate appearances between formal communication (artefacts) and informal communication (face-to-face). We coined this appearance a ‘fuzzy’ artefact, an artefact which is not formally documented, but one that is still explicitly recognized by an agile team. The findings confirmed their existence and teams use them, for instance, in the requirements process, the elaboration of user stories and in taking Go/ No-Go decisions. The overall answer to our research question thus is: Yes, artefacts play an important role in the communication within agile teams. This is no surprise as far as agile artefacts, artefacts that are inherent to ASD, are involved, for instance a product or sprint backlog, or user stories. Agile teams use, in addition, non-agile artefacts, which are associated with traditional software development rather than ASD. However, they have sound reasons to do so. Two examples: (1) Team-internal communication benefits from functional and technical design artefacts, (2) Quality assurance leads to test-related artefacts. In general, agile teams are able to explain why they are using the artefacts they use. Artefacts do not replace face-to-face communication, but complement it.