Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask professional scrum trainer series, where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Good morning. Good afternoon. Good evening, wherever you're located today. Welcome to Ask professional scrum trainer. I'm Lindsey Bell Sina. I will be your moderator today. And we are super lucky today to have two PSPs. With us to answer your scrum questions. We have Andreanna Marshall and we have Scott Adams. So welcome, everybody. And thank you, Andriana and Scott for taking the time today. And very quickly about scrum.org. We are the home of Scrum we were founded by Ken swaybar. Back in 2009. Our mission is to help people and teams solve complex problems. And we do so through our professional scrum training, professional scrum certification, and our ongoing learning opportunities. So there are a lot of free opportunities on the scrum.org website, and some great content there learning paths, learning series, things of that nature. So please be sure to check out these free resources to help you continue your learning. That's super important, the learning does not stop at the classroom. So please take advantage of that. And you're obviously taking advantage of some of it because you're here today. So with that, I will hand it over to Andriana and Scott to introduce themselves.

Scott Adams: 1:52

Hi, I'm Andrea in the martial. I've been in tech and Scrum master or a senior technical program manager for over 10 years now. I'm the founder of Project Academy which focuses on professional scrum training because I'm obviously professional scrum trainer, you know, enabling agility, even some PMP as I do have that program management background, and as well as some technical background. So AWS cloud training coming soon. And really also the business is focused on coaching and helping people land jobs. And both Scott and I actually, anytime you take a class with us, you do get a free one on one. So we do coach and help people implement what they learn or, you know, get a job, as I mentioned. And Scott and I are also we both co hosts that not scripted podcast where I think we add both education and fun together. So there's a education and a lot of last and hopefully we get to have fun answering your questions today. All right, Scott. Greetings, everyone. It's pleasure to be here. Lindsay, thank you so much for hosting this. Thank you spot.org for this amazing platform. A little bit about me. I've been in Scrum and Agile space for about over 10 years now, I started out in project management. And that just wasn't the right tool for some of the complex things that we was trying to solve. So being a scrum practitioner for quite some time and PST since 2019. The summer that was my Christmas Present back in 2019. Yay. Do contract scrum master for Fortune 100. Companies at this particular point did full time work for a while but I liked the flexibility of contract work. I am the founder of Scrum Academy. Offer, you know, scrum.org Amazing classes, and also a co host of nuts going up dumpster. So we're excited to be here for you looking forward to answering your questions. Lindsay Awesome.

Lindsay Velecina: 3:46

All right. Thank you, everybody. So I'm going to stop sharing. And it's time for questions. So very quickly, question about you both. Um, what do you cover in the not scrum done podcast?

Scott Adams: 4:06

I guess I'll get started. We cover a little bit. I mean, obviously Scrum. So we cover that we cover a range from landing a job to giving some practical skills giving some one we did recently was how do you actually teach scrum in your organization, we actually use one of the templates that scrum.org created. And then even recently, we talked about AWS. So Amazon Web Services, the cloud platform, so we're also introducing a little bit of other things to kind of help people gain additional skills and see if certain things are the right fit for them. So we've been doing this for a little over a year. So we're experimenting with some new things. So we're always open to new things. But Scott, did I miss anything? No, you covered it very well. It's just you We offer practical tips. And there's some different ideas. We talk about things as a scrum master, you may feel impostor syndrome and things like that just normal stuff that we all go through. And, you know, our own experiences, even though we professional scrum trainers, we feel some of the same feelings and go through the same stuff as YouTube. We're not immune to it. But yeah. Well, relaxing we do we do take on questions. So people do submit questions, whether that's via LinkedIn, or in our comment section, and then we turn those into videos as well. So that's, that's, that's another thing that we do to help generate content to make sure that we're giving our audience what they're looking for.

Lindsay Velecina: 5:39

Awesome, thank you. Yeah, I just wanted to give you an opportunity to plug your own podcast there. Before we get started, perhaps some people already listened to it and drove them to come to this session or listening to this session. So cool stuff there. So here's a question. So what is the scrum guidance around scrum master support of career development for individual scrum team members? Or your own guidance? You want to take this one. Okay.

Scott Adams: 6:15

Yes, I start off with that one. What is the guidance around scrum master supportive career development for individual scrum team members? The scrum guide is not prescriptive. But you know, we are you know, in an environment where we want to inspect and adapt, we have empiricism to fall back on empiricism you can make decisions based upon was known. So as we don't I'm thinking about as we do in the retrospective where we see something that's not working, whether it's a team framework, your question is around individual. If we see that your team is lacking in some skill set, whatever you environment may be, how about we you know, hey, how about we incorporate some type of learning in the sprint could be a retrospective continuous improvement item. Just take it to the team and let the team decide will be my two cents on that on John. Anything? Yeah, one of the things that I'll add is I look at when I was a scrum master. And I think helping individuals like you do have to coach them one on one to get better, and that does ultimately help your team get better. I worked on a team where there were two people that both wanted to be leads on the same team. And they bicker and argue about everything, things that weren't even worth arguing about, they will argue about. And so through like one on one coaching, having these discussions with them understanding what their motives are, one of the things I told each of them is no one's gonna make you a lead if you can't get one with people, you know, like you have to be able to work with different personalities and find a middle ground and negotiate with them. And that seemed to help because then they understood like Leadership isn't that simple. Like it's not just as if I can't just lead when I like that person. So that's another thing I know you specifically said career development, but that both of them did end up as our company grew becoming leads. So coaching them one on one, helping them get individually better will ultimately help their career and understanding what those gaps are. Hopefully that helps.

