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 a 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. Welcome to today's scrum pulse webinar. I'm Lindsay Velecina. I am going to be your moderator today. So welcome. And today I have Lavaneesh Gautam with us. He is one of our professional scrum trainers based in the UK. And he's going to be answering all of your burning questions about Scrum. So any questions that you have, please start entering them into the q&a. And we will answer as many of those as we can today. And really quick about scrum.org. We are the home of Scrum. We were founded by Ken Schwaber in 2009. And our mission is to help people and teams solve complex problems. And we do so through our professional scrum training, certification and lots of ongoing learning opportunities, including many free opportunities like this webinar and the learning paths on our website, and lots of free resources. So please feel free to check those out. And I hope that today's session plays an important part on your learning journey. So with that, I will hand it over to Lebanese to introduce themselves.

Lavaneesh Gautam: 1:41

hellos Good morning. Good afternoon. Good evening, wherever you are guys. So welcome to Ask a PSD. So my name is love Nish. As you can see, I am a professional scrum trainer with scrum.org For the past three years, and I live in UK born and brought up in India. And in terms of the experience, I have a quite a lot of experience, especially in the banking and also automotive in the industrial industry. But also at the same time, I have worked with quite a lot of startups as well, something I really, really love to do. So. So I do both the training, coaching and all the consulting work as well. So I think I'm ready for some burning questions that you guys have got. So let's see.

Lindsay Velecina: 2:33

Okay, so everyone could start entering your questions. So here we go. Here's a question that just came in. What is the best practice to use when management still needs to do a yearly performance review for members of the scrum team? Would retrospective boards be a good plan? What ideas do you have around that lab and niche?

Lavaneesh Gautam: 2:54

That's a really good question, actually, what's the best practice to use when management still needs to do yearly performance reviews for the members of the scrum team? So I would say some there could be some good and bad practices or obviously around it, but it's pretty much depends upon what level of organization we have got and what is the maturity of our organization as well as as well. So I give you one example. So I have worked in certain organization where our annual objectives or performance reviews, they were pretty much the individual performance based, okay. So you are writing your objectives driven from your line managers, you are just making a little bit changes to it. And then even when you are filling those annual objectives, it makes no sense. And then we are judged based on what thing that we are filling out. But in one place, when we I saw this thing happening, sometimes as a Scrum Master, we have to act as a change agent as well. And that's the moment when I worked with the HR and other line manager. And we moved those annual objectives. Not just the individual performances, but also from the team's performances as well. And we will be answering those team performances and those individual performances every quarterly. Because we work in a complex environment things changes very frequently. So I think you're right, we need to be agile in our annual performance review, as well. But it's a big cultural change. And I would say, as a Scrum Master, we should show low tolerance for impediments like that.

Lindsay Velecina: 4:46

That's some great advice there. Thank you. Right, and if there are any follow on questions from that, please feel free to enter those into the q&a as well. All right, so this question here so How do you deal with a situation when the scrum team developers in particular complain that PBI refinement for upcoming spreads is impacting on their productivity and ability to deliver in the current sprint?

Lavaneesh Gautam: 5:16

Again, very good question as well means what's the aim here, keeping the people busy or delivering the value. And I think refinement plays a huge importance in especially the bringing the focus back on the value aspect as well. For me, refinement is an activity where we break the big items into the smaller items, but and also we understand the value, the size, and also the detail behind those product backlog item as well. If we are not doing that refinement, I think we will be entering into the sprint planning with the garbage. And again, it may end up into garbage in garbage out, you're entering into the sprint planning with the garbage and very highly likely we are getting the garbage at the end of the sprint as well. So choice is ours. Do we want the value? Or do we want the busy people? I think I would go with the value.

Lindsay Velecina: 6:18

Definitely. Okay, great. Thank you for that question. All right. So this one here from Zack, how would you recommend handling waterfall project related work that needs to be assigned to a development team music, Scrum, examples of this work would be go live support, project related development work needing to be done by a deadline etc? Yeah.

Lavaneesh Gautam: 6:49

