Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask professional scrum trainer series, where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Good morning. Good afternoon. Good evening, wherever you are located today. Welcome to today's Ask a PST session. I'm Lindsey Bella Sina from scrum.org. And today, I have J. Rahman. And he is going to field all of your questions today about agile leadership and any scrum questions that you have as well. So let's get started. And just a little bit about scrum.org. We were founded by Ken swaybar, one of the CO creators of Scrum back in 2009. Our mission is to help people in teams solve complex problems. And we do that through professional scrum training, certification and also ongoing learning experiences. And this webinar is just one of those free ongoing learning experiences that we offer. So please be sure to check out all of that on our website, we always want you to continue your learning beyond the classroom. And with that, I'd like to kick this off to Jay, one of our professional scrum trainers. And he can introduce himself and kind of set set the stage here for the q&a, and we'll get rolling with questions.

Jay Rahman: 1:48

Great, thanks, Lindsay. So, yeah, my name is Jay. I'm a PhD and founder of fractal systems. We're an agile consultancy that was born out of the frustration of witnessing the many, many failings of agile implementations and transformation that have gone wrong. Our goal is to help firms build true agile capability that really works and really delivers. So we're not just trainers, but we're active practitioners that work with firms across product leadership and engineering. Oh, and we've put together a five minute scorecard that helps folks see where they are with their agile delivery. And if needed, how they can improve it. There's a link on the screen there. So please do check that out. And do let me know how you think. Well, how it goes for you. Super happy to be here and answer some of your more pressing questions. Lindsay over to you.

Lindsay Velecina: 2:39

All right. Fantastic. So I am going to stop sharing. Okay. That's me. There we go. All right. And let's kick this off with a pretty basic question to kind of set the stage here. So what is an agile leader?

Jay Rahman: 2:59

That's a great, that's a great question, Lindsay. So we see agile leadership as the art and science of creating an environment where teams and organizations thrive. Agile leaders build close collaboration and focused on rapid organizational and team learning. I think they're also focused on consistent valuable deliveries are actually having the organization or their teams realize the firm's mission goals. I think agile leadership is the easiest way to see it is it's usually distinguished by approaches like decentralized command, intent based leadership, decentralized execution, and servant leadership. So you've seen all those sorts of key phrases when you come when it comes to to leadership.

Lindsay Velecina: 3:47

Great. So that kind of sets the stage please have your questions. Keep them coming in to the q&a, please, that would be great. This question. So only things that bring value to the customer count to the velocity, can you create estimated user stories for say maintenance tasks?

Jay Rahman: 4:10

Sorry, say that again, only.

Lindsay Velecina: 4:13

So this question from Demetrio says only things that bring value to the customer count toward velocity. Can you create estimated user stories for say maintenance tasks? This is more of a developer type of question.

Jay Rahman: 4:30

So I wouldn't worry so much velocity primarily is a great tool for planning. So when it comes to figuring out what your team is able to deliver in a particular sprint, it's a great historical measure for that. So but I wouldn't worry, I wouldn't worry so much about velocity, I think about you know, what is the work that we need to be focusing on to get to done so how do we release valuable increments and if there's work or additional work, which isn't, you know, which isn't maybe a very simple piece of work that customer will see but as necessary for delivery. By all means include that in your estimation. That helps.

Lindsay Velecina: 5:08

Okay. Thanks. Pay. So what's one common mistake that agile leaders make that you see j.

Jay Rahman: 5:19

So there's actually there's actually a view. I think, I think when it comes to high pressure, sort of agile programs and delivery, strategic delivery, sometimes what I see happening, what we tend to see happening is that agile leaders don't account for the learning curve. So you've got an organization of, say, 1000, plus developers, even 500, or even 30. Developers, they've never done this before. They've got hard targets or important strategic targets that they need to hit. The leadership team don't think about, what what is it actually going to take for our guys to learn how to do this? Well, you know, what mistakes are they going to make? How do we figure out backsliding? How are we going to manage challenges around you know how the teams are going to interact and relate and learn, all those sorts of things tend not to be tend not to be accounted for, they just assume that this is the target. We're gonna go Agile, twice as much work half the time, and we're just going to nail it. So just looking at the realities and thinking about what, what the teams need to do to shift towards that new way of working. It's important to ask. Okay,

Lindsay Velecina: 6:28

thank you. All right. So this question so says we have more than one sprinkle, sorry, reality hits. And I am really struggling to transform the daily scrum from a status check. To check it toward the sprint goal. People really tend to report out any hints, thanks.

Jay Rahman: 6:56

So the way the most the most important thing about the dailies considers the daily scrum, the question was asking about Lindsey.

Lindsay Velecina: 7:04

Yes, it's asking about the daily scrum. Yeah, kind of shifting from a status check toward really checking the progress towards the sprint goal.

Jay Rahman: 7:13

way to think about thank you for that. The way to think about the daily Scrum is it's really a risk management event. So providing a status, providing a status doesn't really may or may not be helpful towards MT managing that risk that but if you if you approach it as well, this is the tactical risk management that we're doing on a day to day basis to achieve our sprint goal, then what's going to affect the delivery of the sprint goal is what's going to come up what's going to bubble up, and that will bring your daily scrum to life. And we've done that with, you know, we've done that with many, many teams, but most importantly, with managers and leadership teams, because leadership team don't want to come along to a daily scrum. That is just the status check. What they're there to do is to manage risk around the delivery. So if you think about it from that perspective, that might change the way you interact with your teams interact in the daily scrum. Right.

Lindsay Velecina: 8:02

That's good advice. daily scrum was not a status meeting. So this next question. So the scrum guide doesn't mention managers, do managers have a place in the scrum team?

Jay Rahman: 8:19

