How To Run An Effective Project Retrospective

You may have heard of the saying, sometimes you gotta move backwards in order to move forwards. It's really important that you don't just go off and party when your project ends. It's important to get together as a team to talk about what went well and what you can improve for the future. You as a project manager are responsible for holding it all together. Now, it's important that when the deliverable is done, that you don't just dismiss the whole team. Most project managers think that when the deliverable is delivered is when the project is done. However, before you can let the whole team go, it's important that you do a project retrospective, and I'm going to show you how to do this in today's video. What is a project retrospective? So if someone on the project team says, let's have a ritual, that doesn't mean let's throw an '80s-themed party, although that would be super fun as well. A project retrospective refers to a formal activity where the project stakeholders are asked to look back on the project and reflect on what went well, what didn't go so well, and what they can improve on in the future. This is one of the key Agile ceremonies. Retrospectives are the time the team spends together to assess how well they're working together to define steps for improvement, and they're meant to be a safe place where people are able to speak Being able to get people to open up and share feedback can sound easy, but in reality, it could be a bit challenging. You need to take into account that people have different feelings, and sometimes people may avoid sharing anything in fear of being reprimanded. Also, some people are more introverted and less likely to speak up. I agree. Let's talk about how you can run a project retrospective successfully now that we know what it is. Step 1 is to create a company culture of trust. Like I said earlier, getting people to open up and provide feedback can be difficult. It is even more difficult when there's distrust among the project team members or among the stakeholders. You have to ask yourself some of the following questions. In the past, was feedback criticized or team members made to feel intimidated when they had ideas or feedback to share? Was blame game played if problems were uncovered? And if feedback was shared, were there a lot of negative actions taken and fingerprint pointing? If you answered yes to any of these questions, there are definite reasons why people may not be very willing to open up. So how do you get people to share feedback openly and create a culture of trust? You can try some of the following. You can create opportunities for collaboration. These could include daily project status check-ins and non-project activities like a team building activity where people can collaborate. You can also make sharing feedback a part of your team's culture. This is very common in software development where all of the team members depend on each other in order to create the working product. You could also encourage open and honest communication. Ensure that your team feels that they are valued and appreciated, and what they have to say is really important. If people know that you will listen to them, they will be more likely to open up and share their feedback. Step number 2 is to determine what type of feedback you would like to collect. A lot happens during a project, and as such, there is a lot of opportunity to collect a broad spectrum of feedback during the retrospective. You have to decide what kind of feedback will be useful for your project team going forward. So during the retrospective, it's good to have a plan going in there. Some common themes could include things such as team performance, communications, and stakeholder engagement. Was information shared on time with the right people at the right time using the right tools? And you also want to take a look at your project deliverables itself. Did your project deliverable meet the expectations of the stakeholder? Why or why not? This is probably the most important thing you should be discussing during the retrospective. Lastly, with your project team, you could also be talking about your project processes and tools. Did you use the right processes? Could you be more efficient somewhere else? Were there anything missed? After you come up with your plan of the questions that you want to discuss during the retrospective, let's now move on to step number 3, which is to set a dedicated time for the project retrospective. If the retrospective is going to be done at the end of the project, there will no doubt be competing demands on everyone's time during this phase. So it's important to set up periodic project retrospectives at dedicated times throughout the project. Also, if you do the retrospective all at the end of the project, well, it might not be so useful to you because even if you identify things to improve upon, it's already too late. The project is already over. So the retrospective should really be conducted at set times throughout the project. In Scrum, the retrospective is conducted at the end of every 2 weeks or at the end of every sprint. This is a chance for the team to discuss what went well, what didn't go so well, and what they could improve upon in the future. And then over the next sprints, the team could actually start to implement these changes. You want to make sure that the retrospectives are scheduled on people's calendars And they are booked off during that time so that they don't get pulled into competing demands. You may wanna send out these calendar invitations a few weeks in advance as well. Likewise, when scheduling your retrospective, it's also helpful to send out your agenda so people are prepared when they're going in. They already thought of ways to improve and know what you want to discuss. The project retrospective meeting agenda. Now, when you start off your project retrospective meeting, you could start off by just welcoming everyone and telling everyone why they are there. Then you give them an overview of how the feedback will be collected. This includes giving them a brief summary of how feedback will be collected during the session and what tools will be used. You may also want to go over any ground rules. For example, All feedback needs to be constructive and honest, and no one can talk over one another. Next, you wanna actually go through the questions that you have prepared and collect feedback from all of the team members using the tool of your choice. It could be as simple as a whiteboard, or you could use a Google Doc. Next, you wanna review all of the feedback from the participants. Review all feedback collected, the good, the bad, and the ugly. During this part of the session, the feedback will only be presented, questions and discussions around around the specific feedback should be limited. You just want everyone to say what they have to say without any discussion at this point. This actually brings me to my next point. After everyone have given all of their feedback, the next thing you want to do is to discuss the feedback and questions. So gather thoughts, opinions, and responses from all of the participants. Do they agree with the feedback? Do you agree with the insights? And do they have a solution on how to improve the problems that have been pointed out? Next, you want to formulate actions and next steps for improvements. Now that you have all of the feedback and the team have discussed this feedback, you want to form a plan of action in order to improve upon the criticisms that have came up through the project retrospective. Based on the feedback presented, there are certain action items that could be taken by the team members. During this section of the project retrospective, detailed plans on how to make the improvements will be discussed. Also ask for volunteers to take ownership. Now, after all of this has been done, you can summarize the feedback and improvements and make sure that you highlight these summaries and send it out to everyone post-meeting. You will thank the participants for coming and also follow up to ensure that the action plan that has been set out will actually be implemented. So that's pretty much all there is to it. A project retrospective is not very difficult, but very essential to the success of your project. A question I get asked very often is, what is the difference between a project retrospective and a lessons learned? So lessons learned is a terminology generally used in waterfall project management, while project retrospective is a Scrum methodology. They pretty much do the same thing where the project team gets together post-project or post-sprint and talk about how they can make improvements. It's just the terminologies would differ depending on the methodology being used. Sometimes it could also be wise to include the client as well. This would depend on your project situation. Also, you as the project manager or Scrum Master should be the one running the retrospective session. You don't want to outsource this responsibility to someone else. It's really important for you to understand what is going on in your project. Like I said, the good, the bad, and the ugly. Now, before I wrap up today, I'm just going to talk about some tools that you can use to run your retrospective. Some of my favorite ones include Miro, Confluence, and as well as Go Retro. Thank you so much for joining me, and I hope you learned a lot regarding how to run a project retro. Thanks so much. I will see you soon.