Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask professional scrum trainer series, where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Good morning. Good afternoon. Good evening, wherever you are located welcome to today's Ask professional scrum trainer session. I'm Lindsey Villa Sina a scrum.org and I will I will be moderating the session today and I am very lucky to have with me today three professional scrum trainers. From one of our partners responsible advisors, we have Rob peeper, Greg crown and Jason mom stat here. So we are ready to kick this off. Very quickly about scrum.org. We are the home of Scrum. We were founded by Ken swaybar and 2009. We our mission is to help people and teams solve complex problems. And we do so through our professional scrum training. We have over 350 Professional scrum trainers globally. And we also offer professional scrum certification and lots of ongoing learning opportunities like this webinar. So please check those out on our website. And I know that the responsible advisors guys here put out some great content on our blog, so please be sure to check that out as well. So with that, I'm going to kick it over to Rob to introduce himself.

Robb Pieper: 1:42

Hello everyone, I have a Roomba that I need to pause because somehow found its way into my room and just sort of making all kinds of noise. Get started. My name is Rob peeper. I have been a professional scrum trainer efficiently now 10 years, it was 10 years this spring, I guess. Shocking. I've never done anything for 10 years except for breed. But I'm I teach a variety of courses. I just got the PSM two license after working on that for about three years, fairly inactively. But it's done. national public speaker I I've spoken at a lot of conferences, at least pre pandemic and only a few since the pandemic has eased. And I will actually be speaking at the PMI a couple of global gathering. I don't know what they called it this year, but it's in Atlanta in October. So if you are really into PMI, PMP XYZ certification stuff, I don't know what other certifications they have besides PMP. I'll be there as me your hardest questions on my talk on Agile transformations. other quick things about me into music. I mean, I'm in my music studio when I do my training classes as well as today. And I said then in to Texas at six, because that's when I first started programming a Commodore 64. So for those of you who started your programming careers as children, I was just trying to learn to make video games and just found programming fascinating. And it kind of kicked off a lifelong career in tech and Scrum. And, you know, it's just been a snowball of craziness. So anyway, that's a little bit about me.

Greg Crown: 3:14

Very cool. All right. So I'm the one of the Agile coaches and trainers for responsive advisors as well, and also the CTO, I have been a professional scrum trainer for gosh, I think since 2019. So I can't do the math, it's about four years now. Something like that. But since since then, been able to acquire a number of classes that I can teach recently added the pallet II and pursuing adding the evidence based management course as well. Pretty excited about that one. That's a good topic. So for my background, I've got to theology is my foundation with education. That's an interesting launching point for my career. I've got about 10 years in construction, and which I would say learn most about product management. At that point in time and customer engagement, some pretty high profile clients gave the opportunity for that experience. They're running a couple of businesses and have now joined forces of responsive advisors to continue to grow this company and help people because that's what we love to do. So yeah, things I like to do. I suppose I'm hanging out with my puppy dog. He will not be on the call. I get him off. He might be a little too disruptive. But hanging out with him. My 15 month old daughter, and yeah, just having a good time enjoying life.

Lindsay Velecina: 4:43

Okay, and Jason,

Jason Malmstadt: 4:45

that leaves me. Yeah. Hey, everybody. I'm Jason mom stead also professional scrum trainer. I've been teaching scrum for several years, but I joined the scrum.org community last year. So I've been a professional scrum Trainer. Coming up on a year now, my background is in software development, I spent about the first decade of my career writing code for medical devices, which is pretty fun. And also very high pressure, as you know that a software bug could adversely affect the patient. So, but I've I've used scrum for many years, I love being a scrum master. I've had some experience as a product owner or developer. And now I get to teach with these guys that response advisors and really love training. That's I have a theatrical background. And I think that kind of works its way into my training, as well as a little bit like being onstage I suppose. When I'm not working, I'm a vocalist. And my joke that I tell in every class as a vocalist is like being a singer. But the word vocalist sounds cooler. See my wall of nerdery on my slide. They're like, Lord of the Rings, and Zelda and Mario and Star Wars and all those good things. And I've got two young kids who much like Greg's dog should not be making any appearances in this webinar, but their kids you never know. So

Lindsay Velecina: 6:07

that's me. antastic Thank you. All right, so I am going to stop sharing. Because it is time for questions

Jason Malmstadt: 6:19

into some q&a.

Lindsay Velecina: 6:20

Yes. So just a reminder to everybody on the call today, please make sure that you are entering your questions into the q&a box, and not the chat. let's utilize the chat for any comments that you want to make or chatter, and that type of thing. And then let's utilize the q&a for your questions. Okay, so this first one here, so learn lines between Scrum Masters and project manager as expectations of roles. I want to talk about those blurred lines a little bit. Let's start with you, Jason.

Jason Malmstadt: 6:55

Sure. Yeah, I was just talking to somebody yesterday about this, who came from a project management background and said, you know, that Scrum Master is basically the same thing, right. And she was very surprised to see that a Scrum Masters responsibility is not to manage people not to manage tasks really not to have any decision making authority, other than perhaps upholding Scrum. So, you know, I tell people that Scrum Master is much more like a team coach, much more involved in coaching a team to be self managing, coaching a team to be more effective, sometimes removing impediments, but more often helping them learn how to manage their own impediments. So, you know, can a project manager become an effective scrum master? Absolutely. I've seen it many times. But you have to get your head around the idea that you're no longer in charge of managing managing time, budget and scope. You're actually much more like a coach, a facilitator. And just helping a team do the best they can be curious if I, Robert Gregg, have anything to add there?

Greg Crown: 8:05

