Diagrams or structural lists in software project retrospectives – An experimental comparison

Abstract

a b s t r a c tRoot cause analysis (RCA) is a recommended practice in retrospectives and cause-effect diagram (CED) is a commonly recommended technique for RCA. Our objective is to evaluate whether CED improves the outcome and perceived utility of RCA. We conducted a controlled experiment with 11 student software project teams by using a single factor paired design resulting in a total of 22 experimental units. Two visualization techniques of underlying causes were compared: CED and a structural list of causes. We used the output of RCA, questionnaires, and group interviews to compare the two techniques. In our results, CED increased the total number of detected causes. CED also increased the links between causes, thus, suggesting more structured analysis of problems. Furthermore, the participants perceived that CED improved organizing and outlining the detected causes. The implication of our results is that using CED in the RCA of retrospectives is recommended, yet, not mandatory as the groups also performed well with the structural list. In addition to increased number of detected causes, CED is visually more attractive and preferred by retrospective participants, even though it is somewhat harder to read and requires specific software tools.

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

“…The tool probably made it easy for the participants to record all the relevant statements, but we do not know how the tool affected the retrospective meetings. In our earlier work (Lehtinen et al 2015a), we compared the use of diagrams and structural lists in retrospectives, and those results indicate that diagrams might well increase the number of findings and relationships in the outcomes and help in organising the findings. Diagrams were also perceived to be visually more attractive.…”

Game-based Sprint retrospectives: multiple action research

“…Accordingly, the retrospective is an opportunity for the team to look back over an iteration and recognize successes and failures; to link the related experience to people, the development process, engineering practices, and tools; and to create a plan for improvements to be enacted during the next iteration (Dybå et al 2014b ; Lehtinen et al 2015 , Lehtinen et al 2017 ; Dingsøyr et al 2018 ; Ilyés 2019 ). Indeed, the retrospective is one of the most frequently mentioned agile practices in the context of software process improvement (Mas et al 2018 ; Küpper et al 2019 ).…”

“…This study extends the body of knowledge on the Sprint Retrospective. Prior literature has mainly focused on: (1) the process and steps of a retrospective (Derby and Larsen 2006 ; Rubin 2012 ; Kua 2013 ; Andriyani et al 2017 ; Schwaber and Sutherland 2020 ; Loeffler 2017 ; Mas et al 2018 ); (2) specifying the techniques of conducting a retrospective meeting (Gonçalves and Linders 2014 ; Roden and Williams 2015 ; Krivitsky 2015 ; Lehtinen et al 2015 ; Caroli and Caetano 2016 ); and (3) recommendations on how to make retrospectives effective (Babb et al 2014 ; Lehtinen et al 2017 ; Gaikwad et al 2019 ; Mesquida et al 2019 ; Marshburn 2018 ; Matthies et al 2019 ). However, there is little research evidence on the effects of collaborative games on retrospective meetings.…”