Welcome, welcome! This is the third episode of The Agile Audit: Real-life Strategies for Career Success – a podcast where I’m interviewing Agile professionals working with teams about their real-life challenges and professional stories that led them to where they are now. It’s about bringing listeners into the real world of Agile implementations through the lens of people working with teams day-to-day.
Scrum Master and Product Owner are supposed to work together as a team to really achieve success.
However, what if you and your Product Owner are constantly at odds with each other?
What if they have managerial power to make decisions that you know will drive the Scrum team to failure in the long term?
This is a situation that many of us can find ourselves in if we didn’t set up the right expectations with our Product Owner and management.
In this episode, I’m talking with Giulio about how to create collaborative relationships with your Product Owner in challenging situations, and what changes you can implement in the way the team works to reduce stress and pressure while increasing their ability to deliver.
Giulio has been a Scrum Master since 2019 when he transitioned from the Project Manager role.
What he really likes about the job is that every day is different and he can help the team to have significant improvements in the way they work.
Giulio grew up and lives in the beautiful Lake Como area in Italy, with his wife and two cats.
Let’s hear more of his Scrum Master stories.
In this discussion, we covered a lot of topics:
- Helping the Product Owner to play the role of a Product Owner, working with stakeholders, and prioritizing the backlog.
- Using estimations, velocity, and capacity to plan Sprints.
- How to plan for unplanned work, such as new support tickets during the Sprint.
- Teaching management their role in an Agile transformation.
- Fixing SAFe (not really, we talked about Sprint Reviews :)).
- Engaging quiet people to talk in retrospectives.
Transcript
Please note that the transcripts are generated by AI, so it may have some small errors here and there. Daria: Hi Giulio. It is really nice of being able to speak with you today. Thank you for joining in and I know you are bringing some good questions for me. So let’s jump right in. Hi
Giulio: Daria, nice to see you and nice to be here with you. Actually, I’m working with two teams in the same General release train that are completely different from each ones.
One is more mature and the team composition is defined by people that are working together for from a long time. And the other one is a quite new team dedicating themselves. Health mostly to support request, but on the other side, they are working also on some delivery of new features to stakeholders.
Product Owner overcommitting every Sprint Planning
Yeah, I’m trying to work with the PO according to the story points that we are delivering every sprint, but it seems like he doesn’t work to rely on velocity when it comes to plan the work ahead for the next sprint in terms of. Sprint planning because he’s over committing every time 20 story point as the velocity we are actually having.
He is committing 40 story points because the team has two different
Daria: different types of work, you mean? Or?
Giulio: Yeah, it’s like one is working on database and some of them are working on application. Okay. So he’s trying to balancing the work between the different team members in order to have every one of them covered by work for the next.
Sprint, but this is causing every sprint, having the team overloaded with the things to be done, and a lot of carryovers, every sprint. And I keep teaching him on how to rely on velocity as a number to focus on when planning according to the capacity of the team, but he’s not following me. And every time he feels undertaking to.
So, mm-hmm. He wants to over
Daria: commit. Like what, what to do here. Well, I have a couple of things that immediately kind of popped into my head. First thing I think what struck me that you were, when you were saying it, the product owner commits to the story points. So is it the product owner who decides how much work is actually being taken into the sprint?
Yes, exactly. Yes. Okay. So this is the, your main problem actually, because the product order only decides the order. Like, what are we doing exactly? The order of the items in your product backlog but not how much work is going to go into the sprint because it’s not the product owner who is doing the job.
So the only people who can say how much work is they’re able to take into the sprint are the developers background
Giulio: of the situation, is that the product owner is also a developer and he’s working actively on the sprint backlog. I teach the, the team that they are responsible to pick stories on the sprint planning in order to have the sprint backlog decided altogether.
But they are relying too much on the product owner because they on, on the po. Yes, exactly. Because they were working until three months ago and I joined this team two months ago. They were working waterfall from 15 years. Let’s say they had centralized person that looking at the work to be done and assign it back to the developers.
So they are not feeling responsible for their work. So they are waiting for the product owners to give them the job to be done and then doing in the
Daria: sprint. Okay? So we need to work more on them. Team’s responsibility and obviously the fact that the product owner makes the decisions doesn’t help. Mm-hmm.
So in this case, I think you actually still need to work with him and more kind of on the leadership side of things. He is a developer. How much time realistically, he’s dedicated. 80%
Giulio: of his time doing dev work and 20% product owners. And in the last two weeks the situation is that he’s dedicating himself a hundred percent of his time on dev work and 0%
Daria: of product ownership.
Wow. Yeah. Well that’s because he is overcommitting, that’s the problem is there, okay. Well, a few things. I guess maybe going back to the basics, first of all, to, I don’t know if you did like a training for them to explain, because as you say, Until three months ago, they were working in a completely different way of working, right?
Yes. They were working like in a waterfall. What kind of training did they have previously? Did they have any training on Scrum? What it is and like the roles and responsibilities?
Giulio: Actually. I don’t know because this was a company decision. They want to mm-hmm. The old company, they want for the Italian division of this company to use safe for their teams.
So before I joined, they had training on Safe and after then that they had the green lights to go using Scrum as a tool for them. Yeah. But yeah, I, I haven’t invested much time on training on Scrum because you know, I have another team that I have to take care of. And on the other hand, I can see that things are going not that well, but at least the role is things are going on.
Yeah, but I haven’t invested much time on proper training on Scrum, and I
Daria: think you don’t have to do like a big training, classroom training or anything like that. But I think it’s good to maybe go back to the roles and responsibilities. Mm-hmm. To kind of iterate what it means to be part of a Scrum team.
What, what the role of the product owner is. But then the fact that the developers are actually responsible for their work, they’re responsible for estimating the work and taking, like deciding how much work they can take into the sprint. Some kind of like the training session in this case I think would be helpful, like a workshop type of thing, more focused on the roles and responsibilities.
But then you do need to work with that product owner.
Giulio: And do you think everyone has to be involved?
Daria: Well, the whole team, yeah. Okay. Definitely. Yeah. The whole team, everyone should be there. Like the product owner and the developers obviously, and the product owner. You do need to work with the product owner.
Maybe you can start collecting some metrics to kind of show him what the problem is because, The real problem is that the amount of time, as you say, he is spending more and more time on development work instead of being a product owner, but he has a full-time product owner role that needs to be fulfilled somehow.
Right? That has not been fulfilled. And then talk about the history of non-delivery, let’s say. Right? Hey, here’s realistically what has happened, right? What has been. Completed and what we thought we could complete and what we, we realistically completed. So why are we trying to add more and more if historically we can see it’s not working?
Like tell me the definition of insanity. And so kind of going back to maybe a bit of that numbers, I
Giulio: pick up the numbers every time we have sprint planning and I show in front of the team okay guys, we are trying to, committing to deliver. Yeah. 50 story points, but now numbers in Jira reports shows us that we have delivered not much than 24 story points.
Why are we doing that? We haven’t planned the work for everyone in the team, so he’s trying to figure out that everyone’s has something to do. But what happens mm-hmm. Every sprint is that the incoming work that we haven’t planned for support to other teams fill the space of the other deaths.
So the desks Okay. Okay. Okay. Yeah. The day after the sprint planning have a lot of things to be done because they have to mm-hmm. Give support to other teams. And I’ve also spoken to management here to let them know that this is the situation we are over committing. We are going also through PI planning process Every quarter we are committing mm-hmm.
To delivery of some features or aps considering that the product owner is not working a hundred percent and we are overcommitting, we cannot stick to the PI planning plan that we had on a quarterly level. But the answers that I got from management are always evasive. They say we know the situation about this team.
We are considering a new evaluation on the people they are, that are working on the team. And that’s it. Okay. So I know for sure that having a new person, having the role of the product owner in the team could be helpful because at least I have someone to rely on as a product owner because the actual product owner do.
A very important job from the dev point of view that it’s really important for the company and I’d like for him to be dedicated to that job in instead of doing the product owner. But if from the company, I don’t get any information that something will change sooner or later I have to stick to, to this situation.
But trying to let him understand that over committee is not the solution there because he got a lot of input from management, the product owner. Yeah. He feels so responsible for the work that he’s doing, that he has to say yes to everything. The stakeholder come from outside says this of work you have to complete.
Okay, yes, I do it. Mm-hmm. Yeah. And this is the root cause of the problem, in my opinion. Yeah. And on the other hand, as you said, having a reflection on team responsibilities can help me on the other team members to say, okay, on the sprint planning, okay guys, but we are over committing, so we have to plan less in order to deliver something next sprint.
Daria: Well, I think you need to work much more with your product owner. On the role, like actually setting the, the time. And I know you work with another team, but it seems like this team needs more help. I mean, I know what’s going on with the other team, but right now we’re talking about this team and so I’d say they need more help.
They need a little bit more handholding, which means that probably, honestly, you need to spend at least One or two hours a week with your product owner just talking about the product owner stuff until he gets to the point where he can prioritize. Because if he says yes to everything, the reason why he does it is that he has zero prioritization system because he does doesn’t know what is more important.
Is it which stakeholder is screaming the loudest? Because if he is overcommitting, kind of talking to him about the the long term, what’s, what it’s gonna lead to is a lot of disappointment because you’re gonna yes, say yes to everyone and in the end you won’t be able to deliver because we are not magicians.
Right. And that exactly you are over committing and you know it. Right? And in the end, you, the team will not be able to do it. Well. They’re gonna turn back to you because you told them it’s possible. So before we, we get to that point, let’s set the right expectations and things like velocity can help us talking about the, the thing that happens in the Sprint plan and say, Hey, look at velocity.
We’re never able to complete. Oh, but we don’t have enough work.
Planning for new support tickets mid-Sprint
Well, you just told me there are lots of new support tickets coming in. Well, yes. What about metrics on those support tickets? How do, are you tracking them? Are they estimated?
Giulio: No, they are not estimated because I don’t want that the velocity will be affected by those.
So we are not estimating those tickets. We keep it a zero story point.
Daria: That’s fine, but you need to track them. Yeah. At the end of the sprint. You need to track
Giulio: them somehow. At the sprint review, I show stakeholders when stakeholders are coming to sprint reviews because you, you did a good video about that on YouTube and I saw that.
I showed them how much unplanned stories. Unplanned tickets. Mm-hmm. We have, during the sprint for the support work we have for other teams, and it’s about 40% of our tickets coming from outside. Every sprint. Yeah. And they are enough to fill the work for the devs that haven’t planned anything in the sprint.
So sooner or later something will come for them. And on the other hand, we have also a cross-functionality problem in the team because as I. Told you two team members are fully dedicated to database staff, and the other three members are dedicated to application. And we have just one dev that knows.
Kinda something of database and something of applications, but the other team members doesn’t know nothing about the two aspects of so I’d like to stress out that if we don’t have anything planned for the other devs, maybe they can invest times to per programming with the other desks. Yeah. Working
Daria: on database.
Exactly. Yeah. A hundred, a hundred percent. I think that’s a good way to also, Say, don’t worry. We’ll, they will have work, right? Yeah. But when you’re going into the sprint review and they say, oh, but we, we don’t have enough work. Well first of all, we have 40, I don’t know, you, if you have just at least the list number of tickets, you may even want to start collecting.
Like how much time people actually spend on those tickets. Like, not the estimation, but like an approximate number. Like how, how many hours did you spend on this once you. Well, first of all, we will not be like, sometimes you need to be most a bit more strict. You’re a scrum master. You kind of are the holder of the process, and I think it’s okay to say, well, look, prove to me that you can complete 40 story points and then we will be taking 40 story points.
But this sprint, we’re only taking 20. That’s the maximum. Once we finish it, great. We’ll keep adding things. Don’t worry. Show me that you can finish 20.
Giulio: Yes, exactly. This is what I should aim for. I don’t.
I don’t, don’t want that people feels that. But on the other side on the other hand, I have to do something new. Yeah, that always complaining about that. But it’s just one team member that is complaining about that and it, he said always not in a good way. So it’s not taken very seriously, but the message that I heard is the correct one is saying, every time we are over meeting, we cannot do that.
Something has to change. Yes. As
Daria: you said, setting up some rules around that and also tracking that support ticket. Like how much time is actually spent on it by the team saying, Hey, you think our capacity, like, I dunno how long you sprint us say two weeks. Oh, you think your capacity is two weeks?
Well, actually no, it’s not 10 working days. It’s minus 40% because this is what we have identified is how much time this support tickets take. Right. So you only have six days in the sprint. That is your capacity. So we’re only planning for six days. Yes. And so that’s also kind of putting in, is that always like we actually don’t have a full sprint to plan for ever.
Right. Because of the support tickets. Yes, exactly. And yes, I think putting in that plan maybe for knowledge transfer in place, I think that’s a definitely a great idea. Saying, Hey, you know, if someone doesn’t have anything to do on day one of the sprint because we didn’t receive any tickets, why don’t we do some payer programming?
Why don’t we expand that knowledge between the team members so that we can, like in the long term, have a, not a full stack, but more cross-functionality on the team.
Giulio: How can I leverage on people that doesn’t want to have new skills and told me that they are not interested in having a new set of skills for themselves to enable cross-functionality?
Daria: That’s where you go back to roles and responsibilities. Well, now we work in Scrum. And in Scrum that is part of your job and that’s it. Same as planning, same as estimation, and that’s, this is part of your job. Are you trying to tell me that you don’t wanna do your job? Because I know you think that your job is just to code, but it is not.
Right now we’re working in a Scrum environment. And look, it’s your decision, but this is now required of do you like it? Do you want work to work in this environment? That’s up to you to decide, right? But right now, this is what the, the company’s decision is, is to work in, in this environment. I. And that requires us to change, like our responsibilities change.
Lack of support from management
Giulio: And don’t you think that sometimes companies decide to bring up frameworks like safe in teams that have never adopted it, but do not really explain the reason that stands behind the adoption of that frameworks, and this really makes it. Harder for people to understand and start using it and start to really enjoy using Scrum as a tool to work with because I use it also for my personal life.
I use Scrum, I do sprint retrospective for myself. In a weekly sprint, and I really enjoy work with Scrum and I’d like to bring those values also to the team, but I can see that having them imposed to them really makes it difficult.
Daria: Well, I agree that a lot of companies kind of say, we’re doing Scrum now, or we’re Agile.
A lot of the times they don’t actually know what it means. They don’t understand the implications. And as you say, or they don’t explain the reason why, probably they don’t know the reason why. They just know that it’s how most of the companies are working right now. That is one of the ways to attract talent for like new, new people who are are coming from that kind of background.
If you take like all of the fancy tech companies, right, that you know that they are using some kind of that agile framework. That’s why it becomes more of the the, we’re just chasing the popular word, but we don’t understand what actually is. And so a hundred percent, a lot of companies, you know, just kind of.
Jump in it and say make it agile. And it often is like, okay, I made the decision. That is my, my role of a leader to make the decisions. I made the decision. Now you go implement it. Except that when we’re implementing Agile now leadership has a role to play. Yes, exactly right. No, no, no. Wait a minute. I know that usually like you get got used to the fact that you just told people to do things and that’s it.
But now you are implementing Agile, well now you have job extra. Stuff to do actually that is related to this new agile implementation. Yeah,
Giulio: and also command and control method doesn’t work anymore because if you want to implement Agile a hundred percent, you have to leave that behind, I think. Yeah, hundred percent.
But sometimes I can see the same patterns. Over and over again, people doing the bus with common and control. Mm-hmm. And you impose things you have to do that, mm-hmm. And on some people, this, this doesn’t work and makes it really difficult to transition to Scrum, even if Scrum is. Fantastic. I love it.
For me it doesn’t have problems because I’m trying to think about Scrum and implement it to my daily life. I can see just the benefit using Scrum. Yeah. And it’s part of your day-to-day life. Working with Scrum, you can watch yourself packed what you did the day before. Try to plan something for the day after.
Have sprint goals and everything, but sometimes it’s getting really difficult to let people understand all the benefits that are behind.
Daria: I think some people actually are not kind of made in a way to work in a, in that Agile and Scrum environment that the traditional way of working works well for them and it just works better for them, you know?
So I think it’s more often we kind of make the change and the hard decisions in the companies are not being made where there are people who will not change and these people are slowing down the rest of the organization, not because they’re bad people or they’re not doing the job, it’s just that the new way of working is not working for them.
That’s it. That’s the only reason there is like, it’s, it doesn’t fit, you know? And I think that is one of the things to sometimes help people understand that, hey, here is what Scrum requires. Here’s like what it is. It’s not about implementing like sprint planning, reviews and retros, right? It’s not about that.
It’s about everything else. It’s about how we work, how we interact. Continuous improvement, continuous learning. All of these things come with this new, and it’s up to every person to make a decision. Okay, do I want to work in this environment? Yeah. Sometimes they just don’t know. They think they can do the same thing.
It’s just they call it differently, but it’s not true.
Giulio: Yeah. But I think that openness here is playing a crucial role in order for people to. Really try to use Scrum as a tool for them also. Yeah. Also for their lives. I have another questions. Go ahead. About the other team. It’s about the other team.
The team doesn’t want Sprint Reviews
Okay. This is a question that I posted, also a comment on one of our video on YouTube and it’s about the Sprint interview. Okay. We are working within Safe and we have system demos every other Tuesday before iteration reviews. Assistant demo has been planned every other Tuesday before iteration reviews.
And the iteration review were imposed to be set on Tuesday mornings in order for stakeholders to mm-hmm. Jump into some integration reviews and listen to the increment delivered by the teams and collecting some feedback and so on. But my team, before I joined the team, they had just the system demo and they never planned an iteration review.
This is because one of their dev was the scrum master of the team, but they really do not understand what’s the review about. Also because, No one come to the iteration review to listen to the feedback of our team. They are thinking to do double job with the system demo. Yeah. But I’d like to fight the status quo here with the the RTE of the Agile release train because I don’t think that system demo.
Should be done every sprint first and should be done on the same day of the iteration review because this somehow invalidates the meaning of the sprint review, in my opinion. So
Daria: what
Giulio: is a system demo? It’s an artifact in space. It’s an event that is, Held on the agility stream level where all the team meets in order to show stakeholders the increment they produced over the the sprint.
This can be done at the end of every sprint or at the end of the PI program increment. But it’s for everyone’s aware of the increment that as a collective part of the general release trade we produce about the product because we work on the same product altogether and we are presenting to stakeholders what we did over the last sprint in terms of features for the product.
And this is happening, as I said, every sprint.
Daria: What is the difference? Like I have, I’m myself kind of having trouble and understanding what the difference is between the integration review. And the system demo. How are they different? I don’t know.
Giulio: Okay. No, I’m trying to figure it out because we have an hour and a half to have the system deliver collectively, and every team has eight minutes.
To present their increment mm-hmm. During the spring. But we are making some work before that be because we maybe create a video to show the functionalities. We create an agenda to show the functionalities to choose which functionality we’d like to share with the stakeholders. And then at the beginning, the release train engineer go through the agenda and pass the voice over to every team in order for them to present the.
To stakeholders. Mm-hmm. But this is presented on a high level, let’s say. Okay. And the detailed level should be done in the iteration review, in the sprint review.
Daria: And so iteration review is one team, no
Giulio: iteration review. Sorry, it’s yeah, just one team. It’s sprint
Daria: review. Okay. But who are they presenting it to?
To stakeholders if they can, but it’s the same stakeholders that are also in the system demo. Yes, exactly.
Giulio: That’s why I’m
Daria: confused. They’re kind of right. It’s the same thing. Why do you need two? I
Giulio: don’t know. But it’s imposed that every team should have an iteration review, as they called it. Imposed By who?
By the company. By a company?
Daria: Okay. Yeah. But who is the company? Who is the person in this
Giulio: case, the R t e, that is talking to management that told us that we should. Have an iteration review after the system demo, and most of them are happening on the same time slot for I don’t know, three maximum, three teams is having sprint reviews on the same times.
So stakeholders cannot even join all the sprint reviews. Well, you have the system demo. Yeah, exactly. And this is why I’m really confused. Me too. I don’t know what to do because I’d like to, to say, okay guys, but let’s talk about this system demo or the system demo or the traditional review. You have to choose between one or the other
Daria: one.
Yeah, between one right or the other. So for the system demo when they are, because there are many, like all of the teams are there are other teams, well I guess they are getting. Like they all are working on the same product, I assume. Yes, exactly. So that’s why they’re all in the same review. Yes. Well, that is the, the, that’s kind of the whole point of that sprint review.
Well, your sprint review, the, the real sprint review is your current system demo. Yes, exactly. You have all of the teams working on the same product. There you have all of the stakeholders, right? So you are reserving just one time slot for everyone. You are already doing the what you would do in a sprint review, right?
So for me, duration review is just a waste of time. From what I’m hearing right now, yes, I would maybe extend the system demo to, I dunno how many teams you have, but eight minutes to present and collect feedback. That’s not a lot. I would extend the system demo to maybe two and a half hours and put in a break of 10 minutes in the middle, you know, but it’s duration review.
I don’t see the point. And I think, yeah, as you say you want to fight the status quo on this, I think you need to go back to the release train engineer and. Try to understand like, why do you believe we need two? Because we’re doing the same thing. Why is it needed? Is it just because it’s like maybe in the safe framework?
I don’t know because I’m not very familiar with the safe framework. But the reality is, even if it is, as I always say about any framework, what purpose does it serve? So if it doesn’t bring any additional value, we should not have it just. Remove it. Right. I don’t know. For me it makes no sense to have an iteration review.
And on this side, like I’m kind of sided with the developers. Yeah. Yeah, me too. Like
Giulio: what’s the point? I’d say to them, okay, let’s try this way and see how things are going, but it’s not working, so I have to get back to someone and talk
Daria: about it. Yeah. Yeah. So r t e, but you say that the r t E is talking with some management team, leadership teams?
Yes, exactly. Okay. If you can’t get into those discussions, that would be good. But in the meantime, it would be good to maybe identify some of the stakeholders that are actually like going into those meetings, into both and ask them, what do you guys think? Like because we feel that it maybe is, or doing the same thing twice.
Are you finding value in having two meetings? I think that can be also like a little poll. Yeah.
Giulio: Also considering that most of the time people, stakeholders doesn’t come to iteration reviews because they already had the
Daria: system demo. Exactly. Well, there you go. Gather their feedback. Ask them, do you like, how often do you come to the iteration review and why?
If you don’t come, why don’t you come? Right. Like Yes, exactly. A little survey with the stakeholders.
Giulio: Yeah, for sure. Eight minutes for every team is not enough to collect feedback. Most of my struggling are with safe right now. As you can
Daria: see, it’s just a framework. I know there’s a lot of hate for Safe in the Agile community.
I don’t date
Giulio: it, but Something I do not understand.
Daria: Right. Yeah. I mean, I’ve had safe training, but I’m not that familiar with the framework, but I kind of say, you know? Mm-hmm. Every framework is important to understand, like, what are you trying to achieve, the values, the principles, rather than just kind of following the framework blindly and say, that same that I say about Scrum is understanding why do you have all of those meetings?
Right. What is. Making sure that you’re focusing on the value of each element rather than just kind of having it in your calendar.
Giulio: Yeah. I feel that somehow they want to feel home overwhelmed by having a lot of meetings that are not really required because we have system demos that we have community of practice, that we have scrum of scrums and also spring planning.
Yeah, iteration reviews. They describe a lot. Really a lot over structure. They are over structuring in my opinion, scrum. Yeah. But okay, I’m here also to fight the status quo, so it’s part
Daria: of my job. Yes. Yeah. We do have that kind of weird organizational expectation is that if your calendar is free, there is something wrong.
Like why don’t you have 10,000 meetings? Why aren’t you triple-booked?
Giulio: Sometimes I have to choose between two meetings. Which
Daria: one should I go? You just put in like one, one headphone, you know, and one ear and the other one and the other one have two meetings. Not, I try.
Giulio: It’s not possible for me. Yeah, it doesn’t
Daria: work.
Yeah. I hope it was helpful. I hope that it kind of gave you some ideas of what you can do. At least, you know, get started with some of those things and yeah, for sure. Lets start making the life of your team a bit easier. Yeah,
Giulio: mine too. I brought just some challenges that I’m facing. One of the most common I think having heard about also other scrum master is that not everyone is talking during retrospectives.
Team members not speaking up in retrospectives
That’s a common one, and I have always the same two people which are really talkers during our one-to-ones, but they are not talking during retrospectives. I’ve tried to put them on the spotlight sometimes asking directly. Okay, what do you think about that? What’s your feedback on this? Mm-hmm. Once happened me that these people disconnect from the call.
Oh, are you serious?
Daria: Yeah.
Giulio: Yeah. Really? He pretended Wow. I don’t know if it’s true or not. He pretended to have some technical problems and I’m okay with that. Sometimes they are keeping me say that they don’t have any feedback about. Sometimes they are giving some, but the overall situation is that they are not talking.
How can I make them start talking? Because I think also that I’m not asking the right question.
Daria: Well, how do you run your retro?
Giulio: I run it differently. Every sprint retrospective for me is different. But I start with reminding them about the purpose of the retrospective, and I prepare a sort of agenda of the retrospective the day before the retrospective.
I collect feedbacks on possible topics that they like to cover so I can prepare something in advance. So I can focus on particular topic and collect the feedback having brainstorming session with them. Or I can go through this med set glad format or the continuous stop, invent act. But I’d like to keep it different.
Every sprint retro should be different in my opinion, so I keep them engaged. And during the sprint I try to understand which topic could be better. To be covered by talking
Daria: with them. So you kind of bring in the question. Yes, exactly. So you bring in the questions, well, not the questions, the topics, and kind of say, here are the, like, I dunno, five topics that we have identified that we would like to talk about in this retro Yes.
Kinda. Okay. And so then what do you do? Do you say, let’s talk about topic number one. What do you guys think or how, how do you do that?
Giulio: Sometimes I do a brainstorming session and we collect feedback about does this situation make you feel about a particular topic and what you can do to improve?
And based on the improvement section, we try to gather the action points. To be focused on the next sprint. Mm-hmm. Or we focus on what we’d like to stop about a particular topic of doing and how we can do it different in the next sprint and so on, so we can plan some actions for the future.
Daria: So when you brainstorm, do you say, let’s take, I know, three minutes, write down your thoughts, or how does, like what?
What is the brain? Right. Okay. And so everybody participates?
Giulio: Yes, exactly. I give the sticky notes and they try to fill in the sticky notes. I remind them to try to write at least one sticky note per person, but most of the time those people don’t write any sticky
Daria: notes. Well, don’t say try. At least one sticky note per person.
Hmm. How about in try? Yeah, no, trying. You need to add one sticky note per person and then I’m going to read through them and obviously each person is talking about their sticky note, right? There’s something to say because when you say try, I. Like, what do you mean try everybody’s participating? Think about like, you have zero thoughts on this topic.
Really? Okay.
Giulio: Yeah. I, I follow you. And why? If they don’t write any sticky notes,
Daria: you wait for them. Hmm. Okay. Honestly, sometimes I, I did it once, you know, I had this situation once and I was so mad that people were like, not participating. I remember. That I said, okay, we’re gonna use the talking stick, but I’m gonna do it reverse it a little bit.
Every person will have two minutes exactly. To speak. Not more, not less. Right. And so we’re passing the talking stick to everyone. Well, some people obviously are talking too much, but then it got to this one guy who didn’t talk, and so he said, well, I don’t really have anything to, to do. And so he was holding the, you know, the, the talking.
Yeah. So yeah, basically I don’t have anything and then he put it on the table kind of saying, that’s it. I’m done. I’m like, well, we still have a minute and 50 seconds. And we sat there for one minute, 50 seconds in complete silence, and he wrote something. No, it’s just that I, I was proving the point. I’m like, Hey, I’m gonna put you on the spot.
Because I need you to participate. Maybe this one time he, he didn’t kind of come in and started participating, but next time it was clear to him that I’m not gonna vge, and I, I was very like, everybody needs to participate. You too. I know that you think that you can just kind of say, that’s it, I’m done.
No, no, no. Yes. No, no. You are still on the spot. Right? So that can be some of the things that, how I would some type approach it. But then what you can also do, I dunno how many people you have. You have like six people. Six people, perfect. Do breakout rooms. I don’t know if you have the software that you’re using, you can do Yes.
Maybe instead of, actually, let’s brainstorm on the topic. Actually use give one topic to each pair and you say, I’m gonna give it like one. So for all. Yeah. Not even that. Just like literally you have, we’re gonna have three teams or three pairs. Right. Pair number one. Mm-hmm. You’re gonna take topic one, and once we get back into the main room, I’d like you to like present your solutions.
Basically, what can we do about this? Right. Team number two. You take topic two. Okay. Yeah. So what it does is that they are just kind of in the pair, so it’s easier for them to talk to each other. It’s not like in a big group, as you say, some of those people are more comfortable to talk to you like one-on-one.
Yeah, yeah, definitely. And so you can, you can kind of give them that opportunity saying, Hey, let’s just do in pairs. So that it’s a, a simple conversation. Think of some ideas of what can we do about these topics? Like what are some of the things that we can do differently next time, right? To improve whether it’s stop something or start doing something that is some, some of the ways how you can like, just make it a bit easier for some, some of them to communicate and contribute in this way.
And then maybe you don’t want to collect topics in advance. Maybe you want to collect topics in the retrospective as well. Yeah, that’s a good
Giulio: point. Let me take it note.
Daria: Maybe when they come into the retrospective, those are not the topics they actually want to talk about. Okay.
Giulio: Even if I share it with them and we define it all together, I can feel it right.
Somehow that they want to speak about something else. Maybe something that came to their mind that the same day they want to talk
Daria: about that. Yeah, exactly right. So give them that opportunity. And
Giulio: how do you run a retrospective without the topic in mind? Which format do you recommend?
Daria: There are so many.
Something super simple is honestly, lean Coffee is where you just basically say, Write down any questions or any topics you’d like to discuss. So there’s no really format, right? You just kind of give them the reins, like whatever you wanna talk about. Do want to talk like you can even accept some funny topics.
I had it once where someone said like, Wrote global warming on one of the topics. You know, like, okay, do you guys wanna talk about global warming? I mean, we can do that. Definitely. Right? Was that funded? It was, we spent a couple of minutes actually talking about it with the team, you know? Okay. But then you give them the opportunity to vote.
So you give them like.voting. Let’s define which topics are the most. Popular ones. Basically, which ones do you want to discuss? And then based on the topics that got the most votes, you focus on those. So that’s like the easiest way to, to run it, to be honest. And then you can use things like mad.
Glad to, to talked about it. So, It’s more about the questions that you ask. You say, okay, in this sprint, let’s just look back on our sprint and we have mad, sad, glad. Write down what made you mad, what made you sad, right? What made you glad during the past sprint? Just write down the, like whatever comes into mind when you think about these, and in the same you do.
Either you do a voting exercise or you group them. Like it’s good to group them if there are some things maybe. And try to understand people want to mo like talk about most. Well, you know, there isn’t one solution for everything and the more you dig, the more you find.
Giulio: Really good advices on things that I considered but haven’t realized could be the solution to my problems.
Because I, having heard it from outside is different. Hmm. It made me realize, okay, maybe I should go that way instead of trying to understand from every possible angles, what’s the point? I should try one. Let’s see how it goes. It just goes,
Daria: you know, yeah, try it, it’s gonna fail, and then you’re gonna find the solution next time.
You know? Yeah.
Giulio: Because sometimes I fear to that something could blow my
Daria: face. Isn’t it? Kind of like by default some like, you know, it, it, it most likely is gonna happen in some cases, so it’s more of. Comes with the job. Yes, exactly. Yeah. You’re doing your best. Attempting different solutions. There isn’t one magical solution that’s gonna solve all of the problems in the team.
And you know, just kind of one step at a time and some things won’t work and that’s fine.
Giulio: Yeah. Should go with that mindset also.
Daria: That’s, yeah. No, that was a good questions. Really enjoyed talking to you. I think that was really nice, kind of having a little sneak peek into the life of your teams and what kind of challenges they’re facing and hopefully some of those things that you can implement and help them really become better and enjoy their work.
A bit more. I’m pretty sure about that. Thank you so much for joining me today to speak with me, and I hope to see you around in the comments or, yeah, way. Don’t
Giulio: way on. Thank you, Daria.
Daria: Oh, thank you so much. You’re welcome. That’s awesome. Bye-bye. Bye. Daria. Thank you for tuning into today’s episode.
If you enjoyed this conversation and want to hear more stories like this, make sure to subscribe to the podcast on all of the different platforms. We’ll be posting the video version on YouTube and the audio on other podcast platforms. All of the links can be found below the video, or you can also go to scrum master.com/podcast.
You can also find the transcript and the show notes on my blog. And I’ll see you in the next episode. Cheers. And Scrum on.
