Ask a Professional Scrum Trainer - John Riley and Ben Thorp

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.

 

Transcript

 

Lindsay Velecina (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 Thorp. 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 Lindsay Velecina. I am with Scrum.org and I will be your moderator.

Lindsay Velecina (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 questions as we get through these intro slides here. So really quick who is 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 team solve complex problems through higher levels of professionalism.

Lindsay Velecina (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 knowledge 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.

John Riley (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 coach and trainer for Ready Set Agile, which I started back in 2017. And we really just have one, one idea and that's 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. You can be part of our community and I'll send you a Slack invite.

John Riley (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 you, 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 a marketing team for a credit card promo. You know, that, that was very interesting cuz it was mostly marketing focused, but not completely cuz we had to figure out how we're gonna integrate with some of the IT teams.

John Riley (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 formal 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, hope to have some really good questions to answer.

Ben Thorp (05:45):
Hi everyone. My name's Ben Thorp. I kind of went with, with a visual approach here for, for my bio. I received feedback once at a job interview that my resume made absolutely no sense <laugh>. 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 bys and, you know, pretty quickly realized where my, my real passion I was in around creating work environments that really leveraged 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 Thorp (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 the 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 in 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 a 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 the empirical 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 SaaS 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.

Lindsay Velecina (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 good one to meet that one. Go ahead, Ben.

Ben Thorp (09:06):
Yeah, I don't, we're, John and I are both like, Hmm, who's gonna, who's gonna bite first? <Laugh>. 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? In my experience in a lot of environments, the product owner is actually incentivized for 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, can mean it means very different things depending on the organization.

Ben Thorp (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 one part, help the product owner understand the role. See if you can help make connections with key stakeholders who 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.

John Riley (10:57):
I actually liked your answer a lot, Ben. And I was gonna say 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 you're coming from. When I've been a scrum master on teams, what sometimes what I do is I try to 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 backlog. 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 there, kind of separate the what from the how so product owner's all about the, what the self-managing developers are about the how so might not have better can something there. Yeah, absolutely.

Ben Thorp (12:26):
So, so you, as you were talking and 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 d delivery, output based team towards value by first at least just starting with each backlog 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 in terms of the why for each of these items.

Ben Thorp (13:18):
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 we're doing more than just shipping piece parts, we're plugging into this o overall objective that, you know, hopefully as you know, some of these larger objectives, there's more clear tie to customer value or business outcome. So some additional ideas.

Lindsay Velecina (14:09):
Awesome. Thank you both. Moving on. So could you explain the difference between test first and test driven?

John Riley (14:23):
I guess we would, I, 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. I, in, 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, a bank here in central Ohio.

John Riley (15:28):
And during our refinement sessions 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 is 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 Thorp (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 a, 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.

Lindsay Velecina (16:46):
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?

John Riley (17:09):
Jennifer, thank you very much for that question. Coming from a manufacturing background, I know exactly what you're talking about. 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 want to 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 said, I would think that Scrum with lean is a great way to go, because I mean, the very first lean principle to identify value and to map, and then second is to map the value stream, which, you know, in Scrum, that's what we do. So takes some time to kind of analyze why Scrum would be the right way to manage your complexity.

Ben Thorp (18:31):
Yeah, I, my, the, the, it depends answer is always, you know, the dreaded answer in, on these calls, but I'll assume that, 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?

Ben Thorp (19:26):
Well, that helps us create focus during the sprint itself. 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 up 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 need, so you can tie, you know, in the retrospective itself, you know, one thing you might 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.

Lindsay Velecina (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 to manage this problem is very welcome.

John Riley (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 sprinkle never changes during the sprint. However, the work can change. So first thing, look at the sprinkle, is it line up with that? And if not, then work with the product owner to see how we can put this on the 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 sprinkle? Yes, but then how can we work it in, depending on where we are on 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 sprinkle is most important and the work is secondary. Anything I had to bent, John

Ben Thorp (22:54):
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, ma may not see the impact of that. So what I would suggest too is f 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'd like to categorize all work, you know, so you have different types of work item.

Ben Thorp (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 sprint 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 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 can create context switching, which generates waste, you know. But I think creating a transparency initially can be a good way of talking about the impact you're having a conversation about what happened versus opinions and things like that. So,

John Riley (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

Lindsay Velecina (25:08):
<Laugh>,

Ben Thorp (25:10):
I charge I charge a fee for that. So.

Lindsay Velecina (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 Thorp (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 developers 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 s 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're 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 Thorp (26:45):
Here's a couple things we could try. We can start writing our acceptance criteria in a, in a product back 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'm using words that are maybe scary, but you, you, you know, you gotta move a P B I to done, and you can 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 and adapt.

Ben Thorp (27:38):
And so it, 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, let's, 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 team and you know, they end up, they decide their, their practices. So anything else, John?

John Riley (28:12):
Yeah, I might as well share my journey with that as well. It's very similar to Ben's you know, making empirical. When I was a developer and I was presented 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, starts creeping up on me. And then I realized, well, the problem isn't really well defined, so 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 an 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.

John Riley (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 see 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 system. 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, you know, get that muscle, as Ben says, going.

Ben Thorp (30:35):
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 project, a home project, and I replaced all our, our 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 Thorp (31:30):
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 have a pull of those kind of floating in your mind when you're, a lot of times these, these coaching are 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 Thorp (32:28):
So.

Lindsay Velecina (32:31):
Great, thank you. This next question is very much related to this whole topic. So it comes from him and 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 M V P. I think there's something wrong here. Have you had this situation at some point? How did you find a solution?

Ben Thorp (33:22):
So just to, again, we have to make some assumptions in this sort of format around. Yeah. 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 share a link there

Lindsay Velecina (33:53):
In independent negotiable value Estimable, small testable,

Ben Thorp (33:58):
Greg, Greg Porter. Thank you, Greg Porter, <laugh>. Thank, 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 Velecina (34:23):
Yes. Does not want to test each user story,

Ben Thorp (34:26):
Each user story. So ultimately the team has maybe a different understanding of what they're accountable for than, than you do. Jimena, you know, so, or maybe people in leadership. So I think, you know, this might be a, 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 of part that we're delivering, we are also responsible for that quality. So the 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 add 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 backlog guide. But, so that definition of done can expand over time to increase the, the accountabilities, but it's a tough one. Do you have anything, John,

John Riley (35:41):
I'll, 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 is 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 meaning the definition of done? Or is it just because we don't, we're too good to be on this team and test stuff?

John Riley (36:35):
You know, it could be a myriad of reasons. I just picked a couple <laugh>. 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 of done. So you know, I would kind of question that first and say, well, we mean the quality standards for our product. I mean, the Scrum team is empowered to make those decisions. So that's kind of where I would start.

Ben Thorp (37:12):
Definition of Dun is so SoCo 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 prof, true professional, you know, product development teams that deliver high quality invest user stories, all acceptance criteria. These are all great, but I 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 of the definition of done. So, yeah, I'm just kind of adding, plus wanting what you said there, John.

Lindsay Velecina (37:58):
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 Riley (38:13):
Well

Lindsay Velecina (38:15):
Kind of a broad question, but

John Riley (38:17):
It it is,

Lindsay Velecina (38:17):
You have some examples that you could share?

John Riley (38:19):
Yeah I mean, I've, in my bio, you know, the last three projects that I, or products 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 Canvan diagram or a Stacy diagram, basically measure your what with your, how I'm using my arms as axes 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.

John Riley (39:23):
What's 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 of done, figuring out your cadences and all that kind of stuff. So you 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 Thorp (40:00):
There's, there's a lot of ways you can get started. I think there's different, and there's different 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 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 conbon, CONBON 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 Thorp (41:07):
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. Well, how about we start a sprint 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.

Lindsay Velecina (41:40):
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. 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?

John Riley (42:23):
Well,

Ben Thorp (42:23):
This, this might be known as what you might call a hand grenade question. Yeah, yeah.

John Riley (42:27):
<Laugh>, 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 great. 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, 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 p 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? Is it less? Right?

John Riley (43:31):
And, and one thing to learn to know about estimation is that in general, my feeling is that estimation is a waste. 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 P B I, 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 Thorp (44:37):
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 useful. These do not replace the importance of pur 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 Thorp (45:36):
So a lot of, a lot of interesting discoveries can be made when a team is trying to do an es an sort of an estimation exercise in a pure sense. And I'll, 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 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, hi, 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 Velecina (46:48):
Awesome. Thank you. This next question comes from Claire. I think it might re others might relate to this one. I'm working with a team where the product owner has been assigned too many projects, too 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 Thorp (47:23):
<Affirmative>? So I 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 Velecina (47:39):
Of the value of their time,

Ben Thorp (47:41):
The value of the product owner's time? Sure, 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 they're, 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 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 item, this is where you can start to bring in some lean and combine metrics.

Ben Thorp (48:46):
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 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? 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 Riley (49:23):
Great. Yeah. Yeah. Ben, you, you, oh, sorry, Lindsey, go ahead. Go ahead. No, I was just gonna say Ben stole my answer this time. What you wanna 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 are 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 know we're definitely bringing up in a retrospective.

Lindsay Velecina (50:25):
Okay, this question again, 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 Thorp (50:48):
This is something I bet I, I don't, you know, want to be presumptuous, but I bet many or most of us have experience over the last 18, 24 months.

Lindsay Velecina (50:58):
Absolutely.

Ben Thorp (51:00):
It has been a tough time for, for many of us. And you know, I, I have experienced this very directly. It's, you know all of us have our own 2020 stories, 2021 stories, pandemic stories, 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'll, I'll say whatever your your title is, if you're in a position of leadership, the most important thing is to have empathy and really just understand 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. So as a leader, you need to just have empathy, understand, you know, what's going on. So that, that's my, hopefully that's not too soap oxy type of an answer, but that's how, what I've appreciated when I was maybe going through some struggle with 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.

Ben Thorp (52:14):
Second answer, use the, leverage the frame, 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, retrospective has become very mechanical. They become, well, we have to generate our, our action item. You know, retrospective isn't useful unless it's generating an action item. And we're always, you know, positive action, chipping away continuous improvement, 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, I guess I would do a 2.2 point B answer. 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, leverage 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 Riley (53:54):
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 reach the 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 'em to the best you can. I have been 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 product goal.

John Riley (55:08):
Let's look at how we did the sprint and everything like this. But some other things were coming out. You know, if you break out 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 <laugh>, those are the times when you really, there's, there's reasons why the retrospective is you just with the team, and it's usually in a closed room. Take that time, make it effective, 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 Velecina (55:56):
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. I'm 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. It 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 to 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 Riley (57:11):
So if, if I'm understanding the, correct the question correctly and, and 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 right, right. Go with it. Learn

Lindsay Velecina (57:27):
To go, like, how, how do we get these folks up to speed?

John Riley (57:34):
You know, being a Scrum trainer, I'm always gonna say, yeah, you need to <laugh>. 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, 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.

John Riley (58:43):
And the most important part of, you know, that first sprint is to realize that the value is most important, 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 going to 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 Velecina (59:40):
<Laugh>.

John Riley (59:43):
Okay.

Ben Thorp (59:43):
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 a leadership or a respective position you know, kind of build that. That could be a good way to, to start as well train, 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. You use a great term there, John. We'll feel mechanical at first, kind of going through the motions, but again, it's, you know, like if you're learning karate or TaeKwonDo, you're going through the motions until it becomes second nature. So,

Lindsay Velecina (60:39):
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 John and Ben. I thought this was a great session. And I think I hope the 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 you all have a great rest of your day or evening and scrum on.

Ben Thorp (61:42):
Thanks, Lindsay. Thanks John. Thank

John Riley (61:44):
You, Lindsay. Thank you everyone.

Ben Thorp (61:46):
Bye.