AA142 - What Technical Skills Should a Scrum Master Have

The question came up recently at a community event: "What Technical Skills Should a Scrum Master Have?"

Brian didn't answer the originally posed question, turning it into "What skills should a SM have," and that bugged him so much, he wanted to turn the actual question into a podcast!

On this episode, Enterprise Agility Coach Om Patel and Product Manager Brian Orlando discuss the corporate atmosphere that may be behind this question, as well as answering the re-worded question, and even delving into some pros and cons of the Scrum Master having technical skills.

0:00 Topic Intro: What Technical Skills Should a SM Have?
0:23 Om's Response: Should Haves
1:39 Om's Example
2:28 Brian's Counter-point
4:53 Desire for Knowledge
7:50 Additional Value via Skills
11:35 More Examples (New Dev Laptop Example)
14:31 Speed to Knowledge
16:21 Barriers to Initial Employment
19:12 Om's Counterpoint: Curiosity & Willingness to Learn
21:32 Product Managers & the BA Skillset
23:35 Skills a SM Should Have
24:36 Programming Knowledge/Skill
26:54 Self-Imposed Barriers
28:58 Public Opinion vs Reality
31:30 Is a SM Entry Level?
35:44 You Get What You Pay For...
37:13 ...but Entry-Level Can Be Done

= = = = = = = = = = = =
Watch it on YouTube

Please Subscribe to our YouTube!
= = = = = = = = = = = =
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = = 

Transcript

0:00

