RetroTalks - David Pereira

Watch our RetroTalks to hear more from David Pereira, a Product Leader with 10+ years of experience with Agile teams and Product Management. From his vast experience, we tried to gather the most useful tips, what to avoid, and how to better handle some of the most common challenges retro facilitators encounter.

Transcript

David P: Hello? 

Noa: Hi, David. 

David P: Hi.

Noa: How are you doing? 

David P: Good.

Noa: I'm great, thank you. I see you are starting to join, so we'll give them like one or two minutes if you don't, uh, if you want in the meantime to share a bit about your trip to Brazil, I think we would love to hear that . 

David P: Yeah, it does take it. It was a great trip.

So it started in the northeast of Brazil. I flew from France, so, and Germany, France, France, nos, and then met with my parents and brother there. So we had the relaxing week, uh, week there, visiting different beaches and so on, including driving on the dunes, which was quite fun. Yeah, it was, it was scary. It was.

It was like a paradise. I have never imagined anything like that's like a beach in the middle of the dunes and you drive there, and so it was quite beautiful. 

Noa: Well, I mean, last year I did, for the first time ever, I did like snowboarding. So I'm imagining it's like kinda like a similar feeling, but being inside a car, it has to be strange.

David P: Yeah. I haven't done snowboarding so far, I have thought, but never the, Yeah. I also, I, 

Noa: for years I wanted to ski or snowboard and every year was like, no, it's, and I just thought it was never gonna happen, ever. Uh, and uh, yeah, and I thought that, uh, I, and, but last year finally I had the chance, uh, to do it just a second.

David P: And it was, uh, a fun adventure. Um, but I had to get a guide there to help me because, um, it's quite dangerous to drive along in the dunes cuz I, I had a Jeep Renegade rented mm-hmm . And then, uh, a lot of people were signaling like, ah, be careful, be careful. And then one guy came with a motorcycle and I was a bit scared and then he approached and he said, You can drive there, but you need some help, otherwise you get your car stuck.

So let me help you. I said, Better do that . 

Noa: Cool. Uh, so I think we are ready to, to start. I think we can start. Let me just start. Sure. So I, I prepared very few slides, uh, just to make things a bit, uh, maybe a bit more formal and then we will take it off so that we can see, uh, you, But I guess, uh, just a second.

So I'm gonna share my screen. This one. Great. And slide. Uh, so hi everyone. Thank you for joining us, uh, for our first retro talks. Uh, I'm very happy to have, uh, David Perrera with us, uh, for this one. Uh, what is gonna happen today? Uh, so we're gonna do a quick intro about Go Retro and what we're doing. Then we're gonna get to know, uh, David a tiny bit more.

Uh, and then we're gonna talk, uh, about retros Basical. We will have some time at the end for questions and answers, but if you have anything that comes to mind while we're talking, uh, please feel free to write it down. Uh, already. So a bit about Go Retro. Uh, basically, uh, we are a team of developers. Uh, we share a challenge.

We believe many dev teams, uh, are sharing, right? We always want to deliver more. We, uh, under, under deliver, we over plan, uh, all these things and we definitely wanna continuously improve. Uh, we found that the retrospective, uh, is the most important Scrum ceremony, basically. So we decided to start. So using Go retro, you can run simple, fun, engaging, uh, retrospectives.

You can increase engagement, you can follow up on action items. Uh, we have a full section of data driven, uh, if you'd like to see that as well. Uh, and super excited, uh, to say that coming soon we're going to release something, uh, completely new, uh, which we call currently Sprint Professional, which will allow you, uh, to not just focus on retrospectives, but also manage your sprint, uh, prepare for planning better.

Uh, we'll have a session about that next month. So, uh, stay tuned. So, uh, I had a lot to say about David, but I didn't wanna take all our time and I will let him introduce himself a bit more as well. Uh, but just so you know that David is a product leader with over 10 years of experience with agile teams and product management.

Uh, he's a top writer on mediums, so if you haven't seen any of his blogs or articles yet, definitely uh, go and do that. After, uh, the session, uh, he writes mostly about Scrum and product manage. And he's everywhere else. Right? So you can find him on YouTube podcasts, blogs, and one, Uh, David, would you like to introduce yourself a bit as.