Really good question. Again. So when we're talking about project, I think here, we need to see that the project and the products, they have got very different kind of mindset as well. Projects, yes, on time on budget on scope delivery, awesome project. But I think that on time on budget on scope, delivery, and meeting, those guideline can still deliver crappy products as well. And that's where the focus on the value comes in, and how to handle this thing. So even I know they're in certain places, they sometimes we have got those deadlines, especially let's say, if you're working at a regulatory environment, I have worked in the banks, I have worked in those regulatory requirements as well, we are we have to meet the deadline, otherwise, you will get fined. And more importantly, it's it can be the huge reputational damage. And I think in those terms, still, that's something that we need to do is that inspect and adapt, which is I would say the call to the Scrum is really, really important. And I think in those kinds of environment, the scrum can fit really, really well. We all have worked on to test tasks, which turned into three days and the four days, okay, we work in a complex environment, things changes, shit happens, those things happens. So, again, we have to be able to adapt our plan. So if we have got our deadline fixed, the only thing that we can probably play with is probably the scope than Okay, so even if you so I have worked in one of the regulatory environment. And what we did was, yes, we had a deadline, but we learned that what are the most essential thing within that regulation that we have to meet Not everything has to be met in that regulation as well. So the thing that we kept flexible, and that was the scope. We cannot have all in the complex environment. And that's something that we need to see if we tried to see on on time on project on scope delivery, then only thing that we are compromising is the quality, which I think we shouldn't.

Lindsay Velecina: 9:03

Right. Hey, awesome, thank you. So this question here. So keep these questions coming audience. They are all across the board. So we're going to be jumping all over the place a little bit. So this question from Anne. She asks, Can we change the team structure for one sprint during a longer project with more sprints, for example, take out a back end developer because of a little workload for our back end, who is responsible for this decision?

Lavaneesh Gautam: 9:40

Making? I like the question, can we change? I would say yes, we can. Yeah, nothing. Nothing stops us, isn't it? Nothing has stopped us in in making those changes the team structure. I think what comes next is what is the impact of that change? Okay, so are we just doing the workload management? Or are we doing the value based product backlog management? I think that that's, that's a really important thing. Okay, if the back end person hasn't got a little workload, but first obvious choice would be, can they go and help other people. And this is where I think that mindset of keeping the people busy comes in, rather than thinking about the value in itself. I have been business analyst a lot in majority of my life. But when I was working as a business analyst, sometimes I have done testing as well, whenever I had the workload, the less workload. So the first thing is, can I help someone? Is it within the team? And this is what we need to see is the team goals over the individuals goals, rather than keeping the people busy, deliver the value. Second part of this question was the who should take that decision? Again, people who do the work is come talks about the self management and self management needs is the people make their own decisions. This is I think, that team based decision, which is something should be taken by the team. Baby, if they get the developer, they cannot take the decision by themselves, maybe a scrum master and the product owner, they can help in that. But I think the ultimate decision should be with the team rather than anyone else.

Lindsay Velecina: 11:36

That's great. Thank you. Right, so this question is more of an idea proposal, I think we might need to get some more context. But maybe not. Maybe you've seen something like this before. So Avinash, what do you think of using or implementing an agile maturity scorecard? To measure a scrum teams adherence to agile practices? What types of things have you seen maybe like this before?

Lavaneesh Gautam: 12:06

I have seen a certain models, certain agile maturity models, there are quite a lot of out there. And the one thing my experience has been, there is no one size fit all, guys. Every team is different. Every product is different. And every pro if you're working on the projects, delivering certain products as well, that context matters a lot. And that's my biggest challenge, especially with these silver bullets, which people say that okay, use our scorecard, and you will be awesome. I don't think that works in the context. Maybe it could be a good starter. I'm not saying they're bad. I think there could be the good starter. But I think we also need to see which part of the scorecard and all actually work in my context as well. Okay. And this thing is really, really important. The essential part is Scrum is all about inspect and adapt. And we should be courageous when of the scrum value in making those changes as well.

Lindsay Velecina: 13:12

That's great. Thank you. If there's any follow up on that one, please feel free to drop that back in the q&a. Okay, so this question, does the daily scrum eventually eliminate the need of other meetings that a scrum team maybe had prior to using Scrum that they used to do on a daily basis?

Lavaneesh Gautam: 13:38

Very good question again. So does it replaces the other meetings. I don't know what other meetings actually we're talking about as well. So, and hence what we need to see it what is the purpose of the daily scrum the purpose of the daily Scrum is that we are inspecting our progress towards our sprint goal, which is reflected into the sprint backlog. We look back into the sprint backlog and then we create our plan for the next 24 hour. Again, to meet our purpose of the sprint, which is the sprint goal. That's pretty much what the daily Scrum is. It's a It's I would say it's a mini collaborative planning session for the developers. If you are having some meetings, maybe the pre scrum which are fulfilling the similar kinds of objectives and the purpose then yes, you those can be replaced by the daily scrum. But if the purpose of those other meetings is very different than this, I'm not pretty much sure that whether we can remove it or not. I probably I need a little bit of context behind what those other meetings are doing actually