So, do managers have a place in the scrum team? That's a good question. The way the way I would look at that is that our managers, helping the scrum team deliver the goals, if they aren't, then they've got a place, it doesn't really matter what your role is, you know what your official role is? But if you're actually if you're part of the team, you're helping deliver, you're making that move forward, then yes, absolutely. Managers in and of themselves, have a have an important place in in organizations, their goals are to help teams eliminate friction. So any challenges that a team may be having to delivery might just for mundane things, like the skills aren't there or technical things that are needed, manage that there to eliminate those frictions, to help the team to help that team really move forward. They're not there to beat teams up. Okay? And that's, that's a really important distinction. You're not there to, to whip the teams and to make them work, you know, 18 hours a day. That's not what a manager's role is, the manager's role is to eliminate friction. Their role in the scrum team is there specifically to help them achieve achieve the goal. So if you're there to help the team achieve a goal, that's great.

Lindsay Velecina: 9:26

Okay, great advice. Thank you. Sure. So, this is a common question that we get, just in general. So how do you explain the difference between Scrum and Agile in terms of how you process your work? So, it's always an interesting question since Scrum is an agile framework. So if you want to explain that,

Jay Rahman: 9:57

sure, so so agile is like an umbrella term for various frameworks or that that that can fit within it. So you have things like DSDM km, and all of these sorts of things are forms of agility. Scrum is a specific framework that has its own sorts of rules. Guidelines for that's the way to lose. It's really a subset of Agile. That's the way I would look at it. Yep. It'd be like saying, can you explain mathematics and geometry? Mathematics is the umbrella term, right? Yeah, it's just the, I'm sure I've nailed that now. Right.

Lindsay Velecina: 10:33

Yep. Perfect. So a leadership focused question here. Should leadership be attending the daily scrum? Would that impact does that impact psychological safety when they do?

Jay Rahman: 10:49

So, first of all, I think leaders don't necessarily need to attend the daily scrum, if they're going to, if they want to listen in I don't see any problem with that we've we've had our leadership teams coming along. If the scrum master believes, however, that psychological safety will be impacted, or teams are afraid, then I would, I would discourage it. It's good to speak truth to power diplomatically and perhaps explain to leadership teams that, hey, having you here scares people, and we need to figure out a way to make it safe for them. Let's work on it together. And let's be transparent and work on it together. That's what we need to do. It's all about the collaboration piece. Right? Right. Most teams aren't used to having leadership teams tap. But if you're doing it right, having a leader turn up, makes no difference whatsoever. Teams should be okay to talk about what's going on what's really happening and be transparent in their in their approach, it shouldn't make a difference. That's the ideal.

Lindsay Velecina: 11:44

Right? When it comes to leadership, itself, is that something that can be taught? Or is that something that is just innate? It's there? And yeah, what's your take on that?

Jay Rahman: 11:59

That's, that's that none of us nature? Question. We've, we have seen, great leadership has been taught. I mean, most people don't wake up one day and become great leaders. The idea is, is that you need to learn a specific set of skills, practices mindset. And you have to drill those behaviors until they become secondary and natural. The other thing is you kind of need to be able to deploy the right behavior in the right context. And that will take practice and training and time. So we always encourage and we always, when we work with leaders, we make sure that they're trained to have a good understanding of what their knowledge is. There's mentoring that happens and that needs to happen. And that that helps them helps leaders operate in real time. So when they're working with challenges and stuff, a mentor will help them figure out what is the right way forward, and execute the behavior that there needs to be that need to be doing. And then finally, there's the coaching piece where a leader has the necessary skill set. They know what they need to do, and they kind of need a coach to help them really kind of finesse it. But those those three approaches, absolutely help leaders develop, and they develop wealth.

Lindsay Velecina: 13:02

Great, thank you. For those of you who are here in our live audience, just a quick PSA, if you're entering questions into the chat, can you please move those questions over into the q&a so that we document them? That would be great, thank you. Okay, so this next question here. So it comes from Asia. I am new to Scrum. But I will be moving to scrum master role soon I understand that the estimation should be done by developers, given the fact that they had the expertise to decide how to get the work done, however, is it recommended that the product owner should be available and present when the estimations are run by the developers?

Jay Rahman: 13:49

So there's a number of so i would i would recommend that product owners around when when developers are doing that kind of thing. And primarily that is going to happen in two places. Either you're doing it in refinement, so not necessarily an event. But definitely something which needs to happen. We found that refinement is absolutely critical for protons to explain to developers and to engineers and to the team on what it is that we're trying to build, and why. And it kind of assumptions behind it and what good looks like and all that kind of stuff. So developers can estimate around that point as well. And the thing the thing is, is that estimating with a product owner in place, does two things. First of all, it ensures that the engineering team or development team really understand developers have to really understand what it is they're building. And most importantly, the product owner also begins to understand what it takes to build some stuff. So I always I always recommend that when you're doing things like that. Make sure the product owner is present.

Lindsay Velecina: 14:42

Yep. That's good advice there. So when organization culture is very traditional, and this has in parentheses, a no mistake policy.

Jay Rahman: 14:56

Notice they policy. Yeah, right. Right and the

Lindsay Velecina: 14:59

top man Each man is immediately result oriented. How can the scrum team deal with that?

Jay Rahman: 15:07

So, the thing, the thing is, is that immediate

Lindsay Velecina: 15:10

result oriented? I mean,

Jay Rahman: 15:12

