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

Abstract

Team-level retrospectives are widely used in agile and lean software development, yet little is known about what is actually discussed during retrospectives or their outcomes. In this paper, we synthesise the outcomes of sprint retrospectives in a large, distributed, agile software development organisation. This longitudinal case study analyses data from 37 teamlevel retrospectives for almost 3 years. We report the outcomes of the retrospectives, their perceived importance for process improvement and relatVed action proposals. Most discussions were related to topics close to and controllable by the team. However, the discussions might suffer from participant bias, and in cases where they are not supported by hard evidence, they might not reflect reality, but rather the sometimes strong opinions of the participants. Some discussions were related to topics that could not be resolved at the team level due to their complexity. Certain topics recurred over a long period of time, either reflecting issues that can and have been solved previously, but that recur naturally as development proceeds, or reflecting waste since they cannot be resolved or improved on by the team due to a lack of controllability or their complexity. For example, the discussion on estimation accuracy did not reflect the true situation and improving the estimates was complicated. On the other hand, discussions on the high number of known bugs recurred despite effective improvements as development proceeded.

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 ).…”

Understanding Work Practices of Autonomous Agile Teams: A Social-psychological Review

“…McHugh et al [ 19 ] found that these types of meeting need work and careful guidance to function in their intended way also in software development. In a recent longitudinal study, Lehtinen et al [ 27 ] showed that, initially, newly formed teams focus more on task progress and task outcome and, as the teams mature, they focus to a larger extent on process and cooperation. Such findings also relate the “agility” of a team to group socialization and group development since members of the group will behave differently depending on how well integrated they are in the team [ 9 ], meaning that a well-integrated individual will be more likely to perform retrospectives in the way they are intended.…”

Blended Scrum model for software development organizations

“…On the other hand, in large‐scale distributed projects, some practices such as implementing product owner role, sprint planning, or retrospectives were found to be difficult and less useful . In addition, team‐level retrospective meetings in these kind of projects are reported to be causing waste in retrospective practice on some topics such as estimation accuracy, and task completion, the state of bug fixing and the need for clarifying instructions since these are complex issues to be solved at team level …”

“…27 In addition, team-level retrospective meetings in these kind of projects are reported to be causing waste in retrospective practice on some topics such as estimation accuracy, and task completion, the state of bug fixing and the need for clarifying instructions since these are complex issues to be solved at team level. 28 In some studies, Scrum practices are reported to be used through adapting rather that adopting. 29 According to the results of the interviews conducted in two software organizations in Pakistan, the difficulties of applying Scrum and areas where issues arose were listed as achieving acceptable software quality, integrating the modules, providing quality code, damage to teamwork, sprint times, lack of training in Scrum, difficulty working with multiple teams, metrics, and idealizing the Scrum process.…”