So welcome all of you. Uh Welcome to this session. Um And thank you for joining. I hope you have your favorite beverage in hand and I hope you take notes from the session because we're gonna talk about something that's relevant um in the life of product managers.Um So, hello, I am Kate KV. I am an A I product manager at Oracle and I recently moved from India to the US to transition from an engineering lead uh to a product manager role. And along the way, not only did I experience a culture shock, but I also experienced a role shock since my role changed, I started hearing a lot of this. Hey KK, that is not my job. Sorry, that is your problem. This is not my job and I was confused. At first I was completely lost, but it took me some time to understand that everything that wasn't a part of the job description of my teammates and my stakeholders was by default, a part of my job description. We welcome to the life of a product manager. I'm sure all of you can relate. So if I were to describe my role as a product manager in a Venn diagram, this is what it would look like. So there is tech, there is design and there is business and our roles as product managers sits at the intersection of these three. But mind you, this also constitutes the many not my job tasks which lie there. And that is why product management is hard.

You are juggling with so many different tasks, you need constant feedback to function. Well, you need to keep your team motivated to work on a common goal and it can get to you. But when, when you become good at running efficient retrospectives, when you can use retrospective as a tool to solicit feedback from your team and understand where they need your help, then that is gonna make you good at your job, that is gonna make you a good product manager.

So by the end of this session, you will walk away with strategies to run retrospectives the right way and let's talk about where retrospectives came from. So if you don't know what the retrospective practices, we'll start with that. So the retrospective practice comes from the agile methodology, which is a software development framework that is going to help you to deliver value to the customer faster because you release the software in multiple increments. So the principle of agile is simple, you release the software in small but independently consumable increments and this helps you to respond to change quickly. Let's now talk about what retrospective meetings are. So if you've, if you've not already practiced this in, in your uh teams, you can take this back and try this out. It is a meeting. Retrospective meeting is an opportunity for the teams to reflect on what they've done in the past and then work together to identify ways to improve in the future. So uh it's not necessary for you to be agile in order to follow retrospective, you can follow retrospective however you want. And in this session, we'll talk about a few strategies to make that happen. So let's talk about the format of retrospectives.

The first thing is if I were to summarize retrospectives in a single line, it would be looking back to look ahead. And when you, when I say look back, you look back at a specific time period in some companies. This is about two, this in some companies, this is about two weeks in some companies. This is about a month, but it can totally depend upon you what the time frame is. So you look back at a particular time period, which is when you're working on your delivery bills and then you reflect on it to understand how you can do better looking ahead and the duration of retrospective meetings, which is about five minutes per team member. So depending on the number of team members you have, it's 30 minutes to one hour. And this is my favorite rule of retrospective, which is there's no managers allowed inside the retrospective room. So this makes retrospective a safe space for you to share whatever you feel about the past increment, you can share about your team processes. You can talk about your team deliverables, you can talk about your team members and you can understand how everyone can improve in working together on a common goal.

So when there are no managers, you can be authentic, you can share whatever you want without the fear of it affecting your appraisal or bonus. And talking about the cadence, as I said, you don't have to be agile to follow retrospectives. So if you're agile retrospective is conducted every sprint, you just typically a period of two weeks and it's also called a nitration. So you can do it every two weeks. But if you're non agile, then you can do the retrospective at the end of a project, you can do it at the end of a month. So it's completely on you to decide the next day is in this session, we're gonna talk about three different phases of retrospective and that is how we learn the art of running the right retrospectives. So the first thing is what do we do before the retrospective, what do we do during the retrospective? And then what do you do after the retrospective to gain the maximum value out of it? Now, there are multiple books that have been written on this but I'll give you the gist in this session. So you can have a starting point to understand how to conduct retrospectives and how can you use it as a tool to gain feedback from your team.

So before the retrospective, you need two things, one is you need to work on a working agreement and you need the relevant data that has to be gathered so that your team is on the same page. So let's talk about each of these in detail. Let's talk about working agreement. So working agreement essentially gives you the ground rules for uh holding your team members accountable. So let's say now uh in our uh in the current era, we work with global teams, we are mostly working remotely. So our team members are spread across the world and it's important that everyone agrees on a certain set of rules so that you have an arrangement of working together efficiently. So working agreement is uh it's not one time thing. You, you start with a certain set of rules and as new team members get added or as you start facing challenges with the team, you can improve the working agreement. So it's a living document of a certain set of rules. And on the screen, I've shown you a sample, it does not need to have five points. It it is completely your team's decision. But let me give you an example to make things clear. So in my case, I work with people from the east coast. Iw, I'm in the west coast. I'm in California, but I work with people in the east coast. I work with people in India and Australia as well. So some of my meetings, they start as early as 5 30 am my time.

