.jpg)
The Agile Within
Providing agile insights into human values and behaviors through genuine connections.
The Agile Within
The Effective Scrum Master with Gary Evans
What if mastering the art of Agile could transform your team's dynamics and boost productivity? Join me to uncover the insights of Gary Evans, a seasoned Agile Coach, Scrum Master, and author of "The Effective Scrum Master." Gary shares his journey of over thirty years in Agile methodologies and reveals the inspiration behind his latest book, filling crucial gaps in current Scrum Master literature. Tune in to explore his unique perspective on the evolving role of a Scrum Master and grasp practical guidance on navigating technical challenges and resolving conflicts within teams.
Discover the intriguing personas that Gary introduces—the Sherpa, Shepherd, Sheepdog, and Diagnostician—which illuminate the multifaceted role of a Scrum Master. These personas serve as a framework for understanding the journey from novice to expert, driven by experience, experimentation, empathy, and empowerment. Gary underscores the importance of community, humility, and mentorship in the path to becoming an effective Scrum Master. Through personal anecdotes, he illustrates how nurturing leadership and fostering self-reliance can empower Agile teams to thrive.
Join the conversation as we dissect the balance of authority and empathy required to protect and nurture Agile teams effectively. Gary candidly shares experiences that echo familial protectiveness, such as defending teams against unreasonable demands while maintaining sustainable work practices. By embracing both the nurturing and protective qualities akin to a shepherd and sheepdog, Scrum Masters can ensure their team's well-being and productivity.
Connect with Gary on LinkedIn:
linkedin.com/in/gary-k-evans-72167
Check out Gary's Book, "The Effective Scrum Master":
https://www.amazon.com/dp/098830113X
Visit Gary's website and subscribe:
https://www.effectivescrummaster.com/
When in Columbia, SC visit Lake Murray and the South Carolina State Museum:
https://www.lakemurraycountry.com/
https://scmuseum.org/
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Welcome to the Agile Within. I am your host, Mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Well, hey there, I hope everyone is having an absolutely fantastic day today. I'm Mark Metz, your host at the Agile Within, and I have a guest today by the name of Gary Evans. Gary, welcome to the show.
Gary:Mark, thank you very much. I appreciate what you've offered here.
Mark:It's great. So, gary, you and I have known each other for quite some time. I was working as a developer and when I got in touch with you and you were given some training classes, you and I have kind of stayed in touch here and there. It kind of helps that we live in the same city, so we're geographically close together, but it's good to have you here on the show.
Gary:Well, I appreciate that and I guess it is unusual to have someone from the same city in which you live. But we have stayed in touch and I remember those days. It was a lot of fun back then and it was a lot of fun.
Mark:So, gary, you and I both are located in Columbia, south Carolina. Not only that, but even closer, by the same suburb of the city. So Irmo, south Carolina, is in the northwest corner of Columbia. So, gary, as our normal icebreaker question, if I were coming to Columbia for a day and had never been there before, what's one thing that you would say that I couldn't miss doing?
Gary:Well, that's interesting. I don't get around much in Columbia but, however, if people were coming here, I would really recommend first that they go to Lake Murray, which is one of the largest man-made reservoirs, if you will. It's a huge lake, all kinds of boating, sports and fishing and all those types of things, and secondly, we have a great museum here. The State Museum for South Carolina is located here in Columbia, South Carolina, and kids love it and adults get a big kick out of it. It's really quite impressive. So I cheated I gave you two.
Mark:That's great. Well, hopefully I won't get a bill for the second one, so I appreciate that. Gary, I can attest that I love Lake Murray and also love going to the museum. Those are both great places to go. Well, I want to introduce Gary to our audience here. So Gary is an agile coach, a scrum master, a developer and an author, and he has over four decades yes, four decades of experience in software development and delivery, and that includes three decades totally dedicated to agile methods. So very, very happy to have Gary here and we're going to talk a little bit about his book that he has released and it's called the Effective Scrum Master.
Mark:And, gary, I've been going through this book and I found it absolutely fascinating. It's over 450 pages. It's a book that you can use. You can read from cover to cover and then, when it's done, it's a great reference to fall back to where you have certain situations may present themselves and you're like gosh, I don't know, I haven't been through this before. I need some guidance. You can just go straight to the book, go to that chapter, and Gary's got some great advice and some steps to walk through for that. So, gary, this book, the Effective Scrum Master I want to ask you first of all, based on the title, is this exclusively for Scrum Masters? What?
Gary:a great question. The answer is no. I focus on the Scrum Master role in the entire ecosystem of an Agile team, and I have entire chapters, multiple chapters, on the product owner role, as well as the developer role that is defined in the 2020 Scrum Guide, which includes not just developers, but testers and database analysts and all of that. So it's really not just for, but testers and database analysts and all of that. So it's really not just for Scrum Masters, but I use that role as the focus for understanding how the team should be operating and how the Scrum Master can help the entire team, including helping the product owner write stories, and perhaps we could cover that later.
Mark:It's a very important topic, I would agree. I want to know, gary, what was your inspiration for writing this book, because, like I say, it's over 450 pages, so there's lots of information in there. Can you talk to us about why you wrote this book?
Gary:That's interesting, I'll share with you. The first two books that I wrote are non-technical books. I eased into those. However, this one, I actually had an epiphany. I was reading another Scrum Master book that came out a few years ago and at the end of that, when I was finished reading it, I said I could have written this book. And then it suddenly hit me I should have written this book and at that point I committed that I was going to take everything that I had learned over the previous multiple decades of working with agile teams iterative development, scrum, extreme programming, kanban all of this I was going to put it together to share as my legacy for our agile community.
Gary:And really it came from reading that one book, which is a pretty decent book, but it left out so much. And so many of the Scrum Master books talk about the soft skills, but they don't get into really detailed issues of should a Scrum Master be technical, should a Scrum Master not be technical, how should they deal with conflict when you have somebody who cannot be saved and how do you vote them off the team All of these issues that are really very sensitive. They were missing from all of the Scrum Master books that I read, so I decided to write my own. That's how it happened.
Mark:Well, I'm glad you did, because the way I look at it is I look at the Scrum Guide that is out there that the 2020 is the latest version that Ken Schwaber and Dr Sutherland wrote, and it's absolutely fantastic, and it's only 13 pages, so it's very digestible. But the one thing is it's so broad and so open. I don't know where to start. I don't have any guardrails. The world was too big. It was like I was a toddler and I was immediately given access to the entire house. I could approach the stairs, I could go outside, I could open cabinets that may have things in there that could hurt me, and really didn't have any information that would help me from doing things that would harm me, and so that's why I like your book. It really provides a lot of context around the Scrum Guide to help Scrum Masters and product owners and the development team to guide them.
Gary:You've touched on a topic that when I was at Bank of America rolling out Agile worldwide for the bank, this issue came up in our team. Do we provide guard rails and guidance for new teams or do we let them flounder until they finally figure out what to do? And we had some spirited debates about that, and this goes on even in the rest of the corporate world. The reason I wrote the book the way that I did I wanted to give people guard rails and guidance without giving them an either or. I didn't want to say you have to do it this way or you're going to fail. I wanted to give them context and some starting points so that they could understand oh, is that how you run a refinement session? Oh, okay, now I understand what my goals are.
Gary:Because the Scrum Guide is extremely abstract. It doesn't go into how you do things. It tells you what you need to do, but not how to do it. I just wanted to comment on that because that particular question that you raised. I've seen so many teams that have been hurt by Scrum Masters who didn't know where to start or, even worse, where to end.
Mark:Scrum.
Gary:Master didn't understand the limitations on his or her scrum master role, and there are some very distinct limitations, but they're all context-based. I just wanted to make that comment and that's why the book is written the way that it is so when you say context-based, that really means it depends.
Gary:It depends. If you've got a new team of nothing but introverts, you're going to work with that team much differently than you will with an experienced, mature team of extroverts. You've got to deal with the people first and the process comes second. And that doesn't come out of the Scrum Guide. The Scrum Guide really doesn't talk about people.
Mark:One of the sections in your book that I really liked and I had this highlighted was that you have agility. Not agile is the goal. Talk to us about that, gary.
Gary:Agile has become a commodity, mark. You've seen this. You've been doing this about five, six years and you have seen that agile has become commoditized. We have certification mills where people get a certification after two days and they think they can actually do something, and they don't yet understand their inability to address some of the nuances.
Gary:If we focus on agility, the ability to pivot when we need to, the ability to constantly evaluate from a medical perspective consider you're working with a patient who's injured.
Gary:You want to constantly measure their vital signs and you will then make, based on those constant measurements along the way, you will decide oh, the blood pressure is dropping, I need to do something. But you only know that after you've been working with that patient for a while. You need the ability to pivot, not to take something again where I sound like I'm picking on a scrum guy, not to take some paragraph from the scrum guide and say that's the one true way to do this. There is a one true way. In truth. You don't have to do stand-ups to be agile. You don't have to do stories to be agile. If we focus on agility, you can even be agile in the sense of embracing agility, even in a waterfall project, even be agile in the sense of embracing agility, even in a waterfall project, if you approach it correctly. So these are often considered to be similar because they have the same root word, agile, but in terms of practice and implementation they're really quite different.
Mark:You mentioned. Do you really have to even have a stand-up to be agile? I had a team with a group of people that worked really well together. They just really enjoyed working with each other. They understood each other, they knew how to challenge each other. And, gary, they were essentially mob programming eight hours a day. They just enjoyed that style.
Mark:And so they challenged me and they asked why do we need a daily scrum or a standup if we're meeting eight hours a day? And I had to. I had to ask myself, well, what's the purpose of the of the daily scrum, cause it's not to report to me. So I understand the daily scrum is for you, the team, so that you are aligned. If you feel like you're fully aligned, then maybe we don't need it after all, and that was a lesson that was taught to me that day. Now I haven't coached a team like that since then, so that was probably an exception to the rule. But that is to say that this team was very, very close, working together and were able to work out all those dependencies, all those blockers. They were able to do that in real time, as opposed to waiting to sync up at some point 24 hours away from each other.
Gary:That is such a great story because you responded to the reality rather than a prescription. You haven't had another team like that, meaning that all teams are different and, as a Scrum Master, we need to be sensitive to those people. Issues in the teams, because teams as a whole have personality, in addition to the personality of the individuals. The team often reflects the individual personalities, but we need to be sensitive to that. In your situation, mark, I would bet that you sat back and just monitored the Slack channel or the Microsoft Teams channel and looked for anything that might require your intervention, but otherwise you let the team roll.
Mark:I did. I'll tell you another little wrinkle that was interesting. That taught me early in my scrum mastering career is that this team worked well together but they had one person from the team leave and had a new person come in are totally different. When only just even a single person comes in and is introduced to the team is a totally different dynamic and that person actually did not like that style of working together. They wanted to.
Mark:Can I have some alone time? Can I just work independently on my own instead of having to look over somebody else's shoulder or have somebody look over my shoulder? So yeah, that was another challenge that we had to go through. And how does the team respond to that? How do we work together? So, like you say, all teams are different. All teams are different. You talk about personas of scrum masters in your book. Specifically, there are four personas and I found this really interesting and started immediately thinking about situations in my own Scrum Mastering that fall into these categories. For our listeners out there, can we walk through those personas and maybe give us some examples of when you have had to exhibit those personas?
Gary:Oh, absolutely, the personas are four additional attributes of the Scrum Master role. So let's go back to the traditional language that you hear in the Agile community what is a Scrum Master supposed to do? And the answer, the default answer for years, has been oh, the Scrum Master is a servant leader to the team and secondly, secondly, removes impediments that the team cannot remove themselves. Okay, and a lot of people stop there, and I stopped there for a long time. In fact, when I started as a scrum master kind of very much by default, back in the days when scrum was just coming out I had no clue what it meant to be a servant leader and I struggled and I struggled. I actually wrote an article years ago called the 10 Scrum Master Crimes, in which I defined what a Scrum Master should not do, so that I could, by contradiction, try to understand what a Scrum Master should do, and it helped me, and I think I have that up on my LinkedIn account, that particular little article. But then I began to understand that the role of the scrum master is much broader than that. I admit I take a very expansive view of the role of the scrum master. I've been doing this for 30 years and I have learned by mistakes and I've made some tremendous mistakes what I, as a Scrum Master, really should do to help my team be successful. So I came up with these four personas. They just emerged. It was very much an emergent set of concepts.
Gary:The first is the Scum master is a Sherpa, which means an expert. Just as the Sherpas on the mountain climbing teams have to know everything about the mountains and the crevasses and all of that, a scrum master needs to be an expert. Now, immediately, that raises the question well, what if I'm a brand new scrum master, how can I be an expert? And the answer is you cannot. But you're on the journey to become an expert through first exposure and then experience, and that leads, thirdly, to expertise, and all of that through experimentation. Those four words start with the letter E, so I call them the four E's, but the Sherpa has to learn and is on a journey to become an expert.
Gary:The second persona is the shepherd and this is the guide. And this again is difficult for a brand new and experienced Scrum Master, because a guide has to know the journey and be able to guide other people, because the shepherd has been there before. So this is where working on multiple projects in different domains. Business domains is so valuable rather than working in the same domain for year after year after year, because you learn so much in different business domains, whether it's medical, commercial, government, education, all of these different areas. You're going to learn much more about what it means to guide your team as they work in a particular business domain and in the process of scrum or Kanban or any other homegrown process that you might rise.
Gary:The third persona is the sheepdog and this, frankly, is the most difficult. For most people. It doesn't matter whether they're scrum guides, the scrum masters, or not. The sheepdog is the protector. This is difficult because it means that you often have to engage and embrace conflict, that if there is a threat to the team, the scrum master has to step in. That often can result in some physical confrontation as well verbal or physical confrontation, and I can share stories about that in a moment if you wish.
Gary:And then the fourth is the diagnostician, and this is the healer. And this is where the scrum master understands the pulse and the vital signs of the team in a very quiet, from the back of the room approach, understanding when things are becoming a little turbulent and when they're ready to turn into turmoil. A little bit of diplomatic ball may be able to smooth the waters a little bit. The diagnostician has to be able to understand, through meaningful measurements of the team, not individuals, what is the nature of the team? What are the vital signs of the team? Are they thrashing? Is there resentment building among any team members? This is crucial, the resentment issue which turns into anger and then you've lost your team at that point.
Gary:So those are the four personas and the reason I added those to the book. They actually are the central theme for the book and the role of the Scrum Master. I'm constantly referring it as I talk about my war stories. I'm constantly explaining as a Sherpa, you need to do this and as a Shepherd you need to do this, so that I can bring them back to these four conceptual roles Again the Sherpa, the Shepherd, the Sheepdog and the Diagnostician a much more expansive view than what you get from just the Scrum Guide. Do those resonate with you in your experience? Have you found those same four personas necessary?
Mark:Yeah, I was actually wanting to talk through each one of those, if you don't mind, gary, because I had some questions for you and just some personal experiences.
Mark:So, starting out with Sherpa, like you say, starting out as a new Scrum Master, you're not going to be the expert, you're not going to necessarily know everything and you honestly never will know everything. But one of the things that I want to bring out is the community that's out there and the willingness to help, in the humbleness that's out there of people saying I don't have this figured out, I need some help in this area, can somebody help me? And then others being willing to step in and share some experiences and just for the goodness of bringing forth help within the community. So that has been tremendous for me. So it's one of the things that I try to aspire to do is to find a mentor and be a mentor. So you're continually having both sides of that and because that can be daunting, right that you're going to be a Sherpa for a team with this community behind you. What's your experience been like?
Gary:We do have a very helpful community where people are willing to sacrifice and help and answer questions and offer guidance in so many different ways. The issue of the Sherpa, especially for new scrum masters accept the fact that you are not an expert but you want to be, and you used a word that I absolutely loved and it's in the book. It should be the fifth Scrum value, and that word is humility. A new Scrum Master or a new developer, anybody who wants to learn, has to have a certain humbleness, a certain sense of humility, so that they're not afraid of asking questions, Because unless you ask the questions, you will not fill in that area that you don't understand. From a short-paced perspective, it could be that you're new to the Scrum Master role, but you're very good in other areas. For example, I actually became a software architect role, but you're very good in other areas. For example, I actually became a software architect.
Gary:That was my major role in object-oriented development back in the 1980s when Scrum was coming out. In the late 1980s, when I was starting my path, I was actually an object-oriented software architect. I had that expertise when I became a Scrum Master to bring that to my teams, but I had to be very clear to them. Okay, I'm taking off my scrum master hat and I'm putting on my software architect hat, so you guys don't get confused. I'm not telling you what to do as a scrum master. I will not tell you what to do. But as a software architect, here's what I think we could do. And so I had expertise in other areas, and you need to bring that expertise. Whether you're new to the Scrum Master role or a product owner role or even a developer role, you bring some kind of expertise with you and then you grow from weakness into strength and expertise in other areas. Ultimately, the Sherpa role is one to which we all aspire, but we may not be there yet.
Mark:Talking about the shepherd role. Tell me if you disagree with this, gary. Maybe you do, but the shepherd role, that's one that's very difficult to acquire or learn. It's something that much more is ingrained within you. I'll just say from my experience I feel like that is one of my stronger attributes, because I believe I get DNA from my mother. She was a registered nurse for 30 years before she retired. How much more of a loving, caring person do you think you can be than being a registered nurse? It wasn't something that she was doing for financial reasons. It was because she felt like she had a higher calling to do that, to serve people and to care for them. So that's one that I kind of feel like it's harder for you to go in, and if you don't have that shepherd type mindset, maybe the role isn't quite right for you.
Gary:Oh, you've touched on such a sensitive area there. You're absolutely right. Personality accounts for so much in everything we do on our teams and a lot of scrum masters struggle and, frankly, some of them fail because they are not people, persons, they do not want to guide, they want to be the boss. And those scrum masters last about two minutes under my coaching Because then I try to teach them. You need to suggest, you need to offer, you do not need to dictate. And it does require a personality that, if I can use the word the shepherd needs to be a pastoral personality where you really care about people. And this is what's missing in the Scrum world and in the Scrum guide. It does not emphasize the people skills. The team should decide everything. Well, what if none of your team are people people either? If they're not people, persons right.
Gary:So, it's a very difficult question. When I work with scrum masters in my role as a coach, I am almost always operating in my shepherd persona. I have to guide the guides, to give them an example of how they should be approaching and guiding their teams. If I didn't do that, they wouldn't have a model to follow. So it's something that I've worked on for years and I'm still trying to become better at it.
Mark:Very well said. So we move on to the sheepdog, and in your book you had a couple of really interesting I'll just leave it at that examples from your own, from your own life. Talk to us, give us those examples and tell us about what you learned from those, because I really found them fascinating.
Gary:Well, I appreciate that the book is filled with war stories. As you have seen, after 30 years doing this, I have lots of war stories and many, many of them are in the book. To give concrete examples, with respect to the sheepdog, one example was to protect the team from themselves, and I had two developers who came to me one day and they were quite distraught that a new developer was taking too much of their time and needing too much hand-holding. And so they came into my little cubicle and they expressed their concern. They did their redress of grievance. The look on their face made it pretty clear what they wanted and I said we need to figure this out and solve this right away. Let's go do it. So we walked down the hall and we went into another cubicle area where the new developer was sitting and I said I'll just say Fred, fred, john and Mike here have a concern. John, mike, tell Fred what your problem is.
Gary:And those two guys, their faces just dropped because they thought I was going to do all the work for them. But I had to protect them by letting them solve their own problem, and they did. They explained to Fred that he was taking too much of their time and that they had other things they needed to do. And Fred said I had no idea. Sure, and I simply said to Fred Fred, you know how to do this stuff, just hammer at it. Don't bother these guys for a while. If you run into a real problem, come see me. You know how to do this stuff, just hammer at it. Don't bother these guys for a while. If you run into a real problem, come see me. Well, fred turned out to be one of the best developers on the team, but I had to defuse what could have turned into extreme resentment and then extreme resistance between Fred, mike and whatever other name I take there.
Mark:I almost feel like in that situation, gary, that there was some level of inspiration, empowerment, because you could have gone into that situation very much and had a very down look on your face. You could have been looking over the and people can't see me, but looking over the top of your glasses with your arms folded and been like no, fred, we don't want to have this conversation again now. So that's one way that could have. But you know me as far as my parenting style, as far as my coaching style with that's me, because that never motivated me. My parents didn't raise me that way and whenever I had a coach that had that sort of demeanor to them, I didn't respond well to that. But the coaches that I do remember were the ones that believed in me and stood behind me and supported me, and that's what I see in this lovely picture that you've painted here is, maybe Fred just needed somebody to believe in him, to give him some confidence. How reassuring and how rewarding is that to see that outcome.
Gary:That particular episode was very rewarding. As I said, Fred became one of the best developers on the team. He just didn't understand because of some cultural differences His name wasn't really because of some cultural differences, His name wasn't really Fred Some cultural differences that he needed to be more self-reliant. My role was to help the guys explain on their own their own concerns, bring their own concerns and issues to Fred so that the three of them could work it out. Because if I went in there, like you said, with my glasses down and my arms folded, it would not have been productive because that would have been basically dictating rather than nurturing those guys. Which brings me to another sheepdog story, which is quite different.
Gary:Yep I had a small team and I was in their cubicle area and the product owner stormed in one morning and he was lit up. He started berating the team, complaining that something wasn't working and that they should have figured it out, and I just said stop right there, you don't talk to my team that way. And I used the word my team because that established right away that I had authority. I was assuming authority for these developers and I said stop right there. He started to come towards them and I physically moved between them and I was ready to engage in some very physical contact if necessary. Fortunately it didn't turn out that way and later I learned the real reason behind his anger and his volatility had to do with a very tragic personal issue in his life and he apologized and it was all good, but for those few moments it was very intense.
Gary:Most people won't have to deal with that kind of threat, but this was a physical threat against my team members and I had to make a decision years ago am I going to step in?
Gary:And since I come from a military family, my answer has always been yes, I'm going to step in. You don't mess with my teams family. My answer has always been yes, I'm going to step in, you don't mess with my teams. Now, not everybody's going to feel that way, but you need to at least consider how will I respond to something like that? How will I respond if a product owner suddenly starts criticizing my team in a public forum, or even in a private forum? Will I stand up for my team, because those guys saw that I was willing to basically take a punch for them and, as I said, fortunately it did not come to that, which in a professional environment it never should. But this was extremely volatile for an unknown reason and I had to respond in the only way I was prepared to do so. But that's a different kind of sheepdog response, as you can see. Sometimes they're very simple, like Fred, the issue with Fred, and sometimes they're much dicier.
Mark:I have a story that did not escalate to that point. I've actually told it on the podcast before. So, listeners, if you've heard it, if you want to skip over, maybe about a minute or so, you may just want to go ahead and do that. But we were working with another company. Two companies were collaborating together to create a software product and they were in different verticals, but they were working on this one product that supported both companies.
Mark:And one of the senior managers that was working on the other company made the comment that he always expects 130% output from the team, because the team will never give you exactly what you say, and by him asking for 130% what you say, and by him asking for 130% when they came up short, he would, in the end, get 100%. And so my response to that was if you want to deal with your team members like that, that's your prerogative because they work for you. But as far as me and my team, we're simply not going to operate like that. We're going to work on a sustainable pace and we're going to make sure that we have quality built in and we're not going to burn out our team. Be that as it may, and we kind of went our own, our own directions because there was a difference of opinion, but as far as my team that I was representing, I was not going to let that influence come in and creep into the team.
Gary:You were a sheepdog for your team. You protected them from that overload, and sometimes it's as simple as saying no, which is what you did. No, we're going to do this the way that we will, in an honest manner, with integrity. But no, we're not going to overload ourselves, we're not going to burn ourselves out and we're not going to overload ourselves. We're not going to burn ourselves out and we're not going to sacrifice our quality. Sometimes being a sheepdog is as simple as saying no, and other times it requires a lot more investment of personal sacrifice. But either way, if a scrum master is not willing to sacrifice, is totally passive and has no skin in the game, that person should not be in that role.
Mark:It's quite interesting, isn't it? Because you have to be a people person but at the same time, you have to have a little bit of an edge to you to be able to push back and not just be an order taker. It's no different than I'm not saying that being a scrum master is like being a parent. Our teams are not our children, but there are some lessons that we can learn and as you're dealing with raising a child, there is a level of love that you have for that child, for them to see them grow up, to see them be a productive member of society and to be happy.
Mark:But that doesn't mean that you're just going to, like you say, be passive and say, well, johnny didn't want to clean his room today, so I guess he's not going to clean his room. No, of course not. You know what's best. So you're guiding them to make some tough decisions. But at the same time yeah, I would hope those of us that are good parents out there. I feel like I'm a good parent because my wife and I are empty nesters and our kids are doing well out on their own now, so proud to say that. But I think there are some lessons that we can learn from, from parenting, and it kind of comes down to that sheepdog persona like you talked about.
Gary:The sheep, the sheepdog, as well as the uh the shepherd, because you're nurturing the shepherd with the pattern that we need to. We need to. We need to have a soft side to us as scrum masters so that we can shepherd our team and nurture them, but we also need to be able to defend them, just as we would defend a family. Now, in my book, I don't mention the parenting metaphor as part of the scrum master role, but you're exactly right, I've always thought this way being a scrum master is very much a parenting role in the sense not that the team are children, but that you're nurturing the team. You're growing them as a team. You're also trying to help them grow individually as individuals and the goals that they have.
Gary:I have a series of questions that I share in the book that I ask when. I have a series of questions that I share in the book that I ask when I'm a scrum master. I ask my team members about five or six questions, a couple of which are very, very personal, but I ask them what are your professional goals, what are your personal goals? And I want them to share those with me because I may be able to help them achieve those goals. My goal, my role, is to nurture them and help them grow, not just professionally as developers or product owners or other drummasters, but also as individuals. And so the more I know about my own team and some of the sensitive things like I actually ask them do you have any health issues or other issues that I need to be aware of that could impact your work?
Gary:And I've had people tell me that they've. I've had people with drug problems, substance abuse problems. I've had people with health problems. I've had people who are going through divorces. I've had people who are, who are caring for ailing parents, and I simply say, great, this doesn't go outside this room, but if you're having an episode that you're struggling with, we need to work out a signal so that you can give me that signal, so that I can know I need to give you some space or I need to come alongside you. You let me know. Nobody else on the team is going to know anything about this, and I have done that for years, just because if somebody's hurting, I need to know it, and if they're hurting and they need to be left alone, I need to know that, and if they're hurting and they want me to come alongside for a while I need to know that and then everything returns kind of to normal. But that relationship that I've had with some of my team members has been so strong they literally are like family.
Mark:So you're right, pastoral and parenting, and you don't get that from just reading the scrum card.
Gary:No, and you don't get it from just sitting through a certification and you don't get it from just one project and one team, and you don't get it typically until you're probably around 40-some years old either, maturity in which we accumulate all of this life experience and we begin to realize the things that we thought were really important in our 20s and our 40s. They're not very important. Other things are much more important, and it's a process of growth for ourselves as well. Another kind of topic that I talk about in the book is the Japanese martial art of Aikido, which has three levels of mastery called Shu, ha and Ri Japanese words.
Gary:Shu is the beginner level, and this is where a new scrum master starts, and anybody starting anything new is at the Shu level, s-h-u and they need a checklist and they have to follow the checklist because they don't know any better. So these are the guidelines that we would give them, right as a shepherd. We would give them some guidance and some things Okay, do these three things when you're doing a daily stand-up and then later you can start to modify that. The next level is HA, h-a, and HA is where you still have a checklist, but you're willing to change the checklist, because you're context-based at that point rather than just scripted. And after HA you move into the transcendent level, which is the RE, spelled R-I, and the RE is the expert level. And it's called the transcendence level because now you don't even, you simply throw away the checklist because it's in your head and you deal with everything based upon total context, and that can only come through this exposure, experience and experimentation leading to expertise.
Gary:I have a lot of people skills in the book. I have a lot of technical skills in the book as well, so this is a great discussion. If people want to get in touch with me or learn more about some of the things that I write about, I have a website that is just coming up now that people can go to and they can register for notifications. The website is called effectivescrummastercom and it will be evolving over the next several weeks. That people are more than welcome to come there and maybe we can start a conversation that way.
Mark:That's great.
Gary:Thank you so much, Mark. I've really enjoyed this.
Mark:Yeah, gary, and I'm sure if anybody wants to reach out with you via email or LinkedIn, we can put all those different ways to connect with you in the show notes of the podcast.
Gary:I appreciate it. Thank you so much. I'm looking forward to maybe talking again.
Mark:That sounds great. Well, Gary, thank you so much for being a guest and for all of you out there listening. Thank you for tuning in. This has been Mark and Gary with the agile within. We'll see everybody next time. Bye, y'all. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, Mark Metz.