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're located today, welcome to ask a professional scrum trainer. I am Lindsey Vale Sina and I will be the moderator today. Today I have a rune here. He is one of our professional scrum trainers here@scrum.org. And we're super happy to have you. So let's move ahead here and very quickly on who is scrum.org. They are the home of Scrum. We were founded by Ken swaybar, back in 2009. And our mission is to help people and teams solve complex problems. We do that through our professional scrum training, certification and ongoing learning. We have a lot of free learning opportunities here@scrum.org. So please check that out on our website and in our resources. We also have learning paths on our website that you can check out. So we hope that this session today too plays a part in that ongoing learning journey. So I will hand it over to Iran to introduce himself to get to know him a little bit before we start asking questions.

Arun Ramakrishnan: 1:38

Okay, thank you Lindsey for a very good introduction. So hello, everyone, myself Arun Vignesh. I shuttling between two countries Malaysia and India. Predominantly, I live in India down south in India climate tour. I'm PSDs. Lindsey said, and I'm also an ICF. Coach. So I also teach people on different agile coaching programs as well. And then also an RSC trained coach. Also I my research interests is on more on team coaching, relationship based stuff, and then handling Agile transformations. That's a brief about me. So over to you instead. Okay.

Lindsay Velecina: 2:25

All right. So please, if you've just joined, I made a few people trickle in. So just a reminder, please enter any questions that you have for Arun. He is our expert here today to answer your scrum questions. So please ask him anything you want about Scrum. And you can add those into the q&a box at the top of your screen. That is where we will be capturing all of the questions so you can start entering your questions there. And I will get through as many as I can in the session. So this question from James, my team wants to embrace a kanban workflow while still using Scrum. What are your thoughts on this? And have you supported teams to use this in the past?

Arun Ramakrishnan: 3:12

Absolutely, James, so you're on the right track, I would say if you've implemented Scrum, and you want to see your teams deliver the value, or the flow of value in a much better manner, then using Kanban would definitely help. And one of the core Agile principles that we embrace in Scrum is keeping it simple and then working on the most important stuff. By working by using Kanban, you have the concept of work in progress, limiting the work in progress. That way you limit the number of items that you work even while you're using Scrum, so that you're focusing on the most important stuff that is really valuable to the customer. So definitely, you can very well use it. And as I said, in my experience, we have used it in many teams. The two concepts, at least if you take from Kanban, limiting the web and managing the workflow. If you're using these to better then your Scrum is going to go to the next level of delivering value to the customers. I hope that helps.

Lindsay Velecina: 4:26

Awesome, thank you. And then there's a follow on question here. Do you have any tips on limiting work in progress?

Arun Ramakrishnan: 4:36

Okay, so when you say tips, it really depends on your team's to say how much they can work inside in at a given point in time, right. So the tips typically, I would say is start with a very small budget, and then try and see how you're able to finish that but Picking the right team and then move on to the next item. That would be the tip. I would I would give it to any team that is embracing Kanban when they are implementing scrum as well.

Lindsay Velecina: 5:15

Yeah, thank you. Okay, so what methods can you use to keep retrospectives fresh? I've tried a few variations. And they all feel like the same format of what went well, what didn't go well, etc.

Arun Ramakrishnan: 5:34

Okay, so here's where I'm gonna introduce it to call I'm not I'm not sure if you know, already, there is a tool called random retros random retros.com. You go and ask for a new retrospective technique, it will throw you n number of options. So try to get the two of the options that the retros random retros throws to you. That's one way to do it. And another way to add in as if you're a scrum master to add it onto your repertoire is liberating structures, there are 33 different types of liberating structures, if at all, if he could use one liberating structure in one retro, you will not be free poor definitely. And also, there is a concept of strings where you can combine two liberating structures, techniques, and then start using it in your retrospectives. So if you're not aware of liberating structures, again, it's liberating structures.org. That's the website name. It's a free free website where you can go and explore these options. And they have a community as well as slack group were to collaborate with different people using liberating structures, and then gain gain knowledge from the community as well. So yeah, try it out.

Lindsay Velecina: 7:01

Awesome. Thank you. Those are great ideas there. And I'd like to add there is a website tasty cupcakes.org, a bunch of PSDs contribute different retrospective ideas and other ideas in there facilitating events. So feel free to check that out as well. So this question here, so we might need to ask for some more context for this one. But I do want to ask it. So in automation, can I use Scrum? Or does it have to be waterfall? My team uses UI path, and I can't demo my sprint by sprint, please guide. So do we need more context? Are you

Arun Ramakrishnan: 7:47