David P: Uh, thank you for the introduction. So I would say I'm a very curious person, so I started my career as a developer and I was super curious, understanding which problems we solve. So I annoyed a lot of people with questions and that's how I got into product management. And since then, It has been a journey.

Different companies, like different business model like b2b, b2c, startups, public companies, and uh, government company, uh, so many, many things. And, uh, ma most of the stories I share are related to something I did incorrectly and I learned, um, how to do it differently. And I share that hoping that people can avoid the traps that I've fallen into.

And that is why I, I love sharing. I'm really passionate about product management. Um, I love solving problems and empowering teams and, and making change. So I think that, Even if you make a change for a small group of people, it's a red significant. So if you make something better, So that's what I strive for.

And currently I am in Germany, so I'm leading a team of product managers at Virtual Identity and soon I'm also starting my own business focused on product management. Amazing. Good luck with that. 

Noa: And if you missed the beginning, he would just got back from a vacation in, uh, Brazil. So also really exciting.

We're gonna try to do a quick poll, uh, just to see if everyone, uh, is with us. So, uh, if you don't mind, uh, go to uh, mani.com. Uh, use this code, uh, and tell us what you need most, uh, in your retrospectives. So we'll give you a minute to do.

By the way, thanks David for, uh, introducing me to this, uh, app. Super cool. I did a lot. 

David P: I use this quite a lot actually. I think that 

Noa: I will start, uh, as well. I've already started and I have a feeling it's not gonna be my last time.

Okay. We're starting to see some data. Ooh, ooh. I love how it looks like. Wow. No one needs fun. That's really, I, I hope this means a good thing.

Okay. Just a bit more, see if you have any other responses.

Okay, So definitely, uh, I think most of people agree that, uh, we need, uh, more engagement, uh, in the meeting. I think it kind of relates to fun, right? If it's fun, people tend to, uh, engage a bit more, Uh, real data. Uh, as I mentioned, this is something we, we also do, uh, and we definitely see that it increases engagement.

People love, uh, to comment about data. They don't always. What the day just says, but it definitely makes them talk about it, uh, and focus. Yeah, this is really hard, uh, to get as well. Um, David, just a few, uh, like a bit of food for thought for you. If you wanna share, like focus your stories a bit on, on these topics.

Uh, thank for participating. I do have one more slide. How do I switch to the next one? Here it is. Uh, and what would you like us to focus on? So it's like a, there's going to be like a workflow, so if you wanna add a bit of input again to help David focus on, uh, his stories and what he should share, because I know he has a lot of stories and not a lot of time to share all of them.

Ooh.

David P: Arguments. 

Noa: Yeah. I love how it's so big here.

David P: Um,

Motivated teams. Stop blaming, make the temp. I guess I have some things to share around this.

Noa: Oh, dominating participants. I like that one.

David P: People don't talk. That happens sometimes when they don't see. 

Noa: Yeah, I, I love that. I see both, uh, things. So once, uh, sometimes people complain about people talking too much and, but also people complain about people not talking at all. Okay. Who? Nothing. Very, very big, but, okay. I, Let's give it a tiny bit more.

Let's see if something else pops. So open to change. Oh, that's a hard one. Tasks for retros. Okay, so I see, I do see some repeating stuff. Uh, action items. Action points. Action. Um, or ideas. Oh, more ideas. Definitely. David has a lot of those. Yeah. Great. One person takes the stage. People don't talk. Creative thinking, ownership, continuous learning.

Cool. Thank you very much for your ideas. Uh, we'll keep that, I will actually take off the sharing so we, we won't see that, uh, because I do want us to focus on, David, if you want me to repeat afterwards a bit of the words, uh, just let me know. Sure. Thank you. Great. Uh, okay, so I think we are ready to get started.

Uh, so I would like to start, I, I thought it was an easy one, but maybe not so much. What is your favorite thing about running retrospectives? 

David P: My favorite thing about retrospectives is about about running them. . Ah, about running them? Yeah. Yeah. When it comes to running retrospective, it. Like creating opportunities to make the team a bit better.