immediate result oriented. Okay? They want it right away. Yeah, yeah. 100% understand that. So we work in financial services, we do a lot of work on financial services and fintechs, and all that kind of stuff. And that that culture is, is prevalent. Right? Right. No mistake, and almost a policy is, is, is okay. It's not a it's not a tell the future policy. Right. So when you speak to senior managers today, if I came along, and I gave you a plan with no contingency and budget or time, what would you say to me? I've always had, I've never had anyone say, Oh, that's great. Let's do that. I've always had somebody come back and say, Look, you can't tell the future, where's your contingency planning? Where is all of that stuff? Okay. So we can use that approach. So when you're speaking to management teams, and when you're thinking about building out gold, Scrum teams, managers, project managers, no one knows how to tell the future. And that's that that's the lovely thing about Scrum, and agility, we start with that with that foundational piece of knowledge. And we accept that from the beginning from the get go. So whenever we're kind of thinking about building stuff, it's really important that when we do estimation, or when we when we're giving, when we're talking to leadership teams about what it takes to deliver something, we're talking about a roadmap that we don't talk in absolutes. Most importantly, we found an approach that works for us is that we talk in terms of probability. So we'll say, Hey, this is the this is the roadmap, we think we're going to deliver, you know, this widget by June and the probability of us doing that is around 75 80%. So there's a 20% wiggle room, right? And what we're actually communicating, so there's a risk there that we're not going to deliver, right, we're putting because we can't tell the future. And leadership teams, good leadership teams understand that they they understand that risk management is part of the game. So when you're doing that, you can then figure out and you can find ways for the teams to communicate some variance in the in the actual delivery, and that there's going to be a bit of a fudge factor. And that's okay.

Lindsay Velecina: 17:06

Great, thank you. These questions are, are very broad, and kind of all over the map. That's great, though. Thank you all for bringing your questions here. This is great place to bring them. So how do you get developers to volunteer to pick up work themselves instead of imposing work on them?

Jay Rahman: 17:32

But I'm an ex developer. So not an it's not just developers, no one wants to be told do this or do that? Right. So I think the thing is, is that a great a great approach is to talk about it in the in the retro. So you have a retrospective, and you say, Hey, guys, how do we want to how do we want to work together? So nine times out of 10, if you if you if you have the luxury of starting a team, and you're right, the beginning, you can figure out and you can build up a team charter. So what are the values? How are we going to interact? What are we going to do about what we don't want to no one wants to do? How are we going to do that? What is the way that we're going to work together to deal with those sorts of things? And guys, do we really want to be the kind of team that? You know, the manager says, Hey, you're going to do this? And he's going to do that? Is that? Is that how we're going to play the game? Or would rather work as a unit and try and figure out, okay, some days, I'm going to pick up the great stuff, sometimes I'm going to pick up the other stuff, and we're going to work together to get the goal done. Ultimately, if we deliver as a team, if the team wins, we all win. Right? So that's, that's where I'd have that conversation. The retrospective is the best place for it.

Lindsay Velecina: 18:37

Okay, great. So that's what retros are for. So, next question here from Shandra. How do we measure the maturity of a scrum team? And what should a scrum master do to improve it?

Jay Rahman: 18:54

How do you measure the maturity of a scrum team was? So big question. That's a that's a big question. That there's a couple there's a couple of things that you can do. The most important thing is to figure out you know, what does mature mean for you? I tend to find that teams that are brand new to scrum there are they really don't really understand the practices. They don't understand the framework. They don't understand why. Why are we doing retros why are we doing daily scrums? What does that actually mean? And we talked early on about risk management as being a fundamental tenant for the daily scrum. So we were working with an asset manager in Georgia, we had the CFO as part of that team, that leadership scrum team. And we had to explain to him why would have him turn up to a retrospective. So he's saying to me, Look, Jay, I'm managing. I'm the CIO for the bank. Why do you need me here? And the question was, well, the answer was, Well, look, it's the risk management exercise. How is your leadership team performing? How are you going to help them? Do you understand why that's important? Can you see why that's important? It was like What if his risk management I'm going to Aviva. So, those sorts of things are fundamental things, right? So when, when a team is at that fundamental level, you want to be making sure that they understand why they're doing Scrum. Why are they doing Agile? Why are the the events are important? Why, you know, why are the roles and responsibilities and the accountabilities? Why are they there? They should they really should understand why. Okay? When teams move from that kind of basic view, so they understand the framework, they're executing it well, and we start to think about things like, definitions of done, are we releasing value? Are we picking up work automatically? When challenges come along? Do we wait for the scrum master to turn up? So when I was working? Yeah, I was working with a brand new team in a financial firm. And I came in one day as a scrum master. I came in one day, we had a desk move. I come in, and no one has moved. What had happened. The developers were sitting around going, are we waiting future? While we wait for me? Oh, well, we lost the Destiny plan. Right. So no one decided to go and ask anyone where the plan was, or you just wait for the scrum master to stay out? Right? Yeah. And that was a brand new team, they hadn't thought about self organizing, or self healing or fixing their own problems. They were like, we're just going to wait for the scrum master to rock up and tell us what to do. So that's a new team, right? A more self organizing team will be thinking about, okay, we don't need the Scrum Masters sort this out, we can figure this out ourselves. And you'll start to see them self organizing, fixing problems, fixing challenges themselves, nine times out of 10, if you're doing it right, when a team is really cooking with gas challenges will come and disappear and problems will be eliminated. And the scrum master won't even know about it, it will just happen. Because the team will be self organized and knows the kind of work on that kind of continuum. The most important thing for a scrum master to do is to be consistently observing how the team is doing and how they're dealing with challenges and problems, as well as how they're executing the framework. Are they doing it? Well, I'll be getting every out the door, or we will be working with the product owner? Well, do we understand what it is we're building? You know, how is that predictability? How do we deal with challenges? Those are the kinds of things that a scrum master should should be doing, observing and intervening when they need to? Right. I was trying to make that really big question.

Lindsay Velecina: 22:08

Yeah. That's, that's great, though. And I hope that answers your questions. Shandra. And if you have anything, follow on for that, please be sure to drop that in the q&a here. So this next question, so I think this could be an opportunity for you, Jay, to kind of think about a story on your side that you can share. Maybe you can kind of tie in the leadership perspective here as well. But are there specific steps that we can implement to be a successful scrum team?