I would need a bit more context. But honestly, I'm not used to a path as such. But just to talk about your first question in automation, can I use Scrum? So it is like Scrum. In boats automation very well. I've seen recently teams started using this AI ops. So I don't know how many of you have heard of you might have heard of DevOps devsecops. But if the new trend is AI ops, if you have heard of GitHub, GitHub has a new feature coming up called co pilot. The copilot helps you if you're if you're a developer writing your code, it helps you automate the unit test cases it reduces the time and also the developers or at times hard on not writing the the steps or the documentation for the code that they create. Now, this copilot has a feature to automate that the explanation of what your code is as well. So that way, you have some sort of a productivity done. So if I'm not wrong, if you're talking about automation with respect to testing, yes, you have a lot of opportunities now coming into picture with the advent of or the the usage of test driven development, where you have opportunity to start doing testing, make the test cases fail, and then developers start collecting those or fixing things for the failed test cases. And that way, you have an automated test already inbuilt as part of your coding thing. So that those are the steps that is there. While using Scrum. You can embrace automation as well. Yeah, so over to you, Lindsey.

Lindsay Velecina: 9:46

That's great. Thank you. Okay, so, this person asked what are the options for introducing high priority work in the middle of a sprint?

Arun Ramakrishnan: 9:58

First of all, I would like to challenge you not challenge have you think if your sprint is of shortest duration, think like first thinking that I would recommend this to see how we can hold this particular item until the end of the sprint and start backing into the next sprint. That way, you don't have to introduce items in the middle of a sprint so that they and the teams have a very good focus. Maybe second option, very, very high priority. Yes, I need to bring that in. Probably the discussion with the developers as a product owner, if assuming that if a product owner needs to introduce that having a conversation developer is to see how the new thing is going to add value to the sprint goal. And then trying to have a trade offs on the items that they've already picked up, try and see if they can pull out some of the lower priority items and then kick this in. Still, the sprint goal is they're not not saying the sprint goal is not being endangered. That's the core thing that you need to focus on. So again, it's collaboration with the developers. That's the answer, but depends on the context. Why it is very, very important trying to give that context better to the developers and make them understand and then collaborating with them to trade off any low priority items. That will be my second approach.

Lindsay Velecina: 11:28

That makes a lot of sense. Thank you. Yeah. And once we have these questions answered, just for our live audience here, if you need any clarification or follow up questions, feel free to add those back into the q&a. And we will circle back. So this question here to? It's a very broad question, but I can help narrow it down a little. So how, how long should each sprint lasts? So do you want to maybe share tips as to like how to determine the best sprint length for your team?

Arun Ramakrishnan: 12:08

Okay, so typically, I take this analogy, I don't know how you think, think of, you're driving your car on a highway on a sunny afternoon. The visibility of the road be pretty clear. And you can speed up for a longer distance, right? relate this to your product backlog. If your product backlog is clear, and you don't see any hiccups in middle, you know most of the stuff what are the top of the product backlog items, then you can extend your sprint length, but it's not exceed one month right. Now, opposite of this, you're driving the same highway on a midnight, which is heavy, raining a bit foggy as well. You wouldn't speed up right you try to look out how as as much as possible or as frequently as possible to see what is coming in front of you. So that's how if your product backlog is very volatile, very uncertain, you have a lot of uncertainties, a lot of complexities, then try to reduce your sprint length. But keep remembering your sprint should always produce an increment that you can use to validate your assumptions. So consideration of complexity of the requirements, then your time that your team needs to create an instrument to generate value. So these are the two major considerations, I would recommend you guys to determine your sprint length. Yeah. So those those should be my tips for the sprinkler.

Lindsay Velecina: 13:42

That's great. I hope that helps. Okay, so somebody asked, Can I ask you what are the pros and cons for using Lead Time and Cycle time metrics compared to burn down charts? And maybe share some of your favorite metrics in

Arun Ramakrishnan: 14:01

general, is the question about cons on using Lead Time and Cycle time than the burndown

Lindsay Velecina: 14:07

pros and cons.

Arun Ramakrishnan: 14:10