Lindsay Velecina: 8:18

Great advice. Thank you both. So here's an interesting question. So what tips do you have for showing value within your company, or showing value when applying for a role to play question there? Want to take this one on Juliana's?

Scott Adams: 8:36

Yeah, I think the initial thing that comes to mind when I think about a showing value, when it comes to applying for a role is I completely changed my resume from saying what I do to actually what I've achieved. And as a Scrum Master, what you work with the team on is also your achievement as well. So we worked on X program, or x, you know, cost saving initiative and save $230,000 per year. So I that's how I would show the value. And I think when you're at your company on the individual level, when you are, I think you have to document everything as they as it happens. Because sometimes those one on one coaching, they cannot be seen and working with your manager on a weekly or bi weekly basis where you're like, here's the things that we've accomplished this week, or here's where I put in some input and documenting those things and sharing that with your manager. So it doesn't go on no this. Those are things that I would recommend off top based based on that question, but Scott, do you have anything to add to this? Yeah, I will tap on the second talk with the second part of that or show value when applying for a role. Thank you for the question. James. X had an interview this morning before this call. And as andriani identified, I kind of make sure I change my resume. Not only to highlight two certifications that I've done to places I've worked for, but also to really just quantify that, okay, tell me something. Okay. What did you do while you was with that company? And in your specific question is show value when applying for a role. So I got things on my resume now, that my last team of work back in December, we was able to achieve 100% predictability, that was a KPI metric that they was looking for. So what is predictability? Predictability is okay, we had sprint planning, we decided, let's say we're going to take 10 product backlog items. Okay, let's fast forward. Now we're working on those 10 product backlog items. Now, by the time we get to the sprint review, the goal is was to hopefully complete all of those things, right? Absolutely. So when we get to the sprint review, we look at it, we completed all 10 items, or we achieved sprint goal don't have to be the bulk. So we make we achieve what we try to cheat, we accomplished a goal, we delivered some value for the customer. Great. Now we completed our 10 product of 10 product backlog items. That's fantastic as well. So we committed to doing 10 product backlog items and sprint planning. By the time we get to the sprint review, we completed 10 product backlog items, our predictability score is 100%. So now put that on my resume. So hey, you know help the team to achieve 100% predictability, which means Hey, you could you could count on us to deliver something most Sprint's no scrum team deliver each and every sprint and a lot of things happen that we cannot control. But that was that was a metric that they use in that particular company. Hope that helps.

Lindsay Velecina: 11:47

That's awesome. Sorry, I just muted for a moment. Bad meeting. So PA. But thank you both so much. I think there's some really good insight there. From both of us. Thank you. So this next question here. So for a small team less than five members with the maturity of 36 brants. Should we retrospect every two weeks, or is once a month? Okay? Two?

Scott Adams: 12:14

I think for this one, it depends on what your sprint length is. Right? So if your sprint length is two weeks in every two weeks, if it's one month, it's every month. Now, I'll extend a little bit. If you're thinking about how long should my sprint be? Ask yourself a few of these questions, how quickly does the business need to change direction? You know, what's our investment, you know, toward risk tolerance? Basically, how long can we go without getting feedback? How often do we need to get feedback from our stakeholders or our business? And how much time does it take us to actually produce a usable increment? Those are some of the things that come top of mind that you should ask yourself in determining how long your sprint length should be. But if your sprint is is two weeks, then you should do it every two weeks, you should be doing all of the events accordingly. If it's one month, and yes, one month, it shouldn't be any more than one month. But based on that question, that's what I that's my response. Awesome. Thank you totally agree. Just Just to add to that, I mean, yeah, totally. Yeah. Take it to the team that then decide to have your sprint cadence in place. Again, if you're doing two week sprints, then yes. Just make sure you scrum requires us to do all of the events within a one month time box. So just make sure we adherence to the scrum guide in terms of that what it calls up for Nice.

Lindsay Velecina: 13:43

Awesome, thank you. Here's a question. So how would you gain some experience after receiving your certification? Got Do you want to take this one?

Scott Adams: 13:56

Absolutely gained some experience after certification. I remember when I was making the transition from project management to get into Scrum and Agile. I went online and first of all, I downloaded JIRA platform. Why? Because I knew that that was the number one tool that most companies use je R A. So now that I got my certification, I need to try to get some practice. So I use JIRA. And I play you know, I bring you know, I played games with my family, you know, actually doing Scrum with my family really just getting practice. I use Scrum at my church, I went to my pastor say, hey, let's try to use Scrum here at church, see if we can do it do something that we can, you know, just finding different ways I even went to my non for profit organization, the YMCA, I go there to work out. And they was looking for a scrum master but didn't have any money to pay, pay a scrum master. So I volunteered hey, I need some experience. I'll be doing it I would love to do that. So they you know they didn't fire me because I was volunteering. I just wanted to practice and that you know, I use eight would you be willing to give me a reference to you know, when I get a job because this is what I'm trying to do full time. Oh yeah, absolutely. So I was able to use that and put on my resume. And that was part of helping me to get a job and a job as a scrum master. couple items there.