Jay Rahman: 22:39

Are there specific steps that we can implement to be a successful scrum team? Yep. That's a great question. I think I think the most important thing is to really understand just actually, as part of genres questionnaire you're on, the most important thing you can do is really understand what why you're doing Agile, what is the what is what is it that you're trying to achieve with agility, right? And then how does scrum fit in par that get good really, really good at working out how to do Scrum? Well, what tends to happen then is that the team will get really great at fixing local problems, team based problems will get fixed really fast, because you're greater, then what will happen is the team will start to butt up against the the organic leadership layer, right, the management layer, the upper leadership layer. And that's where the team can begin to influence leaders and help them figure out what they need to do to help support you as a team and how to move you forward. We we were working with a great story for this actually, as we were working with a quant team, a couple years back just this just before COVID, actually, and we were helping that team, there's about 50 Guys and girls, really smart people, PhDs, absolute, like legitimate rocket scientists, these guys were the most educated, smartest, brightest guys and gals on the planet. And they were, you know, they were managing a lot of money. And so what we found was, we had to help these guys and gals, these teams, coordinate well, delivers, deliver value, deliver product, well, most importantly, manage the funds that they were managing, do that well and keep risk down. What happened was was when those teams started to manage and fix all of their local problems, all the interrelationships and all those sorts of things, they would have other challenges that they couldn't resolve. And so the managers need to step in. Now in financial firms, managers tend to be quite command and control. And so we had to help these guys learn a different way of of helping their teams instead of, you know, carrot and stick. It's more about what are the frictions that you're dealing with that I can help you eliminate? You know, leaders have a massive, massive responsibility. And they're also under a massive amounts of stress and pressure, right, so they don't always have the time to fix everything. The lovely thing about Scrum is that reduces their time. It reduces their management time because the teams will only come to you when they've got a challenge. What these guys were doing is that they were finding ways them to instead of telling teams what to do was to assisting and supporting teams in eliminating the frictions that they were facing. So they will just get quicker and quicker and faster and faster. And some of the great things that came out of that was that the teams pretty much doubled their productivity, so that any kind of goals that they had to achieve that achievement quicker, most importantly, they were their decision making the decision cycles went down. So when you're managing, say, 25 billion, right, and you really need to think through how long things take. It will take sometimes three to six months for them to come up with a decision. We've got that down to days and weeks, just because the operating better, communicating better, and all those sorts of things. That's great.

Lindsay Velecina: 25:42

That's great advice. Yeah, it's always good to hear an actual story to kind of explain it in motion.

Jay Rahman: 25:49

The thing is lean leaders. Love agility, because if they if they look at it as a management approach and a risk management approach, it just brings down their overhead. So instead of having to chase teams and figure out where they are, and you know, who do I need to go after, and where's the work, and they don't need to do any of that stuff. What they need to do is help teams become self healing, self organizing, self improving, that's where they need to focus their time, such that when there is a challenge, you don't need to go up and chase the team to cheat the team will be chasing you. There'll be saying, hey, you know, a Lindsay, you're, you're you're running three teams here, you know, can you help us overcome this impediment, and when you do that, you become a force multiplier, you start to unlock not just five people or 10 people, but 50 and 100 people, because you're gonna you're gonna be dealing with common challenges that the teams are really crying out for support for. So your role as a manager at the time overhead just comes right right down.

Lindsay Velecina: 26:49

That makes sense. So this next question here, if you're working as a scrum master across three teams, which events should you aim to join?

Jay Rahman: 27:02

Wow. So you're so if you're working as a scrum master across three teams, the first thing is, is that a well done? Right? That's, that's, that's a lot. So there's, there's the obviously, that's like three times the work and probably, hopefully three times the pay. Someone's really trying to maximize their value there. What I would what I would recommend is, first of all, you know, the first question is, are you serving those teams? Well, are they three teams that are cooking with gas? And I know you didn't ask that question. But it's really important to know about it, right? Because if you're if you want three teams that are just flying, and they don't need that much support, then call no problem. I would, you know, I would attend, I would attend the events, that I've pretty much made it you don't need to attend the daily scrums. If the teams don't need you there, obviously the other events, you're pretty much there. So to be there for those. But my first question to you would be, you know, are you serving your teams? Well, by managing all three teams, as as as as Scrum Masters, our role is to train, mentor develop, coach our teams, right? So if they're all if they're struggling, or if their various points are struggling, our time commitment is going to be much, much more, those teams won't be doing planning very well. They won't be estimating won't be they won't be learning Well, right. And our time commitment in that space will be expanded. So that's probably the first question. Can you know is that happening? If the teams are cooking with gas, and they're just absolutely flying, then you know, drop, maybe drop the daily scrums, they don't need you. They're certainly be available for the other events.

Lindsay Velecina: 28:40

It makes sense. Thank you. Sure. This next question here. So we're using Scrum to deliver learning and development initiatives rather than traditional software development? What's your advice for writing user stories and or definition of done for non software projects?

Jay Rahman: 29:01

So you Okay, so let's say scrum can be we've used scrum in building startups and helping marketing teams and audit teams and all that kind of stuff. The most important thing for you to figure out it's the definition done is probably the easiest thing. So I don't know very much about your context. So I'm going to be talking in in principles. How do you know something is done? What's the list that that we all need to agree I agree upon? So if it's learning and development, is it that learning objectives need to be there that the trainers need to be set up? Is there a schedule that needs to happen? What do we need to do to actually get to done to deploy that, to deploy that training? Do we need to have people set up? Do we need to have managers approve? Is that is that is that all part of the fix? Is that all part of the game? Sorry. So those that idea of, you know, what is the checklist? I would start with that as a candidate definition of done and continue to improve it right. So every every couple of weeks, you're going to retrospect is this a good definition of Done Do we capture everything? Did? Did we drop the ball somewhere? If so, how can we fix it? How can we build the gap? Can we do something with our definition of done to ensure that we don't drop the ball next time? So that's how I probably play with it the most, the most important thing is to start with something. It doesn't have to be great to start with something and improve as you go. Okay. Yep. That was that was a two parter. But I hopefully I think I covered both parts.