I would say that it only throws mostly most mostly I would think that only because these Lead Time and Cycle Time are my favorite metrics as you as you asked, see, Lita, and cycle time are pretty context Well, I would say so if I if I could explain for the audience perspective, lead time is more like the end to end time that you take from a customer request to delivery a customer has requested a new delivered it right this is your lead times Cycle Time has multiple forms, you can add context to it. Like in case in the lead time that I said customer has requested it. Now the product owner look received the request and then brainstorm with the stakeholders what not the time In the product owner takes and say yes, I'm going to do this. Now there is a cycle time from customer requests the product owner finalize this, yes, this is going to the product backlog, right? This is you can call whatever product owner finalizes inside the time or something like that. Then it gets then the developer picks in. And then the time they when they say, developers, it's the development group, right, the entire group picks in and then they take time to complete it. So that time is your development cycle time. So this is the explanation that I gave right now, the pros of this two metrics is that you have an opportunity to know, hey, when there is a new request that is coming in, which is not there in the market at the moment, how long do I take to get it done that that is given by your lead time, right. Now, within that lead time, let's assume for an example, I talked about product owner, finalizing and they take a time, let's take they take about 15 days to finalize a requirement. And whereas when it development time takes a similar amount of time now 15 plus 15 is 30 days is my likely entire lead time. And one part is your product owner approving cycle time and then the development cycle time. Now, you have an opportunity to take an action to say how can I reduce these cyclic times in a way that I have my entire lead time reduced so that I can turn on a dime, when there is a new opportunity that is coming in, I'm going to the market first and again, grab some market share, so that it gives me value. As a product owner at the same time I am the first to solve the problem to the customer, the customer is also satisfied. So that's how these two matrices are very, very important. These are the pros. Honestly, I don't see any concepts such with Lead Time and Cycle Time. But I would love to hear some any. If you have to compare with the burndown charts, burndown chart are more an indicator to you guys, if you use the burndown chart for the right purpose. As in I've seen certain organization use the burndown chart as a productivity metric to say how they are things are finishing up or something like that, I wouldn't recommend doing that. So what I would recommend is using burndown charts for someone at the start asked about limiting the work in progress using that as a as an as a concept in Scrum. So typically, wherever teams have worked, the burndown chart goes like a flat, and then it comes down on the last day. That is a sign that you have a higher number of working progress items. If you're introducing Work in Progress limit as one, let's take for an example. At any given point in time, the team can work on only one item, which means all the team members need to focus on that item, complete that first, which means you're bringing the bond down to a level or coming bringing that down an earlier day. Which means that's how you should be using the burndown chart using burndown charts for taking come from continuous improvements in a way you start finishing items. Rather than starts starting or stop starting start finishing. Right. So that's that's how you have to use the bone charts. So it has all these metrics just has. Right? The pros in it if you use the right way.

Lindsay Velecina: 18:47

Right, thank you.

Arun Ramakrishnan: 18:48

I covered it in a way that is

Lindsay Velecina: 18:51

yes. And I think you've covered a couple other questions that came in too. So that was perfect. Okay, so this question from Tao. How do you prioritize technical debt, and add technical improvement tickets and sprints?

Arun Ramakrishnan: 19:10

Okay, so I don't know, if you're a product owner or a technical person, trying to find a business case value for your technical items would help. If the product owner is not prioritizing it. That's one way to think the other way to think is like trying to give it a good good thing if you're a product owner, right? If you're if you're looking at your product to go for a longer run, then definitely you got to bring those items at least one or two items mix and match with the business items that you have. So that you have a mix of features as well as technical items. It is available that's a tip or a recommendation that I would give. So what's the question Did I miss Is the question. So how do you prioritize? Is that

Lindsay Velecina: 20:02

the question? How do you prioritize technical debt?

Arun Ramakrishnan: 20:06

Yeah, so one is giving it a business case, to understand what value is gonna deliver end of the day. That's one way to think in terms of value. So giving a technical test, also a value. And then another tip could be bringing the technical debt as part of your sprint or mandating a thought process in your team like, hey, we need to have at least one or two items as part of a sprint backlog. So that we are constantly improving our products quality, right. So that we have we can stay in the market for longer runs. And also taking some reports out of the market, how often have products been failed because of their poor quality. So I have worked in many organizations, I have how I can vouch for this could be there in your all your organization. So you have something like known bugs in your system. If you ask the count of non bugs, people cannot give the exact form because that many known bugs, we will have enough system that is also a type of a conscious choice that we take in our systems to go faster to the market that is going to come back as a form or a period of time. So have the stories into your teams in a retro perspective possible. And then trying to educate them in a way that why addressing technical deaths is very, very important if a product has to go for a long time.

Lindsay Velecina: 21:42

That's great. Thank you. All right, so we're gonna switch gears a little bit. So this question from Anna, thanks for the opportunity to ask questions. What are the biggest challenges? Introducing scrum to a new team that never worked with it? What would you recommend for beginning scrum master? So two questions?

Arun Ramakrishnan: 22:05