So when I wake up at 5 30 I'm, uh my voice hasn't cracked and I'm still cranky and I'm trying to attend a meeting. All I want is for the meeting to start and end on time. And let's say for some reason, if one of my team members does not attend the meeting on time or causes delays, then it's only gonna make me more irritated and I cannot function well. So rather than having an awkward conversation with the team member where I say, why, why were you late and them giving me excuses, what I could do is simply point them back to the working agreement where we, where we all discussed that we would join meetings on time in order to respect each other's schedule.

So there are rules like these where you can jot down whatever you want, your team members to uh follow and then you can hold them accountable on it. And this has to be reviewed before the retrospective. The next is gathering relevant data. So what happens is every time, let's say you're having a retrospective every two weeks. And uh when you're having retrospective, it's possible that different people have different perceptions of the events that have happened in the past. So maybe there was a deliverable that was not uh that was not completed on time and maybe different people have different opinions on it. But when you gather relevant data about everything that happened in the past two weeks, it's not, it's, it's easy for everyone to be on the same page. And it's, it's also going to help you to reduce conflicts in the team. So you can gather uh data on metrics. Metrics can involve team velocity, the number of deliverables completed the total number of leaves taken by the by the team members. Then it can be event related where uh you can maybe celebrate the accomplishments of your team members. You can celebrate the promotions of your team members and you can help them feel motivated.

And then you can also collect data related to artifact where there's a sprint report that you might want to review or you might want to uh look at the team calendar and see what could be done better. So there are these are just some examples of the kind of data that you can gather. But uh the person who drives the retrospective, which can be any person in the team, the person who drives the retrospective has to collect all of this relevant data. So that better decisions can be taken during the retrospective. So now that we've talked about what we do before the retrospective. Let's understand what happens during the retrospective. So let's talk about the format of the retrospective. Retrospective essentially involves answering three important questions.

So you go around the table and every team member answers these three questions. What went well, what went wrong? What could be improved? And it's as simple as that, you give 2 to 3 points in each of these, but you do have to give it some thought, which is where the relevant data that you gather helps you to understand. OK, this is where I think things could have been improved. OK? I think this is where we we've done well, this is where we could have done better. And so that relevant data serves as a foundation of your opinion and your points for the retrospective. Now, the important thing to note is we have different kinds of team members um in the team and uh people have different personalities, they have the different, they have different ways of interacting with each other. And when it comes to retrospective, you'll find two kinds of people.

The first is this kind and they'll be overexcited and overenthusiastic about sharing those points. Now, fortunately, or unfortunately, I used to be this person in the team and I eventually understood how that irritated the other team members because I would come with my research and I would have 10 to 15 points to add and then others would not feel as comfortable or included in the conversation because I would steal the spotlight.

And so there are some people who would be very enthusiastic to share those points, but there would also be people who are like this. No, I'm too shy. Go on without me. Do I really have to do this? And, and you'll find that, um, these people are correct in the way that they're coming from because they might not be feeling comfortable to share those points or they might feel that their opinions are not valued. So the art of running an inclusive retrospective is where you can cater to both kinds of these personalities and you can make everyone feel included so that they can share their points without hesitation. So we're going to discuss about how we can make retrospectives more inclusive to every team member. And for that, we need to remember a golden rule of retrospective which is what happens in the retrospective stays in the retrospective. So when, when you lead with this mindset, everyone can share whatever they're comfortable with. And when people talk about what went wrong, it's possible that people will share certain points that are very, very well, they might be vulnerable in doing so they might be very sensitive in doing so.

So whatever happens in the retrospective, you do understand the takeaways from it, but it stays in the retrospective. You don't gossip about it, you don't talk about it beyond that room. That's an important rule to remember. And Now, let's talk about how to run the retrospective.

So as I said, there can be different team members. Um It can be a round robin fashion where every time a different team member is responsible for running the retrospective, but that's again your team decision. So the first thing is choosing the right time. Now, when there are people working across multiple time zones, it's very important that you are being inclusive in the way that this retrospective is scheduled. Because if it's immediately after lunch or if it's immediately after someone is woken up, it's very difficult for them to participate actively in the retrospective discussion. So schedule the meeting at a time where everyone will feel active and that might need some research, but it's on the person who runs the retrospective. The next thing is when you review the data, do share a few takeaways from the data. So everyone can understand what to focus on. What are the issues of the last uh last two weeks. And what can they do better? The next day we talk about the responsibilities. So the responsibilities for organizing and taking notes during the retrospective, which is a very important part again, that can be done in a round robin fashion so that everyone gets a chance to experience different parts of the retrospective.