My, my, my short answer to this one, and complement what Jason's already mentioned is project managers. They're managing projects. We're Scrum Masters. They're managing the effectiveness of the scrum framework, both for the team and at the organizational level. So once once you identify what the difference is, the lines aren't as blurred. But I think what maybe is at the just to the question is oftentimes organizations still blur those lines. Maybe it's stated, We need a scrum master. But the expectation by way, the job description is project management. And that is that's an unfortunate reality. That's not that's not very helpful and not very conducive to helping strong become effective. So I'm trying to read into the question a little bit thinking that might be sort of at the seat of it there.

Lindsay Velecina: 8:57

Okay, great. Anything to add? Rob? Are we good? I think they pretty much got it. Fantastic. All right. So this next question from James. So a little background about James here I am new to scrum coming from a health and social care management background. I have been in the scrum master role for a couple of months now. I've been reading lots of theory and book to take the PSM one qualification. I wondered what you would advise to someone new to the scrum master role and how to overcome some of the barriers of technical knowledge coming from a non technical role.

Robb Pieper: 9:37

I can go for this one. So sure, it helps to have technical knowledge. But at the end of the day, a scrum master doesn't really solve technical problems that developers are there to solve. So from from an empathy perspective, if you can learn a little bit about their domain that will help if you can pair up with somebody with a lot more technical experience than you and They can translate the geek speak into something that you can understand, that'd be great. A lot of the challenges you will likely hear from technical professionals are Hello, it's really hard to break down work into small enough pieces that being done in a sprint, you don't understand. And you got to understand why they're, they're saying that it oftentimes it's, if you look back, it's waterfall behaviors that are kind of coming through as they're trying to implement scrum by waterfall behaviors. I mean, like, Let's spend six months building a database, no one can use to get a just perfect, before we start building anything on top of it. And that'd be the same as like building an entire city just by starting with all the plumbing and roads before a single taxpayer moves. And so you can learn a lot from Sim City. I learned everything I know about merchant architecture from Sim City to video game. But those are my thoughts, it's helpful to understand it. But really a technique you're going to use as a scrum master is asking a lot of questions, and sometimes just being a good rubber duck. Because when people explain their problem to us, sometimes they go Oh, no, I just figured it out. Greg, and I do this to each other all the time.

Greg Crown: 11:04

You might for somebody who is non technical, you may need to explain what rubber ducking is, because I think that is traditionally a technical thing in itself.

Robb Pieper: 11:12

All right, so Google that but ultimately, imagine Greg is a big yellow rubber duck and can't say a thing. And I have to explain my problem to a rubber duck. Which means I gotta be very clear, because the rubber duck cannot ask me questions. And with the idea that there's a good possibility, as I'm working my way through the problem to explain it, I will have arrived at my own solution.

Jason Malmstadt: 11:33

I have been a scrum master both when I understood the technical background, because that is my background. And I've been a scrum master when I didn't. And I feel like I was often more effective when I didn't want to when I purposely kept myself from getting in the details, because when I knew the technical details, then I would, then I would be tempted to start solving problems, and instead of just revealing them, so don't sell yourself short, just because you don't have the technical knowledge. If you can get good at saying Tell me more. Why is that? Can you explain? Can you explain more of that I'm reminded of what Simon cynics famously said in the video that he's often the stupidest person in the room. By his own admission, he's like, I'm just the idiot. And I'm willing to ask good questions. If you can do that, you'll probably be a pretty effective scrum master.

Lindsay Velecina: 12:12

That's great advice. Thank you. All right. This next one is somewhat related. From Jeremy here, can you talk about Scrum use and team management outside of software development. I am an engineering manager running scrum with a team doing product evaluations, for example, labs, lab work, as well as designing integrated systems with these products. What are some of the key areas of Scrum that people get wrong when applying it outside of software?

Greg Crown: 12:48

Isn't my turn to take one of these? For it? All right. I liked that. We're applying this outside of purely software. And I think we need to accept the fact that the scrum framework helps us with complexity that is that's going to be the thing that we need to lean into. So what whether the technology or the subject matter is software or not. What can we look at to say where do people typically get scrum wrong in these environments. And I would say the the thing that we see pretty much on repeat is the difficulty for teams and I would even argue management layer, or even executive level, have a difficult time with clearly communicating goals that are customer outcome driven. And so when that, when that's missing, that kind of creates a trickle back or feedback loop into your scrum team, regardless of what it is that you're trying to solve problem wise or what your environment is. That creates a lot of dysfunction and noise. So the way scrum can actually be super beneficial and effective is when teams are self managing. But that only happens when we have a common goal. So a lot of inspiration can come from various sports activities, team sports, we've got very centric goals that everyone rallies behind, and they understand what the full purposes. But in traditional environments, there's a huge tendency to divide and conquer. Everybody's doing their own thing. And one of my favorite examples Jason gives it gives in his classes, imagine getting a print off list of a bunch of directions from Mapquest. And then you just put those papers all over the place. It's like cool, let's assemble a road trip. I mean, that doesn't really work that way. We need to know where we're going. So we know what directions to take. So I'd say one of the key key aspects that often get we get wrong within the Scrum teams is not having goals that really help the team focus and be able to rally together to go the same direction. Again, customer outcomes That's the that's the bent. But if you're in a environment in which customer might be internal, then that might be something that you just have to define who is your customer? Who is it that we're looking for those outcomes?

Jason Malmstadt: 15:12