Lindsay Velecina: 15:01

Awesome, thank you. All right, so next question here, I'm gonna see if I can. So longer question, but I think it's an important question. And I want to see it there. If I can. I'm going to share this question with everyone in the chat so everyone could see it as well. So this question comes from Kathleen. So she needs some ideas for how to implement scrum with a technical support team. About half their work is technical project work. But the other is based on incoming work requests from customers and internal stakeholders. How do I manage this in Sprint's just use the sprints for project work? And assume the capacity is really half of their time, since the other half is essentially support cases? Like how do you make that balance? What have you seen on teams with this type of thing?

Lavaneesh Gautam: 16:00

Awesome. So I can share my experience on that, and how I had two different kinds of experiences in it. So So when we're talking about that technical support team that is doing a bit of the Bau kind of business as usual kind of work, but also the feature work as well. In one of the instances which I had in one of the financial services institution, what we identify was that there are a couple of people who would be looking after that Bau kind of work, and that rest of the team will be focusing on the feature development. So that little restructuring of the team helped us in providing the better focus. And that better focus actually resulted in into the better productivity and better quality. So that was one solution. I have seen the another solution is very much similar to what you have suggested, clean is around checking, okay. It's come is all about the collecting the data. So I in those days, what we did was we looked into our past few Sprint's that how much generally our time is going in working on this technical project work. Some tickets are keep coming, some people request in the PTO request that on average, how much of our capacity going in there. And then, based on that evidence, we were only planning for the work which was remaining. If we have been lucky. And if we haven't got any incidents coming, any technical work coming, we all have got so much of bog backlog filled with work, we can always pull it in. So So one suggestion I could always say is create a sprint goal. Okay, identify few sprint backlog items. And then if one or two sprint backlog items are completed, and you still have got some time left some capacity left, maybe you can always pull in, you can always pull in so strong with Kanban. That will be my suggestion.

Lindsay Velecina: 18:11

It's great. And kind of tying in this question, there was a question that came in about reducing work in progress. So what techniques can be used to reduce work in progress for the scrum team during a sprint?

Lavaneesh Gautam: 18:29

So we are we want to reduce the work in progress, isn't it? Is that the question?

Lindsay Velecina: 18:35

Yes? What techniques can be used to do so.

Lavaneesh Gautam: 18:40

So the first pass post is, obviously use the work in progress limits. And if you're using it, I would say that reducing the work in progress limit should not be the aim increasing the flow should be the aim. Reducing too much of work in progress limit, some times I have seen has not been helpful for certain teams as well. So what we need to learn is what is the right work in progress limit for us. And that's something what we need is inspect and adapt again. Okay. So if you see that during the sprint, there has been certain situations where we didn't follow our work in progress limits, we broke it some time, then maybe that's a sign that maybe our work in progress limits are not right. Or another could be that we had our work in progress limit setup. But majority of the time, our the word that we had is always under that work in progress limit. That's another sign that maybe our work in progress limit should be reduced as well. So these are the few signs that we need to read that we need to see to adapt our workflow and the workflow policies. Work in Progress limit is part of our workflow, workflow policies and I think we should regularly inspect and adapt as a team learn more, they implement changes as well. Reducing whip limit. Yes, it is an aim. But keep reducing, it probably can end up into a different problem as well. So every environment is different, I would say find out the right whip limit. And for that, we need to inspect and adapt that perspective, make whip limit a part of that perspective?

Lindsay Velecina: 20:32

There you go. That's great advice. All right. So this next question here, how do you best deal with teams who are over committing nearly every sprint? How can we best help as a scrum master?

Lavaneesh Gautam: 20:48

So I assume when we think over committing they are selecting five items, but delivering the three items? That's what I'm assuming?

Lindsay Velecina: 20:57

That's what it sounds like something along those lines? And please clarify if that's incorrect in the chat.

Lavaneesh Gautam: 21:05