Yeah, so I go with the first one, and then I go to the next one. So you talk about biggest challenges, the biggest challenge is, it's like this, right? You're going to challenge the status quo. That's the biggest challenge. So Liveaboards Kron liveaboard introducing Crumley, if you're going to introduce any new change to a person, it is going to be difficult for them to accustomed to it, right. So it is like you are working in a normal way. So I don't know if I can take this example. So let's take for an example, if a virus enters into our body, right, what are our body immune system to it is going to resist because that is an unknown thing. Right? Similarly, if you're going to introduce any change, let's say for the crown, if you're going to introduce, if they don't have enough information about what is changing, and why it is changing, then that is going to bring resistance, they then have to resist, they are going to resist because they don't know what it is giving as much information about what Scrum is all about, and how is it gonna help? How is how is it gonna help them in a positive way? Not in a negative way addressing all those concerns about there are probably I would put it like empathizing the audience, empathy, empathize with team members, in what all ways they might get their negative thought in their minds. addressing those negative things with a positive storytelling or positive way of giving information minimizes most of the challenges that you can that you that you want to come when we introduce crap, right? This is obviously this outside of Scrum. Scrum doesn't talk anything about introducing change. This is typically change management tactics. If you have known how to introduce a change, then use the same tactic, right? That's the one. So minimize the resistance of the change or a new change as less as possible. Obviously, there'll be people resisting as change, or there will be people who are embracing the changes will use them as change agents to help the other people come on top as well. So that's how I that's the tip that I would give you to minimize the challenges as introducing new introducing scrum to the new team. That's one mix recommendation for beginning scrum master. If you're a new scrum master, that you're starting in a new team, again, start coming to the communities and then try to see how you can take some learnings that have already there in the industry, there are free community events like these, ask for a lot of tips, there are a lot of questions that will be put up in this as well. Those are some of the references that you that you get to know there are different different points that are coming into, into the system, right. So we have typical, every human being goes through the cycle of learning. So they start with unconscious incompetence, which means you don't know what you don't know. Right, like, like a kid trying to walk or a person trying to learn driving a car, you don't know what you don't know, at the start. Now, when someone teaches you, let's say go and apply, go into a proper education program like PSM, probably, or a PSP and then coming to those and then learn what it is where you're gonna get conscious company, you're gonna learn something, right? conscious competence, that's a second layer, as a scrum master consciously learn some concepts. Now, consciously practice it, next level is going to you will, you will have a lot of struggle, right. That's where it's gonna say conscious incompetence, you Yo, you know what you don't know now, now you're going to consciously practice, practice is the only thing that is going to take you to the next level. So come to the community and practice if you're at your home, if you could apply scrum as a concept, and then try to do your daily tasks. That could be another example of your organization's Go, Go tell your team that, hey, I'm very new, I'm going to try this helped me out. Be open, be vulnerable. People are definitely good humans, right. So we have good humans in our teams. So they will definitely help you as well. So those are the baby steps, I would try and say as a new scrum master dig in to get some experience, and then take learnings.

Lindsay Velecina: 26:54

Awesome, thank you. All right. So this question I want to ask because other people may run into this too, at some point. So RPO is about to move on. As he has a six week notice period. I want to ensure that the team keeps its togetherness. And we continue moving forward, how have you ensured smooth transitions in the past, a Pio feels like a key member to leave. However, we have good documentation, and I've discussed any knowledge silos he may have.

Arun Ramakrishnan: 27:31

So I'm gonna talk about the first question that is a two part question. I understand. So first question was like, if the POS leaving in six weeks time? How do I make this transition smooth? The first thing would be if there is an if at all, there is a new Pio identified or hired, that's great, there is a transition what you talk about. But in case, this is something that's happening, you can't hire someone some six weeks. In your teams, do you have one who's volunteering to step up into POS role to be first thing, if no one is volunteering, probably check out in your next circle in your organization, if there is any volunteers, volunteering works better, because they are going to bring up that passion towards learning and then trying to step up. So that's the tip that I would give, in case nothing works, then probably you need to see who's the most possible fit and then trying to see if they have an alignment on these po roll and then trying to educate them, what's in it for them when they get into a PEO role, and then trying to get on board on their thought process. Again, this is a change that we were talking about in the previous like in a previous case as well. You need to tell them what's in it for them as well. That's when it's gonna work well for them. So these are the three things that I have tried in my experience to get on board. New PA, new Pio for Pio leaving. I hope that I hope

Lindsay Velecina: 29:07

that's good advice. Thank you. Okay, so another scrum with Kanban question that was asked. Since there aren't any sprint goals, how can we get team members to own their delivery and Kanban.

Arun Ramakrishnan: 29:25

So if you're using Scrum with Kanban, then there should be a definitive goal sprint goal. That's another rule, along with the rule in the sprint, like every sprint should have an increment, every sprint should have a sprint goal. But in case you're only using Kanban. Yes, that's the downside of Kanban. If say, because it's first in first out, you don't have city, in my view, again, views differs from different people as well based on their experience, in my view, if you're only using Kanban that's the downside because you Not galvanize your team into a single group or team, when you call a team, they are the ones that is going to work together towards a collective objective. So that's the missing piece in Kanban. So probably use Scrum and then on top of it Kanban both works well.

Lindsay Velecina: 30:20

Okay, great. Thank you. Okay, so, next question. What are some things that you've learned that helped you feel confident as a scrum master? I'm relatively new to the role.

Arun Ramakrishnan: 30:40

