1 Introduction

Retrospective meetings embody the ‘inspect and adapt’ principle of Agile Software Development (ASD) [1, 2]. They are designed to enable agile teams to frequently evaluate and find ways to adjust their process [3]. There are several purposes for retrospective meetings, such as to evaluate the previous work cycle or sprint; to determine the aspects that need to be focused on as areas of improvement; and to develop a team action plan [4]. The purpose and the techniques of the retrospective meeting have been stated and described clearly as a guide for agile teams [2, 5, 6].

Much of the existing research focuses on the techniques of performing retrospective meetings and provides lesser detail about the reflection process involved [5,6,7,8,9]. The Reflective Agile Learning Model (REALM) [7] classified reflection in ASD practices into reflection-in-action or reflection that occurs during a practice, and reflection-on-action or reflection that occurs post a practice based on definitions of the same by Argyris and Schön [10]. A retrospective meeting was seen to embody reflection-on-action where the agile teams reflect post finishing their sprint [7]. However, what is focused on during retrospectives and how reflection occurs in this practice is not well understood.

To address this gap, we conducted Case Study research by observing four agile teams and interviewing 16 of their members guided by the following research questions:

  • RQ 1: What aspects are focused on during the retrospective meeting?

  • RQ 2: How does reflection occur in the retrospective meeting?

2 Related Work

2.1 Agile Retrospective Meeting

There is a standard format commonly used to conduct an agile retrospective meeting which involves setting the stage, gathering data, generating insight, deciding what to do and closing the retrospective meeting [2]. Setting the stage involves welcoming and explaining the aim of the retrospective meeting. Gathering data involves agile teams sharing their review and feedback, reporting on what happened during the previous sprint and briefly discussing with other team members. In generating insight, agile teams participate in a further discussion and making agreements about what issues to focus on, and then on how to solve those issues and what areas that need to improve in the deciding what to do stage. Closing the retrospective involves summarizing the retrospective meeting and appreciating all team members’ efforts.

There are several recommendations for embedding reflective practice within standard agile practices as it is related to team performance improvement [7,8,9]. Cockburn [8] introduced a reflection workshop which involves collecting issues and generating tasks and decisions. This workshop is performed regularly during or after the post-iteration workshop. Babb et al. [7] investigated reflection in agile practices based on Argyris and Schön’s [10] classification and introduced the Reflective Agile Learning Model (REALM). REALM describes how some agile practices embody reflection-in-action and reflection-on-action. Retrospective meetings were seen to embody reflection-on-action where the agile teams reflect post finishing their sprint [7].

Most of the existing research focuses on the techniques of performing a retrospective or identifying a broad classification of the type of reflection that occurs, e.g. reflection-on-action [7]. What actual topics or aspects are discussed during a retrospective and how reflection occurs, however, is not well understood. We build upon these works by investigating the retrospective meeting in depth.

2.2 Reflective Practice

Reflective practice according to Osterman and Kottkamp [11], is defined as “a means by which practitioners can develop a greater level of self-awareness about the nature and impact of their performance, an awareness that creates opportunities for professional growth and development”.

Bain et al. [12] classified reflection into five levels: reporting, responding, relating, reasoning and reconstructing. Level 1 and 2 are reporting and responding and enable learners to share brief descriptions of their experience, their feelings about events, facts or problems that they encountered. Level 3 is relating and involves connecting experience with personal meaning. Understanding at this level occurs when learners try to highlight good points (e.g. their ability, successful work) and negative points (e.g. mistakes, failure) to learn and identify areas of improvement. Level 4 is reasoning where learners explore the information shared as well as background knowledge related to the occurrences. Level 5 is reconstructing which signifies a high level of learning where learners generate the general framework of thinking, which is specified in a plan or action for responding to similar obstacles in the future.