I believe this is how it would be maybe. But if it is, if it is, then that's it thing is this this is what are the indirect prospects are for retrospectives are not just for Okay, what did go well, what didn't go? Well, these are the data that you have got in front of you guys, we selected five items, but we only delivered three, is this the right throughput that we have caught. And if we have got, then in the next sprint planning, select only three items. Again, we work in a complex environment, full day's tasks can turn into five day stars very easily. Okay, when you are planning the work, you sometimes cannot see, there's so many dependencies that we got so many blockers that we got, sometimes we can open a can of worms as well, those unforeseen will only get on earth when we actually start working on it. And this is the thing that we need to discuss into our retrospective ties, what happened with our estimation, is it something because of certain underlying reasons that we don't understand it? Okay, or maybe we can take this opportunity to get better at our estimations as well, because this is what I have done in my, in my journey as a scrum master, especially in the early sprints of any product, I always look into that, okay, guys, how much we have done. Okay, how much we planned for how much we delivered. And then based on this empirical data, then we are built setting up a learning about our capacity in the next sprint, which again, changes up and down, which always keep on changing. And I think is probably what we were looking for here is the predictability. And we should use the data for the predictability rather than finger in the air, I can do three, I can do five. I think if the data suggests team can only do three, okay, COVID Three.

Lindsay Velecina: 23:08

Awesome, thank you. And if you need clarification on that person who asked that, please let us know. So this next question, I am going to paste it into the chat. So everybody sees it because it is a bit lengthy. But I think you can provide some good advice here lob niche. So in traditional water, fall development are the byproducts is that you typically have documents that capture all the business rules in one place. This is not the case in Scrum, where the business rules are scattered throughout various user stories. And it's difficult to understand the complete picture of the applications, business rules. How do you handle this? So if you want to maybe share some insights here, and I'm sure you have some good tips to share regarding definition of Done here as well.

Lavaneesh Gautam: 24:00

Yeah, he's, again, when we're talking about these business rules, I believe these business rules could be yes, those. Sometimes we have to document those business rules, especially for the audit. I have, again, I would give the example of working in the banking industry where because we are heavily regulated, so we have to adhere to certain business rules, we have to capture those business rules as well. And the documentation is a big part of the work that generally we do about rather than again, making the documentation is a one time activity. We were doing documentation as an ongoing process in itself and that's where we Lindsay as already suggested that we made it as a part of our definition of done so if you are building any features, if you are building any Some solutions, related documentation if it is required regarding the business rules and all, and especially sometimes the standard operating procedures, things like that, we will be building at the same time when we have built that features in in itself. But this, the good thing that happened was because our we have just built it, our information is fresh, and you're able to write the things better. Whereas if I tried to write the same business rule three months down the line, I have to put so much of effort to just remember what actually we did. And that's where we start losing some productivity as well and make mistakes.

Lindsay Velecina: 25:45

Right. So I

Lavaneesh Gautam: 25:47

would say iterative and incremental way of documentation helps. Yes, documentation are for the features. Right?

Lindsay Velecina: 25:57

That makes a lot of sense. Okay, so this next question, how as a scrum master, would you handle a situation where two talented senior developers don't agree on the estimation of a high priority user story?

Lavaneesh Gautam: 26:15

Hey, awesome. Get the data. Okay. So again, remember in story pointing exercise is an complementary practices that many Scrum teams they do it is not part of the system. First of all, I would like to make it clear. Yes, because many teams, they still do, because you want to have the predictability how much time it may take. But again, you call it three, you call it eight? What matters? Is that why that person thinks it is eight and why that person thing is three. And the discussion that we have, that we are having at that very moment, is the crucial rather than that pointing in itself. If someone asked me, I don't care about the points, I do care about the discussion that is happening when someone is saying that, okay, it is eight because I have to do a lot of regression testing. And someone says three Oh, come on, we already have got some automation test scripts already written for that. Yep. And that's a conversation that we need to have, because that's where we are sharing the information, we are calling out our assumptions and we are creating our solutions together. So, if you are using this planning poker story pointing kind of exercises focus more on the discussion rather than the points in itself, okay, points points don't matter, and they are also not the measure of the value whatever it is, you will you will know in a month's time or the two weeks time whatever it is, but then use that evidence. So that wherever the similar kind of work coming in the future, you know, how much to the point you need to give, but I would not spend too much of time and just keep bickering on whether it is three point or a five point I will just put any and then see okay, how how big it could be.

Lindsay Velecina: 28:13