Okay. I can tell, okay, I have to think about my experience, right. So in my experience, what made me confident is my failures. I know when I do some things, I will fail. Taking learnings from those failures definitely made me confident, or I could say, all my failures made me a stronger person as well. Also, in my initial days, I was I was actually frustrated with the things that I'm thinking not working. Don't take it personally. Embrace this is this is a job that is a thankless job, right? Don't ask for look for any gratifications and the initial fees, try or prepare yourself for a lot of experimentations and a lot of failures. But the key thing is start learning from every failures, that's the one that is going to make you stronger. If I quote an example, in my initial days, my teams don't deliver value, my burndown charts doesn't come down as fast as possible. I used to follow up just like anything going in round here, and they're trying to solve all the obstacles possible. At the end of the day, I would have burnt up. Then I thought there is a power called delegation, giving people better accountabilities for their job, and then asking them, Hey, how can you get this done? This is your ownership. What is that you can do asking some right questions with from them. If he or less, it will help you less burnout. And that the at the same time people will feel empowered. Okay, this is something I'm owning, right? That gives them what's in it for the that? that wow factor or that excitement factor. I'm owning this, I'm going to take care of this sort of stuff. So yeah, prepare for failures. That's going to make you confident.

Lindsay Velecina: 32:36

Thank you. That's really good advice there for new Scrum Masters. So this question from Russia. We are a remote scrum team that works around the world. And that makes us difficult to run a sprint when most developers start the day some of us are closing the day. We have multiple clients and one team says spring sprint team. I don't know if you met scrum team in one sprint team, which is where it is difficult to have a single sprint goal. What do you suggest for team like that?

Arun Ramakrishnan: 33:16

I think this is to question. Let's say the first question is you're working in remote setup? And also the question was, if I heard it, right. Most developers, some of the developers are closing when some of the developers are coming in. I could relate this experience when I was working with a client service model, where you have this typical challenge of non overlapping arts. This is where we thought of doing the sharing the pain and kalasha. Right. So we want we had a retrospective and then sought input from the team and the team had come up with an initiative called Hey, know what, two sprints which probably a month. We had, we were running two week sprints, right? So two weeks, we will come late to office, one part of the geography come late. So that we have some overlapping hours next to sprint cycle, the other part of the team will come early. So which ways this this brought that overlapping ours bit more higher? That way we have we were able to collaborate? That's one recommendation that you can see if it works for you. Probably second question, what was the question? Let's see if he could read it again.

Lindsay Velecina: 34:38

So I think I think that was the main question. They did mention. We have multiple clients in one sprint team. I don't know if they met scrum team, which is where it is difficult to have one single sprint goal.

Arun Ramakrishnan: 34:54

What do you suggest where you're coming from? So when you have multiple when you say multiple clients, I'm not sure If they are there, so consider those people are stakeholders? Can I continue to consider them as stakeholders? Then? My question would be do you have a product owner who can take decisions on behalf of the stakeholders or for the product on behalf of the product? If there isn't, if you if your answer is no then probably the first option would be to identify a person who can take decision on behalf of or on behalf of the product. By collaborating with all your stakeholders. That way, the product owner can keep that decision making transparent with a single product backlog. With all these decisions are stacked up in the product backlog in which order it is going to come that we are going to manage stakeholder expectations in a way that you know what your items are coming in this sprint, your items are coming in this sprint. That way you have an opportunity to create a coherent sprint goal that your sprint sprint team can work on.

Lindsay Velecina: 35:58

That's great. Thank you. I hope that helps. Okay, so this question from Nadeem. I had asked for some clarification here on the question to simplify it a little bit. I don't know if you saw it come in earlier but. So, our sprint timeline is 10 days and 10 new features will be covered in the sprint. Unfortunately, the team only completed eight features before regression testing, then how can we make a release in which we want all 10 features? If the rates then the sprint or what?

Arun Ramakrishnan: 36:36

Okay. This is what the typical This is the learning that we should take Nadeem. So you said this is not working? Right, then probably we should change something. It's not like we can make it work. Something doesn't work. Right. So typically in waterfall you have this passing of lateness to the next sort of cycle. That's what we are reducing here. We're going to start finishing items. How can we do that? We have to reduce the number of items that we are picking out. How can we do that? The way that we can do that is by creating a sprint goal. So now the whole focus is not 10 features, the whole focus is the sprint goal, Coker and let's take for an example the 10 features that you're taking up as. Let's take a layman example. Like everyone knows Amazon. Amazon has multiple features and clicks to log in as a feature homepage is a feature payment is a feature like wise. Now, think in the perspective of k what is my what would be my sprint goal, if I'm starting Amazon like product, buy. If I'm Jeff Bezos, I will be wondering if anyone is willing to pay in my system, because that's the crucial part. That's what will extend to generate revenue as well, then he was willing to purchase an item by paying in my system, which means I need to at least give a flow where people will be able to log in select items and pay in the system, which means I'm not going to do entire feature of login, etc, etc. I'm going to pick up the minimalistic items of how can I manually log in? Okay, minimally select the item, how can I willingly do a payment maybe one payment method. So my customer audit journey with a payment option. If that's the goal that I can create as a coherent item, then then it makes your life easier because you're not worried about fixing of 10 items, whereas you're worried about picking the most important items, or the most valuable items to get to the market so that I can validate my assumption this this headache is much more easier to handle by forming a sprint goal and then trying to figure out what items that I can pick up for the sprint goal, rather than fixing up the 10 items, and then moving on to it. So I hope that helps.

