Driving Continuous Improvement with retrospective meetings
Abstract
Project management is a dynamic field that requires continuous improvement to meet the evolving needs of clients, stakeholders and the broader market. One effective tool for continuous improvement in project management is retrospective meetings. This article will explore the key activities, inputs, and outputs of retrospective meetings and highlight the benefits and limitations of this approach. The article will also outline retrospective meetings' role in continuous improvement and provide guidelines on how their impact on future projects can be measured. By analyzing the structure and purpose of retrospective meetings, this article will represent a comprehensive guide to improving project management practices and promoting continuous improvement within organizations.
Introduction
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.
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.
Overview of retrospective meetings
A retrospective (from Latin retrospectare, "look back"), is a look back at events that took place in the past. 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.
What are retrospective meetings
Definition
A retrospective meeting is a structured session that gives teams time to reflect on a completed project. 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.
Why are they used 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 future projects, ultimately leading to better results and greater satisfaction for all involved.
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. 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.
The goals of retrospective meetings
Different approaches
Inputs for retrospective meetings
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.
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: 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;
- - 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,
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. 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.
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.
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.
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 stay and 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.
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.
What went well?
The ‘what went well’ is one of the easiest and most efficient methods for teams to complete their retrospectives. 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 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.
The Sailboat
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). 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.
The Starfish
4 Ls
Brainstorming of potential solutions and improvements
Prioritization of recommended actions
Outputs of retrospective meetings
Action items for continuous improvement
Feedback for future projects
Documentation of meeting outcomes
Benefits of retrospective meetings
Improved communication among project team members
In addition, involving all team members in the retrospective promotes a culture of collaboration and transparency. When everyone participates, it encourages open communication and sharing of ideas, leading to better decision-making and problem-solving.
Enhanced learning and continuous improvement
Improved project outcomes and performance
Better team morale and motivation
Limitations of retrospective meetings
Limited scope of discussion
Bias and subjectivity of meeting outcomes
Difficulty in implementing recommended improvements
Measuring the impact of retrospective meetings
Quantitative metrics
Qualitative metrics
Comparison of project performance before and after retrospective meetings
Conclusion
References
SBOK - SCRUM Body of Knowledge