Lindsay Velecina: 30:23

Yeah. And and if, and if you need to dig more into that, please feel free to add that back into the q&a as well. So there are a number of questions here around estimations. So I'm going to try to tie some of these things together. So there's a question here of how to find out or understand if developers are estimating the story points fairly. And there's also a few questions here about just best advice for estimation planning in general. And what do you recommend?

Jay Rahman: 31:01

Okay, cool. All right.

Lindsay Velecina: 31:03

And things like that. Yeah, a few, quite a few questions here in that vein.

Jay Rahman: 31:09

Sure. Okay. So we do the second one first, about how to estimate well, that men don't do that. They will do the fairly one later. But let's, let's let's do that. You know, how do you estimate? Well, the most, the most important thing about estimation is to ensure that the developers agree on what small looks like. So I'm, I'm gonna go ahead and assume that you're using story points. Or you can use hours you can use day it doesn't, it doesn't really estimation, it doesn't really matter what you're using. Okay. So if you're using, say, for example, we're trying to build a piece of code. What we want to be able to figure out is, what is what is the smallest piece of code? What does that look like? Why do we call that a one? Human beings generally a great African out size of things, they're not so great at figuring out exactly to the minute how long something is going to take, right. But they kind of know the bigness stuff. Right? So figuring out what the smallness of something is. So how do you know, a great a great thing? Is it what's the smallest dog? You know, I would say Chihuahua. Great. So what's the biggest dog? You know? It's a great day. Okay, so how many chihuahuas fit in a great day 1050 You're gonna get, you're gonna get some kind of, hey, there's gonna be 15 chihuahuas in a great day, right? Or 22 hours in a great day. So it's a big dog and a teeny dog. So, and people weren't going to generally agree around what that takes. And that's what we're looking for. We're looking for general agreement. Okay. So when you're looking at software, I'm assuming this is a software question, right? So when you're looking at software, then you want to think about, okay, what is the smallest, smallest piece of work that we think we can do and the team agrees on? Is the smallest piece of work? Let's call that a one, one hour, one day, whatever. All right, we're talking to make it easy. Let's just say it's one point. Okay, cool. What's the biggest piece of work? Well, it's this. This is what we did last time. And it took us I don't know, it took us 15 points, we're gonna say, right. Okay, so now we know what one is. And we know what 15 is. So what's the middle? Seven points? Great. Whether you seven points. What was that? Is there a piece of work that looks like that? Yeah, it's this. So now we have three reference points. So now with those reference points, when we then considering other pieces of work that the team is doing, right, we can figure out where those pieces of works based on our estimates, where that fits on the continuum. Okay. By the way, this is why points or estimations in one team does not translate over to another team. Because each team is doing different things. They have a different context, right. So if you're building web pages, for example, your big, maybe 15 points, and your small maybe one point, but it's to do with webpages, your context sort of webpages, if you're building data, you know, data back end servers or whatever, or you're you're implementing infrastructure, your one point and your 15 points or your 18 points, whatever Fibonacci sequence you're using is going to apply to your particular context. You can't then you can't then compare teams, because it's not apples to apples, right? So that's, that's a great way of doing it. And another thing is, the teams can get practice just by going through the dog exercise. It's such a great exercise, and it's so fast, you can use chimps monkey, and you can even get really wild with it. Okay, well, how many great data inside an elephant? All right, and people will come back with the answers and ideas, and the team will generally agree. Why. Because teams are good. And people are good at figuring out sizes of stuff and bigness of things and smallest of things. Okay, so that's that question. Hopefully that will be. That's that's clear. If not come back to me. And I'll try and I'll try and be clear. We'll second one.

Lindsay Velecina: 34:34

Other one, yes. So how to find out and understand if the developers are estimating the story points fairly. So it's a little ambiguous.

Jay Rahman: 34:44

So so the word fairly seems to imply this is more of a trust thing, rather than Yeah, this is not a this is do I trust my development team? Do I trust my developers? Are they inflating the work so they can relax and go to Jim for 15 hours a day is that those are those are the kinds of questions when I hear that word fairly, those that are kind of things which kind of come to my mind. The most, the most important thing I think, in that space is is that if you have trust issues, and that's a different kind of conversation, right, we need to be thinking about, Hey, have we hired the right person? Do they understand our values? Is that is the company values? Do they understand that? Do they understand transparency and openness and honesty? Are they all about that? If they are great, then we need to have a conversation about hey, how are you estimating? What is it you're thinking about? Okay? If it's about just making sure that the guys have considered everything, then ask for help ask for support, right. So let's imagine that a team are building a product that they have nothing, no idea about. No idea, they've never built it before that or anything, they're brand new team. And they're coming up with wild estimates, then bring some help him bring some architects in some engineers in bringing some guys with some experiments. And so bringing in some guys with some experience, those people will help you figure out and help you work through your actual estimation. The other thing you can do is is that refinement sessions are, are there to help you think ahead. So you know, you know, potential product backlog with the stories that are going to be coming in, in the future sprints. So refinement doesn't necessarily have to be just about the story you can run to, you know, I asked technical teams to run technical requirements. So if you don't know what something is, you can work together as a technical team and go, Okay, we're gonna build this widget never done it before, what does it take, and then you as a team, break down the actual thing that you're trying to build, figure out the detail together as a unit and as a group. And that will familiarize you with what's coming. The technologies involved, where the holes are, where the gaps are. And so your estimates will be closer, a little bit closer to what is achievable. Oh, that helps.

