Driving Continuous Improvement with retrospective meetings
(→The Starfish) |
|||
(136 intermediate revisions by one user not shown) | |||
Line 1: | Line 1: | ||
+ | ''Written by Alberto Pillon'' | ||
== Abstract == | == Abstract == | ||
− | + | This article explores the use of retrospective meetings as a tool for Continuous Improvement in project management. A retrospective meeting is a structured meeting held at the end of a project or iteration to reflect on the team’s performance and identify areas for improvement. The purpose is to facilitate continuous learning and improvement within the team. <br/> | |
+ | The article then delves into the key phases and activities involved in conducting an effective retrospective meeting. These include setting the stage, evaluating the project performance, brainstorming potential improvements, and prioritizing recommended actions. The article provides a detailed guide for conducting each of these phases and discusses best practices for facilitating effective retrospective meetings.<br/> | ||
+ | The benefits and limitations of retrospective meetings are also discussed. Some of the key benefits include improved communication among project team members, enhanced learning and continuous improvement, improved project outcomes and performance, and better team morale and motivation. However, there are also some limitations to consider, such as the potential for groupthink and the difficulty in implementing recommended improvements.<br/> | ||
+ | Finally, the relevance of retrospective meetings in the field of continuous improvement is assessed. The article argues that retrospective meetings are a valuable tool for driving continuous improvement in project management by providing a structured process for reflecting on past performance and identifying areas for improvement.<br/> | ||
+ | Overall, this article provides valuable insights into how retrospective meetings can be leveraged to drive Continuous Improvement in project management. It provides a detailed guide for conducting effective retrospective meetings and discusses their benefits and limitations. | ||
== Introduction == | == Introduction == | ||
− | ==== Background of | + | ==== Background of Continuous Improvement in project management ==== |
− | Continuous Improvement is a philosophy that W. Edward Deming described simply as consisting of "Improvement initiatives that increase successes and reduce failures". In general, Continuous Improvement can be defined as a culture of sustained improvement targeting the elimination of waste in all systems and processes of an organization. It is achieved through the use of several tools and techniques dedicated to searching for sources of problems, waste, and variation, and finding ways to minimize them.<br /> | + | Continuous Improvement is a philosophy that W. Edward Deming described simply as consisting of "''Improvement initiatives that increase successes and reduce failures ''" <ref>Bhuiyan, N. and Baghel, A. (2005), "An overview of continuous improvement: from the past to the present", Management Decision, Vol. 43 No. 5, pp. 761-771. https://doi-org.proxy.findit.cvt.dk/10.1108/00251740510597761</ref>. In general, Continuous Improvement can be defined as a culture of sustained improvement targeting the elimination of waste in all systems and processes of an organization. It is achieved through the use of several tools and techniques dedicated to searching for sources of problems, waste, and variation, and finding ways to minimize them.<br /> |
− | Continuous | + | Continuous Improvement programs have evolved from traditional manufacturing-focused systems that concentrate on the production line to reduce waste and improve product quality, into comprehensive, systematic methodologies that focus on the entire organization, from top management to the workers on the shop floor <ref>J. Bessant, S. Caffyn, J. Gilbert, R. Harding, S. Webb, Rediscovering continuous improvement, Technovation, Volume 14, Issue 1, 1994, Pages 17-29, ISSN 0166-4972, https://doi.org/10.1016/0166-4972(94)90067-1.</ref>. |
==== Overview of retrospective meetings ==== | ==== Overview of retrospective meetings ==== | ||
− | A retrospective (from Latin ''retrospectare'', <nowiki>"look back"</nowiki>), is a look back at events that took place in the past. | + | A retrospective (from Latin ''retrospectare'', <nowiki>"look back"</nowiki>), is a look back at events that took place in the past <ref>https://en.wikipedia.org/wiki/Retrospective</ref>. |
Retrospective meetings have their roots in Agile software development methodology, which emphasizes continuous improvement and adaptive planning. The idea of retrospective meetings was to provide a safe space for team members to reflect on their performance, identify areas for improvement, and make changes accordingly. Over time, retrospective meetings have become a popular practice in not only software development but also in other industries, and they are widely recognized as a powerful tool for continuous improvement. | Retrospective meetings have their roots in Agile software development methodology, which emphasizes continuous improvement and adaptive planning. The idea of retrospective meetings was to provide a safe space for team members to reflect on their performance, identify areas for improvement, and make changes accordingly. Over time, retrospective meetings have become a popular practice in not only software development but also in other industries, and they are widely recognized as a powerful tool for continuous improvement. | ||
− | == | + | == Retrospective meetings == |
==== Definition ==== | ==== Definition ==== | ||
− | A retrospective meeting is a structured session that gives teams time to reflect on a | + | A retrospective meeting is a structured session that gives teams time to reflect on a project <ref>Cullen, E.(2023), Mentimeter.com, Why & How to run a retrospective meeting, https://www.mentimeter.com/blog/great-leadership/the-why-and-how-of-project-retrospective-meetings</ref>. It allows a team and individuals to highlight both the successes and failures of a project, identify areas that need improvement, and reflect on the project as a whole. |
− | ==== | + | ==== The role of retrospective meetings in project management ==== |
Typically, organizations have numerous new projects queued up for execution, and as soon as one project wraps up, it seems reasonable to launch the next one. In support of this logic, one could argue that completing more projects could lead to a greater sense of accomplishment for management and stakeholders.<br /> | Typically, organizations have numerous new projects queued up for execution, and as soon as one project wraps up, it seems reasonable to launch the next one. In support of this logic, one could argue that completing more projects could lead to a greater sense of accomplishment for management and stakeholders.<br /> | ||
− | However, it is important to remember that simply completing projects does not necessarily equate to success or satisfaction. Quality and efficiency are equally important factors in achieving desired outcomes. This is where retrospective meetings come in as a valuable tool for Continuous Improvement in | + | However, it is important to remember that simply completing projects does not necessarily equate to success or satisfaction. Quality and efficiency are equally important factors in achieving desired outcomes. This is where retrospective meetings come in as a valuable tool for Continuous Improvement in project management. By reflecting on what worked well and what didn't, teams can identify areas for improvement and make meaningful changes in their projects, ultimately leading to better results and greater satisfaction for all stakeholders involved. |
==== When to use ==== | ==== When to use ==== | ||
Retrospective meetings should be held at least once at the end of the project, but it is recommended to have a retrospective meeting at the end of each project milestone or iteration. The frequency of these meetings will depend on the length of the different phases of the project. Still, they should be held regularly to ensure that the team has ample opportunity to reflect on their performance and make improvements. <br /> | Retrospective meetings should be held at least once at the end of the project, but it is recommended to have a retrospective meeting at the end of each project milestone or iteration. The frequency of these meetings will depend on the length of the different phases of the project. Still, they should be held regularly to ensure that the team has ample opportunity to reflect on their performance and make improvements. <br /> | ||
− | When thinking about the right cadence of retrospective meetings, it is also important to consider the influence of the recency bias. The recency bias is a cognitive bias that gives greater importance to the most recent event. For example, if we hold the first retrospective after six months of the project, people will likely focus on what happened in the last few weeks rather than all six months. | + | When thinking about the right cadence of retrospective meetings, it is also important to consider the influence of the recency bias <ref>https://en.wikipedia.org/wiki/Recency_bias#:~:text=Recency%20bias%20is%20a%20cognitive,before%20being%20dismissed%20to%20deliberate</ref>. The recency bias is a cognitive bias that gives greater importance to the most recent event. For example, if we hold the first retrospective after six months of the project, people will likely focus on what happened in the last few weeks rather than all six months. |
− | == | + | == Planning a retrospective meeting == |
− | + | ||
− | + | ||
− | + | ||
==== Preparation ==== | ==== Preparation ==== | ||
Preparation is critical for a successful retrospective meeting. Ideally, retrospective meetings should be scheduled in advance, so that everyone on the team knows when they will be held and can plan accordingly. Additionally, it's important to schedule the meeting at a time that works for everyone in the team, to ensure maximum attendance and participation. | Preparation is critical for a successful retrospective meeting. Ideally, retrospective meetings should be scheduled in advance, so that everyone on the team knows when they will be held and can plan accordingly. Additionally, it's important to schedule the meeting at a time that works for everyone in the team, to ensure maximum attendance and participation. | ||
Line 39: | Line 41: | ||
It is important to use data to inform retrospective meetings and improve team performance. Two different types of data should be gathered for data-informed retrospectives: quantitative data and qualitative data.<br /> | It is important to use data to inform retrospective meetings and improve team performance. Two different types of data should be gathered for data-informed retrospectives: quantitative data and qualitative data.<br /> | ||
Quantitative data refers to numerical data that can be measured and analysed. Quantitative data is important because it provides a measurable and objective view of team performance, allowing teams to identify trends and patterns over time and make data-informed decisions. This data can be gathered using tools like project management software, time tracking tools, or data analytics platforms. Example of quantitative data are: | Quantitative data refers to numerical data that can be measured and analysed. Quantitative data is important because it provides a measurable and objective view of team performance, allowing teams to identify trends and patterns over time and make data-informed decisions. This data can be gathered using tools like project management software, time tracking tools, or data analytics platforms. Example of quantitative data are: | ||
− | ::- cycle time: the amount of time spent working to complete a task; | + | ::- cycle time<ref>Monday.com (2021), What is cycle time?, https://monday.com/blog/project-management/cycle-time/</ref>: the amount of time spent working to complete a task; |
− | ::- backlog size: the number of tasks in the backlog, which represents the work that needs to be completed by the team in order to achieve the goals of the project; | + | ::- backlog size<ref>https://project-management-knowledge.com/definitions/b/backlog/</ref>: the number of tasks in the backlog, which represents the work that needs to be completed by the team in order to achieve the goals of the project; |
::- team velocity: the measure of the productivity rate of the project team with respect to the produced, validated and accepted deliverables. <br /> | ::- team velocity: the measure of the productivity rate of the project team with respect to the produced, validated and accepted deliverables. <br /> | ||
− | Qualitative data, on the other hand, refers to non-numerical data that is subjective and harder to measure, such as team morale, communication, or collaboration. Qualitative data can be gathered through surveys to be sent before the retrospective, | + | Qualitative data, on the other hand, refers to non-numerical data that is subjective and harder to measure, such as team morale, communication, or collaboration. Qualitative data can be gathered through surveys to be sent before the retrospective, and also with individual and group conversations with the team members. |
==== Involvement of project team members ==== | ==== Involvement of project team members ==== | ||
As mentioned before, all team members need to participate in the retrospective meeting. Having all team members participate in the retrospective ensures that everyone has a voice and can contribute their perspectives on what worked well and what did not. This allows the team to have a comprehensive view of the project and identify all possible issues or opportunities for improvement.<br /> | As mentioned before, all team members need to participate in the retrospective meeting. Having all team members participate in the retrospective ensures that everyone has a voice and can contribute their perspectives on what worked well and what did not. This allows the team to have a comprehensive view of the project and identify all possible issues or opportunities for improvement.<br /> | ||
− | Creating a safe space for team members is crucial for a successful retrospective meeting. A safe space means that people feel comfortable sharing their honest opinions and feelings without fear of judgement or repercussion. Thus, it is important to carefully examine who to invite from outside of the team, and the impact that their presence may have on the safety of the space. For example, if a senior executive is present, team members may be less likely to speak candidly for fear of retribution or damaging relationships with these individuals.<br /> | + | Creating a safe space for team members is crucial for a successful retrospective meeting <ref>Axtell, P. (2019), Make your meetings a safe space for honest conversation, hbr.org, https://hbr.org/2019/04/make-your-meetings-a-safe-space-for-honest-conversation</ref>. A safe space means that people feel comfortable sharing their honest opinions and feelings without fear of judgement or repercussion. Thus, it is important to carefully examine who to invite from outside of the team, and the impact that their presence may have on the safety of the space. For example, if a senior executive is present, team members may be less likely to speak candidly for fear of retribution or damaging relationships with these individuals.<br /> |
It may be helpful to establish ground rules for the meeting that reinforce the importance of confidentiality, non-judgement, and respect for all participants. This can help to set the tone for the meeting and encourage open and honest communication. | It may be helpful to establish ground rules for the meeting that reinforce the importance of confidentiality, non-judgement, and respect for all participants. This can help to set the tone for the meeting and encourage open and honest communication. | ||
Line 52: | Line 54: | ||
Retrospective meetings can be broken down into four different phases: setting the stage, evaluating the project performance, brainstorming potential improvements, and prioritizing recommended actions. For each of these phases, there are techniques and practices that encourage different ways of thinking and promote an environment of collaboration, engagement, and innovation. | Retrospective meetings can be broken down into four different phases: setting the stage, evaluating the project performance, brainstorming potential improvements, and prioritizing recommended actions. For each of these phases, there are techniques and practices that encourage different ways of thinking and promote an environment of collaboration, engagement, and innovation. | ||
==== Setting the stage ==== | ==== Setting the stage ==== | ||
− | The first few minutes of a retrospective meeting are crucial for setting the tone for a successful session. It is important to recognize team members, provide a smooth transition into the meeting, and set the context and boundaries. <br /> | + | The first few minutes of a retrospective meeting are crucial for setting the tone for a successful session. It is important to recognize team members <ref>O'Flaherty S., Sanders M. and Whillans A., A little recognition can provide a big morale boost, hbr.org, https://hbr.org/2021/03/research-a-little-recognition-can-provide-a-big-morale-boost</ref>, provide a smooth transition into the meeting, and set the context and boundaries. <br /> |
− | When team members arrive, they should be greeted with a simple “Thank you for coming” or “How are you?". Attention should be paid to their responses and clues should be looked for in what they say and how they say it. Greetings are not just a formality, they are an important way to show recognition and appreciation. When people feel recognized at work, they are more likely to | + | When team members arrive, they should be greeted with a simple “Thank you for coming” or “How are you?". Attention should be paid to their responses and clues should be looked for in what they say and how they say it. Greetings are not just a formality, they are an important way to show recognition and appreciation. When people feel recognized at work, they are more likely to perform well. This step can be used to create a welcoming atmosphere and show attendees that their presence is valued.<br /> |
Also, it should be kept in mind that everyone is coming from different places, both mentally and physically. If the meeting is started without providing a smooth transition, some attendees who are still adjusting may be lost. An effective way to get everyone on the same page is to review the action points from the last retrospective. This can help everyone start thinking analytically about the process and performance. | Also, it should be kept in mind that everyone is coming from different places, both mentally and physically. If the meeting is started without providing a smooth transition, some attendees who are still adjusting may be lost. An effective way to get everyone on the same page is to review the action points from the last retrospective. This can help everyone start thinking analytically about the process and performance. | ||
Line 59: | Line 61: | ||
During a retrospective meeting, team members should reflect on the project and discuss what worked well and what could have been done better. This involves identifying the successes and failures of the project and understanding the reasons behind them. The goal is to identify areas for improvement and develop a plan of action to address them. By reflecting on what worked, what didn't, and why, teams can learn from their experiences and apply these lessons to future projects.<br /> | During a retrospective meeting, team members should reflect on the project and discuss what worked well and what could have been done better. This involves identifying the successes and failures of the project and understanding the reasons behind them. The goal is to identify areas for improvement and develop a plan of action to address them. By reflecting on what worked, what didn't, and why, teams can learn from their experiences and apply these lessons to future projects.<br /> | ||
Here are some of the main techniques and exercises used to reflect on the project performance and identify improvement opportunities.<br /> | Here are some of the main techniques and exercises used to reflect on the project performance and identify improvement opportunities.<br /> | ||
− | ===== What went well? ===== | + | ===== What went well?===== |
− | The | + | The ''What went well'' is one of the easiest and most efficient methods for teams to complete their retrospectives <ref>Retrium.com, What went well retrospective, https://www.retrium.com/retrospective-techniques/whatwentwell-whatdidntgowell</ref>. This exercise opens discussions on what went well during the previous phase or sprint, as well as what didn’t go well (or as planned). Each team member is asked to reflect on what ideas, projects, and activities went well, and which did not go well. After members write down their thoughts, each point is discussed and action items are created so the team (and each member) can set goals for the upcoming sprint. Post discussion, team members decide upon specific action items to improve future engagement and sprint results. This format isn't overwhelming or complicated - it's very black and white. Sometimes that contrast is a great way to find patterns for what seems to work with this particular set of people and what doesn't. Methods can then be refined to improve in the future. This method is a great way to vent and fix frustrations, only to then end on a high note of all that went well and an acknowledgement of everyone's strengths to embrace in the future. |
+ | |||
===== 5 Whys ===== | ===== 5 Whys ===== | ||
− | 5 Whys is a problem-solving technique used to identify the underlying causes of problems and prevent them from occurring again in the future. When a problem is determined, the goal is to identify the underlying causes of it by asking "why" repeatedly, until the root cause is identified. Once this is done, the team can develop an action plan to address it and prevent similar problems from occurring again in the future. <br /> | + | ''5 Whys'' is a problem-solving technique used to identify the underlying causes of problems and prevent them from occurring again in the future. When a problem is determined, the goal is to identify the underlying causes of it by asking "why" repeatedly, until the root cause is identified. Once this is done, the team can develop an action plan to address it and prevent similar problems from occurring again in the future. <br /> |
While doing this exercise, it's important to remember that understanding what contributed to the team's success can be equally valuable in improving performance as identifying and addressing the root causes of problems. By analyzing what contributed to the team's success, it's possible to identify common patterns, behaviours, and habits that led to positive outcomes and replicate them in future projects. Celebrating success and recognizing the underlying factors that contributed to it can also boost team morale, motivation, and engagement, leading to increased commitment and better overall performance. | While doing this exercise, it's important to remember that understanding what contributed to the team's success can be equally valuable in improving performance as identifying and addressing the root causes of problems. By analyzing what contributed to the team's success, it's possible to identify common patterns, behaviours, and habits that led to positive outcomes and replicate them in future projects. Celebrating success and recognizing the underlying factors that contributed to it can also boost team morale, motivation, and engagement, leading to increased commitment and better overall performance. | ||
− | |||
− | |||
− | ::- Sailboat: the team itself (or some teams prefer to make this the project) | + | ===== The Sailboat retrospective ===== |
− | ::- Island or shore: the ultimate goal or vision for the team (where it’s headed) | + | [[File:Sailboat.jpeg|right|400px|thumb|Template of the Sailboat]] |
− | ::- Wind (or the sails): | + | This technique uses the metaphor of a sailboat heading toward shore to help teams visualize their ship (team) reaching its ultimate destination (or ultimate goals) <ref>EasyRetro.io, Sailboat retrospective, https://easyretro.io/templates/sailboat-exercise-sailboat-retrospective/</ref>. In a Sailboat exercise, there are traditionally five main components: |
− | ::- Anchors: things that are slowing the team or project down or delaying progress (silos, areas of weakness, etc.) | + | |
− | ::- Rocks: the risks or potential pitfalls of a project (areas of tension, bottlenecks, competition, etc.) <br/> | + | ::- '''Sailboat''': the team itself (or some teams prefer to make this the project) |
+ | ::- '''Island''' or shore: the ultimate goal or vision for the team (where it’s headed) | ||
+ | ::- '''Wind''' (or the sails): things that are helping the team glide along (team strengths, competitive advantages of your product, good communication, etc.) | ||
+ | ::- '''Anchors''': things that are slowing the team or project down or delaying progress (silos, areas of weakness, etc.) | ||
+ | ::- '''Rocks''': the risks or potential pitfalls of a project (areas of tension, bottlenecks, competition, etc.)<br/> | ||
The effectiveness of the Sailboat Exercise lies in its ability to use relatable metaphors to help team members easily identify important strengths and weaknesses. Because it is more of a non-pressure approach, it can help team members feel relaxed and more open to communicating without overthinking things. | The effectiveness of the Sailboat Exercise lies in its ability to use relatable metaphors to help team members easily identify important strengths and weaknesses. Because it is more of a non-pressure approach, it can help team members feel relaxed and more open to communicating without overthinking things. | ||
− | ===== The Starfish ===== | + | ===== The Starfish retrospective ===== |
− | Better known as the Starfish retrospective, this technique was developed to help teams better understand what they did wrong and how they can make things better. There are numerous levels of activities that go into getting something done and it is very important to get to the root of the issues. | + | [[File:Starfish.jpg|right|400px|thumb|Example of Starfish model]] |
+ | Better known as the ''Starfish retrospective'' <ref>EasyRetro.io, Starfish retrospective, https://easyretro.io/templates/starfish-retrospective/</ref>, this technique was developed to help teams better understand what they did wrong and how they can make things better. There are numerous levels of activities that go into getting something done and it is very important to get to the root of the issues. Instead of just listing down the problems with the process, the Starfish exercise encourages workers to think beyond traditional perspectives and truly understand where they went wrong. | ||
+ | The main purpose of the Starfish exercise is to enable the team to look at the activities and actions of the project and evaluate which ones need more resources and energies directed towards them and which ones need less of these. The technique is named after the shape of a starfish, with five arms representing different categories that the team should focus on. The five categories are: | ||
− | + | ::- '''Keep Doing''': this category includes the operations and activities happening that are adding value | |
+ | ::- '''Less of''': as the name of the category suggests, these are practices that are happening but could need some improvement. These could include a certain routine, an activity or the behavioural aspect of the employees that might not be as productive for the project. So, it is best advised to reduce its occurrence | ||
+ | ::- '''More of''': these are activities that are not proving as beneficial to the business as they could be. The performance could be higher if these activities or actions were more widely adopted. These could include a certain style of meeting or a new motivational process that might benefit a large number of employees | ||
+ | ::- '''Stop Doing''': these are simple activities, actions and operations that are not adding any value to the project whatsoever. For the benefit of the project, these need to be stopped and let go of right away | ||
+ | ::- '''Start Doing''': these practices could be something that other teams or competitors have adopted and that you would like to practice in your team. This could also be something that has been cooking up in the minds of the team members for a long time and now they would like to implement it in the hopes that it will add value | ||
− | + | ===== 4Ls ===== | |
− | + | The ''4Ls model'' <ref>TeamRetro.com, The Four Ls retrospective, https://www.teamretro.com/retrospectives/4ls-retrospective</ref> is an attempt to capture the natural thoughts that team members might have that can lead to continuous improvement. We naturally tend to think and share in terms of things that we appreciate, lessons learned, things that were missing, and that we wish we had. 4Ls leverages that natural thinking in a focused and helpful way. It is divided into 4 sections, each of which constitutes one L of the 4Ls. These are: | |
− | + | ::- '''Liked''': what did people like about the last iteration or phase? This could be anything from a process, an achievement, a particular team action or even a technology | |
− | + | ::- '''Learned''': what things did the team learn from experiments, testing, conversation and from working with each other? These are any new discoveries, points of interest or highlights | |
− | + | ::- '''Lacked''': what seemed to be missing from the last iteration? On reflection, this might be something that was unclear or needed to be implemented to ensure that things continue to run smoothly | |
− | + | ::- '''Longed for''': what is something that they wish existed or was possible that would ensure that the project would be successful? | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
==== Brainstorming of potential solutions and improvements ==== | ==== Brainstorming of potential solutions and improvements ==== | ||
− | ==== Prioritization of recommended actions ==== | + | Deriving good actions often determines whether retrospectives are perceived by the team as a "chatter meeting", or value-adding time in the project.<br/> |
+ | Once the team has identified what went well and what didn't, it's time to prioritize the issues. Some techniques that can help with prioritization include dot voting, simple ranking systems, or impact/effort matrices. It's important to prioritize based on impact, meaning how much the issue affects the project or sprint, and feasibility, meaning how realistic it is to address the issue. It's also a good idea to focus on a small number of issues rather than trying to tackle everything at once.<br/> | ||
+ | After identifying the top issues, the team should brainstorm potential solutions or action items for each of them. It's important to encourage specificity and provide actionable steps that can be taken to address the problem. One way to do this is to ask questions such as "What can we do to prevent this issue from happening again?" or "What specific steps can we take to address this problem?". Brainstorming solutions can be done individually or in small groups and then shared with the larger group for further discussion. | ||
+ | |||
+ | ==== Prioritization of recommended actions and follow-up==== | ||
+ | After identifying potential solutions, the team should review and prioritize them. This involves assessing the impact of each potential action item on the project or sprint and evaluating how feasible it is to implement. To simplify the process, grouping similar items together or breaking larger items into smaller, more manageable tasks can be helpful.<br/> | ||
+ | Once the most impactful and feasible action items have been identified, it's crucial to assign ownership to a specific team member or group and set realistic deadlines for completion. Assigning ownership and deadlines helps ensure accountability and progress towards the identified goals.<br/> | ||
+ | To monitor progress, the team should regularly follow up on the action items and make necessary adjustments. This ensures that identified issues are being resolved effectively and that the team is on track. Regular follow-up can be conducted through status updates, progress reports, or check-ins. Additionally, being open to making adjustments if the action items are not achieving the desired results, or if new issues arise, is crucial for success. | ||
− | |||
− | |||
− | |||
− | |||
== Benefits of retrospective meetings == | == Benefits of retrospective meetings == | ||
==== Improved communication among project team members ==== | ==== Improved communication among project team members ==== | ||
− | + | One of the key benefits of retrospective meetings is their ability to improve communication within the team. These meetings provide a platform for open discussion, promoting a culture of collaboration and transparency. As team members regularly share their thoughts and ideas, they develop a better understanding of each other’s roles and responsibilities. This can help to reduce misunderstandings and conflicts, leading to improved overall effectiveness. | |
==== Enhanced learning and continuous improvement ==== | ==== Enhanced learning and continuous improvement ==== | ||
+ | Another benefit of retrospective meetings is their ability to facilitate learning and continuous improvement. During these meetings, teams reflect on their past performance and identify areas for growth. This allows them to learn from their mistakes and continuously improve their processes and practices. Teams that foster a culture of continuous learning and development can become more efficient and effective over time. | ||
+ | |||
==== Improved project outcomes and performance ==== | ==== Improved project outcomes and performance ==== | ||
+ | Retrospective meetings can also lead to improved project outcomes and performance. Regular reflection on performance and identification of areas for improvement can help teams to make changes that lead to better results. For example, if a team is consistently missing deadlines, they can use the retrospective meeting to discuss the reasons for this and develop a plan to address the issue. Implementing these types of changes can help teams to improve their performance and deliver better project outcomes. | ||
+ | |||
==== Better team morale and motivation ==== | ==== Better team morale and motivation ==== | ||
+ | Finally, retrospective meetings can have a positive impact on team morale and motivation. These meetings provide an opportunity for team members to celebrate their successes and acknowledge each other’s contributions. This recognition can boost morale and motivation, leading to improved overall performance. Fostering a positive team culture through regular recognition and celebration can help to improve job satisfaction and retention. | ||
+ | |||
== Limitations of retrospective meetings == | == Limitations of retrospective meetings == | ||
==== Limited scope of discussion ==== | ==== Limited scope of discussion ==== | ||
+ | One limitation of retrospective meetings is that their scope of discussion may be limited. These meetings typically focus on the team’s recent performance and may not address broader organizational or systemic issues. As a result, the meeting may not identify or address the root causes of problems that lie outside the team’s immediate purview. To mitigate this limitation, it can be helpful to broaden the scope of discussion to include relevant organizational or systemic factors. | ||
+ | |||
==== Bias and subjectivity of meeting outcomes ==== | ==== Bias and subjectivity of meeting outcomes ==== | ||
+ | Another limitation of retrospective meetings is the potential for bias and subjectivity in their outcomes. The perspectives and opinions shared during the meeting may not represent the views of all team members or stakeholders. This can lead to biased or incomplete conclusions and recommendations. To address this limitation, it’s important to actively seek out and consider diverse perspectives, and to use objective data and evidence to support decision-making. | ||
+ | |||
==== Difficulty in implementing recommended improvements ==== | ==== Difficulty in implementing recommended improvements ==== | ||
+ | A third limitation of retrospective meetings is the difficulty teams may face in implementing recommended improvements. Translating insights and recommendations from the meeting into actionable changes can be challenging. Teams may face barriers such as resource constraints or resistance to change. To overcome this limitation, it’s important to develop a clear plan for implementing improvements, with specific actions, timelines, and accountability. | ||
+ | |||
+ | ==== Groupthink ==== | ||
+ | Another potential limitation of retrospective meetings is the risk of groupthink. This occurs when team members are hesitant to speak up or challenge the prevailing view, leading to suboptimal decisions and outcomes. Groupthink can be particularly problematic in retrospective meetings if team members feel pressure to conform to the opinions of others or if there is a lack of diversity in perspectives. To mitigate this risk, it’s important to create an environment where all team members feel comfortable sharing their thoughts and ideas and to actively seek out and consider diverse perspectives. | ||
− | |||
− | |||
− | |||
− | |||
== Conclusion == | == Conclusion == | ||
+ | Retrospective meetings are a valuable tool for driving Continuous Improvement in project management. By providing a structured process for reflecting on past performance and identifying areas for improvement, retrospective meetings can facilitate continuous learning and improvement within teams and organizations. The benefits of retrospective meetings are numerous, including promoting transparency, boosting team spirit, helping team members learn and develop, highlighting team and individual strengths and weaknesses, identifying blockers in ways of working, setting better and more realistic expectations, and improving planning and structure for future projects. | ||
+ | |||
+ | However, there are also limitations to retrospective meetings that should be considered. For example, ensuring participation from all team members and creating a safe environment for open discussion can be challenging. Additionally, retrospective meetings may not always result in actionable improvements if the team is not committed to implementing the changes identified during the meeting. | ||
+ | |||
+ | Despite these limitations, retrospective meetings can still be a valuable tool for driving Continuous Improvement in project management when implemented effectively. By following the guidelines and best practices outlined in this article, project managers can successfully implement retrospective meetings to drive Continuous Improvement in their organizations. | ||
+ | |||
+ | == Future work == | ||
+ | |||
+ | Looking to the future, there are many potential extensions to this article that could further explore the topic of retrospective meetings in project, portfolio and program management. For example, future research could examine the effectiveness of different approaches to running retrospective meetings, such as using different facilitation techniques or tools. <br/> | ||
+ | In the fields of program and portfolio management, future research could explore how retrospective meetings can be used to drive Continuous Improvement at higher levels of organizational planning and decision-making. | ||
+ | |||
== References == | == References == | ||
− | + | <references/> | |
+ | |||
+ | [[Category:Retrospective meetings]] [[Category:Learning]] [[Category:Continuous Improvement]] [[Category:Project Management]] [[Category:Agile Project Management]] |
Latest revision as of 16:46, 9 May 2023
Written by Alberto Pillon
[edit] Abstract
This article explores the use of retrospective meetings as a tool for Continuous Improvement in project management. A retrospective meeting is a structured meeting held at the end of a project or iteration to reflect on the team’s performance and identify areas for improvement. The purpose is to facilitate continuous learning and improvement within the team.
The article then delves into the key phases and activities involved in conducting an effective retrospective meeting. These include setting the stage, evaluating the project performance, brainstorming potential improvements, and prioritizing recommended actions. The article provides a detailed guide for conducting each of these phases and discusses best practices for facilitating effective retrospective meetings.
The benefits and limitations of retrospective meetings are also discussed. Some of the key benefits include improved communication among project team members, enhanced learning and continuous improvement, improved project outcomes and performance, and better team morale and motivation. However, there are also some limitations to consider, such as the potential for groupthink and the difficulty in implementing recommended improvements.
Finally, the relevance of retrospective meetings in the field of continuous improvement is assessed. The article argues that retrospective meetings are a valuable tool for driving continuous improvement in project management by providing a structured process for reflecting on past performance and identifying areas for improvement.
Overall, this article provides valuable insights into how retrospective meetings can be leveraged to drive Continuous Improvement in project management. It provides a detailed guide for conducting effective retrospective meetings and discusses their benefits and limitations.
[edit] Introduction
[edit] Background of Continuous Improvement in project management
Continuous Improvement is a philosophy that W. Edward Deming described simply as consisting of "Improvement initiatives that increase successes and reduce failures " [1]. In general, Continuous Improvement can be defined as a culture of sustained improvement targeting the elimination of waste in all systems and processes of an organization. It is achieved through the use of several tools and techniques dedicated to searching for sources of problems, waste, and variation, and finding ways to minimize them.
Continuous Improvement programs have evolved from traditional manufacturing-focused systems that concentrate on the production line to reduce waste and improve product quality, into comprehensive, systematic methodologies that focus on the entire organization, from top management to the workers on the shop floor [2].
[edit] Overview of retrospective meetings
A retrospective (from Latin retrospectare, "look back"), is a look back at events that took place in the past [3]. Retrospective meetings have their roots in Agile software development methodology, which emphasizes continuous improvement and adaptive planning. The idea of retrospective meetings was to provide a safe space for team members to reflect on their performance, identify areas for improvement, and make changes accordingly. Over time, retrospective meetings have become a popular practice in not only software development but also in other industries, and they are widely recognized as a powerful tool for continuous improvement.
[edit] Retrospective meetings
[edit] Definition
A retrospective meeting is a structured session that gives teams time to reflect on a project [4]. It allows a team and individuals to highlight both the successes and failures of a project, identify areas that need improvement, and reflect on the project as a whole.
[edit] The role of retrospective meetings in project management
Typically, organizations have numerous new projects queued up for execution, and as soon as one project wraps up, it seems reasonable to launch the next one. In support of this logic, one could argue that completing more projects could lead to a greater sense of accomplishment for management and stakeholders.
However, it is important to remember that simply completing projects does not necessarily equate to success or satisfaction. Quality and efficiency are equally important factors in achieving desired outcomes. This is where retrospective meetings come in as a valuable tool for Continuous Improvement in project management. By reflecting on what worked well and what didn't, teams can identify areas for improvement and make meaningful changes in their projects, ultimately leading to better results and greater satisfaction for all stakeholders involved.
[edit] When to use
Retrospective meetings should be held at least once at the end of the project, but it is recommended to have a retrospective meeting at the end of each project milestone or iteration. The frequency of these meetings will depend on the length of the different phases of the project. Still, they should be held regularly to ensure that the team has ample opportunity to reflect on their performance and make improvements.
When thinking about the right cadence of retrospective meetings, it is also important to consider the influence of the recency bias [5]. The recency bias is a cognitive bias that gives greater importance to the most recent event. For example, if we hold the first retrospective after six months of the project, people will likely focus on what happened in the last few weeks rather than all six months.
[edit] Planning a retrospective meeting
[edit] Preparation
Preparation is critical for a successful retrospective meeting. Ideally, retrospective meetings should be scheduled in advance, so that everyone on the team knows when they will be held and can plan accordingly. Additionally, it's important to schedule the meeting at a time that works for everyone in the team, to ensure maximum attendance and participation. Project managers should prepare the following:
- - Agenda: the meeting agenda should be prepared in advance and circulated to all participants;
- - Goals: The meeting goals should be clearly defined to ensure that the team stays focused.
- - Data: project managers should gather project data, including timelines, budgets, and team performance metrics.
[edit] Gathering of project data
It is important to use data to inform retrospective meetings and improve team performance. Two different types of data should be gathered for data-informed retrospectives: quantitative data and qualitative data.
Quantitative data refers to numerical data that can be measured and analysed. Quantitative data is important because it provides a measurable and objective view of team performance, allowing teams to identify trends and patterns over time and make data-informed decisions. This data can be gathered using tools like project management software, time tracking tools, or data analytics platforms. Example of quantitative data are:
- - cycle time[6]: the amount of time spent working to complete a task;
- - backlog size[7]: the number of tasks in the backlog, which represents the work that needs to be completed by the team in order to achieve the goals of the project;
- - team velocity: the measure of the productivity rate of the project team with respect to the produced, validated and accepted deliverables.
Qualitative data, on the other hand, refers to non-numerical data that is subjective and harder to measure, such as team morale, communication, or collaboration. Qualitative data can be gathered through surveys to be sent before the retrospective, and also with individual and group conversations with the team members.
[edit] Involvement of project team members
As mentioned before, all team members need to participate in the retrospective meeting. Having all team members participate in the retrospective ensures that everyone has a voice and can contribute their perspectives on what worked well and what did not. This allows the team to have a comprehensive view of the project and identify all possible issues or opportunities for improvement.
Creating a safe space for team members is crucial for a successful retrospective meeting [8]. A safe space means that people feel comfortable sharing their honest opinions and feelings without fear of judgement or repercussion. Thus, it is important to carefully examine who to invite from outside of the team, and the impact that their presence may have on the safety of the space. For example, if a senior executive is present, team members may be less likely to speak candidly for fear of retribution or damaging relationships with these individuals.
It may be helpful to establish ground rules for the meeting that reinforce the importance of confidentiality, non-judgement, and respect for all participants. This can help to set the tone for the meeting and encourage open and honest communication.
[edit] Key activities of retrospective meetings
Retrospective meetings can be broken down into four different phases: setting the stage, evaluating the project performance, brainstorming potential improvements, and prioritizing recommended actions. For each of these phases, there are techniques and practices that encourage different ways of thinking and promote an environment of collaboration, engagement, and innovation.
[edit] Setting the stage
The first few minutes of a retrospective meeting are crucial for setting the tone for a successful session. It is important to recognize team members [9], provide a smooth transition into the meeting, and set the context and boundaries.
When team members arrive, they should be greeted with a simple “Thank you for coming” or “How are you?". Attention should be paid to their responses and clues should be looked for in what they say and how they say it. Greetings are not just a formality, they are an important way to show recognition and appreciation. When people feel recognized at work, they are more likely to perform well. This step can be used to create a welcoming atmosphere and show attendees that their presence is valued.
Also, it should be kept in mind that everyone is coming from different places, both mentally and physically. If the meeting is started without providing a smooth transition, some attendees who are still adjusting may be lost. An effective way to get everyone on the same page is to review the action points from the last retrospective. This can help everyone start thinking analytically about the process and performance.
[edit] Evaluation of project performance and identification of areas to improve
During a retrospective meeting, team members should reflect on the project and discuss what worked well and what could have been done better. This involves identifying the successes and failures of the project and understanding the reasons behind them. The goal is to identify areas for improvement and develop a plan of action to address them. By reflecting on what worked, what didn't, and why, teams can learn from their experiences and apply these lessons to future projects.
Here are some of the main techniques and exercises used to reflect on the project performance and identify improvement opportunities.
[edit] What went well?
The What went well is one of the easiest and most efficient methods for teams to complete their retrospectives [10]. This exercise opens discussions on what went well during the previous phase or sprint, as well as what didn’t go well (or as planned). Each team member is asked to reflect on what ideas, projects, and activities went well, and which did not go well. After members write down their thoughts, each point is discussed and action items are created so the team (and each member) can set goals for the upcoming sprint. Post discussion, team members decide upon specific action items to improve future engagement and sprint results. This format isn't overwhelming or complicated - it's very black and white. Sometimes that contrast is a great way to find patterns for what seems to work with this particular set of people and what doesn't. Methods can then be refined to improve in the future. This method is a great way to vent and fix frustrations, only to then end on a high note of all that went well and an acknowledgement of everyone's strengths to embrace in the future.
[edit] 5 Whys
5 Whys is a problem-solving technique used to identify the underlying causes of problems and prevent them from occurring again in the future. When a problem is determined, the goal is to identify the underlying causes of it by asking "why" repeatedly, until the root cause is identified. Once this is done, the team can develop an action plan to address it and prevent similar problems from occurring again in the future.
While doing this exercise, it's important to remember that understanding what contributed to the team's success can be equally valuable in improving performance as identifying and addressing the root causes of problems. By analyzing what contributed to the team's success, it's possible to identify common patterns, behaviours, and habits that led to positive outcomes and replicate them in future projects. Celebrating success and recognizing the underlying factors that contributed to it can also boost team morale, motivation, and engagement, leading to increased commitment and better overall performance.
[edit] The Sailboat retrospective
This technique uses the metaphor of a sailboat heading toward shore to help teams visualize their ship (team) reaching its ultimate destination (or ultimate goals) [11]. In a Sailboat exercise, there are traditionally five main components:
- - Sailboat: the team itself (or some teams prefer to make this the project)
- - Island or shore: the ultimate goal or vision for the team (where it’s headed)
- - Wind (or the sails): things that are helping the team glide along (team strengths, competitive advantages of your product, good communication, etc.)
- - Anchors: things that are slowing the team or project down or delaying progress (silos, areas of weakness, etc.)
- - Rocks: the risks or potential pitfalls of a project (areas of tension, bottlenecks, competition, etc.)
The effectiveness of the Sailboat Exercise lies in its ability to use relatable metaphors to help team members easily identify important strengths and weaknesses. Because it is more of a non-pressure approach, it can help team members feel relaxed and more open to communicating without overthinking things.
[edit] The Starfish retrospective
Better known as the Starfish retrospective [12], this technique was developed to help teams better understand what they did wrong and how they can make things better. There are numerous levels of activities that go into getting something done and it is very important to get to the root of the issues. Instead of just listing down the problems with the process, the Starfish exercise encourages workers to think beyond traditional perspectives and truly understand where they went wrong. The main purpose of the Starfish exercise is to enable the team to look at the activities and actions of the project and evaluate which ones need more resources and energies directed towards them and which ones need less of these. The technique is named after the shape of a starfish, with five arms representing different categories that the team should focus on. The five categories are:
- - Keep Doing: this category includes the operations and activities happening that are adding value
- - Less of: as the name of the category suggests, these are practices that are happening but could need some improvement. These could include a certain routine, an activity or the behavioural aspect of the employees that might not be as productive for the project. So, it is best advised to reduce its occurrence
- - More of: these are activities that are not proving as beneficial to the business as they could be. The performance could be higher if these activities or actions were more widely adopted. These could include a certain style of meeting or a new motivational process that might benefit a large number of employees
- - Stop Doing: these are simple activities, actions and operations that are not adding any value to the project whatsoever. For the benefit of the project, these need to be stopped and let go of right away
- - Start Doing: these practices could be something that other teams or competitors have adopted and that you would like to practice in your team. This could also be something that has been cooking up in the minds of the team members for a long time and now they would like to implement it in the hopes that it will add value
[edit] 4Ls
The 4Ls model [13] is an attempt to capture the natural thoughts that team members might have that can lead to continuous improvement. We naturally tend to think and share in terms of things that we appreciate, lessons learned, things that were missing, and that we wish we had. 4Ls leverages that natural thinking in a focused and helpful way. It is divided into 4 sections, each of which constitutes one L of the 4Ls. These are:
- - Liked: what did people like about the last iteration or phase? This could be anything from a process, an achievement, a particular team action or even a technology
- - Learned: what things did the team learn from experiments, testing, conversation and from working with each other? These are any new discoveries, points of interest or highlights
- - Lacked: what seemed to be missing from the last iteration? On reflection, this might be something that was unclear or needed to be implemented to ensure that things continue to run smoothly
- - Longed for: what is something that they wish existed or was possible that would ensure that the project would be successful?
[edit] Brainstorming of potential solutions and improvements
Deriving good actions often determines whether retrospectives are perceived by the team as a "chatter meeting", or value-adding time in the project.
Once the team has identified what went well and what didn't, it's time to prioritize the issues. Some techniques that can help with prioritization include dot voting, simple ranking systems, or impact/effort matrices. It's important to prioritize based on impact, meaning how much the issue affects the project or sprint, and feasibility, meaning how realistic it is to address the issue. It's also a good idea to focus on a small number of issues rather than trying to tackle everything at once.
After identifying the top issues, the team should brainstorm potential solutions or action items for each of them. It's important to encourage specificity and provide actionable steps that can be taken to address the problem. One way to do this is to ask questions such as "What can we do to prevent this issue from happening again?" or "What specific steps can we take to address this problem?". Brainstorming solutions can be done individually or in small groups and then shared with the larger group for further discussion.
[edit] Prioritization of recommended actions and follow-up
After identifying potential solutions, the team should review and prioritize them. This involves assessing the impact of each potential action item on the project or sprint and evaluating how feasible it is to implement. To simplify the process, grouping similar items together or breaking larger items into smaller, more manageable tasks can be helpful.
Once the most impactful and feasible action items have been identified, it's crucial to assign ownership to a specific team member or group and set realistic deadlines for completion. Assigning ownership and deadlines helps ensure accountability and progress towards the identified goals.
To monitor progress, the team should regularly follow up on the action items and make necessary adjustments. This ensures that identified issues are being resolved effectively and that the team is on track. Regular follow-up can be conducted through status updates, progress reports, or check-ins. Additionally, being open to making adjustments if the action items are not achieving the desired results, or if new issues arise, is crucial for success.
[edit] Benefits of retrospective meetings
[edit] Improved communication among project team members
One of the key benefits of retrospective meetings is their ability to improve communication within the team. These meetings provide a platform for open discussion, promoting a culture of collaboration and transparency. As team members regularly share their thoughts and ideas, they develop a better understanding of each other’s roles and responsibilities. This can help to reduce misunderstandings and conflicts, leading to improved overall effectiveness.
[edit] Enhanced learning and continuous improvement
Another benefit of retrospective meetings is their ability to facilitate learning and continuous improvement. During these meetings, teams reflect on their past performance and identify areas for growth. This allows them to learn from their mistakes and continuously improve their processes and practices. Teams that foster a culture of continuous learning and development can become more efficient and effective over time.
[edit] Improved project outcomes and performance
Retrospective meetings can also lead to improved project outcomes and performance. Regular reflection on performance and identification of areas for improvement can help teams to make changes that lead to better results. For example, if a team is consistently missing deadlines, they can use the retrospective meeting to discuss the reasons for this and develop a plan to address the issue. Implementing these types of changes can help teams to improve their performance and deliver better project outcomes.
[edit] Better team morale and motivation
Finally, retrospective meetings can have a positive impact on team morale and motivation. These meetings provide an opportunity for team members to celebrate their successes and acknowledge each other’s contributions. This recognition can boost morale and motivation, leading to improved overall performance. Fostering a positive team culture through regular recognition and celebration can help to improve job satisfaction and retention.
[edit] Limitations of retrospective meetings
[edit] Limited scope of discussion
One limitation of retrospective meetings is that their scope of discussion may be limited. These meetings typically focus on the team’s recent performance and may not address broader organizational or systemic issues. As a result, the meeting may not identify or address the root causes of problems that lie outside the team’s immediate purview. To mitigate this limitation, it can be helpful to broaden the scope of discussion to include relevant organizational or systemic factors.
[edit] Bias and subjectivity of meeting outcomes
Another limitation of retrospective meetings is the potential for bias and subjectivity in their outcomes. The perspectives and opinions shared during the meeting may not represent the views of all team members or stakeholders. This can lead to biased or incomplete conclusions and recommendations. To address this limitation, it’s important to actively seek out and consider diverse perspectives, and to use objective data and evidence to support decision-making.
[edit] Difficulty in implementing recommended improvements
A third limitation of retrospective meetings is the difficulty teams may face in implementing recommended improvements. Translating insights and recommendations from the meeting into actionable changes can be challenging. Teams may face barriers such as resource constraints or resistance to change. To overcome this limitation, it’s important to develop a clear plan for implementing improvements, with specific actions, timelines, and accountability.
[edit] Groupthink
Another potential limitation of retrospective meetings is the risk of groupthink. This occurs when team members are hesitant to speak up or challenge the prevailing view, leading to suboptimal decisions and outcomes. Groupthink can be particularly problematic in retrospective meetings if team members feel pressure to conform to the opinions of others or if there is a lack of diversity in perspectives. To mitigate this risk, it’s important to create an environment where all team members feel comfortable sharing their thoughts and ideas and to actively seek out and consider diverse perspectives.
[edit] Conclusion
Retrospective meetings are a valuable tool for driving Continuous Improvement in project management. By providing a structured process for reflecting on past performance and identifying areas for improvement, retrospective meetings can facilitate continuous learning and improvement within teams and organizations. The benefits of retrospective meetings are numerous, including promoting transparency, boosting team spirit, helping team members learn and develop, highlighting team and individual strengths and weaknesses, identifying blockers in ways of working, setting better and more realistic expectations, and improving planning and structure for future projects.
However, there are also limitations to retrospective meetings that should be considered. For example, ensuring participation from all team members and creating a safe environment for open discussion can be challenging. Additionally, retrospective meetings may not always result in actionable improvements if the team is not committed to implementing the changes identified during the meeting.
Despite these limitations, retrospective meetings can still be a valuable tool for driving Continuous Improvement in project management when implemented effectively. By following the guidelines and best practices outlined in this article, project managers can successfully implement retrospective meetings to drive Continuous Improvement in their organizations.
[edit] Future work
Looking to the future, there are many potential extensions to this article that could further explore the topic of retrospective meetings in project, portfolio and program management. For example, future research could examine the effectiveness of different approaches to running retrospective meetings, such as using different facilitation techniques or tools.
In the fields of program and portfolio management, future research could explore how retrospective meetings can be used to drive Continuous Improvement at higher levels of organizational planning and decision-making.
[edit] References
- ↑ Bhuiyan, N. and Baghel, A. (2005), "An overview of continuous improvement: from the past to the present", Management Decision, Vol. 43 No. 5, pp. 761-771. https://doi-org.proxy.findit.cvt.dk/10.1108/00251740510597761
- ↑ J. Bessant, S. Caffyn, J. Gilbert, R. Harding, S. Webb, Rediscovering continuous improvement, Technovation, Volume 14, Issue 1, 1994, Pages 17-29, ISSN 0166-4972, https://doi.org/10.1016/0166-4972(94)90067-1.
- ↑ https://en.wikipedia.org/wiki/Retrospective
- ↑ Cullen, E.(2023), Mentimeter.com, Why & How to run a retrospective meeting, https://www.mentimeter.com/blog/great-leadership/the-why-and-how-of-project-retrospective-meetings
- ↑ https://en.wikipedia.org/wiki/Recency_bias#:~:text=Recency%20bias%20is%20a%20cognitive,before%20being%20dismissed%20to%20deliberate
- ↑ Monday.com (2021), What is cycle time?, https://monday.com/blog/project-management/cycle-time/
- ↑ https://project-management-knowledge.com/definitions/b/backlog/
- ↑ Axtell, P. (2019), Make your meetings a safe space for honest conversation, hbr.org, https://hbr.org/2019/04/make-your-meetings-a-safe-space-for-honest-conversation
- ↑ O'Flaherty S., Sanders M. and Whillans A., A little recognition can provide a big morale boost, hbr.org, https://hbr.org/2021/03/research-a-little-recognition-can-provide-a-big-morale-boost
- ↑ Retrium.com, What went well retrospective, https://www.retrium.com/retrospective-techniques/whatwentwell-whatdidntgowell
- ↑ EasyRetro.io, Sailboat retrospective, https://easyretro.io/templates/sailboat-exercise-sailboat-retrospective/
- ↑ EasyRetro.io, Starfish retrospective, https://easyretro.io/templates/starfish-retrospective/
- ↑ TeamRetro.com, The Four Ls retrospective, https://www.teamretro.com/retrospectives/4ls-retrospective