That makes a lot of sense. Thank you. All right. So we have two questions, here are two different people that are the same. So how do you handle if Well, the first question actually, so, can the daily scrum go beyond the 15 minute time box? And how do you handle it? If if it does do finish at the time box no matter what or do you say a few minutes longer?

Lavaneesh Gautam: 28:47

Again, I have got very practical and pragmatic approach on this. Not to be honest, I would not just say it's comply say so we have to finish it in the 15 minutes. The thing is that we joke and that again my experience majority of the places they are the daily scrum last more than 15 minutes is the place when generally be doing that round robin individual status updates. That has been my experience in maybe a couple of cases people are doing the really good daily scrum I hardly have seen it is crossing the 15 minutes. So if it is crossing the 15 minutes what we need to see is that what kind of discussion are we having? There are so few options that is causing that 15 minute is yes, you are providing the individual status update to the scrum master where everybody's saying, Oh yeah, yesterday I work on the JIRA ticket 56984. Today, I'm going to work on the JIRA ticket 7698 For no impediment, thank you. And that keep on going where nobody is listening to each other. You're just providing the status update. So that's not the pope Most of the daily scrum guys remember, it's a plan. It's a planning. It's a collaborative planning for the developers. So my suggestion on that would be, Okay, think about the most important product backlog item, what's happening on this? Okay? What's the plan for the collective developers look like somebody is maybe doing a bit of analysis, somebody may be doing a bit of a coding somebody, maybe writing the test cases, once you have understood your plan for the most important item, then come on to the next, then come on to the next, then come on to the next by this way, you are focusing on the work rather than the individual. And you will see that the collaboration and the quality of discussion that is happening in those 15 minutes is going to be quite high. And that's what we are looking for collaboration and clarity, and the transparency, not the status update. Crossing the 15 minutes very highly likely it is turning to the status update. And maybe if you say whether it can cross. Yes, it can cross but I don't see that sir. Reason. Generally, there are some other reasons maybe we we are not doing the daily scrum the way it should be.

Lindsay Velecina: 31:17

Right. And I'm actually going to drop a video and for the audience on this very topic. daily Scrum is not a sexy. Okay, so we're gonna switch gears to a different scrum event. We're going to talk about the retrospective. But this person is asking question about a management perspective. So it sounds like she's involving management in or he or she is involving management in their retro. So just wondering if you have some ideas on facilitating a management retrospective? What sort of question are, what sort of questions are applicable to drive a positive output and give a sense of safety, I will be facilitating a chapter lead retro in two weeks need some help, as I've never done this before, anything that you could share, for facilitating a retrospective? Oh,

Lavaneesh Gautam: 32:15

I don't know what this management retrospective is. But I believe based on after listening to ulinzi, that it may look like there are some land managers or the leadership they are coming together. And then we are doing a retrospective on that. They may they maybe it's not the scrum team retrospective, but the leadership and the management, they're coming together and thinking about certain kinds of continuous improvement, if it is happening, awesome. Because learning should not be just limited to the team, it should go beyond team as well. And the management that leadership should learn as well, continuous learning should be an habit. So just certain facilitation technique, if you will, if we are doing in that as well, is basically the management level people's sometimes they have caught conflicting goals. And I think that's something that we should address as well have you caught certain conflicting goals or goals or not. And in the end, if you're looking for certain kinds of facilitate facilitation tips, and all, I would definitely suggest use this technique, the one of the liberating structures called One Two for all managers, they love to talk some of them at least, and in some times, in those kinds of management talks, the quieter voices they are not heard. And we need to be quite inclusive, in especially in this kind of continuous improvement sessions for the management and the leadership. So use this one too, for all what you do is in one to four all you provide, first of all, one minute everyone to just write out their opinion, suggestions, the challenges, whatever you want to focus on. And then you divide the people into the peers, where they explore more and more ideas, maybe discuss their ideas further as well refined their ideas, challenges for the court, then these two peoples they come together, they create a form of for and in this kind of facilitation technique, what happens is that you get ideas from everyone, it is very inclusive, it is very, I would say very psychological safe environment as well. And sessions like this requires loss or loss of ideas. So what to for all, I would say and also please explore these liberating structures as well. You will find their loss and loss of facilitation techniques that you can use as well probably I would add something like 15% solution on top of it as well. 15% solutions are that you identify At least one action, which doesn't require anybody's approval. And it, I think it brings that make the continuous improvement a habit, rather than a one off activity. So what to for all along with something like the 15 person solutions, these could be few liberating structures I can use to facilitate our retrospective, which involves management and leadership as well.