Lindsay Velecina: 38:59

That's great. Thank you.

Arun Ramakrishnan: 39:01

So that way, you you reduce spillovers as well, you picking up less items, you're finishing everything. That way you don't have spillovers, even though even Okay, let's say for an example even by doing that, if you have some sort of scenario that your items are getting, or in a state that it is not getting completed properly, that's where you got to think, Hey, what are the trade offs? Can I drop off the bottom two items and then complete the one item that is half done, so that I have completed items at least out of the five that epic I'd have three or four items complete and one completely not completely incomplete. So that that can be moved to the next sprint. So those sort of trade off that you need to do in your sprints along with the product owners so that you're starting finishing items rather than starting items, and then keeping it halfway.

Lindsay Velecina: 39:56

I hope that that's great. I hope that helps. And if you need more clarification and let us know, Nadine, thank you for that. All right, so this question from Jacob. What should you do when you joined a company as a scrum master, and then your boss requires you to do things that were meant for waterfall project manager, preparing a Gantt chart, preparing project report for the Project Steering meeting, joining the change advisory board or the prop project, managing a budget, distributing work to team members to ensure productivity etc. How do we make that shift?

Arun Ramakrishnan: 40:37

I empathize. You have been in your state, right? What I've done is I've done all those, whatever they asked for. And I also asked them, Can I do one thing on my own one thing, can I start creating a sprint goal for the team so that they are focusing on the sprint, the scrum has one concept of sprint goal, and then creating implements, these are the one thing that I want to do, by creating a sprint goal, I'm trying to achieve it, I have all new items, whatever you're coming into, I'll update it, I do all these things. But this is the thing I want on what you're promising for. So that's trying to move a smallest of needle and then trying to show them a glimpse of promising land, hey, by using this, you have this value coming at every two Sprint's I've done this verse. So earlier, if I had I'd done this way, we would have only done half of this complete, now I've done completed something like this. So asking permission from them. So basically, you're collaborating with your boss, and then trying to move your needle slowly. So it's not like overnight, you can change everything. There is no magic wand like that. You need to take baby steps. Definitely. And as I said, the core core thing about is what's in it for me from your bosses perspective. Give that what's in it for them when they use Scrum, right, trying to see if you can talk in their language that helps them if they're worried about stakeholder communication, why is the Gantt chart useful? empathize with them, ask those what are the purposes of these all these things that they are using for understand from them and try and see how you can give the similar information by using Scrum, but in a different format. So those are the stuff it's again, collaborative learning. Keep them what they need in a different format. Scrum has all those what they need, what they were doing it in, in those different types of reports, there is an underlying purpose for those reports as well. So all these you get in your scrum as well with the help of your product backlogs. So that's the tip that I would give it to you. I don't know, James.

Lindsay Velecina: 42:49

Thanks. Thanks for sharing that. I think that others can definitely resonate with that as well. So this question from Daniel, I have a team that has a primary objective of improving performance in the product. This is achieved by short spikes, followed by user stories that implement the performance gains, it is very hard to create a complete product backlog to predict delivery. Do you have any tips for a research team in Scrum?

Arun Ramakrishnan: 43:24

Okay, so I guess whatever you're doing is perfectly fine. It's just that you got to set up your sprint goal based on that. So so the one problem layers, you talked about predictable delivery. So let's talk about what is the delivery that you're going to carry, let's put that in terms of value, a predictable value that I can deliver, I'm going to improve the performance of my system. If that's the goal, right, I'm gonna definitely improve at least one or the other performance by working on the spikes at the same time. And I'm trying to improve the system based on the learnings from the spikes, right? So creating a sprint goal in a way that you can work on the performance items. If performance is the most important thing that at this moment, then create your sprint goal based on that, that helps you bring in items and then work on those items as well. And then improve your performance. So tying it back to the sprint goal is the solution. Yep.

Lindsay Velecina: 44:28

That makes a lot of sense. All right. So this question is Is the Agile transformation type of question in, in your experience, do organizations use an agile roadmap during their transformations? And does this run in parallel with the product roadmap and or organizational strategic goals?

Arun Ramakrishnan: 44:51