And it is not about, uh, like finding a massive opportunity and then transform the team from whatever they are now to a high performing team. Cuz a lot of people think that there is a shortcut and there's no shortcut. But there is incremental improvements that will lead the team to something great. So I love running retrospective to create hope that the team can become better if they take one step at a time.

Yeah. 

Noa: Well that's, uh, I think it's so important. I think it's really important to, to remind that to the teams as well. Right? Because like you said, people think there's, there are shortcuts. They think, Okay, we did a retrospective, We may created an action item, but we're still. Uh, so much better. So why put the effort into it?

Right? But it's true. It's all about these small incremental changes. That's absolutely good. Uh, is there a different answer for what you love about retrospectives? Uh, because that was a question you thought I asked. May maybe have an interesting 

David P: question. Yeah. What I love about retrospective is like helping the team see themselves as a hero, because connected to what I shared.

It's very easily the teams like without retrospective to few victims of the circumstances, and then they, ah, it is bad. We always receive features to deliver and we have no guidance. And then maybe it, there's some external factors that disturb the team, but they don't act upon it. They just complain. But then you, the retrospective is a.

To see what can we do as a team? We are the hero of our stories, and that is the card we have. What can we do right now to change it? So I think the retrospective has the magic when done right, which is not all the time to change it, to create this, uh, moving from victims to heroes. I feel 

Noa: like I, I want a t-shirt that says, we're the , we're the heroes of our story.

I love that one. Cool. Uh, so, okay, so you touched a bit about this and I think people also mentioned that, uh, in our poll. Um, how do you ensure, uh, that your team's retro is a safe place, right? Not blaming, but actually creating this opportunity to become heroes and improve. 

David P: Yeah, that comes with trust. And trust is built upon vulnerability.

So is a team allowed to fail? Because if it is an environment where the team has no permission to fail, they will not open up. Because then it'll, like, they have a fear of being perceived as weak and they don't want that. But once it, uh, once trust is built, then the team can can grow. So I have been in many scenarios.

I like this scrum master and I was a product owner, a product manager in the setup, and someone had to run their retrospective and the team generally wanted to skip that. But for me it's a very important moment and I believe teams will only see value in retrospective and see this, uh, once it is a safe space.

So I generally started using the retrospective. To expo, to show vulnerabilities, and I would, uh, start complaining about something I did wrong. I would like, uh, say I like one retrospective, which is a metrics, and I put like, how happy you are. So the first one, you are totally unhappy and the neutral, and then, um, you're happy.

So these are the, the three levels. And then I look at people and Interac. Processes and, uh, our quality. So the technology we use and the quality we deliver. And the first day I did that, I put that I was unhappy with someone and someone was me in this case. And I said, I think I misled the team over the last sprint because I did this and this.

And then I said, I'm not very happy with what I did. And this was the opening, the, the open. The team needed to start sharing. And then they felt, yeah, it's a safe room. We can talk. Um, I know that in SCR there is no hierarchy, but teams tend to perceive the product owner as a little bit different because product owner has more access to executives and so on.

But everyone was in the same level. But by being vulnerable than we had a space, uh, that we needed to talk about the right things, talk about our mistakes and say what we could do, Differe. And there's one secret I like doing, I call is the prime directive, all retrospectives. They started the same way. I started by reading that and saying, We are here to learn from each other and do something better next time no matter what happened.

We believe and we trust each other that we have done our best. So here is about learning, not judgment. And just by saying this, it is a moment that you can expose yourself and like it's a reminder that people need in the beginning and it helps them arrive in the retrospective. 

Noa: Yeah, I, I really agree. I sometimes have this feeling that, you know, developers, uh, are maybe a bit more on the cynical side, and if they, they feel like we are talking about this, it's kind of like, you know, they, maybe they don't really, you know, see the point in imagining this, but I, I really agree.

When you hear it and when you hear it over and over again, you know, it, it has the effect on people and it really helps. And I think the, the favorite, uh, my favorite thing that you said is kind of like leading by example, right? You're being vulner. Allows, uh, people, uh, being vulnerable as well. Uh, that's really, really good.