Lindsay Velecina: 36:51

That's good advice there. Thank you. Yeah, trust is super, super important.

Jay Rahman: 36:55

Yeah. I'm hoping it's a second though. It's just a brand new team. And

Lindsay Velecina: 37:00

yep. It seems like there's quite a few brand new teams in the audience today based on the caliber of questions for sure. So here's kind of a fun personal question. So can you share one thing about Scrum or agile that you yourself were surprised to learn about?

Jay Rahman: 37:22

That's a great. That's a great question. That I was surprised to learn about. I think I can tell you something I'm not sure about surprised. I think the thing I love about it is the principle that we don't know, the future. You know, I was a startup, I kind of got into agility as a developer. And then for my sins kind of got greater that became a team lead, became a project manager. And when I was project managing, the thing, which kind of really bothered me was that I've got to predict the future. And I can't even figure out what I'm doing next week. Right? I've got to tell these guys, I've got to tell the leadership team, that we're going to deliver this really kind of expensive products, like multimillion pound per up with 30 guys working for the guys and girls working across this. And I've got to give you a date when it's gonna happen. And my engineers don't know. And my leaders don't know. And I don't know. But the most refreshing thing about agility, I think and about Scrum is that it's okay not to know, right? It's right not, in fact, if you tell people things that if you give people absolutes, and certainty is good leaders experience leaders, even though they're not good leaders, but they're tough leaders, they will tell you that if you don't put in some kind of uncertainty, you don't, you don't own up to the truth that you don't know the future. All of your plans are in in sand, right? It's all going to fall to bits. So that's the thing I love the most about agility that helps.

Lindsay Velecina: 38:58

So this next question, so as a Scrum Master, how does one help the team to slice the stories? Are there any specific tips or techniques that you would recommend for the scrum master to help the team with slicing stories? Smaller pieces?

Jay Rahman: 39:14

Sure, look, you know, I always find that if, as slicing stories, primarily, I always find my view is, is that if you're a technical scrum master, and you've got a got a coding background, that really helps because you can really kind of get into the nitty gritty in the detail or build. Ideally, though, what I would always say is, I would say, look, think through what is the smallest piece of work we need to do to actually deliver some value across, you know, we don't want to be focusing primarily on complex back end stuff or, or you don't want to be focusing on just small, small components. What you want to be doing is you want to be thinking about what can we do to release value? And what is the smallest amount of things that we can do to release value? That's where I'd be thinking, that's where I'd be starting. Slicing stories can be challenging specifically, when especially when the context is quite complex, and there's a lot of moving parts, you've got a UX, you've got back end, you've got all these, when you've got all that happening. The idea is what is the minimum we can do to get value out? That's where I'd start that the temptation becomes, oh, let's just do the UX today. Unless just do the back end, next sprint, and then maybe we'll do the tetanus. And suddenly, you're now building all these different components and stuff, building out waste and technical debt, and all these sorts of things that don't work together, right. So the key is trying to keep try to keep the whole thing moving, try to go end to end. And try to think of the smallest stuff that you can do and build on that. That's, that's hard. It's a hard question to answer, because I don't understand the context. But hopefully, there'll be enough in terms of principles for you to go after it.

Lindsay Velecina: 40:47

Yeah. And feel free to add more follow up questions if you need there, as well. So this is kind of a fun question. A lot of Scrum Master focused questions in here today. That's cool. So Scrum Masters. What do you do on your first day as a scrum master?

Jay Rahman: 41:08

So that's a great question.

Lindsay Velecina: 41:11

It's a good question as well maybe paint a scenario here. All right, cool. So there's,

Jay Rahman: 41:16

there's a couple of there's a couple of contexts where we can be a day one scrum master or we are day one scrum master ourselves day one, like it's the first time we're ever doing it, or I'll be an experienced scrum master new team leader, I think the most important thing is to first figure out hopefully, you'll have another scrum master that you're taking over from, right. And if that's the case, then what the most important thing in that case is to begin to share with them and see how they're operating, and start to learn about the team. Figure out the context of the work that's being done, understand what's you know, what is it we're building? Why are we building it, talk to the product owners try and really understand what the team is all about, and what they're trying to do really, really understand that. The next thing I would do is, once you figured out the work, is trying to figure out the personalities involved, where's the team, their level of maturity and their ability to get product out the door and get delivery out the door. Now I'm using the word product. But I, you know, Scrum teams operate in all kinds of environments, audit marketing, we've mentioned, we talked about trade management and stuff like that we talked about and software, right? So it's all about getting value out the door. So how is that team in getting value out the door? What are their main challenges and problems and frustrations? What is what is preventing the team from doing all the great stuff that they're there to do? I always find that great Scrum Masters add value by fixing or helping the team eliminate impediments. So whenever I'm in there, I'm trying to figure out whenever whenever I've started a new team, once I've understood what it is they're trying to build the personalities involved in the challenges they're facing. I try and work hard to try and eliminate some value. So I try and eliminate some of the frictions, and create value, not eliminate value if you do that you're doing it wrong.

Lindsay Velecina: 42:58

Yeah, that makes a lot of sense. Hey, so here is a question about retrospective. So someone asked to recommend any interactive or fun tools to hold rare retrospectives. But in that same vein, just recommendations for more engaging retrospective.

Jay Rahman: 43:14

So there's loads of tools out there, depending on if you're right. There's Myra, there's, there's all this stuff, right? You just google and you get a ton of that. So I'm not going to go into the actual tools themselves. Fun. retros. What so what we would do is when when I have a team, so I'm gonna give you a secret here. Right? So I hope you're ready for this. So whenever we have a new team doing retros The one thing I would always do, and I was kind of honestly famous for but certainly known for was the Krispy Kreme, retro. Okay, so why is it called the Krispy Kreme, retro? Because the most important thing about retrospective is to help teams relax, and to think about how things have gone over the last sprint. All right. You want to do what you can to, you know, I would always bring Krispy Kremes whenever I'm bringing Krispy Kremes for those of you that are not, um, you have Krispy Kremes up there in the States, right? It's not just a UK thing.