Okay, fake Western. It's, it's good if you have an agile roadmap as well, but it should not be fixed roadmap, the only thing is like that roadmap. They are like not a fixed roadmap. It's like, let's take for an example, you take a GPS, your GPS is showing a path now. Right? That is your tentative path that you may go. If everything goes smooth, you can go to the same roadmap. What if there is a incident that happens in that middle, you got to take the tour, probably got to do it, right. So as you rightly said, If you could have an organizational or strategic goals that are in line with your product goals, then you're both of your roadmaps would be similar. Right? So which means that whatever I'm doing, as an organization, do an Agile transformation, there's got to complement to my product delivery. See, end of the day, your transformations are there to deliver value to the end users or the customers. So obviously, to be connected, if it's both are very distinct, then I would recommend you guys to have a sit down and then check why it is so distinct, it should be shouldn't be. Struggling is the right word, it should be embracing each other, it should be working together well. Both goals. So that's how I see it. If it's different than probably that's the point of awareness that you're getting that, hey, we need to refine this or try and see if we are doing the right thing. So yeah, that's the first thing to do it and keep your roadmap flexible, so that you can take a detour anytime if there is a change that is needed.

Lindsay Velecina: 46:45

Awesome. Thank you. I hope that helps. All right, we have time for several more questions here. So how this question from Jacob How do you size a spike during sprint planning? Do you recommend this approach? What do you do when as an Agile Coach not teaching Scrum? Wait. I'm having a hard time reading this question. So what do you do when as an Agile Coach not teaching scrum right will lead to the wrong result, as the team will no longer be doing Scrum versus teaching Scrum, right and losing your job because everybody agrees with you except the sponsor the boss of the project? Oh,

Arun Ramakrishnan: 47:32

very interesting question. I talked again, two questions here. How do you size a spike during a sprint planning? See, when you say sizing, you're not talking about estimation, if I'm not wrong, sizing is all about sh. Can this be completed within a sprint? Is that a realistic? Fine? That's all right. If you have the answer, go ahead with it. But if you're trying to think in the angle of gain or what I need to think an estimation then it's a difficult thing. So scrum doesn't talk anything about estimations. So I'm I'm a big advocate of going for no estimations at times, right. If you don't have estimations, then you don't have this problem of how much will I complete? So how much will I report to the end users or the managers or the management? Right? So then you don't have this problem of thinking of? How much will I complete. So if you still have it, then have a, again, a complexity based pricing, if you could give a stalling point, given if you have a practice like hey, we don't estimate spike. Good. So you have you reserved some time for your spike or a capacity for in your sprint and then start doing Spike. Spike should be a learning and an action that you can take based out of the learning as well. If it's just a learning, I would recommend you to see how what is the minimalistic action that you can take from the learning within that particular sprint as well. So having a bandwidth for that helps. Right? That's that's one way to look at spikes. That's my recommendation on using spikes in your sprint and sprint planning. Okay, now coming to your next question. So this is where as an Agile coach, if you're an Agile Coach, you got Scrum, right? Anything any change that you're bringing in, trying to have an alignment with this point. So that's the first thing that I would be asking as a sponsor, via an Agile coach, why me? That would be the first question I will try to understand from the sponsor. If you don't see an alignment, then probably helper. Help him help the sponsor educate by explaining that hey, from an Agile Coach standpoint standpoint this is what I'm coming in for how does it resonate with you? If they say no, I don't want this, I want you to be giving all these things. Probably as someone sat down short hours, whatever things not so much, I will probably ask them, again, a follow up question. So by doing this, whatever the charts, what are we trying to get out of it? Somewhere on the thing that your sponsor will be tying it back to the business value of the outcome. So, if they may not be explicitly saying you got to prop them, and then understand the core reasons, again, against why are they trying to set is doing in certain way, right, there should be a purpose, that purpose, ask them, okay, if this is your purpose, can I help you achieve this purpose by doing it in a different way. Try to have an alignment again, moving smallest of the needle, trying to get a buy in for your agile ways of working. That's the first important thing that as an Agile coach should be doing right along with you working with the teams in the right way of implementing Scrum.

Lindsay Velecina: 51:07

Super important advice there. Thank you. All right. So we have time for a couple more questions. So this question from Hersh Hirsch is asking, how do we break down large product backlog items? What are your suggestions for slicing and breaking down those bigger pieces. So

Arun Ramakrishnan: 51:32

if you go to your scrum guide, there is a very simple thing to break down items in a way that that it can be completed within a sprint, that is the Bible I would say whatever whatever breakdown that you can do, there are a lot of techniques, there are techniques like invest, make the item independent, negotiable testable is more or less dimmable and valuable. That is another technique. Irrespective of the techniques, try and see how that can be individually done, at the same time, deliver some value to the customers. That's it. And that should be completed that can be completed within the sprint length that whatever you're agreeing on. Should that should be the tip to start with.

Lindsay Velecina: 52:18

That's great, thank you. And I will drop a link in the chat in a second here with a learning series that we have on product backlog management that will be helpful. So this question from help them saying this correctly, Holger? What kind of sprint goal, would you suggest if the team is used to working on individual sprint relevant tickets that are important for for the requesting department?