Lindsay Velecina: 15:09

That's a great story. Thank you, Andrew, Jana, anything to add?

Scott Adams: 15:18

No, I think that was great. Another thing is actually I do have something that one thing that I think is look at your company and see what ways you can implement there, if you're already in a working environment, I've talked to people that look at how you can implement empiricism at the least right? So transparency, inspection, adaptation, maybe you can't implement Scrum. But maybe you can start with at least adding that, like inspection points, adapting working with your team members, on a specific cadence to actually inspect and adapt that start somewhere. Don't just wait till you find like a perfect outside opportunity, see what you can do within your company. That's going to be the easiest way.

Lindsay Velecina: 16:06

Awesome, thank you. Great tips there. So hope that was helpful. Here is a metrics focused question. We're gonna switch gears a little bit. So other than burndown charts, how can we analyze project progress metrics wise? And you're gonna want to take this one?

Scott Adams: 16:31

You Yeah. So when I think of, I'll just start when I think of burndown chart, I think of just the developers using a burndown chart within their within themselves to track their progress toward the sprint goal. When I think of a project, and I'm thinking something that may spend several months, I'm thinking of actually using our sprint and the increment to help us understand where our progress is toward that project. So if we're delivering a done increment, at the end of every sprint, that's going to be progress right there. So we get to see or we have, let's say, we're creating five new screens, we have one screen done this sprint, we're actually seeing progress toward that. So you do have your product backlog that should have everything you need in there to plan forecast and understand your progress toward that project. And or its in some cases, it might even be the product goal instead of what your project is. So that's what initially comes to my mind when I think of tracking progress is actually using our sprint or increment to track our progress. Scott, do you have anything else? Absolutely, I would take a step back and go back on the video we just did. We did a product mindset versus a product mindset. So there will be two different approaches that we have there. So overall, yet it is a project but our if we have a project mindset, the project is not over until all the tasks are done. If we have a product mindset that the project is over when we achieve the thing, whatever the thing is, so first of all, let's take a step and say okay, which which, which approach are we looking at, then I will also throw in velocity in there, I like velocity from the standpoint of velocity means that it's an indicator of what the team can do. Going back to my example earlier, that if we had sprint planning, excuse me, if we had sprint planning, if the if the scrum team takes in 10 product backlog items, and they are able to complete those product backlog items by the end of the sprint. Now let's say in the overall product backlog, we have 100 product backlog items left. So we can use velocity what the team is completing on an average sprint by sprint basis. And we can use that to forecast how long would it potentially take for this project to get done. So we started out with 100 product backlog items, we completed 10 We got 90 product backlog items left. So that may take us approximately nine Sprint's whatever the sprint may be in your environment one week, two weeks, three weeks or one month. So you can use that to forecast. So that's one way I like to use velocity from that particular standpoint. Hope that helps.

Lindsay Velecina: 19:21

That's great. Thank you. All right, though this question here. So what philosophies or frameworks have you found helpful to encourage collective ownership and loving support within a scrum team? Like that loving support? We all need a little love sometimes. Got to take this one.

Scott Adams: 19:44

Absolutely. What philosophies or frameworks have you found helpful to encourage collective ownership? Oh, I gotta go with the Agile Manifesto. From a philosophy standpoint. I'm talking about the Agile Manifesto. You know You know, the four values and 12 principles. So I really embody that to me. The manifesto is the philosophy in terms of to me Scrum is, how are we going to do the work? And the Agile Manifesto is okay, what are we thinking about as we do the work with thinking about people have across the seas, you get the idea. And my favorite principle in the manifesto is number 12. Principle number 12. At regular intervals, we're going to take a look at our behavior and adapt accordingly. Andriana anything that? I think that's a that's a great answer, I think not necessarily philosophy but restrained from solving the problem for them every single time. So I think error or doing it yourself, I think sometimes even that's really challenging for me, because I'm like, Will I just rather get it done? Or get it out of the way? So I think that's that's another that's another one to add to that. I have one more to give on frameworks. I can I give one more missile engine?

Lindsay Velecina: 21:07

Yes, give one more my own

Scott Adams: 21:09

frameworks that I have used Kanban to force the team to work together. They didn't know it was I ran a little trick a retrospective I saw that. Hey, you know, ideally, when I'm with my team, I want I'm looking at the team after sprint planning to see what did they do after sprint planning, visualize with face to face, this is easy to see if we face to face. So we've dealt with planning what happens after sprint planning? Does everybody come together swarm on a problem? Or does everybody go their own separate wait? So I observed everybody was going their separate ways. The way I talked to the product owner said, Hey, product owner, I want to use Kanban for the next sprint. Would you be open to that? He said, Yeah, I don't really know what it is. But yeah, so I explained it at the Sprint Retrospective. And the team decided, Hey, okay, well use Kanban. So we get to sprint planning. I say, hey, we created a sprint goal. They selected one product backlog item. Let's hit stop. Let me start. Work on that to get it done. Take it all the way and give it to the customer. Then what then when you don't go back to the product backlog, get another item. We'll work on it. With Scott on front end development. This is a this is a back end ticket. What can I do? I don't know. Go talk to the front end person. See how you can support see how bringing them together to collaborate with each other? Well, Scott, I'm a tester What should I do? Well, I don't know. Well, what if I can write the test first, before they write the code? Ah, TT itself. Test Driven Development. Beautiful. Oh, love it. Go talk to me see if you can help y'all see it. So I like combine to use it from the standpoint of, of really to celebrate a team to work together and collaborate. And once we did that, we back to full grown. It's kinda like Canva. You don't need it. I just use the forced out to work together.