Lindsay Velecina: 44:08

Oh, yeah. We

Jay Rahman: 44:10

cool Krispy Kremes are like the, you know, the king of doughnuts as far as how to be hot. 100% 100%. So when I was, so what I would do is I've been I've been Krispy Kreme and coffee. And what that does is the most important thing that kind of does is helps development teams do Scrum teams. Think about the event and the conversation differently. Most meetings are quite focused, okay. And the retrospective is also quite focused, but the mindset has to be different as to be more exploratory. It must be more inward thinking. Just bringing bringing some coffee and bringing in some food helps people relax a little bit and be a bit more introspective. India, we rock we, you know, we will bring we'll bring in some offices and things like that and retire and bofi and all these things. But here in the UK, and the states is all about the doughnuts, man. But we've run we've run we Even retros in coffee houses and different spaces and gardens, those just changing, just changing where you are, makes a huge, huge difference. And helps the team kind of relax a little bit and think and just kind of open themselves up to thinking about how they're doing. You want it to be that the team is open to introspection. And this is not a blame situation. This is about hey, we did great here, we smashed it here. And because of that reason, Krispy Kremes. We didn't do so well there, you know, we could have done a bit better there. And what can we do? Maybe we could try this, maybe we can try that and come up with some experiments that we can, that we can rock and roll with, and the next sprint to actually get better.

Lindsay Velecina: 45:39

That's really good advice.

Jay Rahman: 45:41

So what about the doughnuts?

Lindsay Velecina: 45:43

So the next question here? So this goes back to estimation, just a tiny bit. I know, we spent a lot of time on that topic. But it's refinement and estimation, the same meaning are two different ones. So when should the team be doing that? Estimation?

Jay Rahman: 45:57

Right, right. Okay, cool. So look, when you have a refinement set, so estimation, can we believe well, I've when I've used it into spaces, right? You can, when you when you've got a great refinement session happening. And teams really understand what it is they're building, and all the various components and all that kind of stuff. Nine times out of 10, when the team really understands, they can estimate right there. And then they can say this is the this is the thing that we're trying to build. And there's nothing stopping them from from running an estimate in refinement, they can also do in planning, right? So they can leave the estimation, they can go off and they can they can they understand the work when they're in planning. They're talking about a bit more than sizing things up. And at that point, they can start to estimate, I tend to find that when refinements are running really, really well the team is really is is pretty much ready to estimate and they'll just they'll just knock it out there. And then. So I tried to get my view is try and get all the all the estimation done in refinement. If you do that, right, you're planning is 20 minutes. It's like, Hey, we're going to do this, this and this. These are the stories. This is the sprint goal. This is what we're going to do. So this is the this is where we're heading toward in terms of the protocol team figures out the sprint goal. This is what we're going to do these are different stories that estimates are already there. Do we all agree with them? Yeah, we do any changes? Nope. Let's rock and roll. Let's go. And the planning becomes really, really slick.

Lindsay Velecina: 47:16

Makes sense? So we're gonna tiptoe back to retrospectives. Again, quickly, because we have a few questions that popped up. So you talked mostly about retros in the in person sense. So what recommendations for more engaging retro, when you have a remote team or a hybrid team?

Jay Rahman: 47:37

Yeah, so I tend to find that so high hybrid teams, or I'll take the more difficult, hybrid teams can be a little bit more difficult. Because when you're when you're when you have a bunch of guys and girls out in the room, they they're getting a different kind of experience to the people that are on camera, for example, right? So and what I found is, is that the team members that are on camera, or on the phone, tend to miss a lot of the detail that the the organic conversation that retrospective creates. So my view is it's not necessarily right or wrong. But my view is, is that try and do either or don't mixing, it doesn't tend to tend to go so well. If however, you can keep the contents going. And you can have people like former Myro board or something like that, and they're putting all their stuff up on there, and they're disciplined around the phone call. But then you might as well all be online, right? If you're doing if you're doing a fully online, retrospective, then what's important is is again, agreeing your ways of working. We you know, we've we've all been there where someone's doing a retro and teams there and everyone's cameras off. And what's really going on is that they're trying to get their work done. And it happens, right life happens. People are trying to get their work down, they're trying to listen in with one year while they're trying to get something out the door. They're trying to take care of their kids or the dog needs feeding or something like that. So my view is, is that when you're doing a retro, try to do as much as you can to keep the team engaged. If that means cameras on then call if your camera is off, then that means that you're not present. And that's okay. All right. The way you're going to figure that out is through your team charters, through your team agreements. Yeah, by speaking to each other and figuring out Hey, guys, how are we going to retro online? What are we going to do? What is it what is it that we agreed to do it? None of us wants to be the police. Okay, so none of us wants to say, hey, jays got his camera off. He's a bad guy we want to say is we want to say let's make it easy for Jay to be present with his cameras on and his mic is on. That means he's here with us. And if the cameras off, or the mic is off, that means Jay is dealing with something important and he will be right back as soon as he can. Okay, so those sorts of things. I'm not saying that's right or wrong. What I'm saying is, is that those sorts of agreements, help the team operate as one.

Lindsay Velecina: 49:52

That's good advice there. Yeah. And thank you audience for asking those follow up questions about the remote side of things. That's definitely super important. So thank you for bringing that up. So this question here shift gears a little bit. So what is the difference between the product goal and the sprint goal? And if you can give examples of each, that would be great.

Jay Rahman: 50:14