Lindsay Velecina: 35:29

Great, thank you. And I dropped a link with a whole bunch of different filtration techniques for sprint retrospective, some of them that lamination already mentioned from liberating structures and some other ones as well. So feel free to check those out. We have

Lavaneesh Gautam: 35:45

great, great learning material on the facilitation skills on the scrum.org website. Lindsay. Yes, yeah.

Lindsay Velecina: 35:52

So check those out people. Yeah. So I did drop a link there. So this next question here, so someone is asking, so I have I've two client focused questions. The first one is, I would like to ask, what should be done when you had run four to five spreads? And the client did not like the outcome and decided to revise the project?

Lavaneesh Gautam: 36:22

Is this question? Okay, so I can see how to stump? I would like to ask, yeah, yeah, I would like to ask what should be done when you had for five spreads. And the client did not like the outcome, and they decided to revise the project. If they don't like it, it's okay, isn't it, at least we are getting some early feedback rather than spending our 1015 sprints and that's when the learn that okay, the client doesn't like the work that we have done. And this is where the Scrum is a risk mitigation opportunity. So, so my one suggestion on that would be many times, we ask the client, what they need, instead of why they need. And this is really important. So in our PSU class, we talk about this a lot, consider customers and the client as an expert of problems, not as an expert of solutions. And when we, when we treat them as an expert of solution, sometimes these kinds of problems started happening as well. Okay, I have been in too many situations where we have delivered exactly what the customer asked for. And then when we have gone to them, and they say, oh, no, this is not what I asked for. Customer even they don't know what they want, but they definitely know why they wanted. So focus on the needs focus on the problems, focus on the kind of outcomes are they looking for, and then maybe think about the solutions and the outputs, that you can come up to deliver those outcomes. But, again, no one knows the market, no one has seen the future, it can help in reducing that risk by delivering some done increment every sprint so that after one sprint, you can learn what out whether this is what my customers want with it. This is not my customers want. And if they don't want it, okay, that's an opportunity for us to get the feedback.

Lindsay Velecina: 38:35

That makes sense. Thank you. Right. So this next question is a tricky question. And we may ask for more context from you and if you're willing to share, so when is the best time to talk to the client about exceeding the budget within a longer project if that's clearly the case.

Lavaneesh Gautam: 38:58

So So when is the best time to talk to the client about exceeding the budget within a longer project if this is clearly the case? Thank you. Okay. Awesome. Yeah. So instead of Samaya, my suggestion, instead of giving them a big surprise, I will be keep giving them little surprise increments. Okay. So so what how I do is I made sure that if I have got any long project again, I can see that maybe we are in some kind of on time on budget on a scope delivery in this kind of projects. I change my plans, road map, product backlog, and show this to my clients every sprint review. Because we no plan is going to change. And again, it sometimes it reflects on the budget. Sometimes it reflects on the deadlines. Sometimes it reflects on the cost in itself as well. So if any little change has happened, I talk about that in every sprint review. And if our stakeholders and if our client if our sponsor, if they are okay with it, we continue can go ahead. And if they feel that come on, we have got just this much of budget than only option that we have got is then maybe reduced either the scope or increase, maybe the timeline or something like it. But the maturation, talk about this in every sprint review, rather than just making it a big surprise, we don't want big bank of products. At the same time. We also don't want big bank risks and the surprises as well.

Lindsay Velecina: 40:52

That's great advice. Thanks. I want to circle back on a question that we already asked. And it was the one around the management retrospective. I just wanted to provide some clarity I we did get some questions in the chat about that as well, since we weren't 100% sure of the context. And the context was about management coming together to find out how well they are doing with respect to Agile management. That was what that was. So I think we did pretty well in terms of interpreting that.

Lavaneesh Gautam: 41:24

Awesome, awesome. And again, I can give one more tip as well. Look for the EBM framework, pal EVM, or maybe something like it. So there is an EVM guide at the end on the scrum.org website. Those management managers, those leaders, they should look into that thing. Maybe you can run a workshop on that EVM in itself, what is our current value is? What is our unrealized value is what is our ability to innovate? And what is our time to market? I think that would be helpful.

Lindsay Velecina: 41:58