Uh, great. Uh, what will I ask next? Let's see, Well, this one I like. Um, tell us about a retro template that you used. Uh, there was a complete disaster. Uh, and why, If you have something, I, if you don't know David, he has amazing, uh, templates and he does really amazing creative stuff. But do you have one that.

David P: Terrible . Well, I had many, It, uh, didn't go as I expected. Um, I remember once that I wanted to say there was a template to talk about how you felt, what drove you mad, and what we were excited about. This word mad had a super bad connotation. And then the team started discussing about the word, and they forgot about the retrospective.

And they were trying to make up something that drove them mad. And they said, Well, what drove me mad? What? What was it? What was it? And then they start really talking about the word mad, and I just wanted to see something that I could work on and someone remember presented what drove me mad. My code review took two days to, to, for someone to pick it up and give me the result, and then I had really little time to finish.

Then the developer react. Seriously. Did that drive mad? You didn't raise this concern during the daily, or didn't? I didn't think it was such a big deal. So the word mad there was really bad because everything, any, everyone shared. It was challenged by someone else because it, it, it was seen as something super big.

Then I, I stopped using this because it was not what I wanted. I wanted the team just to open up and say, share something that wasn't helpful. Something that, uh, it annoyed them. So I changed this. What annoy. Annoy is, uh, is, uh, lower level than madness because mad they said, Oh, if I'm mad, it means I, I'm really angry.

I, I may want to punch someone . So that was, uh, a disaster because I had to, I, I don't like intervene. Uh, I try like moderating, but in this case, I had to intervene all the time. Saying, Is this discussion helpful to what we want to agree now we want to learn from the others and then we want to come up with actions.

Remember I said, Yeah, but that is that I don't agree that this action would drive key. I disagree with that. So then they were mad during their sprint retrospective . 

Noa: I have to say that I think we also tried that once. Uh, and people also didn't know what to react. How to react to saying what they were mad about.

And I'm pretty sure someone. Said it, that he was mad about the template. Uh, so , I don't know what, why this specific template can get people, uh, upset. Yeah. Cool. Uh, do you have, by the way, like, I don't even have this in my questions, but do you have like a favorite, favorite template or like your go-to template?

David P: Well, it depends. I like alternating, uh, with simple templates. Actually, for me, the retrospective is more like a journey. So I have a kind of recipe. I, I want something to happen during the retrospective. I call, like first it's a prime directive and the prime directive I said that I read, but you need to re to believe in that.

It's not just about reading, it's about engaging people. So I don't read, I, I, I rephrase something that is there with my own words all the time, a bit differently. So that's how I start. And then it needs to have a moment, a kind of ice breaker, uh, then helps the team. Then after you go into the actions that we agreed upon, and then have a discussion like what have we done and what we haven't and why, Uh, and then it goes to the dynamic.

And after the dynamic, I will have like agree on action and then tune out. Like, how are you, how do you leave the meeting? How successful was that? So I alternate different templates for each of them, but to the core part of. I mentioned the one I like the most, it's the metrics because it brings different perspectives.

So this one is when I want to learn about interaction, technology and processes, what is happening? This gives me an idea and I try repeating this, for example, every far sprint because then I can't see if we are moving from like uh, uh, something that we are unhappy with to something that we are satisfied.

Another one I like, uh, a lot is, um, it's a very simple one. It's about discussing, for example, what helped us, what didn't help us, and what could, what could we do differently during the next sprint? So just asking this because it gives some idea. I like also the four Ls. Uh, so the, the, these are the ones that I try doing, but I, the secret for me is don't use the same template twice in a row.

If you do that, people come prepared. Uh, because in the beginning that's what I used to do actually. I had two templates and I was alternating. And sometime I got so into the, the things that I repeated, um, And then people came very prepared. They had everything noted down, uh, and it was mechanical, so it was not really authentic.

They were not saying what was annoying them or what they wanted to share. It was something they prepared. Then when I started changing the template, some people got annoyed with me saying, No, I was prepared for the order. So bring the order back. I don't want this one. Uh, and that's not the goal. You don't want mechanical retrospective.

You want something engaging as people said here. So one of the reasons not have engaging is if you keep repeating the template. Yeah, I 