So I would the way I the way I see it is that the product goal is the overarching, you know, what are we what are we heading towards? What is it we're trying to do? Right? The sprint goal is more of a tactical. So product goals are more strategic. So they're more more further out. sprint goals are tactical, what are we going to try and do this sprint? So I think someone mentioned earlier on about a technical debt or widgets that are not necessarily value given to the customer, but they're necessary for the delivery to be done. So those are the kinds of things that would potentially factor into the sprint goal. And the developers themselves will figure that out. So hopefully, that helps. Thank you. So

Lindsay Velecina: 50:56

this question from Megan here. I'm a scrum master and each sprint planning event, we craft the sprint goals together. We do confidence vote on how likely we feel we can reach these goals. And the last two to three times all the goals have been breached. Do we then need story points for sizing relatively? Are they good the way they're working?

Jay Rahman: 51:24

So the team is the team is the planning of the duty reached or breached? reached? Oh, so the hitting one of their goals? They are? And they're asking if they need story points? Yeah. Well, I mean, what value if you guys if you guys have figured out the size of work that there's there's, there's actual there's actually a movement out there. And I think that you don't even need story points, right? There's no information has been out there. And we actually, we teach the same thing, if you can get your stories, which is which are sized around the same. So let's imagine every story is around the same size. It's just about counting stories, right? Or carrying PBIS. So we know hey, we can do 10, New 10 PBIS? And what's the confidence there? 95%. And we hit it every time, we know that we can knock out 10 PBIS? Why would you need as to why would you need to do points on this and on the third? So if it's working, then you know if it ain't broke, don't fix it. There's nothing to fix. You guys. Just keep going. Do you more? Well done. Right. I

Lindsay Velecina: 52:27

think that question came in when we had all those floods of questions about estimation and things like that, that probably popped into Megan's head. So thank you for asking that. Megan. Here's a question about product ownership. And this might be our last question. Not sure. So my scrum team has more than one product owner adding items into the product backlog? How can the scrum master facilitate the crafting of the sprint goal with multiple product owners? Maybe talk about product ownership? I think General and that type. I think that

Jay Rahman: 53:09

problem is is indicative that you got a symptom right there of why there is only one product owner. Because of that very reason what should be happening is that you should have one product owner who is working with the various stakeholders or what other people interested in what it is that's being delivered and figuring out. What are they going to build? Why are they going to build it that the order the priority, all those great things in order the product backlog, that's the idea. So you have one, one source of truth, so to speak, in terms of what it is we're gonna go for. When you have multiple product owners, multiple multiple products, I mean, I've seen I've seen scenarios where a scrum team, their product backlog is just just a cage of stuff, right? And people just throwing things in there. Because they think it's just a wish list. And there's no there's no relevancy, there's no coordination and nothing so that one minute the team are working on one thing, and they're working on something else, and the team just completely inefficient and ineffective. And everything just gets built in a terrible way. So the purpose of a product owner is to is to release value. And most importantly, you need one product so that the team knows which way they're heading. Right. So what I would do is I would, I would first of all, make that transparent department on his board don't know that that's what's happening. So have a conversation with them. Say, look, guys, I see the three of you here or two of you here doing this stuff. What the effect of it is this there's this is the effect this is having on the team. This is the data this is what's happening with the team. We have no idea what it is. It's one minute we're doing this next minute we're doing that. And also, I bet they're probably reordering the product backlog as they go. So now you've got all this kind of real time stuff happening. In I've seen it happen where product owners then start to interfere in the sprint backlog too. So wait a minute that my story is super important I needed done yesterday. That story that Bob's looking at He put in. It's not that's not that's not that important. So let me just take that out, and I'll throw something else in. And next thing, you know, the sprint backlog is all over the shop as well. So the most important thing is to make transparent the challenges that the team is facing by that approach. And then have the product owners figure out who really is going to be the product owner for that team. Right? How are they going to? How are they going to negotiate the work and all that kind of good stuff? Right. That's part of the game when it comes to being productive.

Lindsay Velecina: 55:28

Yeah, thank you, Jay. So we are, I don't think we have time really for any more questions. However, we have a lot of open ones here. So audience rest assured your questions will be addressed. I'm going to be sharing the question list with Jay. And if you had provided your contact info, you will be getting an answer from Jay. So I will share those with Jay after the event. And we can also figure out a way to answer the anonymous questions as well. So we will, we will figure that out. So thank you all so much. Oh, go ahead.

Jay Rahman: 56:07

Go ahead. I was gonna say that if you wanted to, I mean, if you wanted to connect me on LinkedIn, reach out on LinkedIn, if it's something super pressing, and super burning, come and find me on LinkedIn and be more than happy that I love helping people prosper with agility, come and find me on LinkedIn. It's Jay Rahman. And we can go from there. And maybe we do a podcast and just those questions. Lindsay. Yeah, we

Lindsay Velecina: 56:25

could definitely look at doing that. So as we close up here, we always encourage you to continue your learning. So please check out the learning paths on scrum.org. And also connect with us and the scrum.org community, through our blogs, and our podcast series, and also our webinar series like you're here with today, and all of the other free resources on our website, including our forums and other great place for you to ask your questions. And, again, this is how you can connect with Jay. So please, please do so. And we hope everybody got value out of the session. I'm so sorry. We couldn't get to all of our questions. But we got through 28 of them. So rapid fire. So thank you all for attending. And please keep an eye out for other Aska PST sessions in the near future, as well as our scrum pulse webcast series. We have a webcast coming up next week, focused focused around value with two of our colleagues from McKinsey. So please feel free to check that out. And have a great day and Scrum on and thank you again, Jay for fielding these questions today.

Jay Rahman: 57:51

No worries. I look forward to doing it again.

Lindsay Velecina: 57:54

Have a great day, everybody. Have a great evening. Bye