Welcome to episode 4 of the Agile Audit podcast – a podcast where I sit down with your fellow Scrum Masters to talk about working with Agile teams.
In this episode, I’m talking with Banky and we deep-dive into what it means to lead without authority and touch on building friendships that can help you grow professionally.
We also discuss how to act strategically as a Scrum Master and not get stuck in the operational day-to-day, and share examples of metrics that show team improvement.
Banky shares some challenges he faced in the role and what approaches he took to resolve them. We also get back to the topic of retrospectives – something that comes up often in the Agile Audit discussions.
A little bit about our guest:
Banky Lawani used to be a Project Manager before transitioning to a Scrum Master role a few years ago. He worked with different professionals across a number of business domains and it’s been interesting.
If he learned anything at all as a Scrum Master, it is flexibility and simplicity (watch till the end where he explains what it means). Banky resides in Calgary, Alberta.
Transcript
Daria: Hi Banky. I’m really happy to be able to speak with you today. Thank you for joining me. And as I said, let’s jump right in. And I know that one of the things that you did previously before you became a scrum master, so you are more in the project management background and you made the switch a few years ago.
And I know that you’ve been enjoying the role, uh, but I’d like to learn more about how that switch went, kind of what brought you to decide to switch and, uh, generally what was your experience with
[00:01:19] Banky: that? Oh, thank you Daria. Um, I appreciate, uh, you having me on your platform for the discussion. I used to be a project manager, um, for many years.
And that calls across infrastructure projects and IT projects. And at some time, maybe 2015 ish, maybe I would say I got tired of being a project manager. I was looking for something else. And then in my personal research, I, I came across the Scrum Master Agile project management. And then I researched more and more about it.
And I found it interesting. I saw it as being very close to the role of a project manager because as it is for me, I. I believe that. The project manager will still carry some of those personal qualities you expect in a scrum master. A project manager is not expected to treat his or staff or teammates as, um, trash, right?
You still have to respect people, you have to make sure they collaborate. You have to make sure that people are focused on the result and, and ultimately, uh, care about what the customer wants. Right? So I found that very similar and, and that was how. I, I started journey on the rest of the IS history. But I’ll tell you that in terms of the switch, for me it was smooth because, um, one big thing about how I started my project manual career, I remember then that was sometimes in 2005, I actually, I.
Got into an organization where the manager gave us a lot of responsibility. So you deal with this project, this particular project, you are like the c e o, from beginning to the end. You worry about the contract, you worry about the resources. You worry about having the functional manager. To support you with your resources.
So I learned very quickly how to get result with little or no authority, which means you have to rely a lot on your collaborative skills, your interpersonal skills. You have to write a lot, you know, reaching out to people and be out there. So people will then, like in this case, functional managers and even the team members they work for you.
Not because you have any authority over them, but because you have just built a relationship that they find very, uh, difficult not to support what you’re doing. So that has been my experience. So getting, switching into Scrum after role where, uh, majorly you play support role and you, and where you got people, you don’t necessarily have the authority to.
To tell people what to do or whatnot, you are only expected to sell or suggest ideas and let them see the benefit. So I found it very easy for me. It wasn’t a big deal.
[00:04:01] Daria: Interesting. Yeah. Yeah. That’s an interesting take I think, uh, on the roll, right? Because a lot of the times when we see the role of a project manager, I feel like we’re focused on the manager side of things, right?
And then even the project managers are kind of taking more of that. Even micromanaging stance sometimes, rather than focusing on the people side. Yeah.
[00:04:23] Banky: That happens because of course, you know, for me, I believe that project manager is a nomenclature. You could have been called a project lead. You can, you can be called a project leader.
You can be called anything. Right. The important thing is we are laser-focused on delivering business objectives. Right. And in doing that, you can’t do it all alone. So you would have to work with people. And most times because a project manager may not be an expert in that area where you’re actually working or in the domain, so you still rely on the expertise of your team members to get things done.
So how do you do this if you are not treating people like humans? If you’re not showing respect, right? Fine. We’ll set clear expectations as to what we need to deliver. The how is with the, the team members and regular check-ins, reaching out to people. Show that you, you truly care about people, go the long way to making people go the extra mile for you.
Mm-hmm. Because then one thing that I learned again is people, your team members, your functional managers, support teams, they wanna make sure that you. Do not fail as a project manager before they even start thinking about the business. It’s funny, right? We are all working for the business, but people think about, oh, I would rather work extra hours than to sit bank fail on this project.
Once you get to that point, as a project manager, I. Or as a scrum master or as anyone who is leading anything, then you are there already. Mm-hmm. And these are simple things that you have to do to take you to that point. They’re not the big
[00:05:57] Daria: stuff. Yeah. Creating those interpersonal relationships is really what.
Um, I can totally see that, how that helped me as well in the role of a scrum master to build in those relationships and kind of getting people on your side to help, uh, promote Scrum in the organization. Well, obviously since I was more focused always on the scrum master role, I. Just being able to, whether you creating relationships, obviously with your team members who are on the same hierarchical level as you.
Right. Or you’re trying to build more relationships with maybe management, right. And executives to get them also on your side and to help you, you know, build more successful teams. Yeah. Well, it’s a good experience, I think. Yeah, that sometimes this tradition may be. Hard, but I know that you brought some questions to me.
I think though, those are some of the questions that, um, as we discussed, most likely are on the minds of a lot of people who are, whether they’re still new to the role, already have been working. So I think, um, let’s jump into those. I think that those will be very helpful for the listeners.
Should you have technical background and development experience?
[00:07:05] Banky: Okay. Uh, thank you Daria.
There’s been a lot of talk about should this scrum master should have technical background or should you be like, technically sound, should you be an experienced developer or can you just jump into the role having taken the course, having, uh, you know, spoken with people or learn a few things.
Can you actually do this?
Working with developers when you don’t really know about what development is in terms of what developers do, the coding stuff and all of that, and that takes me to the real question.
These days you find scrum master job placement like job roles at vacancies. Now you would see the scrum master has to be experienced in SAP, Salesforce or type Microsoft 365 dynamics.
So they probably write things like, maybe you would’ve worked in that space before, or you have experience working in that space. For me, I’ve thought about this a number of times and I thought, okay, we could bring it here. Let’s, let’s discuss it. People would definitely benefit from your.
Point of view at what you, what you would like to share. And some other persons can also share their thoughts maybe in the comment section or whatever it is. Now, can we say that Scrum master role is industry application or system agnostic? Mm-hmm.
[00:08:27] Daria: I think it is. Well, but I’m kind of looking at my experience working with teams and I worked with teams in many different industries.
Some technical, super technical, some not technical at all. Even though maybe I’m not an expert in what they do or the product they’re building, I didn’t feel that it prevented me from actually supporting the team. Um, but there is a but, right? So I feel like there is a little, uh, caveat that you need to be able to pick up on, um, the, what the developers or team members are actually talking about in such a way that you’re able to ask good questions to them, right.
So you don’t have to be an expert, but I feel like you need to quickly be able to pick up on the language people are using and uh, trying to like be able to connect the dots between what they’re working on. Because even when you are, say, coaching the team during the meeting and you want to ask some questions, For example, during the sprint planning, you need to be able to use the language they used right in your question.
And when you’re asking, be specific enough so that you can direct them in the, in the right direction when they, you want them to maybe make a decision or, um, say you think that the, um, something needs to be split into smaller pieces of work or you need to be able to understand that, okay, it seems to be way too complex.
Maybe we need to split it, but you can only understand it if you are able to pick up on what they were talking about. Yeah.
[00:10:00] Banky: Makes sense. And I, and I believe that that comes with time. Um, once these ERs that get into that role, it comes with time, it comes with you being conscious and aware that this is something you need to.
Invest time on and show sufficient interest. And for me, my experience, what has helped in the past is to, you know, reach out to developers. What I’ve found out is developers really love it. When you want to know about what they do, like you show interest. They’re always willing to support, they’re always willing to explain things to you in a very, you know, high level.
Yet sufficient, but they would save you from all the technical terms that could confuse you as a scrum master. So, yeah, I, I agree with you making sure that you, you show that interest. You’re talking to them, you are asking you understanding the, the handoff. You know, the angle and all of that would help to, to identify areas where you can help them improve.
Right. Where you, you believe that this part of this area, that there, there’s a chance for support, uh, there’s an opportunity for improvement in that area. I, I think the old thing about it is to, can we wrap it up to say, because what I got from what you’re saying is technical awareness. We, we don’t necessarily need to be.
Technically sound about it. You don’t need to know how to code. After all, if I know how to code, then the whole lessons of developers going to school to study and do all this, then so what’s the difference? If I can actually do what they, they can do by just reading off right. So technical awareness is what is key from what I, I got from what you said.
You have to be technically aware. You may not be technically sound, or you might not be a technical expert, but you have to be aware. You need to know the languages. You need to know the answer. You need to know, you know, things as the, in terms of steps of how these things can be done. Thank you for that.
Thank you for, for clarifying
[00:12:00] Daria: that. Well, because you’re coming from project management, you are not extremely technical yourself. Yeah. Or do you have developer background?
[00:12:07] Banky: Not at all. But for me, I do a lot of, uh, you know, Google Reading, I do a lot of talking to developers. I have a couple of developers from it.
It’s deliberate. Right. I deliberately chose developer friends just so we can continue to have conversations around, oh, what do you mean? When you say this, how best can we do this? How best can developers and testers collaborate more in the process of development? What do you think? You know? So I’m always having that conversation.
So even if we meet off work and we sit down to chat for like one hour, I must bring in something. That has to do with that for 10 minutes outta the one hour. So, and they’re always happy to talk about it. Right? Yeah. So that’s it for me and, and I think that is enough to be able to relate with developers and to help when necessary.
Asking questions to your team
[00:13:01] Daria: Yeah, definitely. What do you think about, I guess a lot of the times I feel people are afraid to ask questions because they feel that they, I don’t know, they show that they are know anything, you know, or they kind of show their weaknesses. And, um, I feel like because of that, they’re actually not learning.
How do you think people can overcome that fear to ask questions?
[00:13:25] Banky: Just ask. Right, because the thing is, you don’t know until you make that attempt to ask. You don’t know if a developer is gonna see you that way. You, you’re the one thinking about it. Let’s come down to, to everyone’s level. I believe that breaking down communication barrier is the very key thing, and that opens the way to.
Every other thing that happens on the team as a scrum master, you, you’re able to come in and show your expertise in Scrum. Now, don’t worry too much about expertise in technical stuff because you cannot be an expert as a developer, is. You cannot be an expert as a QA person or a tester is right? But focus on your own area.
Make sure you show value, and then reach out to people. Let them know that you’re not. Here to show them that you know everything. You obviously do not know everything, and you will be coming to them to understand more about how, how they do what they do. What is it that they do? I think it depends on how you present it, right?
Let them know they’re the champions Here. We are only a cheerleader. You’re only playing a support role. Mm-hmm. So in order to play that support role better, you’re gonna need to understand a few things about what they do, so that at any instance, you, even when they’re not seeing it, because they are busy, you can help them, you know, start looking at certain things you can think critically for them.
Anything to make that work easier. That’s what you’re doing, right? So if you come from that perspective, I don’t see developers or your team members pushing you away or treating you with. Disrespect because they know that as a scrumer, that you know what you’re doing. And again, you have the willingness, you are really willing to help the team.
And in trying to help the team better, you want to understand what they’re doing right? And, and it’s not likely that all the developers would even say no or will act funny. You probably have. One or two that would be willing to share with you? Right. Yeah, so I think I’ll encourage Scrum Masters to be very open to asking those questions and do not be afraid to ask the question.
It’s not, it’s not a bad thing if you don’t know it, and it’s a bad thing if you don’t know and you don’t ask. That is what has worked for me and it’s still working. And again, just to say people should deliberately, you know, have that circle of professional as friends. If you’re looking to understand testing, make sure you have QAs as professional friends that you can ask them.
Question, whether in your organization or outside of your organization, developer, you can do the same thing. If you’re looking for like a U I U expressing, there are, you know, thank God for LinkedIn and all these other channels, there are many people that are always willing to share their knowledge for free, absolutely free.
You know, having that conversation. Will always give you little ideas about everything. You just have to be aware, technically aware, to that point where you can help your
[00:16:27] Daria: team. Yeah, I really like that term. Technically aware. I think that’s a good term. It kind of summarizes, right, what what you need in terms of knowledge.
Strategical, tactical, and operational parts of the Scrum Master role
[00:16:37] Banky: Yeah, I think I have one other question I’m, I would like to bring here. Um, if you were to organize those, the roles of a scrum master into this category, uh, you know, we usually would have operational, tactical, uh, Strategic roles. Now also out of scrum master roles. I’m just trying to adapt into what Scrum Master do.
Right? So what just high level? It doesn’t, we don’t have to go into very details because I like to see, I. The role of M from this perspective, what do you consider operational? What do you consider tactical, and what do you consider strategic? Because at some point you get into an organization, you probably will go through all these phases, but most times, you know, if you are not deliberate about it, and I’m also talking to myself, I’m not exempting myself from this full disclosure, you find yourself really playing.
On the operational and the tactical, you get overwhelmed in those and the strategic might just be suffering. We would like to know your, your thoughts around that. If you could just share one or two examples, benefit of our viewers to understand what this part of what is Commoner does. It’s operational, it’s practical.
Strategy.
[00:17:56] Daria: I think I’m gonna look into strategic first because as you say, we’re often kind of get, uh, a big bogged down on the operational and tactical level. Yeah. And then forget about strategic. And for me, strategic comes back to the principles and values of Scrum, like and agility in general. So all things related to continuous improvement.
Related to empiricism, right? Kind of building the environment and culture in the organization, and not only in the team, so kind of going outside of the team. I feel like this is more on that strategical level because I. It takes long time. You are not gonna see results for a long time. The results are very intangible.
Um, when it comes to those things, it is actually something that can enable the team and the organization to be successful long-term with it. That’s why I kind of look at it as more of that strategic mindset where you are focusing on items in terms of operational. I think those are some of the often misunderstood stances of a scrum master.
I feel like that kind of falls often into the operational role, but sometimes it is necessary for the team to support them. And I’m talking about things like helping with organization, documentation, um, things, helping maybe set things up, maybe do a little bit of admin on like Jira or something like that kind of.
Just helping with, uh, some backlog, cleanup, you know, things like that that are necessary. You do want to minimize them in a way, as much as possible, because I feel like a lot of the operational tasks should be taken by the team eventually. So it is more they’re getting distributed, so you might need to do them.
Maybe at first a bit, but they kind of will be going away. Um, in the long term, well, tactical will be depending on what the team I feel like is struggling with right now. You’ll need to apply certain techniques or practices, depending on what is going on in the team, whether it is related to estimating techniques or it’s related to other practices they’re implementing, or maybe using some specific tools to resolve a problem.
Maybe, um, you need to run, say a product definition workshop or you need to have a workshop on the definition of done. And so things like that, they are essential. They kind of are already stepping into the strategic sometimes, but they are more focused on what the team needs in this current moment. I feel like that would be kind of the separation that I would do between the different tasks.
[00:20:39] Banky: Fantastic.
I like that explanation. Especially, uh, in the area of operational where you, you talked about eventually right? They will, it’s some, the expectation is that the team members are able to take it up. It is just to put it out there for, for the benefit of our viewers that as is commerce, uh, you get into a team, you are likely going to support.
Operationally for some considerable time, right? Uh, because these things would help, again, to build that trust. It, it, it’s also a way to let them know that you’re there to support, you’re there to help them. You are ready to get your hands dirty. You’re not just sitting on a high horse and telling people what to do.
You are for the team and to make them succeed. So when they see that commitment from that, Perspective, you know, team members will feel more at home to work with you as a scru master. Right. You’re not always referring them. That will just be for a while because eventually the goal is to help them transition to being self-managed and self-organized.
Right. But we have to do that part. Yeah. At the beginning.
[00:21:47] Daria: And I think an important part here is that that role has all three levels. And I feel that you need to be okay, um, willing to actually jump in between the levels from time to time. Say you are more right now working on a more strategical level with this particular team or this particular organization.
But if right now, in particular moment your team needs to you to take some operational tasks, you are not kind of saying. No, I’m just taking care of the strategical stuff, right? I’m not gonna like take do DOC documentation or something. You know, like I feel like the role of Scrum Master kind of goes back and say, well, if that’s what the team needs the most, and if this is the value that I can bring right now, then I can do it.
[00:22:32] Banky: Yeah. Yeah, I like that. I like that because it’s about what can we do, you know, re remembering what servant leadership is, right? We, we lead by serving others and serving others would mean consciously. Looking for ways of supporting people to make their life better, right in the things that they do. Thank you for, for that explanation that I think is really helpful.
Making retrospectives valuable
The one thing I would like to talk about is retrospective that. Is the big one I like to talk about, and I’m saying retro because, um, you know, if you go through LinkedIn, agile coaches, enthusiast, and people that talk a lot about, you know, scrum and then when we talk about retro, so people easily and quickly say, oh, don’t make it boring.
Be creative, come up with different themes, come up with different, um, ways of doing it, introduce icebreakers and all of that. Yeah. Now the way I see this in my own opinion is all of these things bothers around what style, what tool, what technique are you using? Yeah. But everything still zeros in on what went well.
What did not and how can we improve it? So I’ve worked with the team before in the past, you know, after working with them for like six months. Yeah. Now I’m gonna explain this leading up to my question. Now we’ve worked for like six months together, and when we get into retro and you say, okay guys, let’s, whether you’re adopting the link coffee or you are using what went well, or you’re using like, you know, learned or whatever it is, whether you’re using any of those things now a developer.
Actually spoke up and said, but he doesn’t understand this. We’ve worked for six months and if we check the log of all the improvement opportunities, we’ve actually implemented them. Mm-hmm. We’re getting better that if by after six months or one year we’re still talking about the same thing, that means there’s a problem.
Most, we always have things that didn’t go well or must We always have things that we must improve on if things are actually going well by their standard. Right. So I wanted to focus less on the themes, on the tools, on the ideas, because that’s how people project creativity doing retro. Right. So is it about if you use Mirror, it’s very colorful or it is about if you use just the Confluence version of Jira to take feedback or you use because there are so many tools, is it a function of those tools that would determine how people would.
Welcome. The idea of retro or it’s a mindset, it’s a mindset shift about retro. Let’s tap into your experience.
[00:25:14] Daria: Well, it, it is an interesting topic. When we are talking about retros and people are struggling with them, it all comes back to, well, you need to try new techniques. And this is, I’m the largest, uh, promoter of that as well.
Um, except that there is like, Another important point that yes, techniques, tools, et cetera. Why are you using them or to facilitate? Facilitate what? Continuous improvement. And from going back to that more strategic level, you can use many different tools and techniques. I’m think it’s good, especially if you’re struggling, but you always need to come back.
Why we’re, well, the whole point is to improve continuously and kind of, uh, to comment on when you, you say, well, do we always have to have something that didn’t go well? No. Sometimes everything was perfect, right? Was it perfect? Can you always to kind of give, uh, your team 10 out of the 10 even on the best sprints ever?
Most times not. Yeah. And the thing is that even if it’s nine point half. Okay, we have some room for improvement, right? Because perfect is not attainable. There is a quote that we like. I think perfection is not attainable, but by pursuing perfections we can reach excellence. Oh, I love that. So, and I think that is what we’re trying to kind of say.
Yes, we’ll never be. Perfect. It doesn’t mean that by default that we’re, if we’re not perfect, we’re bad. And there is this a lot more in between those two. Um, it’s more of, we always need to think about how can we improve. There’s always something you can improve and there’s always something you can do to make it better.
Um, maybe save, uh, extra five minutes of the day for the team members so that they can leave work. Five minutes earlier. Right. It can’t be anything and and I think that’s more of that, as you say. Is it more of a mindset shift? I think it is. It’s more of kind of con, continuously seeking to learn to improve.
What can I do better? And I feel like there’s always something that you can do better, and that’s what you want to focus on. I think what you want to avoid, ’cause this, what usually happens is complacency, right? It’s easy to say, well, we’re good, we’re perfect, nothing to change. And then you actually lose the moment, the momentum, and you miss the, the moment where we, you needed to change.
Right. Yeah. And now you’re going backwards.
[00:27:39] Banky: Yeah. Makes a lot of sense. Okay, so let me ask you if this, it can also help as Scrum, because it’s both ways. As Scrum Master does struggle to think about, oh, I’m going for retro next two days time. Now they are overwhelmed already, and I’m telling you this because like I did mention, I’m someone that I reach out a lot to people that I like on LinkedIn that I don’t know, just to have a chat about how does it.
Go where you work, right? What are your challenges? What are you dealing with? Maybe I can learn from you, maybe you can learn from me, right? 90% of of Scrum a stars talk about retro, so that means there’s something about it, right? That headache of, oh, it’s, it’s again, I don’t even know what to say. Some, some of these guys might not even say anything.
Right? So facilitated a retro some, some years back, even recently that team members didn’t identify any area of improvement, so that got me thinking. In the first place. I quickly, full disclosure, I quickly consoled myself that this is not about me, so don’t feel bad. We just have to find a different way of making this work.
And I thought to myself that, does it help as a scrum master to take note of events during the sprint? Take note of setting things that happen during the sprint and get it to get these things ready. 1, 2, 3 points. Keep it to yourself right now when you get to retro, if people don’t have things to talk about, you can call their attention to that.
This happened during the spring. What do you think? How do you think we could have done it better? How do you think we could have, we can avoid this going forward? Because I’ve now used it in a number of times when I see that, you know, maybe people are not talking or they’re struggling to find things to talk about.
Then I bring it up one or two, and then everybody’s talking about it. And another thing I also find is, you know, when you just reflect on the sprint generally, like we went in with this number of story points. We have some stories that we’re not able to complete. We struggled a few things. What happened?
What did we think? What went wrong? How can we do it better? Right? So I find that. People talk more in such instances. Oh, maybe we, we should have gone with that number of story. Oh, we, we underestimated that story. We actually thought we knew these things. Maybe we should have conducted a tech spike before we moved on, or our tech spike.
Maybe we should have given it to a tech lead to review and then we agree before we moved on, we assume that we got everything all covered, right? So team members will start talking. So what do you think about. Instances like that, you know, letting bring in topics when people, when team members are not able to come up with
[00:30:28] Daria: something.
I’m generally myself a bit wary of that because usually on my side I didn’t feel that it worked for me just because it kind of was coming from me. And sometimes if you bring something and the team maybe either is not ready to actually hear that this is a problem and we need to fix it or doesn’t think that it is a problem.
Yet, maybe then you’re kind of losing momentum. Yeah. I think it can be good to have a couple of ideas, but maybe a way to go about it is instead of just specifically kind of giving, Hey, here are the three topics that I thought about. I. More in kind of the way how you, well, I know that one of the problems was something related to underestimating, well, what can I do without telling the team that they underestimated?
Well, what I can do, I can bring in some facts and say, okay, so we committed to that number of, uh, tickets and work item, but we were only able to complete 50%. And what can we do to, you know, make it better next time? Now you brought attention. To the fact that they’re underestimating work, right? Yeah. Or maybe not doing enough refinement.
Um, and I think that is kind of the good way to go about it. And this is where I use different techniques. Really, it’s um, when I know maybe what the problems are, but I don’t want to bring it myself. Yeah. I want to direct the team towards them. Yeah.
[00:31:55] Banky: Makes sense. I, I think that’s the point I was trying to make, identifying topics.
Of course, I don’t just take it to the, to them to say, these are the issues. Like you rightly mentioned, you’re looking for a subtle way of directing them to see. What the issues might be. They actually would discover themselves to say, oh, maybe we we’re underestimating. Maybe we need to do more. Maybe we need to consult more if we’re not sure about a particular story or a particular item of work.
So just in summary, for the benefit of our viewers. So, so I hear you say, you know, different techniques because they have their benefit, right. The big part of it is the mindset shift about, uh, retro. Retro must be seen as sprint planning too, right? Because you can’t run a successful scrum practice without sprint planning, without daily scrum, without sprint review.
Right. So why do we see retro as dispensable? Mm-hmm. Right? Because you see teams advancing for, oh, can we do this once in a month? Can we do this? Every two sprints must we always talk about this. It’s becoming to academic. We have to come to the meeting thinking about, oh, what am I going to say? They’re gonna ask me to write something or say something.
Right while the sprint, so mindsets shift. It’s one thing I got from what you said. You know, the number three thing is for people to understand that we’re looking for areas of improvement. We’re not necessarily pointing to areas of breakdown. A, a team can be doing well, but we’re saying that there has to be something we can do.
If we’re refining well, can we refine better, for example, Like you did mentioned, can we make sure that we close five, 10 minutes before the end of the me so people must see that it’s beyond work, work, work. It can be anything that would help the team feel better, not stressed, deliver more, and all of that.
Thank you for sharing
[00:33:59] Daria: that. Yeah, I, I think one of the messages that I’ve been trying to convey, especially recently is that, Retrospective kind of became this, this fun meeting where we have different icebreakers. It’s like almost a team building meeting and uh, people are all looking at it like, well, how many team building meetings do we need?
Well, it is not a team building meeting. It’s just that unfortunately through those different techniques and practices, we kind of turned it into one. So what the message I’ve been trying to convey is I say, Hey, retrospective is a serious meeting. It, it is an important meeting. Same as when we’re planning for the sprint.
So yes, we want to have a bit more fun. It’s the end of the sprint, but in the end it is a serious meeting where we need to sit down and we’re planning really for improvement. So I think like that has got lost somewhere on the way. Yeah,
[00:34:51] Banky: makes sense.
How to measure team improvement
Banky: I’m gonna ask you my last question, um, if that’s okay. Um, so from the perspective of team improvement or growth, so how do we measure improvement?
Now you have teams or managers or directors that either rightly or wrong believe that. Oh, you’ve been with this team. The one way I will believe that you are making impact or the team is improving, your velocity should actually be increasing. You know, and this is the reality of what happens, right? I can have the velocity of 20 for three months, 20, 21, 22, if this team is really improving, if they’re learning things.
They should be on 25, 30. So how do you defend yourself as a scrum master, or how do you show that the team is actually improving? Other than velocity, because we know, you know, from benefit of knowledge that we have, an experience as a scrum master is that velocity is there to help us plan, to help the team en stage what they can do, forward planning.
It helps. The benefit of looking back. So beyond that, how do you look at a team and say, okay, we’re really improving, we’re doing well. Remembering that working software is the true measure of a team’s, uh, delivery, right? In the end, whether it is Scrum, whether it is xp, whether it is scrumban, whether any framework, at the end of the day, we’re trying to deliver a working software, we’re trying to deliver value, right?
Mm-hmm. Whichever way you go, You must end up delivering a working software. Yeah. So how do you, what would you tell, what are you gonna share with us today about this? Oh,
[00:36:35] Daria: well, um, velocity, yeah, it is kind of a tough topic because that’s an easy metric to collect. And so because it’s so easy to collect, then everybody is like clinging to it as.
If it’s the only metric that you can have, but there are much more, it’s just that they’re more difficult to get. In terms of things like velocity, I think it’s important to actually shift focus to other metrics that actually matter because velocity increasing velocity is not an objective, and what often happens in teams that are getting good at what they do.
Velocity may even go down because their estimates went down, right? So technically we’re not really looking for increasing velocity. So instead, you can switch focus to other metrics. For example, our consistency. How accurately are we planning? Did we improve? Previously we would commit to 80 story points every sprint, but would only deliver sometimes 20, sometimes 50, sometimes 110.
We can’t plan with those numbers, but right now our velocity is pretty stable. We know that it’s, we’re about able to complete about 20 story points, right? Consistency is really good because what it’s gonna help us with is forecasting for long-term goals. So if we have a release coming up or we have a certain number of product backlog items we want to complete, we will be able to do it with more, uh, consistency.
Our forecasts will be a bit more accurate and more probable. Never a hundred percent, but there will be much closer to reality if we were able to improve in this way. Right? And so I think this is something that we can show, we can show if we’re okay, if we’re sticking to the numbers of story points.
Maybe we can show the fact that the team used to underestimate or overestimate, but now we seem to be much more consistent. We’re able to estimate much better. Well, how did that happen? Well, we, we are doing better refinement. How can you show that you’re doing better refinement? You can’t. Right. You are just, well, we’re just doing better if I’m, I see that.
I know that. But how do you show that? Well, you can show it maybe through how consistent, how well the team is, um, able to estimate you’re doing better refinement, maybe you have better goals. You are doing much better story splitting into smaller pieces of work. Uh, you can look into that. And then often, especially when you’re talking about like sprint reports or, uh, showing the results of the sprint, how well the team.
Did, instead of focusing on the numbers, showing the actual results, what was delivered, the, the value delivered. And I think when you switch the focus to that, it can be helpful saying, well, here are some of the things that we’re able to deliver. Um, if you’re able to even collect maybe some customer’s feedback, right?
What, what do you think? How would you rate, uh, the team or what the team is delivering? Comparing it to, I don’t know, six months ago? Then you are trying to really get those kind of metrics, actually finding you because. I’ve been working with this company and this team since last year, and because I’m not there all of the time, I’m kind of part-time more of a coach rather than full-time scrum master with them.
I personally felt that I’m not really doing such a good job. I kind of felt like, ah, I’m not really bringing as much value as I would like to. Just because I’m not there all the time. But interestingly enough, it was people on the teams who were actually tell saying that where the help came in, right? Or what were the things where I helped them with, because I was kind of approaching the executives saying, Hey, um, just wanted to figure out what do you guys think?
Do we want to, you know, continue our contract? Are you satisfied with what I did? Because I was feeling that I’m not like really delivering to my. Standard, and they’re like, no, you’re just so great real. We could see the improvement. Wow. We could see the improvement in the areas where you worked on like, okay, good.
Because I’m not sure. Yeah. Let the team promote you.
[00:40:46] Banky: Yeah. You’ve said it all, most times, the work that Scrum Master starts do, do. It’ll reflect in the way our customers or external stakeholders most times see this stage. Like the managers, the management people, they see how the team is churning out results, right?
We might not be able to pinpoint in very specific detail. In terms of, oh, this is how, like you did mention, how do you prove that, you know empirically? How do you prove that we’re doing good refinement? Well, we’re doing good refinement because we now have smaller stories. I can tell you that before, before now, when developers pick up stories, most times, uh, six days into the sprint, it’s not even done yet, right? Mm-hmm. That’s another way. But now, if the cycle time it’s short, it tells me that yes, we’re, we’re refining better, we’re splitting our stories better, so another possibility that the team now works better.
Do you understand the system better? They understand where to go to get their answers over time, right? Then one other thing that came to mind is defect, SK ratio. Now, I know that from the perspective of quality, which is also one of the things that we strive to achieve as a team, we’re not just interested in pushing stories to dawn on the Jira bot as we are very concerned about quality delivery as well, and to achieve that, people have also spoken about the benefit of.
Defect escape ratio where we see how many defect did we have before we released, and how many defect did we get back? Use us after the release. If the difference is wide, then it helps us as a team to look back and say, how, what’s going on with our handoff? What’s going on with our quality? Process. How can we build more quality into the process of build?
How can the testers and the developers collaborate to work together better to reduce, because sometimes in my experience with developers, they have said it a number of times. There are are issues you will find in broad that. You won’t find in staging or test environment. I think in summary, I just want us to be at a point where we understand that the big part of it is customer’s feedback, right?
Mm-hmm. Which could be the user department. How do you think that we’re doing as a team, how we. Would you, if you rate us one to five, what would you say? ’cause they would definitely treat that disproportionately if you’re doing it well, they’ll say you’re doing it well. If you’re not, you’re not. You know, this may not be like metric based.
How open is my team to criticism? Mm-hmm. Are we very open to exposing ourselves in sprint review? Because I’ve worked with teams that the PO then said, No, I have, can we not invite too many people? Because once you invite a lot of people, they’re just gonna keep saying, do this, do that, do this, do that, and all of that.
So it took me some time to make him unlearn that idea. Because the truth is we always say that the Product Owner is the person accountable for the product, right? You run with the vision, but who says that the product will not has a hundred percent understanding of? The need of the customer. You can think you have it, but in my experience, even when I, you know, in my experience with customers, sometimes they think they know what they want until they see it, they start coming back on a few things, right?
So a product cannot and should not assume that once I say It’s okay, I think we can just move on. So how open are we to accepting feedback? Are we ready to put ourselves out there? And for me, once a team gets to that level, it shows a big improvement in embracing the pillars of Scrum transparency.
And we, we subject ourselves to that inspection and adaptation. It is not really an easy thing even in our personal lives. How easy is it for me to subject myself, to be transparent enough to subject myself to that inspection where I can be criticized? I still see it as a positive contribution. What’s making me feel better?
It takes a lot. It takes time. So it seems that grows to that level, not because it’s something that has to be done because it’s stated in Sprint Review. Are we very excited as it seems to go to Sprint Review? Even when we were batched last week, are we still excited to go there? And the next one, if the answer is yes, then you have a team that will go to the moon.
In my own opinion, if the answer is a no, then we have a lot of work to do. Mm-hmm. Because it’s very easy in my own opinion to say, oh, come is about failing quickly, getting that feedback. But the way to get the feedback is to open yourself up to that feedback. Right. How easy that, does it make sense?
[00:45:41] Daria: Yeah, a hundred percent.
Yeah. I think that’s all. Those are kind of qualitative metrics really. Yeah. But they are important. As important as any other metric, I feel like sometimes even more important.
[00:45:53] Banky: Yeah. Any questions from your side you want us to talk about?
The ONE advice for Scrum Masters
[00:45:57] Daria: The biggest question would be we’re kind of, um, we going more to the wrap up here.
Um, I think it was a great conversation, but I do want to ask you what would be maybe one most important advice you’d want to give to Scrum Masters who are listening?
[00:46:15] Banky: Oh, from my, in my own humble opinion. You know, just to put that there, that habit in the people say? So for me it’s three things.
Patience, flexibility, and simplicity.
Now, I’m gonna explain very quickly, patience helps you understand that these changes will not be, they’re not magic. It’s gonna take time. So you have to be ready to travel the journey with your team. Hmm. Right. So which means you will focus more on persistence than intensity of how you drive them.
Your point, for example, even if you spend five hours, training, five hours to train your team today on the importance of moving their stories on the board, right. Tomorrow it’s gonna happen again. You know, two days later it’s gonna happen. Tomorrow it’s gonna happen. Next week is gonna happen. So are you patient To understand that what you need to do is to continually say it, remind them in a subtle way, and go the journey with, rather than spend five hours and being very autocratic and being very, you know, being very particular about it.
So patience is very key.
Flexibility. So, Scrum master for me, they say, oh, you master, you are the master of Scrum, right? You understand the practices, so you have to teach the theory and practice. You have to make people understand what Scrum is. You understand the processes, so when people breach the process, you are expected to stop them.
But hey, the reality is sometimes you need to be flexible to show your team that you are for what works. For the team as much as we are not breaching the minimum requirement, even if you have new ideas, you wanna sell it to them as an experiment because from, from my experience, once you do that, can you consider this?
I think this would benefit the team, but feel free to experiment with it if you don’t find it helpful or useful. Let’s circle back. Let’s drop it. But 95% of the time they don’t come back to say it doesn’t work. Right. And if they come back to say, can we do this? Can we not do that? Uh, before Scrum Master that says: “no, according to the Scrum guide”, “No, according to what Jeff said, or according to what Daria taught me” – you cannot happen that way. No. You have to be patient with them, understand what they’re saying, and let them run with it. Sometimes it helps when you let them learn from what they do, so you have to be very flexible.
Simplicity for me is the biggest thing for me.
How, and I’m gonna give an example. How do you help teams collaborate? How do you win trust? For example, change management. We have so many body of knowledge about change management and all of that and things like, and people got certifications. They’ve done this, but then you will still find people implement change with no element of human feeling.
Right in the things they do. So you’ll realize that as much as this body of knowledge, they’re very great bodies of knowledge are very great, they’re very helpful. But where’s the simplicity for you as the person that’s doing it? As simple as knowing your team member’s birthday, simple things as simple as sending coffee.
You know, just buy coffee for your team members. As simple as just work with your team members. A few things about them. Do they have a dog? What’s their dog’s name? Do they have a cat? Right? What’s going on? Little things wins their heart. And then it tells people that you really truly care.
And once you get to that point as a Scrum Master and you continue to improve on that, people begin to see you as a real buddy rather than a colleague.
So, and when people respect you for knowledge power, right, it’s more important that when they respect you for authority, power, that, oh, he’s our scrum master. We must listen to him. No. Your authority that counts most is knowledge. The power that counts most. It’s knowledge, power, and that you care about people.
That’s the power that counts the most. So be simple in your approach to a few things. You help people to break barriers in communication in very simple ways. Talk to yourself. Conduct one-on-one for me, I’m a big fan of team members conducting one-on-one among themselves. It’s not about this Cru master doing it with I do my two yours and come back, do a show and tell for us about the person you met.
It does wonders. It breaks barrier. And once you break that barrier, people can easily collaborate. People can easily, you know, stand up to each other to say, “Hey, I don’t like what you did. I don’t like the way you talk to me in very simple ways and teams will improve. So going back to it again, patience, flexibility, and simplicity in your approach is very important for me and that’s what I do.
[00:50:57] Daria: I love that. Great, great message.
I think to, to send to everyone who’s listening. I. The three always kind of, not a three step, but the three most important things for Scrum Masters to always remember. I, I think that is really great and um, I really appreciate you sharing this with us and sharing your journey.
Sharing more about how you get where you are, but also how you were doing maybe with the, some, uh, challenges and what kind of things that you’ve seen yourself in your sort of mastery years. So thank you so much for joining me for this, uh, call and, uh, I hope to see you around. As always, I’m always happy to keep chatting.
[00:51:39] Banky: Very much appreciate you having me here. I’m happy to be here anytime. Thank you.
[00:51:46] Daria: Awesome. Thank you. So a good one.
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 scrum mastered.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.