On a previous podcast, we talked about a networking event that we were both at. And I brought up a question from that networking event. The responses that the questions sparked were really good. I'm not sure about the question. I'm going to ask you this question and get your first take of your response is, and the question was what technical skills should a scrum master have should slash could I'm going to change the question slightly. because again, the tale as old as time, the age old debate. That's not really much of a debate because everyone tells you the same thing. Right. Well, scrum master doesn't have to be technical. Yeah, but if they were, if they did have those skills. Like, would it be a bad thing? No, quite possibly. It would be, it would be a good thing. But I want to go back to the, the, the question, right? What technical skills should slash could a Scrum Master have? They're different questions. They're different questions, but they're related, right? So let's just tackle them in that sequence. Should have. Should have means they need to bring that to the table in order to be effective. And when it comes to technical skills here, I'm going to lean on the side of You know, technical meaning related to software in some way as opposed to technical, as in like familiarity, the ability to use a tool or something like that, right? Scrum Masters don't have to have any technical skills per se to be effective. So here I'm referring to technical skills like familiarity with development languages. You know, IDEs, platforms, any of that they don't necessarily need to have that. What they do need to do, however, and this is kind of going a little bit away from the question, they need to have the wherewithal and understanding of what their solution space entails. That's different from technical skills. So I'll give you an example here. I'm working with a bunch of Scrum Masters in the Cloud enablement, cloud space, basically, right? All all different clouds. The three, the three big cloud providers. Now, should a scrum master be familiar with, say, AWS or Azure cloud or Google cloud? That's different than saying, should they have skills in it? They don't have to have skills as far as have training in these in any way. But familiarity, meaning What are the nuances, especially if you're dealing with more than one things like metering, how does how does the cloud provider charge you to use their services? These aren't technical skills necessarily, but these are, these are awareness skills that they need to either have or develop to be better at what they're doing, depending on the space. So it's contextual in a way. Yeah. Should they have, that's what we just talked about. Well, could they? That's a different question. AWS is a good example. Is a great example to start with because AWS, if someone's, if someone is saying, Hey, I need this new feature. Your developers may already be thinking in terms of, well, we're going to need all these new clusters, and we're going to need to spin up all these new systems, and we would prefer to do serverless for all this stuff, that way we don't need to pay and maintain and watch log files and all this kind of stuff for for this whole system that you're talking about setting up. Yeah. Whereas sometimes if you want all the bells and whistles, maybe you can't, cannot go. Serverless, right? AWS has a ton of functionality being familiar with like what, what, what like the, the, the queuing system and the messaging system and how AWS does it's a cloud databases and how AWS does it's servers or whatever they call instances or whatever they, whatever they call an AWS, like being familiar with how AWS does all that stuff. I, I think of those as, I think of all that as technical. Cool. It's technical knowledge. Yes. And thereby skill. I think of it as technical. Like, I understand the question didn't ask technical knowledge. They didn't make a distinction. Right. Maybe it's a, maybe that's on the, the, the asker of the, the, the requester of the question. The asker of the question. The originator. The originator. Yeah. I know what you mean. Maybe that's on them, but I, I, I, like the spirit of what they asked is well, how can I have somebody who's supposed to be helping the development team get better at development? And they don't know. Anything about these this environment in which development operates You know, they they really should maybe you don't have to be like aws certified Maybe they don't need to take the certification and pass it Although Like I like earlier in my career I I like I could have taken and passed the vmware certs and the microsoft certs Where at the very beginning of my career the microsoft certs? Were the envogue MCSE and all that kind of stuff. Yeah, and it was like, you were not, nobody in software development really cared if you had those certs or not. However, like the company did, the company would pay for you to further your knowledge and take those things. So I see the scrum master working with the development team. If they want to advance and they want to prove to the company that like they're very serious about this. I can't see a reason to not. learn these things. That's where I'm starting. That's what I'm starting with. Given the opportunity and on the company's dime, would there be a reason to specifically not learn these skills? Absolutely not. I think if that was the case, definitely they should take the opportunity to learn, right? Coming in, though, is that a barrier to entry to becoming a scrum master on the team or program like that? Probably not. As long as they have this attitude of Learning, right? So we talked about AWS. I think it is a good example. They don't have to know necessarily how Amazon prices their infrastructures or whatever else their services. Basically, they don't have to know that what they have to know is that they that that is a real thing. Every time you want something else. You pay for it. Learn over time how what the pricing models are because they're different. Azure has a different pricing model, right? I'm sure Google does, too. So, what I'm saying is, these technical skills we're speaking of, for me, they talk about hard skills, right? Skills like, for example, knowledge in a program, a programming language, to be able to at least look at that, or be able to read JSON files and make sense of it. It's not hard, but do they need it coming in? No. Now, if their team is delivering a lot of services or whatever, right? If they're looking at JSON all the time, it behooves the Scrum Master to at least look at it to see what the team is talking about and learn. And that little learning doesn't have to be formal. That can be sitting with a tech lead or whatever. Just observing. Learn by observation. You're not called upon to design. A payload, right? You're not. But at least you can see what that is, right? So when the team is pointing looking at stuff, you become familiar with it. I think we need to talk about a different word, not skill so much as I think you nailed it, knowledge. So build up knowledge around your space, right? And again, you don't have to have it coming in. What you do have to have is sound principles of agile ways of working, whether it's scrum or Kanban. Those aren't technical at all. But coming in, if you're in the We started with the example of the cloud technology. If you're in that environment, then by all means, learn something about it. Now, there's a couple of ways you can go with that. Is there anything that is available to you in the form of documentation about what your product is? Start there. It won't be highly technical because likely it was created for the eyes of the customer. That's great because you know, you see what they see. So that's a good way to immerse yourself into the space. But then you can move from there to taking these small free mini courses that are out there in in the different technologies You can learn about those right and it doesn't cost you anything The only thing that it costs you is you gotta roll up your sleeves and and be willing to dive in so it will help Yes, but is it absolutely necessary? I don't believe so there could be exceptions to this. Like somebody could be working in the manufacturing space and there's some nuances there. You're creating. Machines or circuit boards or whatever. So it's hard products, not software. And with that comes other things like, for example, quality standards or regulatory standards that have to be met, right? Things like that. Stringent testing standards. Learn about those. Those are, I don't call those technical skills. Again, it's knowledge about your Space. The space that you're operating in? If I were to wheel back and try to and try to peel the technical away and say what skills should they have? I mean, obviously they should have advanced communication skill. They should, they should have some facilitation skill, right? Or, or at least be, be actively working on it. the concern that I'm still not sold on, that I've not overcome yet in the conversation, is what I say when I get a development manager who controls a budget for hiring, telling me I'm not going to replace a scrum master, I'm not going to hire a scrum master because if all they can do is team communication and facilitation that's not a full time job, that's a role. That's what's going to be in their head, right? They're going to have a developer do that. We know that's a little bit short sighted. However, They're going to say, if I do hire a scrum master, I, I want them to be able to jump in and help out occasionally. So I want them to have. A skill some type of skill or they want them to be able to write basic SQL statements, or I want them to be able to do some testing or maybe they maybe with their communication and facilitation skills, they can do some uat testing, whereas the team normally doesn't get involved in that. So there's I can, I can see, I can completely empathize with the development manager or a a busy VP of development or something like that, right? Who says, I can't justify a budget for this because they don't, they don't completely understand. So they want a little bonus thrown in to make them feel better. You know, maybe, maybe they've even taken the CSM or maybe maybe, maybe they get it. But they still can't justify it just because of the like when you get to executive level or whatever there's politics involved they can't be seen looking at hiring what are you spending that much money for? You could get a developer for that, right? Yeah, I agree with that. So I think if you're taking that approach, you have to figure out what are you going to ask your scrum master to bring to the table. I can tell you, you mentioned writing sequel. That's one of the things that I personally did. I learned sequel. It really helped me, but it wasn't one day. I woke up and said to myself, I think learn SQL. No, what happened is I found these leaders would walk by. We were in person before they would walk by and tap a developer on the shoulder and say, can you get me the top top five customers in the last quarter? And the developers like, Oh, sure. I know how to do that. And they go straight away. Hands on keyboard, boom, boom, boom. Before you know it, the conversation keeps spiraling now. Oh off those, can you tell me what the biggest spend was? Boom, boom, boom, right? So the developers take an off track. And as a Scrum Master, I'm trying to protect the team from these outside interruptions. So I took the stakeholder in question away and said, What is, can I help you? Right? And they said, I need to know this. Let me get back to you. And that's when I started thinking, I have access to the database, Oracle, I have access to the... The Oracle prompt, if you will . And so I started learning that by myself. I learned there's only a dozen SQL statements at the end of the day. I'm not trivializing that. It's a skill set for sure. You need to be able to do what you need to be able to do with regard to writing stored procedures, etc. And it's like spreadsheets. You can write it elegantly or clumsily as long as it works. I fall in the former category. But sequel, I write it clumsily. It works, right? I knew enough, I learned enough to query and dump data into temp tables and mess around with them. I didn't crash the database. I never did update. Okay, always always selects. But in order to get back to this stakeholder with data, I was protecting the the development team members from being interrupted. So I saw that as a need. And I figured that's what I need to do to meet the need is learn this. You call it skill. Right? I think that goes a long way. If you're doing that, this could be simple. It doesn't have to be my example. It could be give me all the stories that we completed last two sprints of a scrum master. So the skills here are simply doing queries in your head. LM tool, whatever you're using, if you know how to do that, another example that actually happened to me today a team that is a supporting team, enablement team they basically they want to know their work is tracked in their LM tool, not in the product planning tool. They want to know how they're doing without pushing all their work into the product planning tool. So in the LM tool itself, you see all your epics and features and stories nested in that way. And you can see the progress under let's say user stories. The lowest level is task, but they don't really care about that. You can see that. So you could put a calculation column in that calculates progress on a feature based on its Children stories that are complete. It's it's come. Master needs to learn to do those things. Those are the skills that are helpful in this case. The other side of it I want to take here is at least be familiar with the suite of different tools that your teams are using. Right? Understand what they're using for an IDE. Understand what your test teams are using for automation, things like that. What are your DevOps teams using? Understand that. Are you using GitHub? Right? Understand these meetings. Like what is get out? That's interesting. You wouldn't shuffle that into technical knowledge slash skills because you're not standing up GitHub or anything. You say, well, here's how you use it. Maybe you like. I remember distinctly working at one place That I don't, I don't call out this place, but I remember one place that I worked at that I went out of my way as no, I can't, I can't say it this way, but anyway, I remember one place that the first thing that developers did when they got there is they had to set up their own laptop and it like, it's such an excruciating experience. To have to set up your own laptop when you don't know where, like you don't have any credentials. Usually the credentials in are in some key store somewhere or some some, some secret keeper vault. Yeah, somewhere. And like, so you don't even know the system, the IP addresses. Some, some things are named by IP address. Some things are named by name. Some things are in different network segments that you have to VPN into Sure to get onto or whatever. You don't know the systems. The first thing developers had to do was like run the gauntlet of setting up their own laptop with access to all the... You know, all the repos and then whatever Jenkins platforms that, that, that they need to hook into for whatever repo it was, is and then, and then to get access to in the instance where they had access to the different environments to get access to actually go into the different environments to figure out what networks, network subnets they were on or whatever, like there was no central checklist to walk a new person through all this. So every new person that would start would add to the master checklist. To help the next new person along the way, but the checklist was never and then it was never bulletproof. It was never 100%. I would think this is, this is again it's a painful process. If you're not a developer, you're never going to go through that process because again, they're like, well, these are technical tools. That's why, that's why I asked that question is well, do you consider get or Jenkins or whatever? You know what I mean? Do you consider them technical tools because the development department does. Yes. And you would never be asked to exercise any of this. it's funny, because as a product owner, when I onboard as a product owner, I will generally ask for SQL access. I'll say, you have a SQL server, generate me a read only key and give it to me, so I can go do read only queries to the database and they look at me like I'm funny because they don't know that I was, I know, but I built data warehouses and stuff like that before. Right, exactly. So you have those skills that you already had from your past, right? Oh boy, we should have, we should have expanded this question into product management because I could definitely talk for an hour. On product management, technical skills, because for me, if your company keeps a lot of information in a central database somewhere, like relational database query with sequel, right? Not like a Mongo or whatever. Right, not a document. Not a NoSQL database. If you keep your data in a central database somewhere the amount of time it will take me to bother the development team to do what you said earlier where I was like, I just want to ask for this one thing, and then when I get the results, I want to think about this other thing, and then see how many of this, and see how many of that. Like, go chasing all around like that. I'll write the query. And it'll be a good exploration task for me to learn the back end database. Yep. To see the limitations, to see what tables are slow, see where they've got indexes, see where they don't. That kind of stuff. Learn their back end data. Okay? You might be like, Brian, product manager doesn't need to do that. That's a waste of your time. You should be managing products or product managing or whatever. I agree. I agree with you, however. However, it makes me more effective when I go to plan things in the future. To know, well, this table over here. Is constructed in this way, which has limited our ability to expand it. So if we want to do anything with this table, we have to first take care of the lowest root problems. Right. And then build on top of that. So I can kind of stay away or attack things in different orders. Anyway, the real point is. When I am answering questions, I am much faster because I can go get that data myself. I don't need to rely on anyone else. You know, and then the barrier usually is trying to convince somebody that I know what I'm doing. tHat, that's an interesting point about the barrier because a scrum master you know, say it is willing to roll up their sleeves and learn, let's just stick with a simple example of SQL learn SQL. So they can do just selects. Let's say they have read only access. So they're already starting there. I said, like I'm going to, I'm going to jump in front of your story because I, I agree with what you're about to say is in, in, in the, in the place where In the place where our development takes the time to help employees and sponsor them, sponsor their learning, that's what I'm trying to say. They sponsor, they really get behind their learning and they try to make them more effective in the position they're in. I 100 percent agree with you. However, I feel this question is asked from the perspective of what about the places that are not even willing to hire you if you do not have, you already have learned these skills. Another place has taken a chance on, Hey, maybe our, maybe we can extend our scrum master by teaching them SQL and by having them create a hello world app. So they understand how code is checked in, how code gets propagated from environment to environment, how things roll into production, how, when things don't work right, or, or like, do you really understand merge conflict as a scrum master? When people tell them like when you go and talk to an executive and try to convince them why it's a bad idea to hold a release for X and Y and Z amount of time or whatever. Can you really talk to them the way that your manager of development would talk to them to say, listen, this is going to cause a huge problem. It's going to affect all the other stakeholders that are behind you in line. It's not fair to them. You need to decide like making that case, you need to understand the pain that it's going to inflict. And the only way to understand that pain is to use those systems. And now, now it's easy for me to take the counterpoint because I really believe this. Because again, part of my career where I was a QA engineer, I really believe. If you don't truly understand these things, you might roll over when an executive is kind of browbeating you to be like, Wow, I just gotta have my changes and take your branch and shelve it and then take, make a new branch off and then check the new things that I want and promote them over the rest of the releases that are waiting in line. Wait a minute. We can 100 percent do that. We are a hundred percent capable of doing that. Let me put it that way, but however, if we do that, we're going to incur a bunch of costs that is not like, there's nowhere to put that cost other than your change that's interrupting everything. So you're going to pay extra now to cut to the front of the line. That that's basically the way it is. I think, understanding the technical, even though you don't do it every day, even though you're not, you're not saying like, Hey, I have these technical skills so that I can jump in and test or jump in and knock out a little part of a script or whatever, although that is certainly an incentive over and above everybody else for the team to hire you when all the rest of the skills are equal. Okay, over and above that. It it it it would be I'm forgetting my points left and right today. Like what I'm saying, it was What I'm saying is it would be beneficial to have those skills. Whereas if you didn't have those skills, yeah, I mean, you could learn them. Hopefully if your team is that kind of team. Yeah. So I agree. It would be beneficial if you already had them. If you don't have them, you need to have. The willingness to learn those, but that doesn't happen overnight. The other thing is if you didn't have them on day one, let's say you go in day five, whatever this scenario happens where you're asked to, you know leapfrog other people and put this other stakeholders code in, et cetera, et cetera. If you don't know what you don't know, here's what you can do, though. This is going away from the technical skills. Bring in your tech lead into the discussion. And then ask the simple question in plain language. If we do this, what are the ramifications? That's it. Open ended question. And the tech lead could say something, and you could go off of that. So what I'm saying is, while Those skills are very, very useful, and I'm not denying that, right? They're by no means essential day one. What is essential is that willingness to learn them. And you can talk about this on multiple levels. I, I usually get scrum masters who are non technical at a level where you say, Well, go figure out the names of these tools. That's it. You don't have to know what they do. Ask your teammates, what tools do we use? And they rattle off a bunch of names, write them down. One per line. Okay, write them down one per line, and then put a dash next to every word or keywords that you wrote down for the tool names, and write down a short, brief description of what that tool does. That's it. Right? So, they will have things on there like LaunchDarkly. Okay, it facilitates feature toggles. They don't understand what feature toggles are at that point. But they know there's a tool. Now they also know that their team uses feature toggles. Right. So you've already moved up in your knowledge that, Oh yeah, we, we use feature toggles and we use launch darkly for that. You could use that sheet as a reference sheet, carry it with you. If you want pretty notebook. So you're, you're not an expert in the whole concept of feature toggles. You're not, you're also not an expert in that tool launch darkly. There are other tools, but I'm just using these as examples. So as Scrum master could incrementally build up their knowledge and that should be their willingness. Incrementally build up the knowledge. I'm not suggesting that a scrum master be hired over others because they have technical skills like scripting or SQL because what they don't have possibly could be other soft skills that are really needed to be a scrum master, right? Empathy and things like that, listening skills, listening with intent. So yeah, it's, it's, but I understand how people hire too. The timeliness of talking about this category is I think of all the applications that I see on the internet that are like the scrum master job at particular companies and I see like 800 applicants and the jobs have been open like a day. Yeah. And I'm like, oh, good goodness. Like, you know what? Crazy, if I were hiring for a scrum master, I would be, I'd be looking. To knock it out of the park with all of the facilitation skills, communication skills, organizational design, that kind of stuff. And also... Maybe they've got a sprinkling if I put all the resumes together that have all these skills and then somebody has a sprinkling of these technical skills on top of it, I mean assuming that a, a technical person is hiring in the scrum master and that your scrum, your scrum masters don't work for, I don't know, something wild like product, PMO, PMO. Yeah, I don't really know.. I don't know. At that point, I think they're hiring to like, Hey, will this person do what I say at that point? So I Exactly. I don't have any, yeah. Yes, men. I don't have any. Yeah. I'm not helpful in that conversation. No. But one of the things, one of the things that I remember from the, the first time that I ever was a scrum master on a team , the skill that I, and all the rest of the Scrum masters had, was the business analysis skill set. We were all mini BAs and scrum masters at the same time. And that was fantastic because you actually could help the team and help product. You could, you could coach those dual roles because you could help product because a typical product manager The longer in my career I go on, the more I realize that the typical product manager does not necessarily have the business analysis skill set. I would think a lot of business analysts would jump to that. To becoming a product owner or product manager that route because they're already part of their jobs already talking to people sure and Conducting user interviews and stuff like that. It really lends itself. I mean it really lends itself into that This is I don't know why I'm doing this roller coaster in my hand It's it's it's because it's a roller coaster. You start down here and then you go up. I don't know Well, I agree that that's a natural kind of natural pathway. It should be And they bring the analysis skills that, again, I agree, most product folks don't have that. If they didn't come up through that pathway, right? But I want to just touch on something that I forgot to mention earlier, which is skills that a Scrum Master should have. You could say these are technical. I'll put the word technical in brackets in front of the word skills, right? You're, you're often You either come across the need for or are often asked for things that make you want to take data from whatever system, extract it out into something else, and then munged the data. That's a technical term right there and then come up with whatever it is that that's been asked of you. So being able to use things like, Extracts out of A. L. M. Systems into spreadsheets, perhaps, right? But if you advance enough, you could put things into access or whatever. That's fine. But if you don't, that's fine to Excel. Great, right? And then being able to manipulate this data, being able to create a data source link from Excel into that system. So that whenever you're looking at it, you're not copy pasting data or anything. It's real time. Those skills are invaluable. And they will help you as a scrum master. Right? They will help you immensely. So at least develop those day one. Yeah, what you're describing now is sort of the, the, the cross section of tooling. Data analytics and API integrations, it's sort of those three things together. I think of, I, I, I, I think of a team that I was with one time, where the leadership at the organization asked me to do some pretty advanced reporting That you can only get through the back end of Azure DevOps system. The, the, the API of Azure DevOps and JIRA both. Have a lot more functionality than is exposed through the UI. So they asked me to do, and especially when you're dealing with archived data, it's sort of difficult to, to, to get that data and expose it in a way that is meaningful without scripting of some way, shape, or form. So like, I, I was at that point in my career, I was a scripting like, pro at that point. You know, I could take a, take a script that I had developed when I was a smarter person in the past. And copy paste with the best of them and you know, reuse, reuse and reduce and recycle. Releverage. That's exactly right. Yeah. And that's sort of a, a data analysis slash reporting skill set right there is kind of understanding what people are looking for and then looking how you can get it out of the data and then writing a program to basically get it on a, on a regular basis. I think that there were some things I was doing daily, weekly and. Probably quarterly. I don't really remember. It was a long time. It was like five years ago. But that, that skill set , I could not have done without without programming knowledge, you know. Yeah, it does rely on that foundation, doesn't it, really? Yeah, scripting and things like that. And you can Python's like, it's a very learner friendly language. Sure. Sure. So I'm not saying, I'm not saying that this is not your pearl. No, I'm not saying you couldn't learn it. Yeah, certainly. But again, like I go back to like, well, what skills should you have? I there was a lot of benefit in my scrum master being able to do just basic scripting. Sure. Super basic, very basic. How to query an API, take results, spit them out. How to email. Through, through scripts. Like, very basic stuff. You can learn this in a day. You know what I mean? Trial and error, you can learn it in a day. You know, check your work in. Let other people debug it with you if you're having problems or whatever. But this, this is all the basics of, of programming. Could be very intimidating to someone who's never done it before. And I could see the barrier to entry for someone who's never done it before, certainly. However this is where, this is the conversation I wanted to get into. Which is a lot of people are out there, especially on the internet, lobbying that you don't need these skills, right? Or, or well, these skills kind of take you away from the cost rating on advanced facilitation or whatever. I just, I do not see it that way. I, I, again, I, most of the people hiring for these positions, scrum masters specifically we're not talking about agile coaches. Right. Especially the coaches that can position themselves up at the leadership level. That's different. That's a whole different game. And it requires, potentially, if we want to talk about that, we can touch on that here because that, I'll be much quicker to agree with you it doesn't really matter what your technical skills are at that point. It matters how well you present yourself and how, how good a facilitation and, and, and the other digging into problems and stuff like working with people, that kind of stuff. I agree. Scrum Mastery, on the other hand, all things being equal, again, even on paper, all things being equal. One, having this stuff already, versus one you have to put work into to train. You have to put some money into to train. Like, who's going to get their foot in the door first? There's no arguing with that. Especially assuming that both can express themselves eloquently at the interview. The person who has those skills could say... These are skills I have and here's how I've used them in the past, i. e. the interviewer is now thinking, okay, this person could apply those skills again, right, in the future too. So there's no arguing there. All I'm saying is the willingness. So you talked about how some people just say, well, that's, that's very technical. I feel like to a certain degree, to a certain degree, and it's a large, to a certain degree, Scrum Masters that are, From a non technical background. I think the barrier is largely self imposed. They, they convince themselves, this is hard. Scripting, I've never done that, that's, that's programming. Like, try it, right? And, and use something like, the language that should be used, maybe one or two, that really lets you in. They're more like English, almost. So, definitely use you know, use Python or something similar to get in, get your... interest growing, right? But if you just convince yourself, hey, that, that's technical. I don't do that. That's the wrong attitude. I just read a bunch of posts last night that were like, what does a scrum master do? Somebody was going up and down on, I think it was Reddit, . There was a thread where somebody was Pretty much adamantly saying well, a Scrum Master with only one team, basically, that's a part time job. Like, you're not gonna work more than 50 percent of of the hours of a normal job. Like, there's no way you could work more than 20 hours. Kind of hilarious to me but, but, a lot of people think that way. They do. You know, a lot of people think that way, and, and the question is well, what does a Scrum Master do with the rest of their day when they're not running the events? That, that, that's, that's what I would expect, that's the lowbrow thing that I would expect. Out of your typical troll on the internet. The lowest common denominator comment would be, What do you do all day outside of the 15 minutes? They could be doing what everyone else is doing. They could be testing they could be scripting They could be answering requests for searches in the database and stuff like that because maybe you don't have a ui You know, I mean to to help you do that They could be helping customer support with looking for things. They could be doing a million they could be doing active development It could be if you have a developer playing the role part time, they're doing active development with the rest of their time. That's right. That's a great point. So listen, what happens, we talk about Scrum Masters, right? Yeah. Okay, in Scrum Master. In Scrum Master. So somebody is playing the role of coordination, etc, right? And it's typically one of the team members, tester, developer. They have their regular job, so to speak. These people already have the skills. And you can see the conversation is way different there. Right. Somebody could mention something. Oh, yeah, I know how to do that. We have the raw data. We'll just stick that into power bi and we'll come up with a beautiful presentation. Like a scrum master who doesn't understand or doesn't even know potentially what power bi is. Yeah. That, that's the level we're talking about. Yeah. If those people who come in and say, I don't need to be technical. We use Power bi. What's that? They, I'm saying at least learn what that is. Yeah. And how is it used? Start there, but don't stop there. Mm-Hmm., that's, that's the beginning. And then say, oh, well how do I get this data in? What does this tool do for me? It visualizes things and it lets me deep dive. Yeah. How will that be useful? Well, maybe your leadership could use that. So then have a go at creating a Power BI dashboard, right? Actually try it out because there's no, there's no cost to try it out and learn that way. The nice thing here is chances are good that somebody on your team or another team nearby has the answer to the questions and roadblocks that you may run into. Because guaranteed those will be really simple to solve for most developers, so by all means, dive in, roll up your sleeves. Yeah When people say communication skill or facilitation skill, like that's a very broad topic for what I'm talking about, but, but here's, here's also what I'm talking about is, is there's another conversation that's kind of parallel to the one we're having now. And that conversation is. Is it possible to be an effective scrum master without much experience? Because if you ask the real hardened developers, , the Zealots, they'll tell you, scrum master is not a beginner position. It is a very advanced position. And we, we can kind of argue about whether that's, that's appropriate with the level of scrum master that we see you there's a ton of additional stuff that probably deserves its own podcast, right? But if you look at it from that, if that really is your perspective, the scrum master role is a very advanced role. I mean, you really should have understanding of the full development process. You should have been on a bunch of teams. You should have seen a bunch of ways where it was a poor operation and a bunch of ways where it was an excellent top tier, top shelf operation. And you should be able to coach people through, hey, this is the way the best team does it. Let's slowly work you through, we'll work through your problems to get you from , a poorly performing team to an excellent team and, and beyond and keep you there. I could reword this question to be a much, much more hard hitting question because the people that I want, if I'm hiring a scrum master, I'm here at Brian and Om's software development company. Brian's hiring the scrum masters and Om's hiring the product owners. I don't know why we split it up that way I want it. That's very weird. I don't know why we did that. I want scrum masters. Who are in the seen it all business. I want people who have I've been on 20 teams, people who think that there are commonalities that can be solved in 100 percent of instances. They've seen the worst of the worst, they've seen the best of the best. That's, that's who I want to hire. On my scrum teams. Well, given all things considered, definitely you want somebody who has the experience. Somebody who's come up through the school of hard knocks because they've seen different environments. They've seen different situations and either they've succeeded, struggled, or failed in those situations and learned from that. You definitely want that. I have an anecdote to share on this topic more on the domestic front. I needed to hire a painter to paint a few rooms in my house after I moved in. So I built a great paint. It was chalky and it was just kind of running right off the walls. So, yeah, and it was causing a lot of stain. So I looked around and I was trying to figure out who I should hire, right? I mean, I want a person who is... Going to do a great job. So, it came down to two people. One is a slightly junior person. Really hasn't done this kind of work. You know, he does small jobs. But he was cheap. Right? And the other person was experienced. But he wasn't cheap. And he had done all kinds of painting. Indoors, outdoors. ceilings, all kinds of murals. I mean, this guy didn't just do big roller painting, right? He had, he had skills that I could see in the, in the pictures he showed me. So I decided to hire him for the experience. And here's how I saw it pay off. In my bonus room, I have painted the, the walls where I'm going to have the home theater dark. And the other side of the walls is kind of like a, a Pastel gray color, right? But it's one big wall on the front side of it where the screen's gonna be. So I needed that wall to be painted in a way where the line was A, straight, between the two colors, and B, a color didn't bleed from one to the other because it looks shoddy. Well, the first was, I asked both of them, how would you do this? The first person said, I'd put a piece of tape there, I would do the roll of paint, and then I would move the tape to the other side and I would do it again. And I'm thinking, what are the chances of nailing that? The other guy says, I don't use tape. I eyeball it. And he did. I watched him do this. He took a paintbrush and he went like this, and it was a straight line. That's experience for you, but I paid for that, right? So, I mean, the corollary to this, this conversation, really, you get what you pay for, ultimately, but let's forget about the, the, the payment side. A person who has seen various situations in his past is always going to do a better job, right? Because they have that stuff that they can bring to the table. Somebody new, they're going to either struggle, they're going to make the wrong calls. Right? Or they will simply be laissez faire it, right? One of those three things will happen. So yeah, given the choice, you want the experience here, for sure. I want to make sure that I nail the takeaway of this story. Because I heard a different takeaway from this story. What I, the takeaway from this story is I can take a chance and hire a like a newly minted scrum master, as long as they're enthusiastic and they would have the willingness, willingness to learn. And I, the employer have the willingness to teach them new things. Like we, the relationship potentially has a good potential for success. Alternately, I'm willing to pay a scrum master , the medium bucks, like stealing that from the William podcast, pay, pay a scrum master, the medium bucks who's seen some things and potentially has a bunch of these different skill sets. Maybe at a generalist level. Sure. But the BA skill set, scripting skill set, QA skill set. So basically they can put hands on a lot of different things. But also they're wildly more expensive than you know, my, my newer person. So maybe it comes down to what you, you, you get what you pay for in this instance. That's absolutely true. I think you do get what you pay for. So just, just be aware of that. You can, there's a lot of people out there of all different skill sets. So what do you want? Right? Is keep that resume updated. Is that appropriate? That is appropriate. Yes. Well, this is, I mean we didn't go through every one of these categories, but we, sort of touched on most of them. We can, I mean, it's no, well, it's too late. It's too late. I'm done. You're done. You're done. There was some interesting takeaways in this conversation is like, well, what are you looking to pay for? What are you willing to shoulder on your team from an organization point of view? Yes. Right. But from a scrum master point of view, the person who's in the hot seat, I think there were a couple of takeaways there too. If you don't have the experience, you don't have the experience, right? You can't just buy that. So what do you do? Have your eyes and your brain open to learning. That's the biggest takeaway for me here. I would also expect the, the, the person who is most skilled in facilitation and the, the, the most people person on your team, I would expect to be the scrum master and I would expect to naturally be the most curious, you know what I mean? I was expecting to have that personality type. So maybe it really fits. And maybe, maybe the, the kind of what we fell into at the end of the podcast of like, well, if you know that your early career one year experience, right? Or whatever, six months experience, right? Or maybe you're only an intern or something like that. And you haven't been exposed to all these things and you're searching for jobs. You're trying to break through. You're trying to get your first job. Yes, you don't have these skill sets. So, yes, you will be outclassed by these other people who do have the same amount of facilitation skills, same amount of communication skills that you do, but also have this other technical skill set. The ability to compete now falls in line with your ability to convince the employer that They're willing to invest in you and that you're willing to turn that investment around and make it profitable for them., I do admit it's a tough sell. But you know, let's see. You can be done. It can, absolutely. I've seen it being done. It can be done. The term I use for that is malleability. You have to, you have to adopt a level of malleability. I don't know how to say that. And convince the interviewer that you are willing to change and draw some parallels in the past, no matter how little experience you have. I have done this in the past, I am willing to do this, this, and this in these situations, right? That's what's going to get you above the people that just have the experience but perhaps don't have the same level of malleability that any more, because they are jaded like me. That's right. Alright. This is an interesting topic uh like II The jaded side of the argument as well as I could have But that's all right. You can Like and subscribe hit us in the comments. That's right ring that bell. Let us know other topics that you're interested in and we'll be happy to Indulge that's true.