That's great. Thank you. And I did just drop a link to some EBM resources as well. Alright, so this question here, if the team does not do a sprint review, how do we deal with it? And what action should we take to accomplish this event and the team?

Lavaneesh Gautam: 42:16

If a team does not do the sprint review? Let's see what could happen, isn't it? Because sprint review is one of the best opportunity for us to get the feedback from the stakeholders. If you're not getting the feedback from the stakeholders at thing, our risk of building something which stakeholders and the users and the customers don't want any creases, that's at risk. That's the big risk. Is team aware of this thing? Okay, are they ready for that? Now, if they don't do the sprint review, sometimes now again, I'll share my experience as well, it is because they consider that a sprint review is just about the demo. And that and that becomes a big challenge. Because many of our stakeholders, they do not want to see that demo, they probably wants to talk about that how the product is going. Okay, what is the progress towards the product code look like? What is the progress towards our timeline? And maybe the budget look like? These are the really important questions to them. Okay, and, and this is something we need to discuss into our sprint review, as well as sprint review is not just looking back at what we have delivered, but it's also about looking into the future. Are we building the right thing? And that conversation, I think for that team needs to have stakeholders, and they need to have this kind of conversation very frequently. If you don't, then you are incorporating a risk of building something that nobody wants.

Lindsay Velecina: 44:04

Right. Thank you. Right, so this question here. So what could be some advice for an Agile team that is not 100% scrum team, but they're using limited scaled Scrum, and a few elements from Kanban. The team needs to set priorities and optimize the way the stories are continuously entering in active sprint.

Lavaneesh Gautam: 44:34

So what could be the advice for an Agile team that is not 100% a scrum team use limited scale Scrum. I don't know what the scale is. Scrum means is?

Lindsay Velecina: 44:45

I'm not sure what that means either. If you want to clarify that.

Lavaneesh Gautam: 44:48

Yeah, that means if you're using Scrum, along with the elements of Kanban as well then it's really really good. Yeah. And it In a way, the many scrum team that you also use Kanban board, pretty much they do is in the planning, they set their goal that this is what our goal, this is what our highest level object objective for the next two weeks or month or whatever sprint cycle is. And then they focus on one item, the word word work is done, and they keep pulling more and more work. And I think it's a very high level agility. In that team in itself, I would love that kind of team where they have got that level of self management that flow of the value is quite high. But I really need a little bit more context on this particular question, Lindsay. Okay.

Lindsay Velecina: 45:47

So feel free to. Yeah, so a couple of people have asked us limited scale scrum means some Nexus. So it'd be good to get that clarification. Adrian, if you want to clarify, that would be helpful if you are still on. All right, so we can revisit that one. If we get that clarification. So this question from Giuliana, how do you manage scope, creep and technical debt?

Lavaneesh Gautam: 46:16

Right? Scope Creep. And I think scope creep means when he's talking about as things got identified, maybe later, or the three days task turned into the five days task, I think this is what we're talking about. And I think it's inevitable. scope creeps, when we're talking about they are inevitable in the complex environment, because we cannot identify everything upfront in itself thing emerges. So the only thing that can I can suggest is wherever the scope creep is happening, learn that thing, so that you can plan the things a little bit better. So especially what you have identified into the sprint planning, and once the sprint finishes, think about that, where actually we could have learned from the data during your sprints. And this is where maybe the scrum with Kanban can help. What has been our cycle time, every cycle time, what has been our throughput? And when we have got this kind of data, we can understand our predictability a little bit better. And and the challenges of those scope creeps, maybe those could be minimized. Not that not not the second second aspect of it is how to deal with the technical debt. I think that that's another question. And I would say technical debt is first of all, guys, if you don't know what technical debt is technical debt is the results when you are compromising the quality or the value or the speed. And it could happen because of lack of experience. Or you are making a conscious choice that we want to go to the market faster. And hence we are ready to cut down the quality gate. They could we met these are two main reasons now. How to fix the technical debt probably there could be again, the the strategies and those strategies, I always like to call it as how do you pay a mortgage? Yep, you keep paying your mortgage little by little every sprint, oh, every month. So this is what we need to do, we need to create first of all a space in our brains to keep fixing that technical debt. Now second thing is how do you manage your financial situation as you stop taking more and more debt that and this is where I believe the definition of Done comes in. So maybe improve your definition of done so that in the future, you are not incorporating more and more technical debt. And this could be by adding certain quality criteria. So for an example, in one of the software product company where I used to work, we added automation testing as part of our definition of Done, and it helped us in reducing if I'm not incorporating the more technical debt in the future. But that was really helpful. And another case where we already had some technical debt. We did two things again, first, we made that technical debt transparent. We added this into our product backlog. We were made it clarify this in our sprint reviews as well. And then we start spending certain percentage of our sprint. We used to do leave it every Friday to fix that technical debt in itself. And I can say from the results suggested to us was that though, one day that we were spending a week actually, our team was much more faster in delivering the value So, technical debt can eat up your ability to deliver the value in the long run. So keeping it a little