I would just add to that, I think that I totally agree with you, Greg. And I would just add to that, remember that the whole point of Scrum is, it's to have a done working increment that can deliver value that we can learn from? So in software, yeah, that's a releasable package of usable software. Okay, so what's your product? I don't know what you mean by product evaluations in a lab. But maybe your product is really a service that provides a valuation of a property, no other products? Okay, what's an increment of that product? Right? It could be it could be much more efficient to try to evaluate 10 products simultaneously. But are you going to get to a done increment an evaluated product? Probably not. So you probably want to turn it on its head and say, We want to get to a and evaluated product as quickly as possible. You start by asking what's the smallest thing we can do to provide real value 10%, more of three evaluated products is not real value, but one evaluated product might be real value. And so figuring out what is an increment of my product, I think that's where it begins, especially when you're outside of software. With software, it's just easier to get there. Because, you know, came from software, and we know what an increment looks like, because we get increments of software on our phones every day. But for outside of software, you have to ask yourself, what how can I provide value in a really small and incremental and iterative way?

Robb Pieper: 16:33

I'll just pile on just a quick thing, because I'd hate to spend 20 minutes answering each question as we'll only get. My quick thought on that is whatever you make is likely valuable to someone identify that someone and keep making smiles on their face with small things. And when they don't like what you're making. If you're making things in small pieces, you can quickly change direction. And that's the whole point of Scrum in terms of its incremental delivery. So whatever you're doing, you got to figure out where the smiles are, produced them in small pieces. Obviously, the smaller the better, because you can constantly adapt and constantly put those smiles out there.

Lindsay Velecina: 17:10

That's great. Thank you. Great advice from all of you there. So this next question comes from Christina. Christina asks, How should we manage incidents and bugs when our scrum team also has to attend to the operation and support of the project? How about you, Jason?

Greg Crown: 17:32

Sure,

Jason Malmstadt: 17:33

I've worked with a lot of teams, I've been a scrum master and a developer on a team that was working this way where we were building a product, but we also had to support it as we were building it. And we thought we looked at a couple different ways. First, we were like, maybe we should just build in some buffer time in our sprints, we have some empirical data that sprint over sprint, about 10 to 20% of our sprint is is spent working on bugs and incidents that we hadn't planned on. So maybe we should just build in a buffer. We try that for a while. But the problem there is that you're just absorbing it. And it's easy to treat everything as an emergency. So instead, we started planning, what do I would call full sprint suite, you know, assuming that we're going to spend the whole sprint on building our product, you know, taking things from our product backlog. And then when incidents came in, we had a choice to make are we going to add it to the current sprint, assuming we can still meet our sprint goal, of course. And if we do something else is going to drop off and is fixing this bug really more valuable than this thing, other thing that we had planned on. And so having that trade off, made it much more transparent, both within our team and to our stakeholders, we could say, Yeah, we took on these bugs, because you know, our product owner or we as a team decided fixing this bug was more valuable right now than this other thing that we had originally planned on. And we could get feedback on, did we make the right choice or not? And learn from that. So you know, when in doubt, I go back to transparency, make make your decision making process as transparent as possible. It shouldn't just be a single developer saying, oh, a bug came in, I'm going to jump on it, like have a team discussion. You're you're updating your sprint backlog when you do that. So have a team discussion, bring your product owner and make sure you're all aligned. And make sure you're holding the sprint goal sacrosanct and just make those decisions as transparent as

Lindsay Velecina: 19:17

possible. That's great. Thank you. All right. So this next question, we'll give this one to you, Rob. What are some of your favorite retrospective ideas?

Unknown: 19:28

We're not doing this in order Are We

Lindsay Velecina: 19:31

Now jumping around a little bit

Jason Malmstadt: 19:34

order, there's no order.

Lindsay Velecina: 19:36

Order was no order. And just so the audience knows. I'm not purposely skipping over questions. I'm just trying to get some from the bottom some from the top so we can kind of keep it even for everybody. Since our time here is a little bit limited. We will try to get to as many questions as possible. There's no rhyme or reason, really to the questions that I am picking just so the audience knows All right. Go ahead, Rob. All right, my

Robb Pieper: 20:01

favorite retrospective ideas? Well, one of my favorite questions to ask is, if you had a magic wand, how would you solve that problem? Or, you know, if you had a billion dollars or whatever the main Yeah, the main idea being like, let's take away all constraints, all organizational problems, all deficiencies that are blocking you from coming up with a solution, you could do anything, what would it be? And then sometimes that helps jog people's minds a little bit to get them to go, Well, if I had a billion dollars, I'd buy this, I would do this and hire these people. And somewhere in there, you might find a solution to your problem. But it's not until you remove all barriers to idea creation until you find it. So that will be one of my favorite retrospective. The question was about retrospective ideas for questions, I think was just ideas, right?

Lindsay Velecina: 20:50

It was ideas, but maybe some facilitation tips would be helpful here, too.

Robb Pieper: 20:55

Oh, got him a bad facilitator. Um,

Greg Crown: 20:59

I got one, Rob. Oh, if you

Robb Pieper: 21:01

got an answer, you go for it. You guys are way more creative with facilitation than I am.

Greg Crown: 21:05