Noa: definitely agree with that. Uh, but something really interesting that I understand from what what you're saying, uh, is that yeah, the people, they don't see the template.

They don't have a chance to add their input, uh, in. Right. You don't, you don't do that because a lot of times we hear people that they really like, uh, allowing the team to add their input during the sprint already because they worry that if they only add input during the retrospective, they don't remember what happened during the sprint.

Uh, do you have maybe like, uh, a tip to, to kinda like jog their memory? Uh, or, Um, 

David P: well, um, this is something I. I see. For example, many teams think that the only moment they can give feedback is the retrospective, and this is wrong. The retrospective is the room to step back and reflect on the work and see what we can do differently.

And what I encourage teams, like if you need a retrospective to share feedback, then we have a. Why don't you just share when you what happened? Just share with the others. And then the retrospective is something more global. So that is why I don't like sharing beforehand, because then the feedback becomes kind of, uh, only in the retrospective, Oh, we have a room for that.

I say, Wow. The room is more like, how can we get better as a team? But for example, if someone didn't review your code for two, And that is happening on like, let's say on the third day of the retrospect, uh, third day of the sprint. Why don't you just tell the person, put the wait for the end of the sprint to tell that.

So then you're missing opportunities. So that is why I, I encourage the teams and I, whenever I see something happening, people taking notes, I ask them like, Maybe this is something you would like to share with the team. Is it important to the team? So now I'm, I'm thinking about sharing in retrospective.

Well, we have time now. Sure. Maybe it helps us right now to make a change. And then I got got surprised because then after you do this, people start sharing more often. And in the retrospective they use us really the moment to step back and reflect. Got, 

Noa: uh, that's super interesting. I really, uh, like the fact that, um, it really reminds me of what you said about, uh, that the guy didn't think it got to the other guy mad.

Right? Cause he didn't say anything about it. Right. He waited until the, the retrospective, right. Uh, cool. Uh, something that we hear a lot. So of course, action items, getting action items and acting upon them. Super important, uh, uh, for retrospective, right? But we hear that a lot of people are really struggling with actually taking them, uh, and doing something with them.

Uh, any tips you can share to help with that? 

David P: Yes, sure. First, Make the make the action item as is small as possible. Don't, and don't, and make the action item actionable. You need to be able to see if that is achievable or not. Because I see many action items as attitudes. For example, whenever a stakeholder comes to us, we will challenge this stakeholder if the request is unrelated to our sprint. 

So this is a whenever attitude. So this is an attitude. The action would be, um, for example, we will give feedback to the stakeholders and inform them that requests during the sprint should be related to the sprint, if they want us to, uh, to get that done, for example, during the sprint. So the stakeholder will receive feedback and then an action for me that is valuable is very clearly defined.

It's. We'll do what by when? So by when can be the end of the sprint. And who is generally a person? So I like already assigning accountability during the, this sprint, uh, retrospective. And what you're gonna do should be clear. So you will provide written feedback to the stakeholder, or you'll make an agreement.

Something like this and the whole there. If the person wants to delegate, it's, it's fine, but you are accountable for that happening. So I make it clear and the next time what, what I do, if the actions, the very first thing and the introspective after the ice break is looking into the actions and navigating.

And what I will do, I will ask the person who is accountable, what happened. I didn't get done, said, but you committed to the team that you would be, would make it happen. Do you think it's fair to commit to something and not do so? I, I try. I tried bringing this respect. And then the person would say, Well, yeah, I didn't get to my attention and so on.

So then I said, Okay, didn't get your attention. So maybe what you can do next time is to create an item in the backlog and put in the print and assign to you. Then it'll be visible on, on the board. Because many people think that the board is only about features. No, it's about what the team has to do or the team.

So make Actionables clear, uh, uh, make actions actionable and make maximum three. And they can be small, they can be steps towards what you want to do. For example, you can say like, um, we have a problem with our, uh, release. The release happens only once, uh, every three months. So, and you say, I want to have release every day, so you cannot get to a release every.

From, from three months through every day, then you can say, We want to have an, what is this step to get you closer. Define one single step during the retrospective, and I give the team proper time for that. The action is not something you come up with in five minutes. I give at least 20 minutes for the team to discuss and come up with a max, a max of three actions, Not more than that.