Lindsay Velecina: 22:50

That's great. Yeah. I mean, it really doesn't have to be one or the other. You can incorporate different elements of Scrum and Kanban. Together, it. It's whatever works well for your team. So that's, that's great. So this question from James here, just it made me laugh. So I'm going to read it. So what are some of your tips for a great stand up? Number one, we call it a daily scrum not a stand up. But my goal is to get them to a place where they are running their own stand up, so I could sit back with my feet up. And Triana want to start with this one.

Scott Adams: 23:31

The funny thing is, Scott is much nicer in that regard than me because after a certain point, I'm just like, and you're on your own. So I get like, like, direct like, Okay, I'm gonna do it for this time period, especially if it's a brand new team. I'm like, Alright, so we'll try a few we'll discuss a few different things especially in like a retrospective, like, you know, what way do you guys want to run this? Instead of me just coming in and saying, let's do this I tried to start with even if it's a brand new team, how do you guys want to run this? Do you want to do Round Robin, do you I mean, we have to have the sprint goal up and visible and be discussing, you know, our progress toward the sprint goal. But ultimately, that's kind of where I I, I've been that person James, where I've had I've been like a year running the daily scrum I will sit stand up, but I miss that person. So it totally like I'm like, every new team I start with, I'm like, Alright, let's discuss how you want to run this. And I will be exiting in a month. And this is for you. I started by teaching them the daily scrum, it's for you. It's for the developers, it's by the developers. The goal is to inspect your progress towards your toward your sprint goal. You don't need me here. Try this. It's not a problem solving meeting. We're trying to understand what are the issues and we can discuss some of those after if you have impediments. We can discuss that you can't remove yourself we can discuss after but I usually start with that. And I'm very, like, put my foot down, this is the way it's gonna be. So then I can put my feet up. But that's, I'm more direct, again, because I had to do this for so long. But Scott, I think you're a little bit nicer than me. I'm a different approach. That would be I love that. I love that. One of the things you highlighted, I do start out with the scrum guide, making sure they understand, first of all, what is the purpose of this event? You know, and now Johnny did identify that, you know, we need to figure out are we on track of meeting our sprint goal? And if not, we're thinking about Pearson. We're going to adapt, we're going to look at what we did yesterday. Okay, how did that go? It didn't go very well. Okay. I'm not building the thing. So you developers, the people who are building it, need to be having a conversation, I'm, I'm over in the corner. I have nothing to do with what you're trying to do. So once we get that, okay, we talked about what we did yesterday and how that went. Then the next question becomes, okay, what do we need to do now? And what work? Are we going to select the most important work, keeping in mind our sprint goal, okay, what's the next best step that we can take, that's going to get us a step closer to our ultimate goal, which is the sprint goal. So they have in that conversation, and we have 15 minutes to have that conversation. So what we do when a Scrum Masters, okay, hey, you know, Elmo, you can use something like Elmo enough, let's move on, we're gonna make sure the conversation is about what we're trying to accomplish. And so we can get past that move on. Hope that helps.

Lindsay Velecina: 26:34

Awesome. Thank you. That was great. And thank you so much for that question, James. That was, that was a really good one. So this question here from Sasha. So which first small changes towards Agile and Scrum? Can I suggest in a company with a high resistance to? Now I'm trying to understand this question, high resistance to improvements, that and lack of communication, maybe due to 100% remote work? So what are some small steps you can take with a resistant company? And feel free to clarify your question Sasha in the chat, and I can relay that back to Scott and Adriana. Adriana do want to start here.

Scott Adams: 27:24