All right. Well, this comes with a little bit of story. But when I was scrum master for a smaller startup team, I was late to retrospective. Well, I was nearly late. I wasn't quite late, I was going to be on time within about 30 seconds. And I came rolling in the door realizing oh, I think I'm supposed to facilitate retrospective in 30 seconds. So I came up with this brilliant idea that I'm saying brilliant in quotes. People can't see that in the podcast. But I had this idea that maybe if I asked the group, what they identified with during this last sprint by way of a muppet, I might get some interesting results. So I posed the question, if you could identify with a muppet. And of course, you would have to be a muppet fan. And I knew my team. If you could identify with a muppet, this last sprint, which Muppet were you, and then I got a quick response from somebody saying somebody didn't prepare for a retrospective, got a cup of coffee. While they were all thinking about their Muppets, so they had to go find their favorite Muppet on Google find an image of it. And we all presented the Muppet images and explained why we felt we were this Muppet during the last sprint. And we got some ridiculously good insights, you got the appeal towards emotion because Muppets are very emotional looking critters. Why do the wild and crazy you know, why is that expression on their face? Why do they look angry? Why do they look like they are, you get the idea. So that was a really fantastic way to break the ice, it'd be able to get people to dig a little bit deeper to the emotion and feeling of a of a sprint instead of purely looking at the tactics. And then from that, we're able to get some nice cohesion with thoughts as a result then has some actionable but Muppet retrospective is one of my favorite ideas, or something like that.

Jason Malmstadt: 23:04

I think that's a great example of a broader point that I had to learn when I from when I was a new scrum master to as I as I got a bit more seasoned, it's not about rigidly adhering to any of the facilitation structures out there. If you do the speedboat, or the hot air balloons that are like like learn like it can be really tempting to be like, No, you have to have two in each category, and they can't overlap. And like, it's not about that just let go. If you're having a good conversation, who cares if it overlaps two categories, or if you make a new category on the fly one of my best retrospectives, we had a set facilitation technique in mind. And at the end, I could tell that there was just something else we needed to get out there. So I just throw out a fourth topic and added more things to it, like the conversation and the ability to come up with a continuous improvement item is way more important than rigid adherence to any of the structures.

Lindsay Velecina: 23:56

Great, thank you. All right, this next question here. So we have identified developer test notes as an impediment for the team due to inconsistency. I have completed some research and found a template. I had a meeting today with the team to agree to that template and get feedback for changes as well as agreeing some agreeing on some roles for the test notes. I wonder how you would look at implementing and monitoring this change. Greg, do you want to take this one? Yeah, some more context to feel free to ask James for more context in the chat. That is okay.

Greg Crown: 24:39

Yeah, looking at this so developer test notes as an impediment. Some research found a template meeting today have team agreed to the template getting feedback for changes as well agreeing to some rules for the test notes. Yeah, okay. So, basically what James is hinting at here is a it's an experiment Then based on what was felt as a impediment, we need to prove whether or not it was an impediment by way of this experiment. So I think of finding something that I liked some key words in the question that you've agreed upon as something to try as a team. Awesome. So these general sense of rules around how we might go about this, I think actually appeal to some of the scrum values that give respect and openness for change. So we can focus on doing the right thing. And so, so far, I'm thinking that this is a good suggestion. Now, the question is, how do you monitor the change? Well, there's another retrospective ahead of you. And one thing that I've done as a practice is keep track of the things that you hope to see. See the team integrate by way of changes and updates as improvements, and then periodically go back and look at those improvements and say, did they work? In fact, we just did this with our team. Within our corporate retrospective, we did this and said, Hey, we're gonna look back and visit the last six improvements. Did these make a difference? Yes or no. And if they didn't make a difference, we quit doing those things. And so we're able to look at a bucket of things that we hope to do differently. And with that, say, yeah, that made a big impact that had nominal impact, or that really didn't do it, we think let's quit it. Because if you've basically introduced a new activity for the team, and it's not making the impact you hoped for, you should probably undo the experiment, or try something else and see if that, see if that helps. So monitor the change. I would say it's less about graphing it or finding a chart and maybe just checking in saying, did it work, and even let the team maybe make that assessment throughout the sprint as they're making those notes? Because if it's if it's causing more frustration than hell, maybe it's time to rethink it. I don't know if that helps James, but it's my thoughts.

Jason Malmstadt: 26:57

I'm reminded of a quote from the book scrum mastery by Jeff Watts, good Scrum Masters hold their teams accountable. Great Scrum Masters teach their teams to hold themselves accountable. So if you're the scrum, Master James is might not be your job to monitor its progress, you might be better served coaching the team to figure out for themselves. Is this helping? Or is it not?

Lindsay Velecina: 27:19

Awesome. Thank you. All right, this next question comes from Marcus. So what amount of technical experience and knowledge is a must to be an effective scrum master? Second to that? Is it a red flag if there is a shift in expectations from the organization for a scrum master to have sufficient technical knowledge? Give this one to you, Jason.

Jason Malmstadt: 27:43

Yeah. Hey, Marcus. Marcus is a friend of mine, former colleague. Thanks for being here. Yeah, as Greg was saying, I'm sorry, as Rob was saying earlier, you know, it can help to empathize with the with the technical developers on your team, you know, if they're talking about a problem, and it's, you know, all Greek or all geek to you, you, you know, and you can't even relate to what they're talking about. I think that that can be a problem. I don't think you have to have deep technical knowledge. As I said before, I've been better served sometimes when I had high level understanding of the technical problems, but not at a detailed level, because then I wasn't tempted to get in there and start solving the developers problems for them. Is it? So I don't think you have to have deep technical knowledge. But understanding broad brushstrokes, I think is helpful. Is it a red flag, I think it could be. I've worked for a company that just simply made a decision, we're going to have our our Scrum Masters have technical backgrounds. It was kind of an accidental pattern for that company. And they thought it served them well. And so that was how they hired. In that case, the company understood what a scrum master was and what a scrum master wasn't. And didn't try to morph the the accountability or something. It's not meant to be, in your case, a company that could be a red flag that the company is kind of shifting what the scrum master is supposed to be. So I start digging and asking questions of management. Why why are we doing this change? What are the expectations for the accountability in the future is the expectation that SCRUM masters are somehow the final decision maker for all technical challenges on a team like that would be a huge red flag for me. But it could just be that they've noticed a pattern and they want to continue that pattern. And so I think more context is needed anything else from Robert Greg?