Lindsay Velecina: 50:13

straight. Thank you. All right, so Adrian got back to us regarding his scaling and Kanban situation. So I'm going to read drop this one back in the chat so that everyone can see the original question. And then we're going to dive back into this one to see if we can kind of dissect some advice here. So just to repeat, the original question was Hi, what could be advice for an Agile team that is not 100% scrum team, using limits scaled Scrum and a few elements from Kanban. The team needs to set priorities and optimize the way the stories are continuously entering in an active sprint. And the follow up here is in fact, several teams are working in parallel with their own sprint backlogs and unique product backlog. The goal is to optimize the process to avoid an overburdened team and complete as many new stories that are introduced in a current sprint.

Lavaneesh Gautam: 51:20

So so Yeah, amazing, the busyness of the people in that in that case, I believe. And I always say that you get what you measure. And if your basic the busy people miss more story point you will get you will get more story points than and more story points doesn't equate to the more value. Now in this situation, I think this is where the problem is happening. We are not measuring the value metrics, we are measuring something arbitrary number of the story points and in itself. I know in many organizations, this is a big problem. And one thing can definitely can definitely help is first, if all those seven teams if to several teams, if they are working on the single product, I think you need to have one product backlog, one product backlog but with the multiple sprint backlogs. And with that one product backlog because it is it will be in the priority order. It will help the team to understanding that okay, how it will work. Another thing that can be really helpful is that something is coming from Nexus framework is doing those cross team refinement sessions as well. So that everyone can understand what the dependencies that we have got. So that our cross functionality is a little bit better, we are more self managed as well. But if we all teams are working on one product, they should be having the one product backlog. That could be really, really helpful. And again, move away from those metrics which only measure the busyness of the people. Those are not the value based EBM can definitely definitely help you in that case. That okay, what is whether our user count is increasing or not, but then our customer satisfaction and decreasing or not, whether our cycle time is reducing or not? These are, I would say the fact based figure rather than story points, which are just to me is finger in the air, to be honest.

Lindsay Velecina: 53:38

All right, thank you. And thank you for clarifying that. Adrienne. For us. Okay, so this last question reflects back on one of our first questions. So, question for the first question about performance reviews. My company is also trying to figure out reviews for individuals. How do you measure an individual's performance? They want to use efforts, but for me as a Scrum Master, I feel like this is not a good idea.

Lavaneesh Gautam: 54:07

And this is not a good idea. You're absolutely right, Pauline. And this is where I believe you need to go out of the team and have a chat with the line manager of those peoples as well. Maybe it may require that you have to talk to the head HR department or the people department that you have got in your organization. Choices hours, do we want heroes or do we want awesome team and majority places we want awesome team and awesome teams are the places where everyone is helping each other when we are focusing too much on the individual reviews and the individual performance. That may create some great heroes. But great heroes doesn't mean that you are always going to have the great teams. So hence So, so So again, yes, we can have those individual reviews but at the same time, he also needs to have I think, a little bit element of the team goals and the team reviews as well. Otherwise, think how, if you're not rewarding the people collaborating and helping each other out, while they will then they will be looking after themselves, rather than helping out each other.

Lindsay Velecina: 55:27

Awesome. Thank you so much for sharing that. Great advice there. So all right, we are coming up on our time here. So thank you so much. For everyone who asked his great questions today. I am going to share my screen really quickly. Okay, so just some very quick closing slides here. Okay, so so very quick closing slides here. So each each accountability and Scrum has their own learning path. So we have some free learning paths on scrum.org website. Feel free to check those out. They also have a lot of other free learning resources like this webinar, we run these webinars a couple times a month. Ask PSC is actually once a month per language. So we do run these in several languages as well at as time permits, so please feel free to check those out. And thank you so much love and each for taking the time today and they connected everybody and Scrum on Thank you