If you come with modern, you need to prioritize because when I see teams commuting to more than three actions, generally, funny enough, none of them happens because they start talking and then they don't do anything. But when they commit to maybe two or three, they get all. So it's about small steps helping the team get where they want.

Right. 

Noa: I I, I totally agree with this. I think a lot of teams try to cover. All of the, uh, cards, you know, people read and try to talk about everything, and definitely you can't, uh, you can't do all of them. It's really important to focus. And I think one of, uh, something important people mentioned that they want more of in their retros is focus.

So this is one really good way to do that. Do you ever follow up during the sprint on action items or you say they are owning it and we'll see, uh, at the next stretch, or what 

David P: happened? It depends on the scenario of the team. If I see the team is not doing anything regarding the action, I will make it clear.

Um, I will make, uh, clear in the daily. I will say, I haven't heard anything about the action items. Is there anything I could do to help Or if I committed to something, because many times as a product person, I commit to the action item and then I try making that, uh, done as soon as possible. And then during the daily, I share with the.

And then I just say, I'm curious about the other ones, what's happening? Yeah. Yeah. So I, I think it's important to keep them alive and take them seriously generally with, uh, let's say a less senior team putting this, uh, the sprint backlog, cuz then they will see that, uh, that there is something to act upon.

Noa: Great. Uh, just a reminder for everyone listening to us, Uh, there are no questions yet. Uh, we have like about 10 more minutes, so, uh, we'll, I'll continue asking questions. If you don't have any questions, don't worry about it. Uh, but if there's something I'm not talking about and you want to ask David, uh, then let me know.

Uh, I think, you know what, let's jump a bit back to the, uh, word cloud. So I saw, uh, a bunch of stuff other than action items, uh, about blame. Uh, anything you wanna mention about that, because I did hear you. I wouldn't say blaming, but you know, when people are not following up on direction items, there is a tiny bit of, uh, maybe, maybe blame.

Uh, how do you avoid, uh, 

David P: getting there? So blame can happen in two situations. One that is super bad is when it is blaming our current problems, uh, blaming the outside world, uh, about the, the problems we have, right? So this, you need to move on. Like we cannot do anything about it to what could we do to influence them?

Of example is our roadmaps are only related to features. We only have features to deliver and we don't know which problem we're solving. So which action could you do as the product team or scrum? You can make it clear that delivering feature without knowing the problem, you may end up solving the wrong problem and creating another, and then you ask the business, is that what you want?

Do you want us to invest in things that are uncertain or would you like us to achieve goals? We have better ways of working. So the influence would be providing feedback and giving them an, another alternative in the end of the day would be their, uh, the management decision. But, uh, you are at least trying something.

So instead of blaming them, agree on how you tried to influence. So this is one type of the blaming outside road, but it can happen inside the. So one example, very classic. It is about designers and developers. So the designers say, Developers keep cutting corners. And what I designed is not what was produced.

And then developers will say, Designers keep making it more complicated. I don't understand why two picks will ever make a difference. So how do you solve this puzzle? You need to tell them neither one nor the. Is right or wrong, Let's step back and understand what do we want to achieve? And then you have an argument, Mo, you need to move from opinions to evidence saying like how what you were saying contributes to achieve the goal we want.

And then the developer can say, We have a deadline to deliver in two weeks, so we need to fit the design for two weeks, for example, and then we can achieve this, and then a designer can say, Okay, why do we have this deadline? Then I want to challenge the deadline. If you want to deliver a valuable experience, we should have more time because otherwise we don't get to this.

The users will get confused. Then you can have a conversation based on how to achieve something, instead of saying, Oh, you make my life. So you need to understand what is the conflict. The developer maybe feel pressured because I need to deliver something in two weeks, and the designer feels pressured because needs to ensure the user experience is right, but none of them are talking about actually the real problem.

So I think it is moving from opinions to evidence and facts. So this is one thing, and then someone needs to, uh, to, uh, to moderate this conversation and trying to bring the conflict to the table and solve the conflict. It is about situation, It's not about, um, uh, it, you need to move from personal attacks because that can happen quite easily to a situation that.