Robb Pieper: 29:32

Yeah, I have some thoughts on that. So if you have SCRUM masters that aren't actually demonstrating the value of what a master in scrum means to an organization. They're going to find ways for you to do other work, like go lift those boxes, make me coffee, go write some code, be our project manager. And I find that if you don't have enough experience with Scrum as a scrum master, you don't realize there's like a million really important jobs for you to be doing like causing the removal of impediments. And when you do Don't do those jobs, you're stuck just facilitating meetings. And frankly, nobody wants to pay you to facilitate meetings, unless you're really, really inexpensive. So they're trying to find other ways for you to add value in problems that they actually have. Sometimes, I don't know if it's your problem, but you know, if you're a former coder that's become a scrum master. It's a hard pill for people to swallow to have to pay you at a programmer salary to be a scrum master. And so hybridization of your roles starts to emerge. It doesn't mean you can't add value in other ways. As a matter of fact, it's like you can put your scrum master hat off to the side and do those other things that need to be done. You might be of extreme value to your organization. However, if you break the fundamental mechanics of how Scrum works, like violating self management principles, ignoring empiricism, not removing impediments, well, then you're not serving the scrum role. All that well, and I would focus more on that. So just making up context, assuming your question is somewhere in that category of common problems I've seen. So those are my thoughts.

Lindsay Velecina: 31:01

Great, thank you. Alright, so this next question here comes from Scott, as a coach, I had a recent question to talk about transitioning from scrum master the PEO. At the most basic level, I don't see many common characteristics or skills other than understanding the scrum framework. Any advice for somebody looking to make that move? I think many on a scrum team, see the PIO at the top in quotes, and see it as an actual career step. But I don't see it that way. Who will give that to you, Greg.

Greg Crown: 31:39

Then it transitioning from scrum master to PIO, that's um, these are two very different accountabilities, like, the idea of a transition, I don't even know is, is, is really the best word to use there. That's there just two different accountability straight up. Since a product owners primary responsibility is that of maximizing value with product management activities, if a scrum master who might be really good at interfacing with people, and empathy, and they are accountable for Team health, needs to shift their mindset over to maximizing value, and becoming a really, really good product manager. That's a huge step. Sometimes that could take months to learn, or years to learn how to become a really good product manager, and really a product owner. That's what they are as an agile product manager. So I'm shifting or just transitioning over to as if it's just kind of a Here, take this quick class, read this book, and you're good to go. It's not that that's going to be a pretty major shift for that individual. Now, if they've already got some product management experience in their back pocket, I'm missing that from the question. But it is not an easy, simple transition. And I will add to the point that the idea of a product owner being the top, it is a whole team, there isn't really a top role within the scrum team. Everybody has their accountability and the Scrum Masters accountability to make and help the product owner become really, really effective in combination with how the developers do their work and accomplish done increments every single sprint. They work holistically, you know, that'd be kind of like saying that your left tackle isn't that important. And a football team? When the quarterback would say, Oh, yes, they are. They helped make my job a lot easier. We got to have all these people working together. So hopefully, we've answered that question there at least maybe put some shed some light onto it. And curious if Jason have anything else to add

Robb Pieper: 33:53

different focuses, one is managing a product and making sure that it's the most valuable it can be and one is in effect, helping a team to self manage to be the most effective teammate can be. And there, there's very little overlap, aside from the fact that you're helping a team be effective in the context of developing a product. But your day to days will be different, your focus will be different, your backgrounds are likely going to be different. In one you want to be a master of the product that you're developing and make sure it's the best thing ever and you're constantly improving on that. And then the other year masters from what you're constantly trying to get better at understanding Scrum and teaching others how it works, mentoring, advising, things like that. So very different roles. And yeah, there's no top of the food chain on a scrum team.

Lindsay Velecina: 34:36

Okay, that is great. Thank you. All right, so this next question is humdinger. So this question from Andre. How do you convince people to change and as we all know, most people are resistant to change and it can be tough to push them towards something new, especially if they've been working or got used to process being in a certain way for many years, I'll give this one to you grab

Robb Pieper: 35:05

rates. Great. I'll take the hardest them all. But fortunately for us, I have an answer already in my back pocket. Can I put links in this tool?

Lindsay Velecina: 35:15

Absolutely. Just make sure you filter to everyone. So everybody gets them.

Robb Pieper: 35:19

I've gotten under hosts and panelists, is there an every one option? Yes, there is. I don't see it should be

Lindsay Velecina: 35:25

underneath. Okay, if you do not, you can send it to me. And I'll

Robb Pieper: 35:29

tell you what, like, just if you go to the pro site Institute, P R. O S ci.com, they have a framework called ADKAR ADK. AR. And if you just Google that, you're going to end up at the same place. It's a, it's an organizational change management framework that starts with basically the individual. And so I'll just kind of walk through what ADK AR means at a high level, and I do not have a certification of their stuff. So take this with a grain of salt, do your own digging. But ultimately, it's hard to get people to make a change if they're not a aware, aware of why this change is valuable to them. Like how is this going to affect me. If d you don't desire that change, even if you are aware of it, and you know, you're aware there are some benefits, maybe just don't care, then you won't make that change. If you are aware, and you do desire, but you don't have the knowledge and how to implement the change successfully. That's the case, you don't get very far and making it work. And then the next day on ADKAR is ability if you don't have the ability to use it at the right performance level, like, Hey, I love Scrum. I went to the scrum training class, I came back to work and my organization's like, No, we're not using that it's stupid. You kind of use it or lose it, you'll forget about how it works. After six months of not being able to apply it maybe a year, it's just out the door. And then the last one is reinforcement. So if you're not getting constant reinforcement and constant leveling up in constant polishing the stone and on your skills, it won't stick. And so that's, that is really where I would go to helping people make that change. Yeah, Lindsay sent out the link to everyone. I would start learning more about that. Because for me the 990 9% of the problems with getting scrum sticker people problems. And a big part of that is ineffective change management. People want to push scrum on people like you're upgrading a Windows computer. And it just people don't take a change like that.