Yeah, my, my immediate thought is to do something like a retrospective and start with, and you can call it whatever you want at this, you know, because you're not technically doing Scrum, you're just looking for the small steps. I think that is, in some ways, what a lot of people start with, because it's really helpful to think of like how, let's get together, let's talk about what are some things that are in our control that we can change, and we can actively take, we can take action items, and we can actively work on throughout and try to have a next checkpoint. So it's not just this looming thing that goes over. So I work with, I do this with some of the leaders that I work with, we meet and try to get rid of some of the organizational impediments that teams have, or some of the organizational things that are slowing us down. And I will say some people are they like going to the retrospective and voicing their opinion, but they don't necessarily like to do the work to improve, which has been really challenging. I felt like, you know, like, just pinging them all the time, right, I felt like just repeating myself trying to push for change. I think one of the things that kind of resignated is, again, doing that, that coaching with leaders in your organization is you can't expect your team members to change if you're not willing to change as a leader. And that really resonated with a lot of people and having that conversation, to where now they're taking a lot of ownership in their part and making it better. When you make it better at the organizational level. You're making it better for the team. So that's the initial thing that comes to mind. Scott, do you have anything else to add? And a lot of us we work remote. So a lot of people, we have people in Argentina, we have people in India, we have people in Brazil, where people in Spain and we have people in the US so we have a team all over the place even though some people are in an office but not working with their team. So we have that exact same problem with remote or dispersed work. That's very good point and Sasha. First of all changes toward Agile and Scrum and a company that is resistant to improvement. I'm gonna roll with typer scrum master. So I'm gonna go and do my own thing. I'm gonna tell our teams like okay, we're gonna do this, we're gonna deliver. And I have found that when I deliver that seems to take away a awful lot of problems. So I deliver first and then I make my ask. So I that's my first focus when I want to smoke to help them to deliver. Now in the meantime, some of the things I'm doing it In a retrospective is I like liberating structures. We all have been to meetings, whereas kind of like this whenever you come in to today, whereas the content is actually creating content, so access will be a good case. liberating structures is the is the tool that I use for retrospectives. And a lot of collaboration. Never heard of it. liberating structures, just like it sounds. They have. Oh, beautiful, beautiful. Thank you, James. I use that. And it's like Baskin Robbins ice cream. You got 33 flavors. Yeah, yeah, yeah. Now, what are the tools in there? It's called 15% solutions. We all have teams, Sasha and everybody else that, you know, even my great teams, they think they so great, but that's still something to improve upon. So I like to use 15. Well, you know, we didn't get done this time, because the QA didn't get does not, oh, we had a dependency on another team, or another department, whatever it may be, there's always something. So 15% solution is about, okay. Take away all those blockers and things that you complain about and ask the question to our team and to ourselves. What can we do about this problem? The organization is over there. But we here at the local on the battlefield, what can we do as a team to get the done to solve this problem to whatever that issue may be Sasha. And I love that liberating structures, to put a team to come up some different ideas in terms of how we're going to improve and make things better around here. Hope that helps.

Lindsay Velecina: 31:28

15 Great, thank you. And I'll drop into the chat in a second, we actually have a learning theory on the scrum.org website for facilitation techniques for scrum events, I'm going to drop that into the chat for you all to use as a resource as well. Another one that a bunch of professional scrum trainers contribute to it's tasty cupcakes that org, you can check that out to get some great ideas there also, um, so lots of lots of great resources out there to help with these things. So this next question here is kind of fun. So, Scott, what are the practical anti patterns in the life of a scrum master?

Scott Adams: 32:14

Ah, what are the practical?

Lindsay Velecina: 32:17

What are some, so we can kind of rephrase that a little bit, maybe some common anti patterns that SCRUM masters can fall into? Okay.

Scott Adams: 32:28

First of all, let me start off by identifying what is an anti pattern for those of you who may not know, an anti pattern is something done with good intention. What has a bad outcome? Now, my favorite have not to do this. At some point in time, you're going to have your scrum team coming to you, specifically, developers come to you and say, Hey, Scott, we got sprint review later on today. The development is done. But testing is not done. Scott, can we write another ticket and put the testing in a product backlog and put, you know, and say the development work has done? Absolutely. No, we cannot. Because it's not done? No. So that would be an anti pattern. And I see that in some environments where the scrum master allowed the teams to split that. Now you remember, kins Faber said something about this here in an article. Once upon a time, we want the scrum team when they don't get the done. We want that to pain them. We want that to hurt almost like you play in sports. And when you lose it, you should be happy about losing it's either win or lose either got to done or you didn't. So you know, it's not like in elementary school when they go give you a trophy for participating. No, that's not what we know. Yeah, don't don't allow your team to do that. Set the standard have the courage to say no, I don't think that's a good idea because you are the scrum master representative growl Andriana. Yeah, I think I will say I'll answer the question based on like, what are some anti patterns for a scrum master. I'll start with never changing up the Sprint Retrospective. We talked about tasty cupcakes and all these other things. It could feel like Groundhog's Day. So your team can get very bored and disengaged, and they feel like the event isn't effective. So that's one of the things that comes to mind. I think we already talked about the daily scrum, a scrum master owning that owning that event and continuously like being the one leading it and not allowing the developers to actually lead that. And then sometimes even having no retrospective I think that becomes problematic. Oh, we'll skip it this time. Everything went so well. We're our team is so great and fantastic. There's nothing for us to improve on. So there's always something for you to improve on. There's always a new challenge. You're working in complex environment. There is always something new, challenging and crazy that happens. I worked with a team that is They were really exceptional, they always got to done they, they loved every event, they owned it. I didn't even a lot, you know, a lot of times as a scrum master, you end up, you know, facilitating the retrospective, but they would do it, they'd be like, I have this idea for the retrospective, they were very active, very engaged in one sprint, they didn't get anything done, like nothing. And working with the new technology, they had a lot of challenges, we had to discuss ways that we can, you know, remove some of these barriers and issues and improve the learning curve. So. And I think the other thing is no documentation. I think sometimes people get caught up in like, oh, working software over that it's over documentation, not no documentation, like, oh, yeah, we can complete this work with no documentation, we've met the definition of Done and then no one knows how to integrate with your work. So those are some things that I probably the last thing for a scrum master is not being a safe space for people not being, you know, holding things as confidential, being able to not being able to work with other team members to kind of help resolve some conflicts that are at a point of, you know, you're not able, they're not able to resolve them on their own. So those are some things that come to mind when I think of anti patterns for Scrum Masters.