Our study refers to levels of reflection proposed by Bain et al. [12] and adjusts the levels into three main levels, i.e. reporting and responding, relating and reasoning and reconstructing, based on our observations of the agile retrospectives in practice. Reporting and responding are grouped together as the first level as these levels closely related to reviews sharing and discussions at the beginning of the retrospective meeting. Relating and responding are grouped as the second level as agile teams participate in a further discussion after they reported and responded to the reviews. The third level, the reconstructing level is embodied when agile teams discuss to formulate a plan as an improvement for the next sprint.

3 Research Method

The aim of this study is to investigate how reflection occurs in retrospective meetings. Understanding this is particularly important as agile teams are reported to focus more on their technical progress and tend to pay less attention to how reflection is performed thereby compromising their potential for improvement [7, 13].

This research is conducted by implementing the Case Study research method [14]. First, existing studies related to reflection in retrospective meetings were reviewed, as summarized in Sect. 2. The research gaps identified provided guidance on formulating the interview questions. To gain rich data from interviews, we developed semi-structured questions consisting of main questions and follow-up questions. The data collection method is described in Sect. 3.1 and participant demographics summarized in Table 1. All interviews and observation data were collected by the first author in person. The raw data and emerging findings from the analysis were discussed in detail with the supervisory team (co-authors) who provided feedback and guidance.