Jason Malmstadt: 37:19

I'll adding just a couple of things. One that I had to learn experimentally or experientially that while the scrum guide says so that may motivate those of us that are really into Scrum. But for your average person, they don't care. Like, or at least it's not sufficient. Like that might be good to get them started or help them explain where you're coming from. But you have to help them see the why you have to help them see the benefit, like the scrum guide says we have to do retrospective is not going to convince someone who's resistant change. So help them help them connect, explain it if you can, or help them connect the event or the you know, the change that that you're trying to help them make to the Why leave them there and help them see the benefit. Treating things as experiments is another way like we're not saying we have to do this for all time, we're gonna experiment with this, like Greg was saying before, we're gonna experiment with this, and then we're gonna evaluate it. There's a lot within a scrum team that you can say, We're gonna keep this if it helps us, and we're gonna throw away. If we're not, not core pieces of the framework, we're not going to treat like the events that way. But specific tactics within the framework you can absolutely experiment with. And then finally, I just don't think you can convince someone to change, you can help them you can help coach them, but ultimately, they have to make the decision for themselves.

Greg Crown: 38:37

Yeah, that's the tough reality, though, isn't it, Jason, sometimes people don't want the change, there's no amount of convincing that can be done. You can't give them enough money to change, you can't do anything like that. And so I think knowing when that's going to be an uphill battle, you can't really push them into it if they're not willing. I think recognizing the empathy there for people, there's usually fear at the baseline of change. And so anybody who's in charge, and I love the Add car model, and being able to take that approach, but there has to be an empathy with the people that are part of that, to reduce the amount of fears that change doesn't feel so intimidating or risky. Most people don't want change, because they feel like they're going to lose something as a result. So putting those fears at ease can make a huge difference. Again, they may not want the change, but at least still be open to the conversation.

Lindsay Velecina: 39:31

This is all great advice. Thank you. All right. So the next question here from Alfred, how would you go about coaching a team to monitor their performance? Some lacking some context here, but maybe you can share some ideas? I'll give this one to Jason.

Jason Malmstadt: 39:50

Sure. Well, I'll reiterate what I said before that it really is for them to monitor. So if they're looking at you to say hey, you know, Scrum faster or you know, product owner, what's our performance, you want to remove yourself from the bottle being the bottleneck or the center of that and help them monitor their own performance. When in doubt, I go to transparency. So what is important to make transparent so that you can be very quickly ascertained, right? If I have to, if I have to take 10, to 15 to 20 minutes to start digging through a tool to try to figure out what's important, it's not going to happen. You want it you want something that's at a glance, if you have to build a dashboard, or if you have to figure out one metric that matters. That's something that we've talked about internally, like, what one number are we focusing on right now. You can't monitor progress, simultaneously, and focus on 50 different metrics. And by definition, you can't focus on 50 different things. So maybe you have to pick just a couple of key metrics right now. And make them blindingly obvious, like you can't walk anywhere, or have a meeting without running into it. And then I would also just make sure you're measuring what matters that that we're not picking a vanity metric that we're not picking, you know, sometimes I'll tell technical developers, would you like it if I, you know, paid you on lines of code written? Probably, because you can take twice as long or 100 times as long to write everything and write yourself a new car. But that wouldn't be a very meaningful metric. So make sure that we're not just measuring something that's easy to measure. But something that's actually meaningful. What would you guys add to that?

Robb Pieper: 41:27

Anything? You get me thinking about a copy, paste, copy, paste, when you crank out a lot of code, just to my right.

Greg Crown: 41:36

I think the word performance, we need to be careful of this. So and here's here's what I'm thinking. We could have an in using other sports analogy here. If if performance is being measured by say, like the number of yards for one person on a football team running, and they say, I've ran so many hours, it's like, right, but did your team win? Did you get? Did you accomplish the goal together? To Jason's point, these vanity metrics that sometimes can be the trigger for people saying, I'm so distracted with trying to hit our mark for performance? They absolutely forget why they're even playing the game. And that's, that's an unfortunate reality. So rather than monitoring their performance, I would love to see a team be aware of why they're playing the game, and get them into a consistent state. So are they consistently getting their goal achieved every single sprint? And if they aren't, that's enough monitoring to know there's something wrong. But let's so let's start getting under the hood and find out what's distracting us from our goal. Maybe we bit off more than we can chew, which is probably the number one thing that most teams do they have this misconception that your sprint backlog is this giant bucket that we must fill up to the very top to feel like we have absolutely maximize the capacity for our team. So we're the highest performance possible. And then we don't get our goals accomplished, which basically is like having nothing at the end of the sprint. And so what if you filled that bucket half full with one goal, and you got that done every single sprint, and then you're able to tackle some of the other odds and ends? I'm cautious of the word performance, because that oftentimes will distract from the point which is value, consistent quality value. Instead of how much how many widgets? Are we pumping out a million widgets that nobody wants? I don't want that. But you could say that's extremely performant. So I'd be be cautious of that. And maybe point the direction towards what we should be measuring.