Lindsay Velecina: 36:25

Awesome, thank you. Those are some great tips to share there on that, things to avoid. So this question here, so how do you deal with a team member who starts to dominate the team? And the other team members are fine, though, because they do not like to take any responsibilities. So how do you help the team find that balance, which one of you wants to start with this one, because I'm sure you both had some good insights here.

Scott Adams: 36:56

I take it first. But first of all, I'll tell you about the scrum guide. As we read the scrum guide, the fourth bullet point under developers is we want the developers to hold themselves accountable. So how do I deal with a team member who starts to dominate the team? At first, I'm gonna be quiet. I'm not gonna do anything. Now, let's say sprint retrospective is today's Wednesday, let's say sprint retrospective is Friday. Now what I would do with the sprint retrospective, stellar is say, Hey, how's everything going? Everybody? Oh, great. Fantastic. Well, hey, I've been you know, I've been seeing this. I've been seeing that. Do y'all see any concerns? Do we have any problems that we need to talk about today, I'm trying to create that open space for them to talk about the the elephant in the room, so to speak, those behaviors that are going on. So I'm just going to facilitate and allowed them to really step up to the plate and handle this problem, because we really want to foster an environment where they handled they all problems. Now, there may be a time but we need to step in, like I'm doing now. I'm facilitating. They don't say anything. I will bring that up specifically. Hey, I heard this. Tell me about this. Do y'all think that's conducive for where we're trying to go as a great team? Do we need to revisit our team working agreement, whatever that may be? Certainly an opportunity for me to talk about sprint retrospective if it hasn't been talked about already. Andriana? Yes, I agree with that. I think you already mentioned liberating structures, I think the technique, one two for all, is a good one to get people, right, the one people writing on their own, then people are in pairs. And then people are four, and then people come all together and actually give their opinion. So at least then you're getting some diverse opinions. And you're allowing that space for people to communicate and work together. I think the other thing is talking directly to that person is okay, too, and understanding their motive and, you know, seeing like, you know, some people, they just think they're right all the time. And some people are just, they don't like the awkward silence. So they're rambling on and on and just allowing them to, like, sit in that space and allow other people and lead and encourage. So sometimes I see this often with like lead lead engineers, where they're the first to speak there, they never stopped speaking, and they don't give their team the space and just, you know, coaching them in what leadership really is in helping them foster an environment where they're getting diverse opinions, so that we can come up with the best solution, not just the solution that they suggested.

Lindsay Velecina: 39:24

It's awesome advice there. Thank you so much. I hope that helps. So question that just came in from a DD here. The role of the scrum master talks about removing impediments. How do we coach the team to remove remove the impediments and fight this urge to remove it for them? What should be the standard thought process and workflow in these scenarios wants to take this one.

Scott Adams: 39:53

Yeah, I'll start with an impediment is something that the team cannot remove themselves. So With that, slowing them down or stopping them from work. So when I'm thinking about the thought process of this, is it something they can, my first thought is, is this something they can do on their own is this as something as you have an issue with your MacBook, and you can fill out a helpdesk ticket and you don't need me to do that, I'm not going to be your scrum assistant or your work assistant like, you can do something like that alone. Now, when we're talking about an organizational impediment that we just talked about, maybe I'll just kind of keep that same thing of talking about computers, we had an issue where our organization has a standard for what type of computers you get, but everybody's computer was crashing, when they were using this particular software that they had to use. This is not something that they could go fill out a helpdesk ticket, because it's literally like 50 engineers, and they need special approval. So something like that you can go, I went to management, and I said, Hey, here's our issue. This isn't working for anyone, one of the software development managers, we have to make this change immediately. So that comes to top of my mind is like this is something that they can handle themselves, versus something as simple as you need help desk help or even when you're working on. Like, it could also be as simple as talking to another team, it is a developer's responsibility to work with other team members, or people on the opposite team to get to done. So try not to be that communication, like go between trying not to be their assistant. So those are at least some of the things that come to mind. Scott, do you have some others? The other part of that is, you know, how do you keep yourself from jumping in and just solving a problem for them? Well, that's why I go back to thinking about servant leadership, servant leadership means people will grow as a result of your leadership. So I've come to ask myself two questions before I talk to or deal with anybody on this planet. Scott is what you about to do or say, gonna empower somebody to do their job? Or you enabling them? We don't one or the other? Which one are you doing. So if I continue to jump in and solve their problems, I'm enabling the behavior. But I want to empower them to solve their own problems. Again, as Andrea said, if it's something that they can solve themselves outside of that, I will jump in and, and do what I need to do as a scrum master to get resolved. So those are two questions I asked myself before I act, and that seems to seems to help me stay grounded and do the right thing. Is what you bought to do want to empower the team? Or are you enabling the team?

Lindsay Velecina: 42:35