And try to move to a feedback that is situation, feeling and then consequence. So I, I try saying like this, I rephrase to help the, uh, I, I've seen this discussion all the time, and then I say, Okay, let me rephrase. What you are saying is when the develop, when the you, uh, uh, UI designer rejected your application for the third time, You went mad because you thought it was unfair and you didn't understand why it would have helped you having a conversation in the beginning to understand.

Is that correct? So I try rephrasing and then having a better conversation, but you need to move away from personal attacks, uh, to the situation. So that's what I, I tried doing. It's not easy. I need someone experience in the room. If you have an experience Chrome master to, and then think, what are we gonna do different from now?

Yeah, I 

Noa: agree. I think, by the way, I love this technique. Uh, if, I don't know if anyone here saw, uh, couple's therapy, uh, the, the TV show, uh, it's amazing and I've learned a lot of, uh, these really great techniques from there. It works really well. , uh, great. Uh, so we didn't talk enough, I think, about, uh, some mistakes or failures.

What is your favorite mistake, uh, that you've done? With retrospective, 

David P: I think the favorite mistake is trying to make the retrospective shorter, so try making. So fast that then you don't really have the time to talk about things. So you say, Okay, let's get to the point. Let's take the dynamic and phone.

Let's keep the prime directive. Let's not, uh, have an ice breaker. And then start thinking, why do we need an ice breaker? We work together, we know each other. Let's just go to what worked well, what didn't work, what can we do differently? And then agree on actions. So why is this? This is bad because imagine the fall people are just working on many things and they might be super stressed.

So you have just finished your sprint and so on, and then you rush. That is your attitude. You rush the retrospective because you are saying the retrospective is not that relevant. So the sign you send to the team is, It is not allowed to step back and reflect on what you could do better. So we are just squeezing in something here, but it's not that important.

The most important is to keep shipping features at the speed of light. So all time you have focus on that retrospective here is just like 50 minutes every second week. So this will have this, the negative effect. Then people will start saying, Ah, let's escape. Why do we need this? So I tend to say a minimum you should invest in retrospective is one and a half hour for a two sprint, a two week sprint.

And it's non-negotiable. You don't skip that, but you do it right, And ideally you live two hours because then you can have some time to have to go deep into the discussion. Because if you keep on the very superficial level, then you don't find the the problem. So this is what, uh, I recommend people not doing.

It's a classic mistake. Rushing with retrospective, we will have a si uh, a negative effect. Yeah, 

Noa: I definitely agree. Just yesterday I talked to someone, uh, and she said, Yeah, we're we, we didn't do the icebreakers because we don't have time. I didn't wanna waste time on that. Uh, and then I asked her, How long is the meeting?

And she said, Two hours. I was like, We really, So you don't have time? I was like, No, actually, uh, the retrospective is just 30 minutes out of a two hour. Uh, they were doing, and I felt like, yeah, so this is like really missing the point. You really need to put, you know, uh, put the time and the effort and the, the spotlight on the retrospective, right?

It's really, really important. 

David P: And then generally when I see the situation, I ask what happens if we don't invest proper time? Probably the team will fall into a vicious circle. So they think it is, they are not allowed to make themselves better. They, they're just not. Then what they have in their hearts that is hurting them, they will not share with anyone.

And within time, the team will deteriorate. So instead of becoming a high performing team, they will become a low performing team. And that's because you decided not to invest one more hour into a valuable thing, then this one hour per sprint we start costing you probably in terms of performance, days of performance.

So that is the negative effect. Yeah, 

Noa: definitely. And I think that today is even, uh, could be even worse because it's not just becoming a lower performing team. But today, uh, I don't know, like at least uh, here in Israel, uh, develop. Always get so many, uh, you know, like job offerings. People when they're just a tiny bit unhappy or just think that there might be something better out there, they don't hesitate, right?

They, they, they move. If they're not happy, they move. And it's super important that developers today feel. Good about what they're doing. Right. About their environment, about what the process is. And if they're not improving, if they're feeling low, if the the processor are not working for them, you know, they're, they're, you're just gonna lose them.