Jason Malmstadt: 43:42

Here. If your cookies tastes like garbage, I don't care how fast you bake them, as well.

Lindsay Velecina: 43:51

That's great. Thank you. All right. So this next question here, any advice for software teams that are working in an operations environment other than to block out certain percentage of your time to handle emergent operation issues? Emergency merge emergent,

Robb Pieper: 44:10

emergent, yeah, either emergent operational issues.

Jason Malmstadt: 44:15

Oh, can we do shameless self promotion here? So I wrote a I wrote a blog post and shared a tool on our website not that long ago called the five W's for unplanned work. This is something I developed empirically with, with a client of mine, who was constantly getting hit by the kind of emergency issues that you were talking about. You know, this team was even doing one week sprints, which I commonly called Scrum on hardmode because it's really hard to break your work down and get something meaningful, accomplished in a week. And even with the one week sprints, they would, you know, their plan their sprint on a Monday and by midday Tuesday, they'd have so many emergencies in air quotes, that their their sprint plan would be just sunk. And so we just help them think through What these emergencies were from five different dimensions. So the first one was why why is this an emergency? What happens if we don't do it? How many people are being affected by this thing? The next one was, is there a workaround? Like often these are, you know, these emergencies are fixing something that's broken. And instead of, you know, sidetracking, our whole sprint, could we just do a temporary workaround to limp along until we can really get to this in a in a more planned fashion? What happens if we just wait? If we just say, No, we're not doing this right now we have a sprint in in progress, and we'll get to it in a future sprint? What's the impact of that? Maybe it's not catastrophic? Where does this fall in relationship to other things on our backlog? Like if we add it to this sprint? Now, some other things aren't going to get done? Do we really think this is more important than the other those things? And then finally, if the answer is yes, and it truly is an emergency, we've had a security breach or or the, you know, the, you know, our our whole websites down or something like that. Okay, what aren't we going to get to? And are we okay with that? Is that are we making a positive value trade off here? And of course, you know, keeping our sprint goal, sacrosanct would be the North Star for that. So that's just one way, it's just a way that really helps that particular team go from something like 80%, unplanned work down to like 20% unplanned work. But just really thinking through a lot of things are called emergencies when they really don't have to be.

Robb Pieper: 46:25

I dropped a link to that blog and the everyone chat.

Lindsay Velecina: 46:31

Okay, great. Thanks. All right. This question is interesting. So our sprints are two weeks. And this is nowhere near enough time to get development testing approvals for deployment and actual deployment completed. This often takes three Sprint's any advice, I'll give this one to you, Rob.

Robb Pieper: 46:55

Yes, I was open for this one. All right, well, here's my first thought on that. Scrum doesn't require deployment within a sprint, just that you're deployable, meaning I can release this, if I so choose, it's now a business decision. And we're decoupling do I release from mi releasable? So that's one thing, you can just like push off to the side. Some of the other things, if you look at them carefully, you might realize like, you've got some impediments. Maybe you're testing processes could be faster, like more automation, or maybe, if you're testing people are on a different team, maybe get them on your team. But you know, if you start taking taking note of every single thing that's slowing you down, and preventing you from releasing something of value in two weeks, and then start going after fixing those things, that's basically the spirit of impediment removal, coming up with something valuable, and under two weeks, think of that as a design constraint. So you can't build the Eiffel Tower in two weeks. But maybe you can build a supporting structure in that amount of time, a valuable piece of supporting structure that can be built on. We're not gonna talk about mechanicals sort of applications of Scrum. But if you're in a software space, it's typically very possible to get something done in two weeks, even if you're a one person team. And the way you would do that is by looking for little tiny bits of value in your solution. And just working on that and getting it done. And then working on the next piece, and then getting that done and see how it interplays with the one you just made. And it just in tiny, tiny, tiny batches, making solutions that solve problems. When you've got a big, big, big problem. It's usually a combination of 1000 Micro problems, and you got to find those micro problems. So you can start focusing on getting something useful done in a short timeframe. So if what you're doing is not risky work, sure, make it easy on yourself and go to three weeks. However, if what you're doing is risky, meaning my whole team worked on something for two weeks and just wasted $50,000 of the company's money because we were on the wrong track. I wouldn't keep doing that over and over, maybe make your Sprint's even shorter. So sprint length isn't about how hard your work is. It's more about how much risk are you willing to take on doing the wrong thing. So I'd set a lot of words, but those somewhere in there's my collection of my thoughts on that subject.

Lindsay Velecina: 49:12

Great, thank you. All right. So we have time for maybe one or two more here. This question here from Tom. This question here from Tom. I started using Scrum in 2004 and introduced it into a fortune 50 company guided by Ken I had no development background, but learn to code after I started using Scrum. I feel like Scrum Masters should also develop and I did that for nearly 10 years. What are your thoughts? So we kind of talked about this already? That the Scrum Master does not necessarily have to have the technical skills but wonder what your thoughts on Scrum Masters learning to develop?

Greg Crown: 50:00

Can I take this one? Sure, that'd be really brief. So I think it can be a huge advantage in small teams, small company environments, I know you're talking to Fortune 50 companies. So that's a whole different deal. But when you have a culture and ecosystem in which self management is just pretty much at the core, I think that a scrum master who knows how to code or knows how to develop, produce or help produce be part of the product process can be a huge advantage. However, here's the giant red flag caution. I'm gonna throw flags a little bit the statement I just said, You got to pick who you are, sometimes. Are you developing today? Are you going to be the scrum master today? Because there's gonna be a direct conflict with your accountabilities. So I have seen it work amazingly well. And I've actually seen it be an absolute train wreck for a team and product development. So it's a split opinion, because it does depend upon the context, it depends on how mature your teams are. And I don't mean age. I mean, how well are they able to self manage and self correct and self improve? What's the culture like, because given the wrong culture, that can be a train wreck?