Thank you both. That's great. This next question here. So I actually lost my spot, because I have so many great questions. So what are this is I'm gonna kind of rephrase this question a little bit. So how did you determine like the types of projects or products that you were working on that would advocate for using Scrum over Kanban? Over another framework? Like what are some examples where you've seen where one would work better than the other? Or where it's best to incorporate both? Like, are there some stories that you can share on that?

Scott Adams: 43:18

Yeah, I have one I heard Kanban. I heard Scrum. Now, I've been in some environments where they'd not building anything brand new, I'm thinking about a major bank. That was that I was on my team. And basically all we was doing was maintenance work. They were just trying to use Scrum in that environment. In an environment where we not delivering anything of value to the customer. However, we're dealing with service tickets and things of that scrum to me wasn't the best process or approach to that work. Because you got so many tickets called tickets coming in from customers with problems and let's try Kanban. So we talked about it, I gave us some different options, and we came up with combine is an option. We tried that and combine seemed to work best for that particular situation. Now, when I'm on a team that we are delivering something brand new to the customer. Here's the caveat. Let me go back to the unifying graph. The RAF Stacy diagram, we have simple work where everything is known. We have complicated work, where there's more known, they don't know, we have complex work where there's more unknown than known but what we tried to do and then we have chaotic work, very little was known. So in most cases, if we had a complex domain, Scrum was made for that. That's going to be the tool of choice. So I'm looking at those types of things, too. You know, before I introduce this to a company and organization, looking at their work isn't simple is a complicated it's a complex and it gives the chaotic or we deliver trying to deliver something brand new to the customer each and every sprint. If the answer is yes, then I'm gonna go with Scrum. If the answer is no, it was more on the maintenance side. I'm looking at combine some other tools based upon the environment. Hope that helps you Yeah. So when I think of Scrum versus Kanban, or some other type of framework for Scrum, I'm thinking, do does our product do we need regular feedback? Do we need iterations do we need to plan, for example, I worked with a client that we built was a restaurant app, we needed their feedback on a regular basis, because they were changing a lot of things. They had a lot of questions they wanted to see it they, it was just a lot of feedback that was needed. And so that that we absolutely needed to use Scrum in that situation. So when I think of Kanban, continuous flow, in a kanban work cycle, as soon as one thing finishes, the team takes up another. So with one team that I use Kanban with this team, we there we worked at a company that did she releases, you could guess what company that is, but we would do she releases basically every few weeks major ones. And what my my team did was fight bots. And sometimes you win that battle. Sometimes a lot of times you lose that battle with biting the bots, but Kanban worked best for them. Because they needed to be reactive, they needed to continuously work on something, get information, usually from a release, we would we would understand how many bots you know, bought choose versus didn't, and then quickly change. So we didn't really need that like iteration where this this month we're doing XY and Z, we really needed to be able to continuously work on something as it came up, and quickly adapt and reorder. There's no specific mechanism for that inspect and adapt. So we did have to create our own. So those are some things to think about when you're thinking about Kanban versus Scrum or another framework.

Lindsay Velecina: 46:55

Great, thank you. Okay, so we're gonna switch gears again, these questions are great, they're all over the place. So any tips on splitting stories across more than one scrum team wants to take this one.

Scott Adams: 47:14

My first thought is work with other Scrum teams. Usually, and in this situation, we would bring the teams together and have a discussion on who's going to do what and how it should be split and what actual because the team is going to know best. I'm not going to know best on how it should be split. But get those team or you know, one or two people on those teams and discuss like how can this be broken down, have them in your if you hopefully you do product backlog refinement, have that discussion. Make sure they're actionable. Make sure that it's something that literally can be done and aligned. If you need to align on Sprint on what sprint this is going to be done with that other team. That's immediately what comes to mind is just work with the teams they know best on how it should be split. Definitely look, look at it, challenge them, make sure that's not size to where it's a point of like and XXL. Breaking that work down into something actionable is going to be really important. Scott didn't the other thing. I mean, you touched on the ticket to the team. You work with that team. Now the thing I've done if you've in this environment, maybe you have most of our masses have two teams on average. Watch this. What if both of your teams are dealing with the same product? One is web base. One is mobile base. So there is some overlap of work there. So I suppose the idea now wouldn't like they already thought about it themselves. Hey, so we combined both of these teams. With Scott the scrum guy says we can't go over 10 people. Scrum guide says typically 10 or fewer people is on a scrum team. Oh, we can go more than described and 10 on a date. Yeah, yeah. So the things we have to think about like we adding more complexity to the situation, but it's about what you wanted to do y'all think is beneficial for y'all to do this. And in that case, to say, let's try it. And we always have to what sprint retrospective to inspect and adapt the CIA's work. So yeah, in most cases, if I'm working on a team that has web, mobile and web, mobile and web applications, to different teams, bring them together. That's the one way that you know, could not necessarily solve the splitting stories portion, because they working on different things within that as well. So you want to do some more tweaking in that as well. Not just a story standpoint. So hopefully that helps.

Lindsay Velecina: 49:36

Awesome, thank you. All right. So there's a two part question here that I think be helpful to the entire audience in our listeners. So what book has been most impactful in your development for both of you, and what qualification has been best for your development?

Scott Adams: 49:58

Andriana you Other ones? Yeah, the first one's pretty easy for me the second one, I gotta think about what qualifications has been the best for your development. That one's a little tougher. So I think