Arun Ramakrishnan: 52:49

Okay, so that's, that's interesting. So first thing first, as a Scrum Master, I would try to see how do we bring those departmental requests into one umbrella as a product owner under the big product backlog that gives transparency that's one. So in my experience, how we have worked this, I've worked in a similar mode, but in a different things, they will have different stakeholders coming up with different streams of requests. So we try to tie it back to the end user, and then try to create a coherent goal. Let's take for an example. There are multiple improvement requests sent up there it is going to tie it back to a customer value or something of that sort. If you could relate to that, like, hey, let's take for an example. So we had a concept of categorizing our product backlog into different streams. I can call it as an epics in a way that, hey, I'm going to see if there are multiple requests coming in from a customer point of view. Is it customer desire? Or is it customer? Or is it like compliance? Or is it like some other benefit or a new feature or something of that sort, then we try and see if there are multiple requests coming from multiple stakeholders. And this looks more important. Now we're going to improve the customer desire in this sprint by doing XYZ. That could be a sprint goal that you can think of which we have different requests from different departments in one sprint, and then you are working to them. So which way in which, which way you're going to communicate to the stakeholders, hey, we're gonna do some customer desires. In case if you have some more customer desire requests coming in these lines, skip sending them sending them across, we're gonna prioritize this. So that way you have a streamlined setup that's given by the product owner to the stakeholders to keep bringing the changes. We're welcoming changes and we're keeping it in one place and regardless Together collaborate and then see which is more important out of these customer desires, and then trying to pick the top items, and then create a coherent goal with respect to customer design. I hope that helps.

Lindsay Velecina: 55:12

Thank you. Right. I think we have time for one last question. So, when multiple teams in an organization are following Scrum, what is your advice step cross team sprint planning and coordination between teams and delivering value together.

Arun Ramakrishnan: 55:30

Okay, so I'm a strong advocate of using Nexus. So the core thing is like I've used nexus in a way let's talk about are you asked about the first thing cross team refinement, right? If possible,

Lindsay Velecina: 55:48

bring they actually asked cross team sprint planning. Okay,

Arun Ramakrishnan: 55:52

cross team sprint planning, right. So cross team sprint planning again, this is this is where the new scrum guide, having an option of a product goal helps where now having a product goal is like one goal for multiple teams. Now, as multiple teams, how are we going to do a sub goals to in our sprints, which is like sprint goals are for individual teams. If you could create an next sprint planning, which is like a combined sprint planning, where the representatives of the teams comes in, and then do a sprint planning, if it's less than three teams, when all the teams can come in and do a sprint planning together, we call the risk Nexus sprint planning, where we are agreeing on the sprint goals based on the product goal. And then agreeing on goals for the individual teams, and then trying to high level agree on what sort of product backlogs that we may do to achieve the sprint goal. And then come to our individual sprint planning and then break it down but more and then working it out. And then having not just that right now creating a sprint backlog, which is like a holistic list one single product swing through backlog which is going to be a transparent information for all three teams, what other teams are working on. The core thing here is identifying or I should say identifying independencies, eliminating dependencies and then trying to see how individual teams can work without dependencies is the crucial factor here in the sprint planning. So if you're able to bring that down to a very minimal dependencies, then that's the first success that you're going to create an integrated increment at the end of your sprint.

Lindsay Velecina: 57:38

Okay, thank you. All right. So thank you, everybody, for asking your questions. I know there are some questions that were not answered yet. I'm going to share those with a room to make sure that we figure out a way to address those. So don't worry, we just had an influx of questions, and we got to as many as we could. So I just want to thank you, Arun, so much for your time today. And thank you to our live audience and our podcast listeners as well, for tuning in, and our audience here today ask some really great questions. So thank you so much for participating. Very quickly, I just want to share. Again, I mentioned this earlier, we have a lot of free resources on the scrum.org website, including some learning paths. Please check those out to help you continue your learning. There are webinars, videos, white papers, case studies, all that kind of stuff that can help you on your learning journey. And please stay connected with us through our social media channels. And around what is the best way for our audience to stay in touch with you? Would that be LinkedIn? Or is there another way that you prefer?

Arun Ramakrishnan: 58:51

Probably I can put my LinkedIn profile in the chat. If anything, then I'm happy to answer your questions. But give me a bit of time. If because there might be a lot of chats that are coming in. So that's that's the only. So I would definitely answer all the questions if you're going to throw me in your LinkedIn chats were connecting with

Lindsay Velecina: 59:13

me. Okay. Perfect. All right. Well, thank you everybody, again for your participation today and enjoy the rest of your day or evening and Scrum on. Thank you.

Arun Ramakrishnan: 59:28

Come on. Thank you. Thanks, everyone, for tuning in today.