Lindsay Velecina: 51:07

That's great. Thank you. Right. So I think we have time for one more question. So friends, is there anything in here that you are just burning to answer in this list that we have not gotten to? We'll give you all a moment to pick one that you think you all could collaborate on here. And for those of you who have answered questions, we have not gotten to your questions. We will be sharing the list with the PST is here for

Robb Pieper: 51:42

to answer offline. Guys. Alfred's question is interesting, which scrum event would you eliminate? If asked in an interview?

Jason Malmstadt: 51:48

I was looking at that one too, so let's do it. I wouldn't. And I just like, like asking which of these four table legs would you eliminate like it, the table is not going to work anymore. They all serve a critical function. And I'm not just saying that because I'm a PST and I have to like, that's not they all serve a critical function, you eliminate sprint planning. What's your goal for the sprint eliminate sprint review? How are you going to get feedback on what you actually produced and inspect that eliminate the retrospective, you're not going to improve? Eliminate the daily scrum, you're going to carry impediments longer than you need to, and you're going to be much less nimble. Like none of them are optional. They call it a function.

Robb Pieper: 52:31

Yeah, what most people like to eliminate they don't even realize they're doing it is the concept of a sprint, a time box period of time in which you produce an incrementing accomplish a goal. And so if you go infinity amount of time just working, working, working, no one gets any value. You don't get any feedback, you don't have any pivot points. And that remember, it reminds me a lot of waterfall two years before you have anything useful done. How about this, we all go to getting our paychecks every two years. I don't think anybody wants to do that. But anyway, I diverge. Yeah, I all of the all of the events serve a critical function in scrum in order to make the framework operate. And if you start removing pieces, it's like removing legs off a table. Eventually, it doesn't function as a table

Jason Malmstadt: 53:14

anymore. Or load bearing walls of a house, you have a lot of freedom within the house, how you can arrange and build within your house, you have a ton of freedom in the scrum framework. You just can't take a sledgehammer to a load bearing wall and expect the house to stay standing.

Lindsay Velecina: 53:30

Right. Thank you. Right. So we are almost at our time. I think we do have time for one more.

Jason Malmstadt: 53:43

That was a pretty good. Let's do it.

Lindsay Velecina: 53:45

So we'll take this question here. What metrics or KPIs Do you track to show your being effective as a scrum master?

Robb Pieper: 53:55

I just saw that one. I was excited to get involved in that one.

Lindsay Velecina: 53:58

Well, get involved.

Robb Pieper: 54:02

It kind of piles on the last answer, we just said yes. Here's the one thing you need to be doing. It's producing a solution to a problem a some sort of accomplishment of a goal. Every sprint if you can't do that one thing I honestly don't care what other KPIs you're tracking, because they might be misleading you like lines of code, written bugs fix, you know what what's better than fixing bugs does not creating them in the first place, or not having to maintain code no one uses. So without focusing on increments and really, really, really focusing on who that customer is and delivering something useful every single sprint and learning from it. Nothing else matters. And then beyond that, what else is useful things that help make you more predictable in terms of of your ability to deliver. So if I can predictably and reliably produce increments every sprint, what's even better than that? increments that I can get out the door faster. So your release frequency might be more interesting number of happy customers that are coming in now. for active users, if you're building a website, net promoter score, and then we can get into whole collection of like EBM kind of things like Greg would be a lot more qualified to talk about that myself. But

Jason Malmstadt: 55:14

the question behind this question, which I think might be happening, I had a client asked me like, I think we should measure carryover. What do you think? And instead of answering the question, I threw it back to her, and I said, What do you think I'm going to say about this? She's like, I think you're going to say that if we measure carryover, people are just going to artificially game that metric and break their work down smaller and not pull as much into sprint planning that they're going to just adjust to what they're measured on. Like, yep, bingo. Like if you're getting pressured to do a certain KPI and you don't think it's valuable, engage in a conversation. And maybe don't just give your opinion, but help them get to what could go wrong with focusing on this KPI. I've seen that quite a bit.

Lindsay Velecina: 55:55

That's great. Thank you. All right. So with that. Let's wrap up here. And as I mentioned, we will be sharing the open questions, we do have quite a few, we tried to get to as many as possible. And, yeah, we did our best here. So just want to share some quick resources here. So please check out the learning paths and scrum.org website and a great way to continue your learning. There's lots of different resources in there, like white papers, case studies, webinars like this one. So please feel free to check that out. And with that, please stay connected with the scrum.org community through our social media channels, and our blog and our webcasts that we run a couple times a month here. And I would like for Jason, Greg, and Rob to share the best ways that you can be connected, I see that Greg dropped in his LinkedIn. So how to best connect with you all. Besides Greg, we know that Greg is on LinkedIn.

Jason Malmstadt: 56:57

I'm gonna drop in my LinkedIn as well.

Robb Pieper: 57:00

I gotta go find my LinkedIn. I'm sure it's in here somewhere. Oh, here we go. I think this is me. This is me.

Lindsay Velecina: 57:07

There we go. Right. That's great. All right. So thank you, everybody, for attending today. And thank you so much to Jason, Greg and Rob. This has been a lot of fun. And I hope the audience got some great things out of it. So thank you all and Scrum on