Welcome to the second 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.
This time I’m talking with Diva ✨, as she told me – she was first exposed to this wonderful world of Scrum in 2021 and the love has only grown since then. Diva is also an avid foodie and a singer. ✨👏
Imagine this ➡️ Investors of your startup decided to expand the scope, so the Product Owner is trying to squeeze in new work in the middle of a Sprint. The team while being excited at first becomes less and less motivated AND they have trouble estimating work which makes it even more difficult to plan Sprints.
Well, just another day in the Scrum Master world 🙌
In this episode, I’m talking with Diva, a Scrum Master from Mozambique living in Malaysia. She’s currently working as a scrum master for a fintech startup.
📌 Today we discuss how to create a healthy relationship with your Product Owner and your team to support their growth without driving them to burnout.
Diva also teaches me her secret technique that helps her create rapport with her teammates in 4 easy steps and shares a funny story about how it helped her create an awesome work environment.
Hi diva. It’s really nice to be able to speak with you today. Thank you so much for joining me. At this late hour for you.
Thank you for having me.
It’s really nice having you here. So last time I think we talked about what you are doing. So you are a scrum master right now working with a team in a financial sector.
And one of the things that you told me last time we spoke was, well, I don’t know if I’m doing the right thing. Like how do I help my team? What, what should I focus on? Am I doing the job right? Like, what is the the right thing to do? How can I help my team get structured by also not to overwhelm them with all of the changes?
I know that your team right now is struggling a bit with estimation performance, lots of deadlines that are coming their way. How do we support them? How do we kind of help them with those struggles? So tell me more about some of the questions that you’re bringing today and what I can help you with.
It’s a pleasure to be doing this with you and just jumping right in. Essentially my team and I, we are very small still, but very ambitious and we just, you know, wanna leave a mark, a dent, you know, in the world. And so I’m a very important part of that process and just knowing how to be able to help them in the best way possible is very important.
My first question, which I mean, it would be a little general, but I think it’s still crucial, is when you’re dealing with a small team in a startup, for instance, what are the best tools that you can use? Because there are a lot of tools nowadays. There’s a lot of free tools that we have. For instance, my team right now are using Trello.
I’m not sure if it’s the most efficient tool, you know to be doing what we’re doing. You know, previously when I was still doing my junior experience back home, we were using Jira, which are the best tools to be used for such a endeavor.
So you have still a pretty small team, you say, right? So
Yeah so, it’s three developers and me.
Even for a small team, you want to have a way to track obviously progress. It is kind of a hard and easy question. What I mean by that is that is true. There’s so many tools that exist. Some of them are kind of more promoted in general. For example, JIRA is something that is very popular, especially with bigger companies.
And I think their tool is more geared towards like big companies overall. Same we have Azure DevOps, right? So we have a lot of those tools. Trello is a good start. I think that’s kind of how I would put it. It has some very basic functionality, right? It gives you that visualization of the work, but then if you have a lot of work, it gets kind of overwhelming because you have, you might have a hard time to organize it into like separate places really, or boards that could be synced.
So that’s where as soon as you get a bit more, I think work to do Trello becomes a bit limiting and what I found out actually working with my team here at Scrum Master is that everybody will have a tool and they will sell it to you and say, this is the best tool there ever was, Right? And this is the one you should use but what I found is that It is okay to switch, especially you have a liberty to do so. Right.
A lot of teams are fixed with Jira, they have no say in like have to use it. Yeah. Yeah, exactly. I think it’s okay to kind of check out different tools and see is this the right tool for us?
Will it work for us and kind of try it out for some time and then make a decision of whether this is the right tool for you? With my team, we use Notion to track, our work, but also create documentation because it’s very. It’s kind of more focused on like creating wikis and things like that. Okay. We used Asana, and those tools didn’t work for, we even tried Trello as well, and it just was not working out for us.
It was actually creating more work to stay organized than to do the work itself you know the feeling? And so right now we move to click up. That has been working really well for us. What I learned in the end of it, it’s really about which tool actually replies to what you need.
I think Jira is a good tool and it’s free that you can get started for free at the beginning and it allows you, it gives you a lot of flexibility. It can be a little bit complex, but I feel like as any tool, you kind of learn to use it the more you use it.
So, you mentioned here something that I thought was very interesting, which is the fact that we can actually switch around and see which is the best fit for us and does, let’s say for instance, we use like Jira for like about a year and we’re like way into the process. And so does that mean that if we make that switch that would end up affecting the team in some way?
Or when you advise us to be able to make those switches? It has to be very early on.
Obviously if you have like a huge organization, sure it’s gonna be hard, but sometimes I feel the time and effort you will put into switching, even though it may be a lot. It is worth it because in the long term it’s gonna save you a lot of time.
Like when we switched from Notion to click up, I had a lot of documentation that already existed that I needed to move and of course all of our, like we had a content calendar with like tens and dozens of cards already in there and we just started to really switch actually for what we needed right now.
So we’re working on a project. Say, okay, well this is the project, I’m gonna start already switching this because this is what we’re working on right now and that would’ve also helped us actually to do some cleanup in the process, Right? So that was like, yes, it was an extra time, some extra time that we had to spend, but in the long term it actually saved us time.
That’s awesome. That’s awesome. I bet that’s something we could try out eventually just too. Test the waters and see Yeah, which is best.
The next question I have for you it’s quite a list. So the next question I have for you is cuz we spent a lot of time just kind of planning out our tasks in the backlog, me and the PO.
And since he is part of the developers team as well, we always find ourselves just trying to look into what do we consider priority? Cuz him as a developer be like, no, I think the functions are the better ones, We need, we need to look into this and we need to look into that. You know, the Nitty-gritti
I’m not sure if there’s a conflict between his role and being a developer as well, but we really spend a lot of time, so what are the, I don’t know, tactics or the methods with which we can just cut down that time where we spend prioritizing tasks. Him and I.
When you talk about tasks, like are you actually going like into nitty-gritty details or is it just overall that you keep reprioritizing what’s in.
More, more important.
It’s more of the overall, we try to go Nitty-gritti later, but we just try to get the big picture first and then we get into the Nitty-gritti. So yeah, that’s pretty much what we do. So we’ll come and be like, okay, so I have this, this, this, this, this. And I’m like, okay, so what do you think?
This should come first or second or third? And he’d be like, okay, I think this should be, but then, I don’t know if he ends up thinking, okay, maybe there’s gonna be a complexity in the future, so maybe this one should be down or this one should be up. Yeah. Something like that. So we end up spending a lot of time there.
So is it like he is indecisive in a way?
In a way it feels that way. Yeah. Way.
It always feels like there’s more to the project. Yeah. And I’m like, okay, put it on paper.
Well, there always will be more. Right? You are kind of building that product. Whatever you’re building, it’ll expand and more things will come your way. I think one you pointed correctly that one of the challenges is that the product owner is potentially very technical.
So, he has trouble kind of disconnecting from the how to and focusing on what is the most important more on the customer side. So I think there may be some of that kind of coaching that needs to happen. Then making sure that your product is actually well defined, actually. Do you understand who are the customers? What are they trying to achieve by using this product? What makes them happy? Do you have a well defined customer persona? Do you have some good product KPIs?
Like any metrics that are important for the company actually? When they’re tracking whether the product is doing well, and I think starting there will help.
Even just defining the customer persona. This is what I did was one of the I had kind of a similar situation where, where we have like an interim product owner who was also a tech lead and he had trouble figuring out, okay, what is the most important thing? We actually sat down and created a customer per persona that, helped him then make decisions on what is the most important.
So I think definitely setting some of those basics. So definition of the product itself. Does he or you generally as a team, work closely with stakeholders, like other stakeholders who may have an opinion of what is the most important?
No. Usually it’s just him.
Oh, it’s just him who comes up with the ideas?
Okay. Okay. So that might be also hard. Because if you are just the only person and you do not have the input from the potential user or customer, then it is hard to make a decision. So I can understand why he might be struggling to say, okay, what is the most important? So I would say, identifying some of the key stakeholders in the company and getting access to either potential users or potential, customers, whoever that is, or a sponsor right? Of this project, who is the closest to the customer, who can help you understand a bit more about what they care about and that can be very helpful overall, just kind of hearing someone talk about what the product is, what it should do, what is the ideal situation for them.
That will be very helpful.
I think in this particular case, we kind of did a survey, but it was very early on, so we haven’t really had the chance to do like another survey this time around, so maybe that would definitely help to just clear our direction and just help us focus more on the right things.
You know? Yeah, yeah. Cuz then, then we’ll be able to create a product that caters for their needs specifically.
And in the end, having a good, obviously, product goal is helpful if you have some kind of metric you can track that will be helpful generally to make decisions and maybe as well, I’m kind of thinking maybe he is more afraid to not finish something that’s important.
if everything is important, it means that nothing is. And so I think what can help as well saying, well, we, we are working in sprints, right? We are going to prioritize a set of items that we’re going to work on in this sprint, and then next sprint we can change whatever we’re working on.
So the maximum amount of time or effort you’re going to lose is just one sprint. You are not like setting everything in stone. We just need a decision for the next sprint. That’s it. Kind of reduce that pressure of having to decide everything
at once. Yeah. I will go after those end users.
Well, what about stakeholders inside the company?
it’s, microcredit companies and also financial institutions like banks.
So those are major, major, um, stakeholders for the microcredit companies, they’re the ones that we want to cater to because, they don’t have a lot of services focused for them in Mozambique.
So essentially what we’re trying to do is to be a middleman between the bank and them. And also be able to help them with their day-to-day struggles, essentially that’s it.
So most, just a very brief background. So Mozambique has a credit score system, right? But it’s not really automated in any way.
And so, um, our product will come in and not only help people understand a little bit more about credit score but also help microcredit companies understand a little bit more about the people who are coming to get money from them.
So, that helps them manage their risks as well.
So, okay. Well you have kind of an understanding already. It’s more about like making sure that it is focused. On this, and then it’ll be easier to make some of those decisions.
So the next issue that we have, or the developers, and I face is that whenever we sit down to, you know, do estimations, we have a tendency of overestimating based on each developer’s skill.
So a developer would be like, well, you know, I know this, I have background of this and that, and, um I can do this and I know that this is going to, you know, be great. And I’ll be like, okay, I, I understand what you mean. But, um, we do have a short time. I was like, no, no, no. It’s okay. I can do this. I can really, really put it out on time, like, okay cool.
And at the end, um, yeah, it ends up being an issue. So how can we kind of ensure that there isn’t a big deviation there? Yeah. Where we can have more exactness.
Well, do you have a baseline that you use to estimate again?
What do you mean by baseline? I think that would be my question.
Well, because when we estimate, we want to basically the reality is that the tasks, the work that they’re doing is complex, though they will never be accurate.
As accurate as we would want them to be. What we do want to have is some consistency to help us plan. Right? That’s really what it, it is about, and usually in order to help us with that, We want to do relative estimation rather than just do estimation based on whatever you present me right now, I’m estimating this in a silo, so we want to relatively estimate towards whatever work we already did, right?
And so usually I recommend creating a baseline.
Are you using user story points?
What we do right now is like we have this thing where we have like an, you know, numbers like from zero to 10. And then within that you can tell like the level of difficulty, and from there we just average it and we see if it’s okay or not.
Okay. I do recommend looking into planning poker and like user story estimations. Because that can be helpful. But let’s take, it doesn’t matter really what the system you are using, and we can go with that one to 10.
What you want is to have something that the team already worked on, something that has been completed, and you take this item and you put a number on it based on what you already know because everybody has completed it. So say they have worked on an item and it was okay, it wasn’t too complex, there was a little bit of complexity or like how hard it was and you take this item and you say, this is going to be a five, right?
Somewhere in the middle between one and 10. Okay. And so next time when you’re taking in a new work, you say, okay, well. Do you feel that it is more complex than this one the item that we have finished and our baseline? Or is it about the same? or is it less complex? Now the question is not about trying to figure out new work item on its own.
But you’re, you’re just relatively estimating. So we said, well, It’s actually much easier than this other item. I can see how it is much easier. And so you say, okay, then it’s less than five, right? Or the other way around. No, now it’s actually much more complex. Right? and that’s where the conversation happens really, is that it is easier for our brain to actually do that kind of estimation than trying to figure it out.
Like when we’re looking at a complex task. You know in a silo what it is. And I think that can be helpful overall because deviation will always be there. Okay. Anyway, there is, um, it’s not something that you can eliminate completely. You just want to be able to plan a bit more. And I would even say if they’re always overly optimistic and they’re like, yeah, I can totally do that.
You say, based on our history and the data that we have we cannot complete that much work, so you need to take half of it. Like you are kind of setting the rules in place, saying you have to take less. Okay. Like you’re basically, you’re not allowed to take a hundred percent, you can only take 50%. And when you finish.
Don’t worry, we have lots of other work to do.
Okay. The fact that I have to be like, no, you don’t have to take more work.
Not, you don’t have to. You can’t. I do not allow this.
I know. I’ll be like, no, you can’t have it. And be like, oh, really? You think I can’t take it? You know?
Well, you say prove me wrong.
So true. So true. But yeah. We’ll, we’ll see. We’ll see how that goes. We’ll really see how that one goes. Yeah, I’ll have to, I have to write you back and be like, okay, so here’s the story.
Well, you know, maybe it will motivate them extra or like, I’m gonna prove that I can take more.
Maybe, maybe, maybe. I really hope it gets to be something like that. Like anything other than that gonna be a little bit of a cookie, but, okay.
So, the other thing that we’re, that has happened, and this has happened quite recently, is the fact that, our investors decided to expand the scope of our project.
Like I said, the team is small and our deadlines are quite short. So we have July for our MVP, and then we have our final demo to be like October. And so it’s, it’s pretty tight at this point.
At first they were excited, right? And like, okay, let’s get this going and all these things, and now it’s like, okay, can we do it? Can we finish it? Are we gonna be able to finish it?
I’ve had a situation in the middle of Sprint. It was like, okay, we need to get this task in. We need to get it done. We need to make sure it’s it’s done on time and all these things. And I’m there trying really hard to defend the team and say, you know what, no, they, they, they can’t do it.
They can’t take it. Not right now, at least not right now. We can push it to next time or we can trade it with another task, but we can’t necessarily get the team doing this? No. In those situations, I’m never really sure how to best let the PO know like, okay, this is this because we end up quarreling at this at Yeah, It almost feels like a quarrel, I won’t lie, it almost feels like a quarrel. Because I’m there trying to say, okay, this, we can’t push. And maybe another time. So I’m not sure, like based on your experience, like how have you dealt with such situations? If you’ve had any
Actually, Well, that’s actually a pretty common problem.
Unfortunately, that happens a lot of the times and a lot, a lot of teams that suddenly we have more stuff to do, right? We have the same team, the same number of people, and somehow we need to do some magic. I feel that there are a few things to kind of look into that. It seems that the product owner might not actually understand the general idea behind scrum and sprints and how we are trying to create focus within the sprints.
I’m wondering if some of that training may be in order just to go back to the basics and say, here is Scrum, here’s how we do it, here’s why it is important, we have a sprint goal, the sprint goal doesn’t change.
And you talk about these things just to like a quick overview of here’s how we work, just to make sure everybody’s on the same page.
And then the other thing I think is in terms of like the new work coming in, I think it’s fine to say, sure, we can take it, but now look at this list of tasks.
Which one do you do we remove? Right? Because it’s, it’s not in a negotiation whether we remove something. It’s, no, you, we can take it. No problem. Sure, but now you need to tell me which one of the same size we have to throw away. That is the conversation that you want to have. Then maybe talking about the context switching.
I don’t know if there’s the concept is maybe understood by by him. Do you know the context switching and kind of where it is and how it impacts teams? No? Okay, that’s, that’s fine. Yeah. So basically what it is that in research, what they found is that when you are working on one task and then you are switching context, searching to work on something completely different
You lose of up to 40%, 20 to 40% of your time. To that context, switch. Oh, if you didn’t do the switch. Okay, so if one person is working, say on two projects, We say, well, it’s 50-50. Well now no, actually it’s not 50-50 because you have lost 20% of the time on context switching. So it’s actually 40-40 and 20% of your time has been lost. Right?
If you are working on three tasks, well now it’s getting lower. Now you actually lost 40% of your time on context switching. Basically, this is the time that is wasted, just wasted time. What did, what did it means is that, well, I was working on this, now I need to work on this.
So what was it exactly? Let me figure it out. What I did, I already work on this. So it’s just that point in your brain where you need to switch the topic and figure out, especially if you already worked on this task previously, now you need to remember. So what was I doing again? Right? And when it comes to developers, I think especially is they need some focus time, right?
They need several hours of focus time. If you break it in the middle, they’re going to lose all of that energy. They will need to like restart from scratch. If they were like thinking on the line of code of how to write it. Yeah, that’s, and they’re gonna spend extra 30 minutes trying to figure it out just to get back to where they were and talking about the context switching I think just to show, hey, we can totally switch context.
We are going to lose it. 20% of the time. Are you okay with that?
So you are kind of giving the choice to the person Yes. The facts. I need you to make the choice right now that you know the facts, especially if the change needs to happen and say the team is working on something like in the middle, working on something.
And now they’re asked to work on something like basically on drop, whatever you are doing. Start working on something else.
Exactly, and that ends up, you know, affecting even the way they feel cause. Some of them will feel so demotivated and actually this like the next question cuz they’re like, well, do you know this feels like a lot at this point.
I’m like, you know, I had to change from this and I have to do this now. And, I’m like, okay, but you know, calm down. Like, take some time, take a breather. You know, you can do it, you can pull through. And they’re like, and they’re like, okay, we know we can do it, but it’s not that we’re happy about it at this point.
Point, you know, how do you even deal with that? Like, how do you pump them up and tell them, okay, get it going guys.
Well, you’re, it’s all about being realistic because I can totally see why they’re de demotivated because they can never see any real progress being done. They’re constantly asked to do something different.
So they feel that they’re working, working, working, working. But there is no result. Of course. It’s demotivating. It’s not about how do you hype them up, what you can do is you need to actually solve the problem. In this situation, hyping them up is not gonna help. I wish it was that easy.
But what you need to do is you actually, all of the work that you need to do right now is outside of the team. It’s not about what’s happening within the team. It’s everything that’s happening outside of the team, the product owner. How do we deal with these new priorities? Right? So setting up some rules around what can and cannot happen if we take in new work, we have to throw something away.
If we take in new work, we will only start working on it when other tasks that are already in progress are finished, right? We’re not taking away, like in progress tasks are basically untouchable. So you set in some rules in there, and then you need to set work with the product owner and stakeholders like your investors to set the right expectations.
Because right now there are asking for unrealistic expectations with some short deadlines. They have like new scope that comes out of nowhere, some deadlines that come out of nowhere, and the team knows that it cannot happen. So what you can do, you are the messenger of the information. Okay? Here’s, I know that you want it to be done on July 1st.
It’s not gonna happen, right? this is unacceptable! Well this is, I know. Uh, you think that way, but this is the reality. I’m just letting you know in advance it is not going to happen. So when it happens, you can kind of go back and say, okay, well, as I told you three weeks ago, uh, what can we do now?
Can we plan right now for more realistic deadlines? Mm. Let’s do some better prioritization. Yeah, right. Let’s do some estimation before we create any date.
Definitely can be something that can be improved. You mentioned here something that I thought was very interesting in regards to just going back to basics.
How often would you recommend, for like coaching sessions, just like refreshers to happen for like the entire team? You know, just so everyone can be aligned on, okay. What roles do they have, what they do, what they don’t do.
How long have you been with this team now?
Right now, for about six months.
Six months. Oh, good. Time to do a little refresher. Okay. I usually do it when I start with a new team, so I’ll just kind of by default, even if they know everything. I still like to do just a quick refresher. The thing, what usually kind of the approach that I generally recommend to take is to do that teaching kind of ongoing.
Whenever you get a chance, you do the teaching. If you are, say, in your daily scrum, you listening and the daily scrum is not really going that well or as it is supposed to be. Well, then right after the daily Scrum you can say, Hey guys, just wanted to do a little teaching session here just to make sure we all understand what Daily Scrum is.
Here’s some theory just to make sure that we all are on the same page. And you can do the same thing in many different places when you have a situation like this. Well, that’s an opportunity to do some teaching. Specifically for the product owner, right? Whenever you see a problem like this, I think it’s important to kind of go back and say, you know, let’s discuss this.
Let’s make sure we’re on the same page. It doesn’t have to be like a classroom, workshop or something, or training.
The thing is like sometimes like when you take these opportunities and you try to make it into, a learning session per se, in the times where I’ve tried that, at least the people I’ve spoken to and I’ve dealt with.
And, you know, before it, they would look at it as a sermon kind of like, Hey, why are you being, you know, mama bear on me right now, or things like that. Yeah, that’s, that’s specifically why I asked like how often you would give tellings, but if you consider that to be the best approach, then yeah. I can go ahead and try and see if, that would work.
Tell me a bit more about this. You say, oh, I tried it. And then people approached me and just, this was not with
This team, actually, this was with the previous team. So, um, I was having an issue with the PO of course, because we were not being able to hit our, um, definitions of done and all these things. And I went back to her and I was like, okay, um, you know, we need to discuss a little bit about this and we need to talk a little bit more about this.
And she came at me and she was like, you know, I don’t need you to lecture me right now. I just need you to do your job and I’m like I’m actually doing my job.
It’s my job to lecture you. Actually.
It’s my job to let you know, and we’re not doing things correctly and we need to get things back in line Anyhow, long story short It didn’t end in the best way because we ended up escalating and yeah and then our manager had to sit down with us and I had to explain the same thing I was trying to explain to her over and over and over again to him and he just looked at her and he was like, well, You do know she’s right and I was like, finally someone understands me.
Nice. Oh, that’s really a good story.
Yeah. Yeah. Hey, think it was quite something. So ever since that experience of, I’ve always been a little bit careful when it comes to, oh yeah, so this is supposed to be like this kind of scenario. So what else? Do is I would create like sessions like every three months.
Like I would sit everyone down and go through the basics with them. That worked, I won’t lie that that did work. And with this team, we only did it in the beginning. So I haven’t had the chance to do the second one yet with them, but we’re already planning on that actually. So yeah. Yeah. How that goes.
I’ll see how that goes. But I will try yours first before I go back to mine.
You know, same as with tools, if that worked for you, you don’t need to reinvent the wheel, right? No. If you used to do it every three months and it, it worked for your teams, you can try it again and see.
Maybe that is the approach that works best for you, right? How you interact with the teams and just your facilitation style? Yeah. You know, you can definitely do that. There is no, like one size fits all here. It’s really about what works for you. Okay.
Yeah. So, like one final question I wanna know from you is, okay, so based like on the teams that you’ve worked with, what are like the major differences that you encountered?
What was that one thing that you, you could tell like, okay, these guys were different, these guys were different, these guys were different. And what was that one thing that you think they all had that was very much the same? Because I think each team is so unique. I think it’s like, You know, like when you have like, I don’t even know how to explain, but I think you get what I mean.
It’s like you have different teams. They’re also different, but they’re also alike in some ways. So, yeah, you let me know a bit, a bit more about your story.
Let me, I need to think about this one. In the end, what I found is that doesn’t matter which industry you are in, what the product is. Whether it’s technical, non-technical teams are usually facing very similar challenges in very similar ways.
So that there are a lot of similarities in kind of the issues that you need to help resolve. Okay. Like how, when we talk about context switching, when we talk about, multitasking, changing priorities, all of those things, the patterns are basically repeating themselves. It’s almost every time it’s like a dish.
I’m like, okay, well I’ve, I’ve seen that before. Not exactly in this way, but I kind of seen that before, right? But what I also found is, In reality is that when you are coming in and you really start bringing in some changes, some positive changes to them, people actually really understand the scrum master role when you, they have a great scrum master who can bring in some of those challenges, and they are becoming pretty open to it.
Even if at the beginning they were very like, oh, no I hate this and scrum masters are useless, but when you’re actually working with them, you know, and you start bringing in some of those positive changes in, in reality, they quickly, it’s actually easy to show to them the value and get them on your side.
You know, it’s kind of what I found, even like the toughest people I had to work with, uh, if they’re on my team.
Well, what about you? I mean, you worked with a couple. What are some of the biggest, differences that you’ve found and what are the same, like the similarities?
Okay, so in reality I’ve worked, I’ve worked so far with, with three.
I think what you meant by deja vu is like really, really true because you do get to face similar problems, but they’re just different cuz it’s a different environment. I think one thing that for all the teams that I work with, that was very much in common was the fact that I had really, really cool developers.
I were like they were amazing. The team was very tightknit. So even if I was talking to one, I was talking to all. And so I really didn’t experience any friction when it came to the dev team, and they would welcome me with just open arms and be like, okay, like, let’s work together. I still haven’t had the situation where someone comes and tells me, you know what? We don’t need you. We’re fine.
So I still haven’t had that. So I think I, I’ve had the Mary, the Mary ones this far.
Well I still ha still haven’t had that either. So. When you help people, you know, when you help people, and I think that’s an important point, you said, well, the developers, people are on the teams.
They actually like feel the change, you know? They feel the value. They’re like, no, no, we like you.
Exactly, exactly, exactly. And just being able to be approachable is such a plus. I mean, you can’t. I don’t know. I, I don’t see, the whole thing of working with people if you’re someone who’s very cold and no one can approach you, so.
Just being approachable is really a plus. And I’ve noticed that it helped a lot especially when I had like one-on-one sessions with each one of the devs sometimes just to kind of understand how they work, how like their work styles, cuz I think that’s very important for you to understand how they work, what they like to do, how they like to do it, and all those things.
So it’s important to work on those things too. Yeah. So that was very helpful.
So how do you become approachable?
This is what I do.
So every time I work with a team, I have this sheet where I essentially put, okay, what is it that you like? What is it that you do as a hobby? What is the best way of learning for you?
Me and you, like, we need to have something like a click, like something that when we meet, we say to one another that is cool. That’s just me and you. Like, I’d be like, there was this, this one is the funniest one. So I sent the form out and the dev is like “When I say peanut butter, you say jelly” I was like, why would I, why would I?? you know, but it was so funny cause he’d be like “peanut butter” and I’d be like, ”jellyyyy”
And it really helped cuz then we had something we could click and then everything else is just like a conversation, like any other conversation. And even when we had to have difficult conversations, we would start conversations like that, like, Peanut butter-Jelly. Jelly and yeah. And, and I’ll be like, okay, now we have to be serious.
Now we have to talk serious. Now we, well we need to talk about this, we need to talk about that. So people become a little bit more open to that cuz you give yourself the chance to get to know them and so that that helps. That helps. I mean, I’ve seen people do that, so I’m like, it didn’t touch that way.
You’re doing it backwards.
Yeah. It’s, it’s very much backwards. That’s so true. Cause we’re dealing with people and it’s, it’s important. It’s important to create rapport.
I love that this is okay. This is my favorite new tool. This is the best peanut butter and jelly, the best story ever, and just the questions.
I really like that. I’m pretty sure that people are listening to us will absolutely love that. Yeah, it’s. Yeah. Awesome tool. So easy, but also so powerful. Awesome. Yeah. Great.
Well, I think I only have one question. This is the question I ask everyone really. Okay. Is what would be one advice, one tip that you will give would like to give to Scrum Masters? People who are listening to us.
The one thing that I would advise Scrum masters in general, but right now I think I would say for people who are like in the same stage where I am like, you know, just starting out and all, is to just be open, be open to not only learning more about what it is that you do, but also just be open to applying more of what you’re learning and not to be scared of it.
And, just going bare head in, you know. Dive right in there. Cause at least it’s what I feel that helps me is that I try to get as much knowledge as I can and apply it. Oh yeah. And another tip, contact the person you look up to because that’s exactly what I did. Yeah. Go after the knowledge, you know?
Um, and knowledge doesn’t, it’s not in like, you know, maybe a classroom that you’ve been in or with, you know, only your manager knowledge is everywhere. So yeah, be daring.
Awesome. I love that. Thank you so much for sharing all of your tips, all of your secrets definitely will be helpful for people here.
Thank you for joining. I think that was an awesome discussion. Great questions. And obviously very happy to be able to speak with you here today and you know all of the great things to happen with your team. I’m sure.
if I do correctly apply all that you told me. Trust me, I’m sure it’s gonna be okay.
Thank you for tuning in to 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 ➡️ scrummastered.com/podcast.
I’ll see you in the next episode.
Cheers and Scrum on!