And then of course you're gonna have even lower performance when you're missing team 

David P: members. Yes. Yeah. Of, I fully agree with you. But the effect is not only in a performance is on the morale, so the morale of the team goes down. Because many people think, uh, like, uh, employees leave their jobs because they are underpaid and they get a higher paid job.

Well, that is, uh, is one of the aspects, but they leave because they are underappreciated. If you don't feel appreciated and retrospective is a moment that your opinion can count, once you bring something up and you act upon it, you can see how that changes your team. So it's one of the ways of appreciating, and if you cut this, then.

It did start hurting, you know, as I said, developers receive offers. So that is a, uh, just, uh, let's say fee feeding their motivation to accept, uh, another place. Exactly, 

Noa: exactly. So we just have a few last minutes, so I wanna stop with my questions and ask you if there's anything, uh, that you wanted to, to raise or talk about that we haven't done so far.

Maybe share a story that you wanted to. 

David P: Well, I have a lot of stories to share. Um, 

Noa: we might have to invite you again, David . 

David P: Yeah, it's fine. One thing that, uh, people raise in the beginning, they're the ones taking over all the space and talking a lot and the ones not talking. Yeah. So you can time box. That is one thing you can do.

And it goes really with team seniority because like the, the longer the team works together. The more they will connect and help each other talk, but in the beginning, if they are not used to that, it can happen like this. So what I try doing when people are sharing, I limit. I say, you have three minutes, you share and then everyone will need will have the same speaking time, three minutes.

And then when we are talking about actions, that is more spontaneous. And what I try doing is observing who is not. And what you can try doing, you can make something on your team and understand where is the power center and where are the influencers and where are the outsiders. So just draw three circles and then new position.

Generally on the, uh, the power center, you have choose three people. Maximum generally is around true. And then the influencers are the ones who are like, more people trust them, but they don't talk. Then you have the outsiders always quiet, but doesn't mean their opinions, uh, don't matter. They're just quiet.

So what I try doing is giving them some air time. When I see they are quiet and people are disgusting about action, name it. You say, Hey, I noticed you are quite silent, but I'm curious to hear your perspective because I value our opinion. So what do you think about it? And then this person will come to the.

And what you are doing by, uh, with that, you're showing the team that you care about the other with silent. So then the others, you start gaining more air time and then you ensure that the, the one who's talking too much will reduce. So keep doing this. When you see someone talking a lot and say, Ah, you shared your opinion, you made a strong.

But let's listen to the other. Let's listen to the ones that are, that are quiet because we are a team. We want to, to listen to everyone and make the best decision for us. So try doing this. Uh, you need to moderate, you need to interrupt people. At some point in time, you see that someone doesn't stop talking.

Then you need to go there and intervene. It's not easy, but I think it is very helpful for the team in the median long run. The effect on the short run is it's very little, but in the median long run, the team starts self-managing, self-organizing cuz the beauty will happen when the team starts saying, Ah, you are silent.

I'm not, uh, curing your voice. Can you share with me? And then you start being more like, uh, quiet. If you are this scrum master in this case, and then you participate less, then it means that your team is growing. 

Noa: More quiet but more proud. Right. I just imagine you said Yeah. Yeah. Feeling like, oh, the babies are all grown up now.

David P: Exactly. 

Noa: Amazing. Uh, great. Uh, so we were running out of time, so I wanna make sure I have enough time to say thank you very much, David. Uh, for joining us today. Uh, I thought it was super, super interesting. Uh, like I said, we might have to, uh, invite you, uh, once again because I do know you have a lot of other stories to share.

Uh, thank you everyone for joining us. Uh, as well, this will be uploaded, uh, to our channel as well, so you'll have a chance to to re-watch it. And anyone that didn't, uh, have a chance to join us today will be able to see that as well. Uh, so have a great day everyone. And you too, David. Uh, thank you very much.

Thank 

David P: Bye bye. Thank you everyone, and then just connect with me on LinkedIn and we can change. If you have any questions, just drop me a message and we can talk. Amazing. Thank 

Noa: you very much. 

David P: Bye bye. Thank you. Bye-bye.