Lindsay Velecina: 50:10

maybe there's something that's not a qualification that you want to highlight that may help our audience. Yeah.

Scott Adams: 50:17

So for the first one, I think mastering professional Scrum, I think that book has significantly helped me improve my team. So they have action items at the end of every single chapter. And I thought that was really helpful. These are questions I'd even brought up to the team and some retrospective, so I really liked that book. And then for one of the qualifications, I'm gonna say, one of the skills that I think has helped me with not only my development, but growing in my career has been the skill of negotiating. So when you're working with different teams, when you're working at a large organization, the ability to negotiate work to negotiate priority to negotiate help, and even getting a little bit of a discount on things to help your team has been really valuable. And I think that's like a secret sauce that I don't think many people talk about when when they talk about being an effective and a good scrum master is the ability to negotiate. And that wasn't something I had early in my career. And a friend was like, this is a skill that you need to have. And she was initially talking about it in the frame of like when you find the job negotiating your salary, but the information that I was learning was so good, just in general, it's like, well, I can use this just on my job on a daily basis and influencing people. So those are those are my my answers for that, Scott. That's great. Every book. Favorite book is definitely scrum mastery by Jeff Watts. I think I'm pronouncing that right Goff watts, Scrum mastery, from good to great servant leadership. The other part of that is qualifications. I grew up on the scrum guide. 2017 scrum guide was called out you know, as a scrum master. We are kind of like a servant leader. Today's scrum guide says that we are a true leader. So I come up Stoney in servant leadership, and I love servant leadership, it means that other people will grow, your team will grow your product will grow everything around you will grow as a result of your leadership. So I've deep dive into that. And what I need mostly for that, in terms of qualifications is good communication skills. You need that and whatever you do, and whether you develop a project manager, business analyst, communication skills, that is one of the number one number two skills and anything that you're gonna be doing in life. Now scrum.org has an amazing professional facilitation skills class now. But when I came to the game years ago, I didn't have that. So what did I do? I went to Toastmasters. Why, so that I could work on my communication skills, because I knew and now you know, that the fastest way to mastery is to get feedback. The other fastest way to master is to teach something, somebody to somebody who don't know something, or to share information that you notice somebody else did not note, you actually put yourself in a teaching stance, but when you do that, so scrum mastery, and I will say Toastmasters will be an organization or dollars over six months to get, you know, you would like minded people, you go in and present everything and Toastmasters is, is working on one specific aspect of your communication skills. Most people think Toastmasters is a place where you go be a public speaker. That's the number one and number two thing that people in the world fear the most. The other thing is a snake. Yeah, if you're both of them, snakes, public speaker Toastmasters I'll say it'd be a great option for you as well. Now, the professional skills facilitator for class, you know, on John and I, we do offer that they got that wonderful class, they're just going out or if they had that, when I came in years ago, I definitely took that class because as a scrum master, you are wearing your teaching hat. You're facilitating hat, your coaching hat, your mentor hat, what's the common denominator and all four of those hats? Communication? Yes.

Lindsay Velecina: 54:09

Yep, communication is key for a lot of these things. So I want to thank you both so much. I think we're coming up to our time for questions. But I do want to allow you both to, to share any final words final advice for our audience today and let our audience know how they can best connect with you. So let's start with Elijah. Jana. Do you have anything you want to leave the audience with?

Scott Adams: 54:34

Yeah, thank you. Thank you all for joining. I think one of the things that I wish I would have done earlier in my career was learn the skill of negotiation and just learn one thing at a time, just continuously improve one thing at a time, don't get too overwhelmed. You'll have some gaps in your career, but that's totally fine. Everyone has gaps in their career and just tackling it one thing at a time taking that same approach that we tell our teams to to continuously improve and evaluate ourselves, I would recommend you do that same thing. And you can always find us on YouTube, not scrum done podcast. You can find my website at Project academy.co. And then you can find me on LinkedIn at Andrea on the Marshall. That Well, final words for my final words for everybody's first of all, thank you, Lindsay. Thank you ScrumOrg for hosting this will be to read the scrum guide every day, rather than on every podcast. And you know, every every interaction I'm having with the person is did you read the scrum guide today? Now? What have we mastered? Subscribe, if you're a scrum master, then if you're not reading every day, now, don't think don't don't leave it to your memory that you know this stuff. Even before I did this call today, I read the scrum guide before I got on this call, because I want to use that as a single source of foundational truth for us to have this conversation. And if you're not doing that, how can you teach and really recreate this in the workplace? If you're not reading it, you'll remember I promise is not that good. And then the other thing is, if you want to connect with me, I'm active on LinkedIn, g of LinkedIn forward slash je s m Scott. George Sam, marry Scott. So awesome.

Lindsay Velecina: 56:16

Thank you. All right. So thank you both so much for sharing your knowledge today and giving us your time. I think that was a great session. And I hope our listeners got a lot out of this. I sure did. And yeah, so thank you, everybody. And we run these sessions about once a month, so please be sure to check back and you will get the recording in your inbox within 24 hours in the event that you want to go back and re listen to some of the advice that was shared today. So thank you both so much. And thank you listeners and audience scrum on take care