Table 1. Team and team members demographics (RMD: Retrospective meeting duration in minutes; P#: Individual participant number; FAP: first agile project)
Full size table

3.1 Data Collection

Participants.

We wanted to include software practitioners with a minimum of 2 years’ industrial agile experience to participate in our research. During one of the Auckland Agile meetups, we received interest in participation from an agile team lead working at the largest online auction company in New Zealand, Trade Me. Trade Me had been practicing agile software development for over three years and provided access to four teams. Its headquarters are located in Wellington and the regional offices are in Auckland and Christchurch.

For confidentiality purposes, the teams are named Jupiter, Saturn, Uranus, and Neptune. The team names and team members’ details can be seen in Table 1. Each team consisted of between 3 and 10 members. All members were invited and those willing were interviewed. All teams held retrospective meetings, which lasted for between 15 and 65 min. Sixteen individual practitioners from the four teams participated in the interviews and the observations. All team members had a dedicated role in their team and there were three participants that committed across different teams: P4 was not only fully committed as a Business Analyst in Team Jupiter but also supported Team Saturn. Similarly, P9 was a tester in Team Saturn and a half tester in Team Jupiter. P16 worked as a test lead across all four teams.

Interviews and Observations.

Face-to-face individual and one group interview (of six team members) were conducted to gain comprehensive explanations, which would help derive the real concerns from both individual and team perspectives. We conducted one-on-one interviews with all participants (P1–P16), where the duration of individual interviews varied from 35 to 50 min. We asked some semi-structured questions about their experiences and perspectives related to reflection in a retrospective meeting. Some sample questions include: “Based on the three main points discussed in a retrospective (i.e. what went well, what went wrong, what can you improve), which one(s) do you think are most helpful for your team’s reflection?”, “How does your team use those points to find solutions and ways to improve? Could you give some real examples?” and “What is the outcome of your retrospective meeting? Does your team/scrum master preserve points from the meeting?”. A sample question of the group interview includes: “I noticed that your team exhibited some different ways of sharing knowledge, (e.g. post-it notes, verbal communication, drawing). Did it help your team to perform reflection? How?”

The group interview was conducted immediately after the retrospective meeting of Team Jupiter with six of its team members. Given the variable meeting times, work commitments and deadlines for different teams, it was not possible to gain further team availability for group interviews with the remaining three teams over and above the individual interviews and team observations.

Observations were conducted during the retrospective meetings of all the teams and of their general workplace. The observations aimed to capture the details of the retrospective meeting (i.e. time spent, attendees, and discussion involved) and to help validate the findings from the interviews. Photographs were taken during the observations in order to document the actual situations in the meetings and the report presented by the agile team members. Notes were taken to highlight the important aspects being shared. The information collected (e.g. photographs and notes) from the observations were used to support individual interviews by including the photographs and describing the activities in the retrospective meetings as observed first hand. The duration of each observation depended on how long the team conducted the retrospective meeting. Three out of four teams conducted the meeting for around 40–60 min each and one team, Neptune, had a shorter 15 min’ retrospective. Observational data (e.g. photographs and notes) were found to support the findings from the interview data analysis thereby strengthening them.

3.2 Data Analysis

This research involved sixteen individual interviews, one group interview (of six team members), and notes taken from retrospective meeting observations which were analyzed by conducting a thematic analysis. Thematic analysis is a method that aims to recognize, analyze, evaluate and report patterns in data [15], which enables researchers to search across a data set of interviews. Braun and Clarke [15] classify the analysis into six phases: transcribing data, generating initial codes, searching for themes, reviewing themes, defining and naming themes and making a report.

Sixteen interviews were transcribed and imported into NVivo software to facilitate coding and thematic analysis. Generating initial codes involved code identification by analyzing interesting features of a sentence, which were highlighted and added as a node in NVivo representing a new code, such as identifying and discussing obstacles and discussing feelings. Searching for themes involved comparing data with different codes to see whether they have similar meanings or aspects. Parent themes were classified based on five (grouped into three) levels of reflection, where each code was classified based on the definition of each level.

Reviewing themes involved generating a thematic model to define the links and the relationships between the themes (see Fig. 1). Defining and naming themes involved the generation of several themes that emerged from the analysis, representing the aspects discussed during retrospective meetings, which was formulated and explained in this paper.

Fig. 1.
figure 1

Levels of reflection in retrospective meetings: a thematic map (using levels of reflection from Bain et al. [12])

Full size image

4 Findings

Following the thematic data analysis process, we identified seven themes that represent important topics or aspects discussed in the retrospective meeting, which were then mapped to the five (grouped into three) levels of reflection [12] (see Sect. 2.2).

Table 2 summarizes these themes along with their mapping to the reflection levels. These themes and levels are described below along with pertinent quotes and photographs from observations. The figures below (see Figs. 2 and 3) were captured during the observation and show a glimpse of Team Jupiter and Team Saturn’s retrospective meeting.

Table 2. Themes representing topics discussed during retrospectives, their description, examples, and mapping to levels of reflection based on [12].
Full size table
Fig. 2.
figure 2

Team Jupiter’s retrospective

Full size image
Fig. 3.
figure 3

Team Saturn’s retrospective

Full size image

4.1 Reporting and Responding

Reporting and responding can be realized when an agile team shares some aspects (e.g. identifying and discussing obstacles and discussing feelings) while providing reviews and feedback of the previous sprint. Each team had different techniques of performing their reviews.

All teams were seen to engage in the reporting level of reflection by actively identified and discussed obstacles and feelings. Similarly, all four teams were seen to be actively involved in responding to their retrospective meeting discussions by providing brief comments on the obstacles and feelings being shared. Teams were seen to report on obstacles such as dependencies and unfinished tasks and respond with negative and positive feelings based on the previous sprint, described below.

Identifying and Discussing Obstacles.

Obstacles reported in the retrospective meetings related to the aspects that hindered the team from making progress. During the retrospective meeting, agile teams gathered all the problems that occurred in the previous sprint, which would be useful for the teams to highlight areas of improvement. There were two specific obstacles reported: dependencies and unfinished tasks.

Dependencies.

Most of the participant (11 out of 16) mentioned dependencies as the specific type of obstacle most commonly reported in the retrospective meeting.

“If it’s delayed at the first point, if something is wrong at the first point the next person feels it. So, if one brings it up [in the retrospective] and if it’s a true concern you will have support because it does affect people.” P16 – Test Chapter Lead (Across All Teams)

By sharing problems about dependencies team members became aware of the other team members’ tasks and how they related to their own tasks. By being aware of this issue the team could think about ways to solve the dependency problems.

Unfinished tasks.

Unfinished tasks were mentioned by three participants as an obstacle reported in retrospective meetings. An unfinished task was a problem where team members could not accomplish the tasks they had planned or considered the team to be making slow progress.

“We were not achieving that daily goal and it is a kind of demotivating… let’s say you plan 10 stories for the sprint and you achieve just two or three. The rest we couldn’t complete for whatever reason. So, we say that is one thing which didn’t go well.” P12 – Tester, Team Neptune

Surfacing this obstacle was helpful for teams to understand how much more effort was required to finish the tasks, what tasks were challenging and why the tasks were difficult to finish. For example, when Team Neptune faced a problem with a requirement that delayed finishing tasks, they asked for clarifications from the product manager. It was evident that dependencies led to unfinished tasks in some cases.

Discussing Feelings.

Besides obstacles, agile teams also shared their feelings which were visualized in several forms, e.g. as drawings or journey lines. The feelings shared by team members represented the sense of facts and occurrences from the previous sprint, such as when they were feeling down or happy.

There was an example of positive feelings shared, which had a positive impact on the team’s productivity, where their work can be distributed well. Team Neptune recruited an additional tester after they had a problem with tester resource. They felt happy because their team was complete and balanced between developers and testers.

“We do put down smiley. When we got a new tester on board, a new person we had a happy smiley saying that our squad is complete.” P12 – Tester, Team Neptune

These obstacles and feelings identified and discussed during the retrospective meeting were supported by our observations of the retrospective meetings of Teams Jupiter, Saturn, and Uranus. It was observed that Team Jupiter reported their review by defining some words on sticky notes (see Fig. 4(a)).

For example, ‘muddy’ was used to describe a difficult situation where team members had difficulty in understanding the detailed description of specific user stories in the project. Upon asking a team member about what was the meaning of ‘muddy’, a participant explained:

Fig. 4.
figure 4

(a) Words to describe obstacles and feelings in the Retrospective meeting; (b) and (c) Journey lines visualizing emotions during a sprint in Retrospective meetings

Full size image

“So, I think, he and I came up with the term of ‘muddy’; from observation - they were really struggling to get the right data and really had to analyse the data for this project. I observed that and for me, I would pick out a description which would explain what I’ve observed; as a general team.”, P1 – User Interface Designer, Team Jupiter.

4.2 Relating and Reasoning

Relating and reasoning can be seen when agile teams compile the obstacles and the feelings shared (from the previous reporting and responding level) and investigate the relationship between those aspects. These levels consisted of activities such as analyzing previous action points, identifying background reasons, identifying future action points. The explanations below present the results from the individual interviews, which supported by group interview and observations.

Analyzing Previous Action Points.

An ‘action point’ refers to a specific item selected by the team to focus on for improvement. In analyzing previous action points, agile teams referred to the action points agreed upon by the team in the previous retrospective and evaluated the actual effort made by the team on that specific point.

“..that’s how you define if you made any changes, we measure yourself based on your action points and that you’ve actually made changes for. You could make 200 action points of your 20 weeks, but not a single one of those was followed up on, you really haven’t done anything.” P4 – Business Analyst, Team Jupiter and Saturn

From the example above, it was seen that agile teams reflected on the previous action points by measuring the outcomes achieved by the teams (i.e. good or slow progress). This statement was further supported by the observations where during the retrospective meetings, agile teams shared the process improvement or the failures of the previous sprint.

Identifying Background Reasons.

The background reasons of the existing issues were identified when teams were not actively progressing, they would explore the reasons why and what blockers were related to this problem. By identifying the background reasons, teams would understand what aspects needed to be improved.

This point is supported by Team Jupiter’s group interview, which a team member tried to identify the reason of the major problem during the retrospective meeting.

“I think we addressed like the major issues are causing the squad stuck at the moment and things like test environment and [..] dealing with an external dependency like platform team in [city name]” P4 – Business Analyst, Team Jupiter and Saturn

During the retrospective meeting observation of Team Saturn, it was seen that there was a cause analysis discussion. For example, when team members shared their sad feelings experienced during the first week sprint, team members shared the reasons, such as unclear user stories or the user story was considered as a big task. The scrum master guided the team to identify the causes by asking why they used the sad feeling notation for the first week. Several reasons were shared, such as too many tasks, the previous estimation and the actual effort were different, the unclear scope of work restricted their progress. Discussing those reasons led to the point where the team realized the main background reason was about inaccurate estimation, i.e. the team had created high achievement expectations for the big tasks without considering the actual effort required.

Identifying Future Action Points.

Identifying future action points happened when the teams analyzed previous action points and identified the background issues, which followed by identifying areas of improvement and asking ideas and agreement from the teams. From the discussion, the teams gained the understanding of the existing issues which lead to the thoughts of what areas need to improve and how to improve. Identifying future action points, the teams discussed areas of improvement, which were focused on the process improvement. For example, in the retrospective meeting, most agile teams stressed testing environment issues that delayed the team progress.

“we list down what didn’t go well or problems or whatever, we usually derive action points on those things, which is a good way to improve maybe something immediately like getting a test environment set up so we can test something.…like a more immediate thing… but there are also action points that are related to the squad as well; determine a team chart or something like that.” P2 – Developer, Team Jupiter

From the example above, it was seen that by knowing the existing issues the team to will understand several areas of the process that need to be focused on. To determine future action points the teams also discussed by asking each other’s opinions.

“when we discussed it [a plan], we asked other people what they think about it, do they agree or don’t they? If everyone says they think they agree with what you are saying, then we say so what the action for that?” P12 – Tester, Team Neptune

During the retrospective observations of Team Saturn, an example of how the team identified their future action points was noted. Team Saturn had identified that the main reason for their slow progress was inaccurate estimation. Some ideas for addressing this included elaborating the stories into small tasks, providing the clear ‘definition of done’ for specific tasks, and asking for clarifications from the product manager about the scope of work. The team members were asked their opinions and perspectives about these ideas. Most team members agreed on asking for clarifications from the product manager and elaborating the stories into small tasks. Consequently, the Scrum master of Team Saturn made these ideas as official action points for the next sprint.

4.3 Reconstructing

The Reconstructing level of reflection seems to happen when a team constructs an agreement on a specific plan based on the team members’ perspectives. There were three out of the four teams (Jupiter, Saturn, Uranus) that seemed to engage in the reconstructing level as they performed further discussions and finalized by generating action points.

Generating a Plan.

In reconstructing, teams generated plans decided from their discussion in the retrospective meeting. Action points are an explicit outcome of the retrospective meeting. It is useful to remind all team members about the goal for the next sprint, who will responsible, and what are the associated deadlines.

“So, when they go up on their board and they are doing their sprint work, they can see, “Right, let’s not forget what came out of this retro” and it is getting ticked off.” P11 – Scrum Master, Business Analyst and Product Owner, Team Uranus

This point was brought up in a group interview (of Team Jupiter) where most of the team members agreed that action points were used as a reference for evaluating improvement in the next retrospective meeting.

“umm we pulled out action points on the board. So, over the next two weeks, we will make sure that everything talked about we follow through on.” P4 – Business Analyst, Team Jupiter and Saturn

It was observed that Team Jupiter preserved their concrete action points on their Scrum board (see Fig. 5). Another evidence from the observations was Teams Saturn and Uranus did not have action points but their Scrum master made some notes during the meetings and shared verbally the points that needed to be focused on at the end of the retrospective meeting.

Fig. 5.
figure 5

(Photo taken during on-site observations)

Action points generated by team Jupiter posted on their Scrum Board

Full size image

5 Discussion

We now discuss the findings related to a reflection framework for agile retrospectives including the levels of reflection achieved by the teams studied, implications for practice and limitations of the study.

In response to the RQ1: What aspects are focused on during the retrospective meeting? We found that there are six important aspects discussed in the retrospective meetings: identifying and discussing obstacles, discussing feelings, analyzing previous action points, identifying background reasons, identifying future action points and generating a plan. In response to the RQ 2: How does reflection occur in the retrospective meeting? We found that the reflection that occurs in retrospective meetings can be classified into three levels of reflection [12], reporting and responding, relating and reasoning, and reconstructing.

5.1 A Framework of Reflection in Agile Retrospective Meeting

Based on these findings, we present a reflection framework for agile retrospectives (Fig. 6) that combines the five steps of the standard agile retrospective – set the stage, gather data, generate insight and decide what to do, close the retrospective – and the levels of reflection – reporting and responding, relating and reasoning, and reconstructing [12] within those steps.

Fig. 6.
figure 6

Reflection in agile retrospective meeting (levels of reflection depicted in shaded areas based on [12])

Full size image

Setting the stage involves welcoming and explaining the aim of the retrospective meeting. Gathering data step embodies the reporting and responding level of reflection as agile teams share their reviews (e.g. identifying and discussing obstacles and discussing feelings). Identifying and discussing obstacles and feelings in retrospective meetings was seen to correspond to ‘descriptive reflection’ [16] – a reflection which attempts to answer questions such as: What is happening? What is this working, and for whom? For whom is it not working? How do I know? How am I feeling? What am I pleased and/or concerned about? What do I not understand? The obstacles and feelings shared by all team members answer these questions. From the obstacles and feelings reported, the teams would be able to record and collect important points of the previous sprint. By having reviews (e.g. obstacles and feelings) of the previous sprint, team members can be prepared to deal with other similar experiences.

Generating insight step embodies the relating and reasoning level, where agile teams are involved in analyzing previous action points, identifying the background reasons behind identified issues and identifying future action points. Discussing these aspects was seen to be related to ‘descriptive reflection’, which attempts to answer questions: does this relate to any of my stated goals and to what extent are they being met? [16] and why the issues happen in the previous sprint? The answers to these questions support the reflection in the form of comparative analysis and looking back to the background issues, which help agile teams to determine what areas needed to be focused on. Agile teams move to deep analysis on ideas or perspective shared to identify future action points for the next sprint. It can be perceived that there is a transformation in the discussion from answering what is happening? in the previous sprint; to what are the alternative views of what is happening? and what are the implications of the matter when viewed from these alternative perspectives? [16]. These questions are answered when all team members provide their accounts about solutions of the obstacles or ways to improve.

In the deciding what to do step, agile teams have an explicit formulation which is generated in the form of action points (generating plans). The action points will be used as a reference for agile teams to act upon and improve the process. Close the retrospective step involves summarizing the outcomes of the retrospective meeting.

5.2 Levels of Reflection Build on Each Other

We now discuss the findings related to the levels of reflection achieved by the teams studied. A key finding of our study was that not all teams were performing on every level of reflection. So, while all teams performed retrospective meetings, not all achieved the higher levels of reflection, in particular reconstructing. Table 3 summarizes the levels of reflection achieved by each of the teams and the associated aspects or topics discussed in each level.

Table 3. Levels of reflection achieved by the teams (J: Jupiter; S: Saturn; U: Uranus; N: Neptune)
Full size table

Three teams were found to be fully engaged in all levels of reflection and one of the teams, Team Neptune, performed partially on the first two levels and did not achieve the final level of reflection, i.e. reconstructing. Based on the observation of their retrospective meeting, it was seen that they did not discuss their feelings explicitly and only discussed briefly the obstacles related to changing of task priorities needing confirmation with the product manager. They did not discuss it further as once they agreed on that obstacle then the product manager directly proceeded to the Scrum Board, discussed the issue and wrapped up the meeting. They did not record any outcomes, such as a plan or action points, from the meeting. There was little evidence of analyzing previous action points, identifying background reasons and identifying future action points. Besides, the duration of the meeting was also short, around 15 min, and they reported performing retrospective meetings only when it was necessary. Another interesting observation was that they had adapted the retrospective practice, which seemed too repetitive for them and people often seemed to have forgotten about what happened during the last two weeks’ sprint. As result, they were used to placing all the individual reviews written up on sticky notes in a “retro box” – a box especially allocated to collect individual reflection. If there were no sticky notes during a two weeks’ sprint, they would not perform a retrospective meeting.

The case of Team Neptune is likely related to the fact that three out of six members of Team Neptune were new to agile projects. They had in effect introduced a new reflective practice, that of using a retro box, as a way to identify the need for conducting a standard retrospective. However, a lack of reaching the reconstruction level suggests that they were not able to generate a plan for improvement as several aspects of the retrospective meeting were missing. Our findings confirm that the levels of reflection are related and build on each other [12]. Furthermore, we show that the highest level of reflection, reconstructing, may not be reached at all or not reached effectively until the prior levels are accomplished effectively.

5.3 Implications for Research and Practice

For the researchers in the area of reflective practice and agile teams, our findings present a new perspective for exploring reflective practice in agile teams. Using the framework presented in the previous section, researchers can study agile teams’ reflective practice in terms of levels of reflection both in retrospective meetings and other practices that involve reflection (e.g. daily standup, pair programming [7]). Future studies can explore new aspects or topics covered in each level and further explore how the levels build upon each other in different team contexts.

For agile practitioners, our findings show that not all agile teams reach all levels of reflection by simply performing retrospectives. By being aware of the different levels of reflection meant to be achieved in each retrospective step, teams can consciously strive to achieve the most out of their retrospective meetings. In particular, they can see that only reporting and responding and relating and reasoning levels are not enough rather reconstructing to generate action points and following up on those points in future meetings is critical to harnessing retrospective meetings to achieve continuous improvement. Thus, in order to maximize the benefits of their retrospective meetings, we recommend agile teams use our reflection framework (Fig. 6) to self-assess their level as a whole based on their personal understanding of their team context and track it in practice to achieve higher levels of reflection.

5.4 Limitations

A key limitation of this study lies in the fact that observations of a single retrospective meeting per team is not strong enough to establish and confirm a particular team’s overall level of reflection. For example, it may be that in other retrospective meetings Team Neptune reached higher levels of reflection. However, the findings were arrived at by combining the data from interviews as well as the observations, which provides multiple perspectives that support the findings. Another related limitation is that the findings are limited to the contexts studied in this research, which in turn are dictated by the availability of participants. Further studies can confirm, adapt, or extend our framework to include different team contexts and reflective practices.

6 Conclusion

Previous studies have focused on specifying the techniques of conducting a retrospective meeting, with little focus on how the reflection in the retrospective meeting actually occurs. One of the key contributions of our work is to present a reflection framework for agile retrospective meetings that explains and embeds five (grouped into three) levels of reflection within the five steps of a standard agile retrospective meeting. Critically, we show that agile teams may not achieve all levels of reflection simply by performing retrospective meetings. As the levels of reflection build upon each other, teams need to effectively identify and discuss their obstacles and feelings in the reporting and responding level, followed by analyzing previous action points, identifying background reasons, and identifying future action points in the relating and reasoning level and generating a plan in the reconstructing level. Embedding these levels of reflection into the retrospective meeting will help agile teams achieve better focus and higher levels of reflection from performing retrospective meetings. Another implication is an increase in their awareness of the main aspects that need to be discussed in the retrospective meeting and how to formulate these aspects to generate a plan for improvement.