And this is um something which is very important, which is a, which is a very big myth about retrospective as well. When you talk about when you share points about what went wrong, what went well, what can be improved. You have to understand that it's not just related to work, but it's also related to your team. So things like Bob was rude to me counts. Now you don't phrase it in the same words, but you say something like this team member said this in a way that didn't feel that, that, that didn't make me feel very included or that didn't make me feel very respectable. And so you can find a way in order to communicate well with your teammates. And you can also point uh point at certain situations or certain incidents where it it might have been, it might have impaired your efficiency of working well. So anything that directly connects to your ability to work well with the team ability to work with your team members has to be highlighted in the retrospective. So it's not just about the processes, it's not just about the technical stuff, but it's also about the people part of the retrospective, right?

So you, you can get all of these things, you can get all of these points in the retrospective room and you can discuss and sort it out. So this is a retrospective discussion sample just to give you a better idea of where we're headed, what a retrospective can look like. This is just one particular point. So we discussed what went well. So in this case, this team has talked about task estimation, being accurate and what went wrong. They've talked about the daily status meeting taking more than 30 minutes, which is causing disruption for some attendees. And then they've talked about what could be improved where they're trying to maintain this meeting below 25 minutes and any detailed discussions will be done offline. So you can see there is a problem and there's a solution that the team has figured out together. So now let's talk about what happens after the retrospective. After the retrospective, the output will be, you'll have meeting notes, you'll have action plan. Now, action plan is the biggest takeaway of the retrospective. And if you don't work on the action plan is the the entire retrospective is not going to give you as much value as you would expect. So how do you draft an effective action plan? That's simple to follow.

The first thing is define action items as specifically as possible. So let's say there's a meeting that's running late every day. Now you're going to time box. Uh So this is a sample that you see on the screen. Let's say there's a, there's a daily status meeting where everyone talks about the work that they've done. So uh rather than writing shorter status meetings with shorter daily work updates, which is a very vague statement, you make it specific where you say I'm gonna time box, two minutes per team member when they share their work updates and then I'm going to review after a month so that we can understand if we were accountable for this goal.

So this is where you can make the action plan as specific as possible. You can define the task completion criteria and you can add follow up checkpoints. So the important thing is to focus on the action, not the goal. So the goal is the solution that you want, but you also have to focus on the action that gets you there and make the action very specific add, follow up checkpoints so that your team is accountable. And it's also important that after the retrospective, you choose the top 2 to 3 action items. Now, after the retrospective, you might have 15 action items, but you can choose the top 2 to 3 action items so that uh you know that the team will be able to follow this because the team has other deliverables to work on. They have other priorities and they can hardly address just one or two. So prioritize the action items and choose the top two action items that you can, you can work on. Make sure the task completion, task completion criteria has been defined well, and that serves as an input for the next ration or for the next project that you do.

So before you plan the next project, before you plan your next print, your retrospective action items have to be incorporated and you can even adjust your working agreement if it's needed. So after you've done all of this, after you worked on before the retrospective part, where you gather relevant data and then during the retrospective, you try to make the discussion inclusive, you try to draft specific action items. And after the retrospective, you have a set of top 2 to 3 action items that you can follow, you will be able to produce a high performing team. You'll be able to build a high performing team because everyone will have a space to share and solicit feedback. So after you've done this, uh this is what your team is gonna look like and this always cracks me up because uh this is the sign of a happy team, which will happen when you start having very good retrospectives. So I know that I shared a lot about retrospectives today, but just to bring you back to the point in hand, which is what are retrospectives, we are looking back to look forward, what happens in the retrospective stays in the retros. So if there's one thing that I want you to take away from today's session, it's this uh don't play the blame game, uh ensure that you're being as inclusive as possible and you can add more of what do you think um phrases to make it inclusive and then you don't have to do it all.

You choose just the top 2 to 2 to 3 action items and it's important that the retrospective is done before the next sprint or project planning. Uh So that was, that brings me to the end of this session. Um You can introspect my session and let me know how you like it, what you would take back from the session and implement in your teams. And this is a QR code that you can scan to connect with me. It's um I would be happy to answer any questions that you might have related to retrospective um or product management in general. Uh Thank you so much. If there are any questions at this point, um I'll be ready to take it. Let me stop shouting. OK. So I do have a minute. Um So I'll uh take one question which is from Anna, how can we implement an action plan? When in each sprint, we may have different developers participating as we have a dynamic, the organization. Um So I know I would think um even if there are different developers and different um product managers being involved in a project, the action plan does not depend on the members at hand. It depends on what, what is the goal. So if there's a problem that the team is facing, you draft the solution together and you figure out what is the action plan that we can uh have to, to make this efficient, what is the action plan that we can have to solve this problem?

And then in that case, even if there are different developers, they'll know that this is something which is a part of the project's working agreement and they'll be able to cooper well. So hopefully that answers your question and uh I'll now have to end the session. Uh But thank you so much everyone for joining. I hope you got something after the session. Thank you.