Blog

Update from event: In case you missed it, here is the recording that Ben and I did for a live world-wide audience at an official Scrum.org community event.

Scrum itself is a simple framework for effective team collaboration on complex products. While it is lightweight and simple to understand, it is difficult to master. The Scrum.org Ask a Professional Scrum Trainer series features Professional Scrum Trainers (PSTs) in a live session, answering your most pressing questions regarding the challenges and situations your Scrum Teams are facing. This particular episode focuses on regulating workflow of IT and non-IT teams and focusing on continuous delivery.

In this episode of Ask a Professional Scrum Trainer, PSTs John Riley and Ben Thorp answer questions related to regulating workflow effectively and developing a test-first mindset. They provide insight on practices and techniques useful to kickstarting continuously delivering software and non-software products.

Lindsay (00:05): Good morning. Good afternoon. Good evening. Wherever you are around the world today. Welcome to today’s ask a professional scrum trainer webinar. Today I am here with John Riley and Ben Fort. They’re here to answer all of your questions about scrum and are happy to help with questions around regulating workflow effectively and developing a test. First mindset. Also happy to answer questions related to non-software related industries pertaining to scrum. So hoping for some great questions and some really good discussion today. I’m will I am with scrum org and I will be your moderator. John (00:51): Cool. There we go. So some quick guidelines here before we get started. So you may have noticed your microphone is muted. However, that doesn’t mean we don’t want you to ask questions. That’s what, why we are here. So please enter your questions into the Q and a box located at the bottom of your screen. This recording will be available within 24 hours. So if you need to leave for any reason or anything like that, there will be a recording of made available to you. So please start, you know, populating your question as we get through these intro slides here. So really quick who was scrum.org? So we are the home of scrum. We were founded by Ken Schwaber, the co-creator of scrum back in 2009. Our mission is helping people and teams solve complex problems through higher levels of professionalism. John (01:49): We offer training and certification in professional scrum and have over 340 professional scrum trainers around the globe teaching our courses and also have our professional scrum certifications to help you validate that, that you gain. And we also have a bunch of free resources and we encourage you to use those on our website webinars like these and learning paths as well. So please feel free to check those out, and I hope that today is an important asset that will help you on your learning journey. So with that, I would like to hand it over to John and Ben introduce themselves. Ben (02:35): Thank you, Lindsey. Hello everyone, wherever you happen to be. My name is John Riley. I am based in the Columbus Ohio area in the United States. I just want to express my gratitude for being part of this scrum.org community event and the fact that there’s just so much interest in scrum and to be able to see how you can see how you can effectively put it into practice. I am the principal agile coaching trainer for ready set agile, which I started back in 2017. And we really just have one, one idea and that to obtain feedback rapidly and respond to change. So that’s part of our mission is to help teams understand the importance of what self-managing means and having an empirical approach. So that’s my email there. If you’d like to email me, I can be part of our community and I’ll send you a slack invite. Ben (03:40): Some of my recent scrum efforts outside of the training classes that I run I’ve been practicing agility since about 2010. So most of that has been with the scrum framework in place. The first three that things that you see there are non it related efforts. And that first one the scrum master for a basically a manufacturing project. And that was their mission statement. That was their product goal was to come up with a revolutionary building material and yes, they got funding for that. You know, some other things you know, with marketing teams for credit card promo you know, that, that was very interesting cuz it was mostly marketing focus, but not completely cuz we had to figure out how we’re gonna integrate with some of the it teams. Ben (04:41): I’m also working on a partnership with a couple other guys to help them take on that agile mindset. And another effort is to help a media producing company to come up with a DevOps culture and figure out what that means. I’m also heavily involved in helping our young adults and youth to take on scrum and trying to implement it in our schools. And you know, in general I’m kind of a mentor to show people how to do that. There’s my bio below that all the form stuff manufacturing background, mostly software development. I came up from the software development ranks was a developer for you know, over 20 years, but I still dabble in code here and there. So that’s a little bit about myself. Hope to have a great session. I hope to have some really good questions to answer. Ben (05:46): Hi everyone. My name’s Ben Thorpe. I kind of went with, with a visual approach here for, for my bio. I received feedback once at a job interview. My resume made absolutely no sense so I’ve done a lot of things and, and played a lot of different roles. So you know, came up as a software engineer. Writing code did a lot with, you know, bits and bites. And you know, pretty quickly is where my, my real passion it was in around creating work environments that really leverage the best in people. Because it, you know, one it’s the right thing to do. Two, it creates, you know, drives better business results. When you have, you know, high performing teams, you’ve got a good culture, you’ve got good collaboration. And so I, I realized that that was really where my passion was. Ben (06:42): So I kind of twisted, you know, my, my software engineering background into, to this approach. So you can see there kind of halfway down the, the scrum master and product coach. Once I was exposed to the scrum community became scrum trainer, you know, started taking my scrum master positions. I’ve never gone back every position that I’ve had or role that I’ve been in. I show up as a scrum master, even if it’s not my title. You know, so I it’s, it’s something that sort of was embedded in me. So and you know, really my that’s my professional mission and whatever role I happen to be in is, you know, I say it down here in the mission, you know, delivering product that matters obsessing about customers, constantly learning and experimenting and cultivating the culture of safety and, and cooperation. And, and what I like about scrum is the it’s a value based framework you know, based on empiric process. So it, it really fits in with my own professional mission as well. So currently I am the VP of product development at ever commerce in the home professional services. It’s a SAS company. So I’m running product development there. I’m supporting product development there for those couple of brands there. So yeah, that’s it. John (08:02): Fantastic. Thank you. All right. So it is now time for a Q and a session. So everyone please load your questions into the Q and a box. And I will start going through those for those of you who just joined your microphones are muted. So if you have a question, just enter it into the Q and a box. If you have any technical issues, please type those into the chat. So I’m going to stop sharing. Okay. So questions are starting to come in. So this question is about product ownership. So do you have any suggestions to convince the product owner to maximize the value of the product itself and not try to maximize the utilization of the scrum team? Who wants that one? Go ahead, Ben. Ben (09:06): Yeah, I don’t we’re John and I are both like, Hmm, who’s going, who’s gonna bite first. yeah, that’s a, that’s a tough one. There’s a scrum answer to that, you know, and I, but I, I think the, this webinar is, is about being, you know, practical practical ideas and thoughts around how to kind of address some challenges. What I would first wanna understand is how is this product owner currently being incentivized? And my experience in a lot of environments, the product owner is actually incentivized or delivery for shipping of features for having a predictable delivery process. So as long as that is in place, you know, a product owner might not be incentivized or connected to the value in the organization product owner in, in quotes. I mean, it means very different things depending on the organization. Ben (10:02): So they may not necessarily have what scrum, you know, sort of is in the framework, which is the, the product owner owns the, the actual final outcomes and final value. So I guess the suggestion is in part help the product owner, understand the role, see if you can help make connections with key stakeholders, you do own the value. And two part of, you know, if you’re coming at this from a scrum master perspective, part of your role is to coach upward and outward into the organization. So one of the things you can do is create some transparency around this and, you know, you, you can present, you know, work with this, with those, those key stakeholders and ask, Hey, what would it be better if these software development teams were more plugged into the value statement, but that’s not really much of an, an answer. I’m curious to hear what John has to say about it. Ben (10:58): I actually liked your answer a lot, Ben and I was gonna say the things along the same lines you know, I, I coach a lot of teams that that’s their first go-to from a product owner perspective is to say, well, I want output from the team. So I, I totally understand where we’re coming from. When I’ve been a scrum master on teams, what sometimes what I do is I try to you you know, allow the product owner to understand that they are concentrating on the what on defining the what and what I mean by that is take a lot of time to define what your purpose is for putting a product backlog item on your product. And as Ben was saying, your main job as a product owner is to maximize the value of the product, right. And part of that is to identify value, right? What is value to your customer, your stakeholder, your user what’s value to you, and what’s value to the team what’s going to help the team succeed into being the best self managing team that they can and, and really just start their, it kind of separate the what from the, how, so product owners, all about the, what the self-managing developers are about, the how so might add a better can something there. Yeah, absolutely. Ben (12:25): So, so you, as you were talking, it kind of made me think about different ways of defining value. And this also you, you know, you can start to nudge a, you know, more of a, a factory, a delivery output based team towards value. By first, at least just starting with each back, all item, you know, each, each, you know, in scrum terms, product back on item has some sort of value statement and don’t get wrapped up in, has to be perfect, or it has to be a pure slice of customer delivered value, but it’s valuable to someone. It could be stakeholder value. You know, it might be this thing is valuable to this stakeholder, even though we still might be somewhat disconnected from the final value. But that can start to get the product owner thinking of, in terms of the why for each of these items. Ben (13:19): The other piece is new-ish to the scrum guide. At least last year was the idea of a product goal. And, you know, there’s different industry terms that are also being thrown around like OKRs objectives and key results are another you know, way of looking at this, but in the scrum parlance, the product goal really defines a longer term objective. So if a product owner can help, can work with team and stakeholders start defining these product goals that can also help connect them to why are we even doing this? How does this even matter? You know, we’re doing more than just she piece parts, we’re plugging into this O overall objective that, you know, hopefully is, you know, some of these larger objectives, there’s more clear tie to customer value or business outcome. So some additional ideas. John (14:09): Awesome. Thank you both. Moving on. So could you explain the difference between tests first and test driven? Ben (14:23): I guess we would, I, I, I’m gonna just assume that that means test driven development and test first mindsets. You know, I I’ll, I’ll go ahead and jump on that one in, from the principle of what it’s talking about. They’re basically the same, having a test first mindset or test driven development what’s important to understand there is what is being tested. So, so let me just start with a test first mindset test. First mindset is talking about what Ben was basically referring to with identifying value from a product goal perspective. And, you know, that is when you come up with the purpose of your goal start thinking about, okay, well, how are we gonna test that, right? How are we gonna test this purpose? And that’s what a test first mindset is, is basically saying. Actually Ben and I work with a guy at a bank here in central Ohio and during our refinement session he would be the one that would say that’s great, but how are we gonna test that? And us as developers would say, whoa, wait a minute. Good question. So that’s basically what I see as a test. First mindset test driven development is basically the same as that test first mindset in that you write the tests, you watch it fail because there’s no no code to support it. You write the code to make the test pass, and then you refactor it to go, go according to your standards for quality. So that’s kind of how I differentiate those two Ben, anything to add there. Ben (16:12): So just to summarize test first, we’re saying is more of a mindset around thinking beginning with the end in mind, you know, conducting having an experimental mindset, whereas test driven development is a specific technique used for to apply a test first mindset. But also maybe more specific to the, you know, it’s a very specific software development technique that you can still use the test first mindset though out, even outside of software development. But I think that was a good summary. John (16:47): Thanks guys. Okay. Next question. Comes from Jennifer. I am in a manufacturing environment where some leaders want to lean out the scrum process as a scrum master. I don’t want to see the process leaned out. I think scrum is lean enough. What are you seeing in other organizations? Ben (17:09): Jennifer, thank you very much for that question. Coming from a manufacturing background, I know exactly what you’re talking about. What, one thing you’ll have to know though about scrum is that and it really isn’t made too transparent, but scrum when it was first developed was based on some lean principles. So I’m gonna assume that when you say lean, you’re talking about lean principles you know, that said if you wanna go towards scrum what I would, I, what I would ask you as a scrum master to do is to kind of take some time of why you want, why you think scrum is the way to go. If you, especially, if you think that it’s to help you manage complexity and you have a complex situation, then that’s where probably you would want to use scrum. You know, that’s said, I would think that scrum with lean is a great way to go because I mean, the very first lean principle is to identify value and to map. And then second is to map the value stream, which, you know, scrum, that’s what we do. So take some time to kind of analyze why scrum would be the right way to manage your complex. Ben (18:31): Yeah, I, my, the, the, it depends answer is always, you know, the dreaded answer on these calls, but by assume that to, like you said, John, when we say lean out what comes to mind for me, if somebody in a manufacturing environment, they want to reduce waste you know, if there’s, if there’s overhead and that is a, you know, I see this all the time in my work, there’s a perception that scrum can be, you know, 20 years ago it was, it was, you know, perceived as a lightweight framework today. I do hear, you know, well, it’s, it’s a heavyweight framework or it’s wasteful, you know, there’s all these meetings. So I think what’s important there is to demonstrate the, the value of each of those sessions, as far as, you know, what, you know, the, the sprint planning session, what, what does that help us to do well, that helps us create focus during the sprint itself. Ben (19:30): So that we’re all, we are all kind of working together on one thing, and we’re not context switching, and you can relate these things back to if people understand lean, they might understand, you know, the concepts of flow, the concepts you know, more combine concepts, you know, you can, you can tie it the sprint review back to, well, we’re making sure we’re actually doing the right building the right things by engaging stakeholders frequently. So it might seem like just an extra meeting. But the intent here from a waste reduction perspective is make sure we’re not waiting, you know, two, three months to get, to make sure we’re building the right thing. You, so you can tie in, in the retrospective itself, you know, you might would consider is bring that to the team in a retrospective, Hey, our stakeholders or our management. They’re, you know, I’m hearing talk that scrum is wasteful or, you know, there’s too much involved here. What do we think, you know, is there, are, are there aspects of how we’re implementing scrum that are wasteful there’s too much overhead? Take it to the team is sort of a common mantra amongst kind of a, a scrum folks. So, you know, bring, don’t be afraid to bring some of this, this input to the team directly and get, get their involvement in solving it. John (20:50): Great. Thanks. This next question I am going to join a team whose main problem is receiving backlog items at the last minute to be included in the ongoing sprint, any suggestion to correct and manage this problem is very welcome. Ben (21:11): Another common thing that we deal with as scrum masters or being on a scrum team. The way I’ll start that is just by pointing out that one of the agile principles is to welcome requirements, even late in development. You know, that said the first thing I would ask is that is this thing that needs to be added part of the commitment of the sprint goal, because one of the things in scrum that we try and reinforce is that the scrum goal, I’m sorry, the sprinkle, the sprint goal never changes during the sprint, however, the work can change. So first thing, look at the sprint. Gold is a line up with that. And if not, then work with the product owner to see how we can put this on a product backlog for a future sprint. If it does, then I would say that this comes to a, take it to the team situation where you would ask a team, okay, does this line up with a sprint goal? Yes. But then how can we work it in depending on where we are in the sprint to help us meet our goal, or what can we take outta the sprint BA basically coach the team to figure out what it means to the sprint goal? So, so that’s kind of where I would start with it, just knowing that the sprint goal is most important and the work is secondary. Anything I had to Ben Ben (22:54): John stole my answer. So then I had to scramble and think of something. So one additional thing, and this, this answer probably applies to a lot of these you know, real world issues that come along, oftentimes, you know, con confronting these things in a combative way or a, a resistant way may, you know, feel good in the moment, right? Because this, we know like most, probably a lot of people on this call understand the impact of teams of, of constant context switching and not being able to focus, but others, they don’t may, may not see the impact of that. So what I would suggest too is may make it transparent. And one of the things that I like to do with teams and this isn’t, you know, a scrum specified practice, but I like to categorize all work, you know, so you have different types of work item. Ben (23:50): You have, you might have a bug, you might have a, a new feature you might, and, and so, you know, you can categorize the work. I always categorize something as unplanned. If it came in, you know, after the sprint, after of planning and the, you know, the sprint was, you know, started anything that comes in after you can, you can label it, tag it as unplanned, and simply sometimes I’m amazed still to this day about simply displaying data. Hey, here’s a, you know, here’s how the last four sprints of, of the work item type mix, what looks, you know, and 50% of our work has been unplanned, and you could just leave it at that. And, and, you know, you can then start to talk about the impact of, as stuff comes in, we have to pivot and it create context switching, which generates waste, you know, but I think creating a transparency initially can be a good way of, of talking about the impact. You’re having a conversation about what happened versus opinions and things like that. So, Ben (24:57): And I absolutely love that little tip you gave about making unplanned work, transparent, categorizing that I’m, I’m gonna use that Ben (25:10): I charge I charge a fee for that. So, John (25:17): All right. So we are going to go back to the test first mindset. So can you please share some tips to develop a test first mindset, which makes it attractive for developers? Ben (25:38): So I can talk about my, my own journey. Now, as far as how to influence developers, you know, it’s like good luck to all of us. You know, the, the really good developer are also very, you know, sometimes opinionated for good reason. And you know, they, you know, they have good reasons for doing things and not doing things, but it, it is a, it is a muscle and it’s not easy at first. And so just like anything else, like any other practice there’s initially an initial, you know, sell, Hey, I I’d like to I think this is the benefit having a test first mindset. I think it will help us improve our quality. I think it will help us reduce the complexity of our solutions because we are kind of discovering and teasing out the solution as we’re, as we’re writing these tests, you know, X, Y, Z benefits to having a test first mindset. Ben (26:45): Here’s a couple things we could try. We could start writing our acceptance criteria in a, in a product back, all item stated as a, as a test case, you know, so that your acceptance criteria becomes sort of a a test plan. You know, I using words that are, may be scary, but you, you, you know, you gotta move a PBI to dun and you go to the acceptance criteria and, you know, I can check these things off and it meets the criteria. That’s test first mindset. So you can dip your toe into it. Run an experiment, really test first mindset is an experimental mindset. You know, you are, you’re when you’re running a test, you’re, you’re gonna try something and you don’t actually know what the outcome is going to be yet. And so you, you create a hypothesis, you run the test, you examine the results and you inspect an adapt. Ben (27:38): And so it is a very scientific approach. It’s a disciplined approach. And when you use the D word, when you use discipline, that means it does take practice and some commitment from the team to give it a try. So that’s how, what I would recommend is run an experiment. You know, but for a couple of sprints, we’re gonna try these, these things and then we’ll see how it goes. Ultimately, you know, you take it to the and you know, they end up just, they decide their, their practices. So anything else, John? Ben (28:12): Yeah, I might as well share my journey with that as well. It’s very similar to Bens you know, making empirical when I was a developer and I, with a problem, my first instinct was to, okay, I’m gonna start forming a solution in my head. I’m gonna go right to development. And what I quickly realized is that, oh, I didn’t think of that. Oh, I didn’t think of that. And, you know, start creeping up on me. And then I realized, well, the problem isn’t really well defined. So I had to keep going back and generating a feedback loop to say, okay, well, what do we need to do here? Then I finally realized that, well, you know, it’s, we have to figure out how we’re gonna form this test first. And, you know, Ben alluded to who acceptance criteria that’s you know, something we had to play with on some teams that I, where I was a developer is to, you know, figure out what that acceptance criteria is. Ben (29:17): Because as Ben said, that becomes your test script. If you have well formed acceptance criteria, that’s a great complimentary practice to scrum to try and how this acceptance criteria works, make it transparent on your user stories. If that’s what you’re using and inspect and adapt. That’s a test. First mindset is to come up with a test script. I’ll also borrow something that I learned from DevOps being in a DevOps culture and trying to have that continuous testing mindset. You know, the first way of DevOps is to, you know, emphasize that, you know, the speed and efficiency of your system is more important than your little silo. So, you know, developers actually have to come out of their development silo and start thinking about how this is going to affect the rest of the. John (00:30:01): So, but yeah, as Ben was saying, make it empirical, make it transparent. So then you can inspect it and you can adapt to new ways. And as Ben says, I’m stealing his phrase again, chip away at it. It’s gonna take some time. It, it will take a lot of iterations to be able to start to of, you know, get that muscle. As Ben says, going Ben (00:30:25): One other little tip, and this is something that I’ve started doing over the last few years, but I keep a, if you’re in a position where you’re, you’re in a coach, you’re in a coaching role, whatever your job title is, but your, your job is to help improve the performance of, you know, your, your teams. I keep sort of a backlog notes of analogies and it sounds silly, but I think kind of dumbing it down to something that most people can understand, you know? So I was just thinking about, I did a pro a home project and I replaced all our law flooring with hardwood floors, and this is a big project and you have to buy all the flooring up front. And so you have to sort of get it right. And so, you know, how do, how do I know that the flooring is what I want? Ben (00:31:20): You know? So I started with, okay, well, the flooring needs to match the wall color. Okay. Well, instead of, you know, just going and buying all the flooring and picking the wall color, I ran a test, all right, I’m gonna get a sample. I’m gonna put it on the floor. I’m gonna paint a little swatch of, of paint with this color and I’m gonna, you know, make sure that that’s what I want first. So I ran a test, you know, test number two was, I need to make sure the flooring is secure to the subfloor. I don’t know what I’m doing. I’ve never put hardwood floor in before, but I ran a test and a test was, you know, can, you know, secure this to this, to the subfloor, using these new tools that I developed. So, I mean, that might not be the best analogy, but I think that if you had pull of those kind of floating in your mind, when you’re a lot of times, these, these coaching art, these coaching teachable moments come up out of nowhere and you need to be prepared with, you know, how to kind of walk through the mindset piece of it. Ben (00:32:18): So, Lindsay (00:32:21): Great. Thank you. this next question is very much related to this whole topic. So it comes from him Jimena and we are using user stories in our sprints. The team verifies the user stories to make sure that they comply with invest , which is an acronym in all caps. So we might need, I don’t know if you guys are familiar with that and has an acceptance criteria. However, for some reason, the dev team does not wanna test each user story and wait for the whole MVP. I think there’s something wrong here. Have you had this situation at some point, how did you find a solution? Ben (00:33:12): So just to, again, we had to make some assumptions in this sort of format around the question itself. So, you know, invest. So a point of, you know, just for others on the, on the call that may not know, and I’m gonna have to look, this acronym up probably invest is, is an acronym used to help guide the crafting of a, a user story that, you know, invest? I, I forget what they are. Maybe we can it in Lindsay (00:33:44): Independent negotiable value, estimable, small testable, Ben (00:33:48): Greg Greg Porter. Thank you, Greg Porter. thank you, Greg. Yeah, so it’s a, it’s a very common technique. It’s very useful for creating user stories that are, that are those things that can be, that have value associated with them and it can be delivered, you know and incremental, incremental pieces. So if I get the question, it was the team doesn’t want to test the full user story. Did I get that correct? Lindsay (00:34:13): Yes. Does not want to test each user Ben (00:34:16): Story each user story. So ultimately the team has maybe a different understanding of what accountable for than, than you do him in a, you know, so, or maybe people in leadership. So I think, you know, this might be a situation where we just need to realign on what the team is accountable for, ultimately, which is the final delivery of value. And that means, you know, each piece part that we’re delivering, we are also responsible for that quality. So a scrum answer to this is the, the definition of done is a tool here to use. So maybe for now the definition of done, doesn’t include this full, you know, full end, end to end full testing of each story, but you can that in incrementally over time, and that expands the team’s accountability to the next thing, you know, you know, E the, the team is delivering fully functional, fully tested user value in each product back all item. But so that definition of done can expand over time to increase the, the accountabilities, but it’s a tough do you have anything, John? John (00:35:31): I’ll start my answer by taking it from where you had the tail end there, and that is the definition of done. I mean the scrum guide even says, and I’m quoting it right now, looking it up the definition of done as a formal description of the state of the increment when it meets the quality measures required for the product. So we’re talking about quality here and I mean, this is a commitment for the increment. So I would say that this is the main thing you should be focusing on is your commitment for the increment of the definition of done. If there’s certain user stories that aren’t being tested, then I would question, you know, why is it not meeting the definition of Don, or is it just because we don’t, we’re too good to be on this team and test stuff? John (00:36:26): You know, it could be a myriad of reasons. I just picked a couple but that’s where kind of, I would go. And I would just say that you know, the, the practices that I heard in the question of you know, user story invest you know, all these are complimentary practices to the real thing, which is the definition I’ve done. So you know, I would kind of question that first and say, well, are we me the quality standards for our product? I mean, the scrum team is empowered to make those decisions. So, yeah, that’s kind of where I’d start Ben (00:37:03): Definition of done is so core to scrum and creating transparency, delivering quality, and really it’s one of the key tools in your toolbox as a scrum master to, to create pro true professional, you know, product development teams that deliver high quality invest user stories, all acceptance criteria. These are all great, but let mean, let’s be honest. This could be written on a napkin. This could be a conversation. This could be on a note card that ultimately it’s the final product quality that, that really matters. And that, you know, means that the team really is on the hook for ensuring the quality per the definition of done. So, yeah, just kind of adding plus wanting what you said there, John. Lindsay (00:37:49): Great. Thanks. Here’s a question. So any advice for anyone who wants to get into scrum, but doesn’t work in an it environment? John (00:38:03): Well Lindsay (00:38:05): Kind of a broad question, but it is you have some examples that you could share. John (00:38:10): Yeah. I mean, I’ve in my bio, you know, the last three projects that I, or products that I worked on were non it related knowing that scrum is used to, you know, generate value through adaptive, complex problems. I would start there, I would say, okay, well, a scrum, right? For this situation, do you really have a complex problem? And what I’ve used is what we use in class. I either use a Canne diagram or a Stacy dye ran basically measure your, what with your, how I’m using my arms as a axis here. And if you are kind of far from agreement as to what the business value is needed and kind of you know, kind of away from how you would do that, then you’re probably in a complex situation. That’s where I would start. And then from there, figure out what your product goal is, what your mission, what’s your vision, why are you doing what you’re doing? Start from there. And if you’ve ever been involved as a scrum master, building a team, then the other pieces, you know, kind of fall into place as to forming the team, forming a definition, done, figuring out your cadences and all that kind of stuff. So your events kind of, kind of a broad answer for a broad question, but that’s, that’s usually how we start. That’s how we started on this come up with a revolutionary building material, product goal. Ben (00:39:50): There’s, there’s a lot of ways you can get started. I think there’s different and there’s different amount mindsets around this too. There’s the, you know, push everybody into the water at the same time mindset, you know, where everybody, we do this change, this big change together, and everyone’s bought in and we’re moving to scrum all at once. There’s the incremental mindset which, you know, I’ve actually had more lasting success with, and this is what I recommend for, especially if there’s, if you’re in an environment where scrum isn’t well understood out, like outside of software, product development per, you know, for example you know, start, there’s a couple places you can start. First thing is just make the work transparent. So just, you know, put your work on a, on a board. And this is where if you wanna become sort of a student of Kanban, Kanban can be a good place to start dipping your toe in, but make the work transparent and get into a cadence, you know, so you don’t have to set up all the scrum events at once and define the definition of done. Ben (00:40:57): And, you know, you don’t have to go through this heavyweight transformation. You can start small, start with your daily scrum and a retrospective, and you could just start with that, you know, and then at your, at your retrospectives, that’s your chance to say, okay, what didn’t go well, you know, what could we add? Well, we really need to get our key stakeholders more involved. How about we start a spread review, you know? So you can sort of iterate yourself into a scrum implementation from there if there’s not sort of widespread buy-in or understanding. So, Lindsay (00:41:31): Okay. Thank you. I just want to add a little side note to our audience. We’re trying to get through as many questions as we can, and I noticed some are coming into the chat. If you could please move those over to the Q and a that’ll be a better way for us to capture those as I weave through these questions. So thank you. I would appreciate that this next question comes from Leonardo regarding estimations. So what do you think about estimations in scrum? Do you think that estimating using story points is a good way based on your experience? Ben (00:42:13): Well, this, this might be known as what you call a hand grenade question. Yeah. John (00:42:16): Yeah. , that’s exactly what I was thinking. Ben. yeah, there’s a lot of complexities in the question as Ben and I have already kind of talked about you know, when it comes to estimation story points is rate you know, anything that’s not absolute and more of a relative estimation is, is better. And let me tell you what I mean by that. The, the reason why we use relative estimation in, in agile in general is to use empiricism. So, so it’s an empirical approach to estimating. So basically compared to this piece of work that was already done, what is this piece of work going to be compared to the, the size and complexity of that first thing that was already done? Okay. So it’s comparing it right. Is it more, is it about the same less, right. And, and one thing to learn to know about estimation is that in general, my feeling is that estimation is a waste. John (00:43:33): And the reason why I say that is because we’re, we’re trying to meet sprint goals. And the, the act of estimating in my term, or in my feeling is more of an activity that you wanna spend as least amount of time as possible and just use it for planning. So for this PBI, for example, can we fit it in a sprint that’s about it? You might have heard about the hashtag no estimates movement. If you could look that up, that’s that’s kind of what we’re talking about here. So yes, story points is okay. I try to get away from as many metrics for the team to use as possible , but you have to chip away at it. Ben, anything to add there. Ben (00:44:27): I’ll, I’ll pull up from the scrum guide here, since we’re on a scrum.org call, this is kind of supporting what you said, John various practices exist to forecast progress like burn ups, burn downs, or cumulative flows while proven used school. These do not replace the importance of empiricism in complex environments. What will happen is unknown only what has already happened may be used for forward looking decision making. So the estimation piece can be useful. What we try to go for is to make it empirical, to make it based on things that we already have learned, you know from our past the act of estimation as a technique can be useful in, in, in that it gets the, the team members, you know, around the, the quote table and to really, really dig into some of the details and refine that. Ben (00:45:26): So a lot of, a lot of interesting discoveries can be made when team is trying to do an an sort of an estimation exercise in a pure sense. And I will, I will also agree with John here in a pure sense, estimation is waste. It’s not directly contributing to the, the product development itself. So teams need to kind of use it as a, it can be a U useful, useful waste. I don’t know if that’s an oxymoron, but can be useful. But it’s something that we need to look at, make sure we’re not spending too much time trying to, you know, crystal ball gaze. There’s a hit, there’s a, a question beneath the question. Maybe I don’t wanna read too much into it and it’s, how do, how do how do we share our estimates and how do our stakeholders, or how does the organization use our estimates for forecasting for team performance measurement? That’s a whole nother webinar. But the, the, the core answer here is this is used by the team internally to do forecasting and, and work refinement. So, Lindsay (00:46:38): Awesome. Thank you. This next question comes from Claire. I think it might, others might relate to this one. I’m working with a team where the product owner has been assigned too many projects, much work. So our team has been struggling any advice on how to explain and convince management of the value of the product owner’s time without negatively impacting this highly valuable person. Ben (00:47:14): So I’m just restate the question here. Is it, was it specifically around the product owner has too many projects and too much work, so we need to convince management that the product owner needs more time to spend on their product ownership duties, Lindsay (00:47:29): The value of their time, Ben (00:47:31): The value of the product owner’s time. Yes. yeah, that, that’s a, that’s a tough one. And I’ve seen this oftentimes the product owner is extremely busy, you know, they might only have a few hours a week to spend with the teams and their, you know, they have additional responsibilities outside of just the core scrum team activities. So I’ll give my I’ll, I’ll, I’ll give my sort of canned answer and I’ll, maybe John has some more better ideas make a it transparent if possible. So you can share the findings, you know, scrubbed findings from a retrospective upward, you know, we can say you know, we, we, we needed the, the product owner’s time here, but we, we couldn’t because she was too busy and this caused us to sort of have a lot of rework, you know we had work items. This is where you can start to bring in some lean and combine metrics. We had work items that were sitting in progress for 5, 6, 8, 10 days, while they waited for a product owner to review it. You know, you can capture all that that’s that’s data you can capture and, and sort of present a upward. So we need, you know, so I think being transparent around the issue coming with data, if, if there is any data and how would it, might it be different if you had the product owner’s full engagement? Ben (00:49:04): So sorry if that’s a generic answer, that’s kind, sort of a, that would be one that we need to dig in over coffee for, for a little while, I think. John (00:49:13): Right. Yeah. Yeah. Ben, you, you, oh, sorry, Lindsay, go ahead. Go ahead. No, I was just gonna say Ben stole my answer this time. What you wanted do first is start to make that kind of make that transparent. Right. And to add to Ben’s answer, I would also bring up the fact that, you know, contact switching is actually very detrimental to any team who, where you’re switching, switching teams, you’re switching context, as a matter of fact you know, if you’re working 50% in one area and 50% another, you’re actually decreasing each of those by 20 to 25%. So you’re actually only about 25 to 30% effective in each area. So, but that’s make that transparent and you know, for definitely bringing up in a retrospective. Lindsay (00:50:15): Okay. This question. It’s another broad question, but I think you both might be able to provide some great advice. So how do you motivate a team that went through a rough time? Ben (00:50:38): This is something I bet I, I don’t, you know, want to, you be presumptuous, but I bet many or most of us have experience over last 18, 24 months. Absolutely. it has been a tough time for, for many of us. And you know, I I’ve experienced this very directly it’s, you know all of us have our own 20, 20 stories, 2021 stories, pandemic, you know, we’re still trying to be productive, we’re working from home. So I think the, if you’re in a position of, again, I I’ll say whatever your title is, if you’re in a position of leadership, the most important thing is to have empathy and really just under end, the, the plight of the individual on the team. It, it’s not your job. It’s nobody’s job in scrum or outside of scrum to fix a person. Ben (00:51:38): So as a leader, you need to just have empathy, understand, you know, what’s going on. So that, that’s my hope. It’s not too, so Oxy type of an answer, but that’s how, what I’ve appreciated when I was maybe going through some struggles myself is, you know, if leadership is understanding, you know, so I think that just having that space, you know, it’s okay to have struggles in a tough time, just have, have space. Second answer, use the leverage, the F leverage, the scrum framework. Don’t give up on your retrospectives. The, you know, use your retrospectives. I, I know in the industry and this something I’ve seen retrospectives become very mechanical, they become, well, we have to generate our, our action item, you know, retrospective isn’t useful unless it generating an action item and we’re always, you know, positive action chipping away, continuous improvement. Ben (00:52:33): That’s great, but the retrospective serves another purpose, and that is a release valve. And, you know, for the team who might be going through some tough issues, it’s also culture building, especially as if you’re in a distributed team environment where people aren’t meeting in person, you know having that human connection can make some of these tough times a little, you know, easier to to navigate. So really I would say, you know, put some time into those retrospectives you know, and, and use the framework. I guess I do a 2.2 to be answered, use the framework, you know, clear goals. The product goal is great. I was, I was so excited about that. Addition to the scrum guide, ambiguity is the enemy. When it comes to being in, in a tough time, people need some clarity, they need, they need to be able to focus on something. So, you know, lever is the framework define, you know, work with your product owner, define the goals, have real clear, you know, concise sprint goals. And, and so that people can, you know contribute. So sorry, I went a little long there, John. John (00:53:44): That was a great answer, Ben just to add to what Ben was saying I actually was looking at some data regarding this, you know, big, old job frenzy that we have going on now. And on one site, the number one reason why people were leaving their jobs was because they simply didn’t feel appreciated. You know, it really wasn’t many other things that Reese at top, but that was the number one thing. And, you know, one thing you can do as a, a leader like Ben was saying to you know, help a team through a tough time is to just tell them how appreciated they are. Having that empathy is just so important. And you know, like Ben was saying, use those retrospectives, you know, use them to the best you can. I have, and recently getting into some liberating structures with with retrospectives and it’s been actually very effective to know that, you know, Hey, okay, let’s look at the productal, let’s look at how we did the sprint and everything like this. John (00:55:01): But some other things were coming out. You know, if you break into groups for whatever reason you come together and you start seeing some commonalities you know, it’s like, well, we’re burnt out, you know, and those are the times when you really that’s, there’s reasons why the retrospective is just with the team and it’s usually in a closed room take that time, make it effect. And what can we do to have the company facilitate our needs to let them know that we’re doing some important stuff here. We’re doing a lot of hard stuff here, make that transparent, bring that into your sprint backlog. That’s, that’s where I would start. Lindsay (00:55:47): Great. Thank you so much. Felt like that was an important question. So we have time for like one more here and I, I see a ton of requests coming in through the chat to answer questions that were submitted going through them through I’m pulling questions, that answer multiple answers. But I am going to be sharing all of the questions with John and Ben after this. So they will be able to address them afterward with you. So don’t worry. Your question will be answered. Just not might make this session. So this last question here it hits a few that were asked that are similar. So what’s the best way to facilitate a team through scrum sprints where they do not really know how use scrum or not very well. Should we train people first or try to teach as we go? And this question is for non-developer teams and there was a similar question that came in for non-IT. John (00:57:02): So I, if I’m understanding the correct the question correctly, and then please chime in, I think it’s really about adopting scrum. Should we use training first or should we just, you know, go, you know, kind of Lindsay (00:57:16): Go with it, just learn to go, like how, how do we get these folks up to speed? John (00:57:24): You know, being a scrum trainer, I’m always gonna say, yeah, you need to . I mean, that’s the easy answer, you know, that said I, you know, and it’s about maximizing the value of the people who need to learn scrum and practice scrum. I’ve been practicing scrum, like I said, since 2010 and I’m learning something every day still you know, that said getting up to speed is is really kind of a broad term. I will use something that I’ve used in the past of the forming storming, norming, performing forming the team and being able to maybe go through mechanical scrum with whatever process they’re using now is probably a good way to start if you decide not to do training. I mean, even what I like about the APS class is we, we put the sprints to practice and we allow you to work on a case study where you know, you get to practice scrum and the most important part of, you know, that first sprint is to realize that the value is most important. John (00:58:42): What we deliver is most important because we generate that feedback. So, you know, even if, I mean, I, I train other other teams to just deliver something small, because what you’re trying to do is you’re trying to build that trust with your stakeholders. So even if it’s just a little hello world application, that’s gonna be important because they’re gonna give you feedback saying, Hey, you delivered something it’s kind of worthless, but you delivered something as opposed to, oh, we’re gonna take several sprints now to give you nothing. Right. What kind of trust are you really building with your stakeholders? So form the team, start to storm on your product, go from there and take the APS course. Lindsay (00:59:30): Ben (00:59:33): Okay. Yeah, I think just creating I would add to John’s answer find some allies, so you don’t want to enter into a change management change situation as a lone warrior, you know, so find some allies, find a sponsor, you know, someone who’s in leadership or a respected position you know, kind of build that that could be a good way to, to start as well. Tra even if you training is fantastic way to start, it really is. Even if you don’t, this isn’t an, you know, trying to sell if, if you want to put, pull together your own, you know, training fine, but have some sort of kickoff training and then just get started and it will feel mechanical. Use a great term there. John we’ll feel mechanical at first kind of going through the motions, but again, you know, like if you’re learning karate or TaeKwonDo, you’re going through the motions until it becomes second nature. So. Lindsay (01:00:29): Awesome. Thank you both so much. So we are at our time there are many unanswered questions. Thank you all for your patience. I, I tried to jump around a little bit and all of these are going to be shared as I mentioned before. So we will figure out a way to get them all addressed. So thank you so much, Jonathan. I thought this was a great session. And I think I hope they’ll audience. I hope you all got a lot out of this. So as always, we encourage you to continue your learning. So please check out the free resources on our website and feel free to reach out to Ben or John with any lingering questions that you have. And I hope, hope you all have a great rest of your day or evening and scrum on. Ben (01:01:33): Thanks Lindsey. Thanks. Thank you Lindsey. Thank you everyone. Bye.