Episode Description:
In today’s episode of the Agile Coaches’ Corner podcast, Dan Neumann is back with his co-host and colleague, Sam Falco. Today, they’re discussing whether or not a Scrum Master should be technical. Sam often finds himself being asked about this and has noticed many other people have a strong opinion for arguing either side of the coin. But, there’s more to it than just those two extremes.
In their discussion, Sam and Dan will walk listeners through the various possibilities besides technical or not technical, then provide advice on how to find the perfect balance between the two.
Key Takeaways:
- A technical Scrum Master: Benefits, challenges and advice:
- It can be beneficial to know the product and the knowledge domain that your team is working in, so you can help the team when they have an impediment or are struggling with something
- Knowing the domain also makes it easier to help the Product Owner understand good backlog management, communicate to the development team, and encourage refinement to happen
- With technical knowledge, you can call out your team if they are sandbagging
- The challenge of having a Scrum Master with a technical background is that there is a possibility they might want to get in and do it themselves (which is not their role as a full-time Scrum Master), which can damage a team’s ability to self-organize and innovate
- As a Scrum Master, if someone on the team approaches you and asks you how to solve it, your response shouldn’t be to directly solve it but instead ask, “What are you going to try?”
- A Scrum Master who has no technical knowledge: Benefits, challenges and advice:
- They can be helpful in removing impediments because they have some knowledge about how things work (which may help them with knowing who to go to when there’s a problem in a particular area)
- The danger in not having any technical knowledge (but having domain knowledge) is that they may step on the Product Owner’s toes
- A non-technical Scrum Master could be challenging the team where they shouldn’t be
- Another concern is if the Scrum Master only knows Scrum and they’re only concerned with the team getting value out of Scrum
- Sam’s Scrum Master tips:
- A valuable skill for a Scrum Master is knowing when the team is confused or misunderstanding things, and pausing to check and make sure that everyone is in the same place
- You have to be good at what you do, and you have to be doing it to serve the team; not making sure everyone does everything by the book (without understanding why)
- As a Scrum Master, you should be asking yourself, “What are we doing here?”, “Why are we doing this?”, “How can I help my team?”, and “How can I serve best?”
- Take some time to reflect on, “Is the Scrum Framework being applied well?”, “Is the team delivering value incrementally?”, and “Are the Scrum values present?”
- In conclusion, should a Scrum Master be technical or not?
- The question itself is a bad premise because it implies either “yes” or “no”
- The answer is “yes” and “no;” it depends
- If you’re a Scrum Master who feels your lack of technical knowledge is inhibiting your ability to serve your team, then it is okay to take some basic classes to understand the challenges your development team is facing
- If you’re a Scrum Master who is very technical, take some time to reflect on where your service is best applied and ask yourself if you’re relying too hard on your technical knowledge
Mentioned in this Episode
Sam Falco’s Book Pick
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro [00:03]: Welcome to Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann [00:16]: Welcome to this episode of the Agile Coaches’ Corner podcast. I’m Dan Neumann and joined by co-host Sam Falco.
Sam Falco [00:23]: Hey, how are you doing? Dan’s been along time.
Dan Neumann [00:25]: I am stuck at home. It was snowing this morning. Let’s see, we’re recording on April 15th tax day. Normally snowing and I dunno, it’s just a regular old poo storm right now. I guess.
Sam Falco [00:39]: I was in my pool yesterday.
Dan Neumann [00:42]: Yeah, well I’m glad I was up here in snow and not seeing that, but I digress. I’m just, I’m truly just jealous of the pool thing. Uh, so surviving at home, work from home then.
Sam Falco [01:03]: Yeah, it’s an interesting adjustment. Uh, my wife is also working from home. Fortunately we like each other, so that’s been good. It’s been great because we, you know, we have lunch together. Uh, we got in the pool at lunch and uh, and, and yeah, we just coordinate our meeting schedule. We have essentially a old daily Scrum. I have a meeting from 8:30 to 9. You have a meeting at 9:30 to 10. So, you know, be aware of when we’re going to be on each other’s camera or not.
Dan Neumann [01:34]: Oh yes. Apparently. Um, this, this thing about walking behind people’s cameras while they’re in the meeting is a thing. Yeah. I don’t understand it, but that’s okay. So for a topic standpoint, today, you had proposed, we explore should a Scrum Master be technical?
Sam Falco [01:52]: Right. Yeah. This came up, um, you know, Lean coffee, uh, virtual Lean coffee. I attended last week hosted by our very own Christy Erbeck. Uh, one of the participants asked this and I get asked this question quite a bit and I, it’s always interesting to me because I’ve seen some people with some seriously strong, violently strong reactions to either way, no Scrum Masters should never be technical, uh, or Scrum Master should always be technical. And I kind of wanted to talk, I think there’s more to it than those two extremes. And I kind of wanted to talk through the various options there.
Dan Neumann [02:27]: No, no, no. We need extremes so that we can fight about it and tweet things that make people angry.
Sam Falco [02:32]: Right. I mean, I started, yeah, I started my Scrum career as part of a dev team. I was the QA lead for my group. I am also serving as the Scrum Master, which of course meant I couldn’t fulfill all of the roles, all the responsibilities of the role of Scrum Master. I didn’t have time to do a lot of the organizational aspect of the Scrum Master role. But it was a benefit to me to know the product and know the knowledge domain we were working in intimately. It made it easy for me to help the team when they had an impediment. I was right there. I was in the code with them, so it made it very easy for me to know why they were struggling with something. If it was a situation where I needed to get involved.
Dan Neumann [03:24]: Yeah, it was. I was just thinking through that and the knowledge of the product is valuable for a Scrum Master. You know, one of the things the Scrum guide says they can do is fill in for the Product Owner when they’re not available to answer some of those product questions. And as a certified trainer, you’ll correct me if I’m wrong, I see furrowed eyebrows.
Sam Falco [03:44]: It’s less that they can fill in with the product. The Product Owner can delegate some of what they do to the development team. But the Scrum Master is responsible for helping the Product Owner understand how to order the backlog in the best way and backlog and backlog management techniques. So yeah, knowing the domain makes it easier, or at least I experienced that it was easier for me to help my Product Owner understand good backlog management.
Dan Neumann [04:13]: So I want to circle back on the furrowed eyebrows that nobody saw. Um, because I think in my memory I didn’t quite get the part of the Scrum guide I was looking for, but it was where it talks about ensuring the goals and the scope and the product domain are understood by everyone on the Scrum team as well as possible. And so, um, instead of going to the Product Owner with a question like, what’s what’s happening here in the product or maybe what was intended here, I view it as if the Scrum Master and the Product Owner, can I have a mind meld and can make sure that those parts are understood?
Sam Falco [04:44]: I didn’t say, yeah, I think what is meant there is, um, that’s the Scrum Master helps the Product Owner communicate these things to development team. Um, helps make sure that, you know, refinement happens or encouraged refinement to happen. Um, again, I’ve, I’ve been in the role of Scrum Master where I did know the product backlog very, very well. And so my Product Owner went on vacation. I could fill in that way. I don’t know that that is what that line means.
Dan Neumann [05:15]: Fair enough. We could, we can, we can and I don’t know that that’s what it means either. I’ll take a, I’ll take how you interpret it. Yes. Because I can do that. So, um, as, as a QA person then I’m considering yourself to be technical and I’m not disputing that. I’m just, I’ve met QA people who are not terribly technical, but you are a team member, a Scrum team member and filling the Scrum Master role with the technical bent to it.
Sam Falco [05:44]: Right. I was, I was QA team lead, but I, I did, I did code, I did do some work that we would now consider DevOps. Uh, so yeah, I was technical, I could get in and uh, I actually originally learned to code as a QA person before I got involved in Scrum as a self defense mechanism so that I could go read the developer’s code and help them. Uh, actually I say self defense mechanism, but really it was so I can, I could give better reports. Like here’s where I think you have a problem, but I think we’re, we’re getting off the subject now.
Dan Neumann [06:18]: Nice. Well let’s come back to it. So, um, I was a computer science major, I guess technically I still am a computer science major from back in the day. So I too had a technical background, wrote a lot of C plus plus back in the day. Um, somewhere around when web services became a thing, I got horribly confused by them and ended up coming down to project management path. They were, I think they were harder when I was a kid. Um, and, and so when I became a Scrum Master, I had no longer been practicing code, but I understood like a lot of the patterns and a lot of the approaches and some of the technical options that were still being employed even though I hadn’t written a useful line of code in a fairly long time at that point.
Sam Falco [06:59]: Right. And that’s another kind of a step on the continuum from Scrum Master is very technical, is a, is a developer or has recently been a developer. The next, you know, if you slide down in the direction of the other extreme, uh, where the Scrum Master has no technical knowledge, this is the next step. The Scrum Master who has some technical background maybe is not up to date on the latest stuff or is not up to date specifically on what the team is doing but does have that background, has that understanding. And I think that also can be valuable because again, you, you can understand where the team is struggling. Um, someone in the Lean coffee when we were talking about some, well you can also, you can call them, call them on it when they are, you know, sandbagging, I don’t see that very much. Um, I suppose it can happen, but I, I mean my teams, I just haven’t experienced that with my team.
Dan Neumann [07:58]: I don’t honestly, I sandbagging is a concern that gets raised a lot and I don’t really know that I’ve see it very often. I think it’s one of those things that, Oh, what if they sand bag? It’s, I usually estimates that are intentionally or not and I assume unintentionally too low are usually the biggest challenge sometimes gnarlier than people think.
Sam Falco [08:18]: Right. I think engineers, developers are motivated all by themselves and if they’re sandbagging, that’s not because they are lazy people. You’ve got some problems there. I think the, the idea that, uh, developers might sandbag it comes from old school workers are lazy and will not do work unless you force them to thinking, um, there’s a term for it. I can’t remember what it is right now.
Dan Neumann [08:44]: The Taylorism kind of approach.
Sam Falco [08:46]: Yeah. And I just don’t think in a knowledge domain, again, if you, if, if you have a development team that has that going on as a cultural phenomenon within the team, not just like an individual who’s burned out or whatever, then it has nothing to do with whether or not you are technical or not. But so anyway, I want to get away from that.
Dan Neumann [09:09]: Yeah. Alright. So we talked about a couple of maybe advantages of of Scrum Masters with that technical part. Maybe just touching on some of the things to be aware of some of the challenges that can come with that background.
Sam Falco [09:22]: Yes, there can be some pitfalls. So if you have a Scrum Master who has recently been in the code, like someone who was on the development team and is now the Scrum Master, whether they’re still part fulfilling a development team role or their full time Scrum Master, there’s that possibility that they’re going to want to get in and solve the problems themselves. There’s the danger of, Oh, I, I know how to do that. See me after the daily Scrum, I’ll tell you, which is not as a Scrum Master, not your role. Especially if you are a full time Scrum Master and not part of the development team.
Dan Neumann [09:54]: Yeah, I think so. If done in a way that isn’t helpful or isn’t helping the team self organize or isn’t is some other way working against the Scrum values, I can see that if you do have the information and it’s helpful and it’s an offer as opposed to a command, then that I think takes a different bent to it.
Sam Falco [10:14]: Yes. But even an offer can can damage self organizing. The Oh well you have a solution, let us know. And you have now not only maybe damage the ability to self organize, you’ve cut off some of their ability to innovate. You’ve sent them down a path. Um, so you know, I’m many, many years past my technical chops, so, um, I am not going to offer really any helpful solutions at this point. Um, but yeah, I think there’s a danger that you’re going to, you’re going to dig in and try to offer advice that is not necessarily the most helpful thing that the Scrum Master is supposed to remove impediments. But an impediment is not just that, someone on the team is stumped by something. An impediment is literally they cannot continue to work if this is not raised, you know we get a particular piece of equipment because procurement is slow or whatever. That’s an impediment. I don’t know how to do this particular coding task is not an impediment and if someone comes to the Scrum Master and says, I don’t know how to do this coding task, the Scrum Masters response should not be here’s how to do it, but well what are you going to try? Where could you go get that information?
Dan Neumann [11:27]: Yeah and I like what options come to mind cause sometimes it’s just like we were talking about the options are not have a technical Scrum Master or not technical Scrum Master. There’s at least a third option and there’s, in this case there’s probably many, many options.
Sam Falco [11:41]: Right. There’s a whole, like I said, it’s a continuum. Um, and then so going even farther in the direction of the Scrum Master who’s not technical. We’ve talked about the, the hyper-technical, you know, very involved, the uh, I have technical background but it’s a little rusty and then we get into, I don’t have really a technical background, but I do know something about the domain that we’re working in. And I think that is again helpful in removing impediments. If you are working in that domain, you’re going to have some knowledge about how things work that may help with who to go to when there’s a problem with a particular, you know, area of that. Again, I had worked for this particular company before we adopted Scrum for many years. I knew the product, I knew the domain really, really well. So it helped me help the Product Owner explain things to the development team because I knew that product domain, I knew, I understood the challenges our customers faced, not as well as the Product Owner did, but very well and could translate that sometimes for the dev team when they all looked at each other. And then looked at the Product Owner, what their heads cocked like confused beagles.
Dan Neumann [12:56]: Yeah. And that skill of as of a Scrum Master, noticing when the team appears to be confused or appears to be misunderstanding things and kind of pausing to check and make sure that we’re, we’re all in the same place. Maybe rephrasing what’s been heard or asking the team to kind of rephrase what their understanding is or restate it back. It can be super valuable.
Sam Falco [13:20]: Yeah. But then the danger of that, of not having the technical knowledge but having the domain knowledge is uh, again, if you know the domain very well, there’s the danger maybe of trying to step on the Product Owners toes. Um, and then not having the technical knowledge from the team says, well, we, we don’t no how to do that of maybe challenging them where you shouldn’t. You should say, okay, I believe my team, you know, this can’t be done. Rather than saying, Oh, well, I’m sure you can find a way. No, we can’t make Lightspeed barrier breaks. You know.
Dan Neumann [14:07]: I was on a conversation, we’ll just leave it. It was a conversation, it was fun. And somebody suggested watching the YouTube video about making seven red lines and we’ll include that in the show notes or people can Google it, but it’s hilarious. They want seven red lines, but could one of them be blue? And the seven red lines needed to be all perpendicular to each other and it goes on and on. From there on. Admittedly, I got a little bored of the shtick before it was done, but it was, it was fun. And now me and those team members have a common lexicon for, um, that kind of conversation. The, it can’t be done conversation, right? So domain knowledge can be helpful, but a couple of pitfalls then if they’re starting to second guess the, the Product Owner or step in inappropriately on the product backlog.
Sam Falco [14:54]: Right. Okay. And then finally, I think the, the extreme end again is the Scrum Master. That Scrum Master knows, Scrum does not know the product domain, does not know technical aspects of developing that product. Just knows Scrum and just is concerned that the team uses Scrum and gets a value out of it out of using it. Uh, I’ve been in that position as well. When I, when I left the company where I started Scrum, I went to, I went from being, you know, intimately knowledgeable about the product domain to a new company where I knew literally nothing about the product domain. And that was an enormous culture shock for me because now I had, I really had to justify my existence team by being really good at being a Scrum Master. Um, and so that was a different challenge for me. I couldn’t help them solve any problems and they were using technology that was far beyond what I was used to. So how do I fit in? I had to really dig into Scrum Mastery at that point. So I think the benefit there is that you really have to be good at what you do. You have to be doing and you have to be doing it to serve the team, not well, I’m, here’s a Scrum Master so I’m going to make sure that you have all the meetings and you do them by the book without knowing why. But what are we doing here? Why are we doing this? How can I help you? How can I, how can I serve best?
Dan Neumann [16:29]: What was that experience like for you as you were trying to then justify it, justify if you will, but kind of earn your, keep there by providing value in demonstrating that having a Scrum Master who’s a technical chops are in the background somewhere and who’s doing no, just very limited?
Sam Falco [16:45]: It was terrifying because I’d realized I actually wasn’t that good a Scrum Master did. It really exposed that weakness for me where I have so much to learn where I thought I knew what I was doing. Uh, the very first time someone said, well, why? What are, what does a successful daily Scrum supposed to look like? An eye open my mouth and absolutely nothing came out because there was absolutely nothing in my head except a word that would get this podcasts an explicitly label. So yeah, it was, it was terrifying, but it was instantly challenging. I realized, all right, I’m here to be a Scrum Master. I had better up my game and just dug in where I had never done so before as deeply and started learning. I think that was really the beginning of my flourishing as a Scrum Master and becoming an agile coach was that moment, that moment of realizing I have to do this and do it well.
Dan Neumann [17:59]: That’s interesting and maybe a bit of a challenge to, to folks listening who are filling the Scrum ‘Master role to maybe take a week and reflect as you’re going through that week, which elements of your day job are, you know, technician, which uh, which of those are, uh, actually Scrum Master or Mastering Scrum. Yeah. And doing it, um, not because you know, the domain or not because you’re a technician in the past or still are, but really focusing in on is the Scrum Framework being applied well, are we delivering value incrementally and in the values, are they, are they present? I think that could be in reflection.
Sam Falco [18:39]: Yeah, absolutely. I think maybe tracking what is the team coming to you with? What questions are they asking? And then is this a question about Scrum or is this a question about JIRA? Uh, I saw a tweet recently, someone said they had overheard, Oh, that’s not really so much agile as a JIRA-based developer oppression system. Well, you know, what questions are you being asked? Are you being asked technical questions? Are you being asked to manage the tool? And is that really what you need to be doing as a Scrum Master? Um, we had one of the trainer talk podcast was on the Scrum Master as scheduler and one of the dangers of just being the person who schedules meetings and then maybe is the administrative assistant for the team. Well, if that’s what you’re doing, up your game, what else, what other services can you offer? And that may be a time to actually step away. Don’t answer those questions. Your response should be again, what have you tried? What could you try.
Dan Neumann [19:50]: Thinking of the Scrum Master, being able to track how they were helping the team and what areas they’re digging into made me recall one of the folks that I had the pleasure of interacting with, he started off as an administrative assistant to one of the senior executives at a fairly big organization and had an interest in Scrum Master and agile coaching. And it turns out his night, uh, activities was in, um, he was a producer for a theater troupe. And so he was managing the actors and trying to get collaboration going and they had to deliver because they had to get on the stage and act at some point. And it was really interesting to see how much translation from that interest into working with a Scrum team as a Scrum Master. There was kind of the skills translated really well from this theater troupe into getting technicians to perform with each other and deliver and not a technical chop in his body at all but a wonderful Scrum Master.
Sam Falco [20:57]: Yeah. I think a theater troupe is actually a very, very close analog to a Scrum team. I you used to act a long time ago, um, your, your Product Owner is your director, has a vision for what they want to see presented as a product to the audience and you have a stage manager who is like a Scrum Master and then the team does do a certain amount or the troupe does a certain amount of uh, self-organizing. I remember there was one show I was doing a show called the Dining Room, which is a series of vignettes set in a dining room, not a particular dining room. It’s supposed to be abstract. Uh, and there was one scene where the, um, there was a young boy confronting his father about something. And um, the, the guy playing the young boy who was like five years my senior, but that was the way the show worked. We had this idea and just ran with it and one of the rehearsals and the director just dropped his jaw because it was something he’d never consider that these two characters might say to each other. And it became part of the, the show in much the same way that a development team will often come up with a solution that the Product Owner and Scrum Master never would have thought of. And then that becomes part of the product.
Dan Neumann [22:18]: That’s very cool. So the premise is should a Scrum Master be technical implies a yes and no answer, but I feel like we’re not there.
Sam Falco [22:27]: Well, because it, it implies a yes, no answer. But so many of the questions that buzz around the agile world are, it’s a bad premise. Yeah. You’re saying a yes or no? And the answer is yes and no. It depends, you know, the classic consultant answer. It depends. But you know, should a Scrum Master be technical. If you are a Scrum Master who has no technical background and you feel like it’s inhibiting your ability to serve your team, then by all means go take a class in something basic. Just a scripting language will give you some understanding of the challenges that uh, the development team is facing if it’s a, if it’s a programming sort of environment and Scrum is not restricted to just software development, but go, go take a class, go learn. Um, if you are a Scrum Master who is very technical, really take some time to reflect on where your service is best applied. And are you relying too hard on your, uh, technical knowledge or are you actually teaching Scrum? And, uh, one of the things that we teach in the professional Scrum Master class is that there is sort of a continuum of growth for a Scrum Master that you start by just teaching Scrum, teaching Scrum as it is intended, as it is written. And then, uh, you have to grow from there. Eventually a developer will ask you that question, Hey, what? What’s this supposed to look like? And you darn well better have an answer. I was very fortunate that developer, when I said, I, I don’t have an answer for you. I’m going to go get one. Can I, can I get one for you? And he said, yeah. And the next day I pulled him aside and said, here, does that satisfy you? And he said, Oh yeah, now I totally understand that. And he became like very enthusiastic about the daily Scrum where he had not been before. Once you’ve got the techniques teaching down, you’re going to be just looking at how to apply empirical theory to what you’re doing. Uh, what are some better metrics than just a velocity? Um, what are, how can you measure what the team’s doing? How can they measure what they’re doing and more to the point and use that to get better, um, start taking an interest in the valuable outcome rather than just activity. Which I mean, a lot of Scrum teams are just even a body of work to do. And it’s, again, if velocity becomes the metric and we’re not talking about outcomes, but as a Scrum Master, you can encourage the team to do that, to start living the values of Scrum and the principles behind the agile manifesto. And then at some point the Scrum team doesn’t need you as much and then you can expand your focus much more broadly outside of the Scrum team to help the organization in a much more, um, robust way. I mean, you should always be doing that right at the, even as a beginning Scrum Master, you should be pointing out where there are problems, especially impediments to the team’s progress that are organizational. But, you start from that understanding of Scrum. You maybe pick up some engineering practices enough to help the team consider some new options, perhaps. Uh, then you start looking at the processes beyond the development team, organizational processes that may or may not be technical, uh, and then really getting into the, the whole organization.
Dan Neumann [26:00]: So at this point, it’s probably appropriate to mention that you will be delivering a professional Scrum Master course coming up at the start of may.
Sam Falco [26:08]: That’s correct. May 6th and 7th. This will be a live virtual course. Um, I originally intended to be an in person course, but COVID-19 threw a wrench in our, in our plans. So we’re adjusting. Um, and yeah, that’s going to be an exciting opportunity to teach the professional Scrum Master curriculum in a new way. I’m really looking forward to it.
Dan Neumann [26:30]: And that’s what I like about the work that I’ve seen you doing around that. It’s not death by PowerPoint for two days remote. Um, it wouldn’t be that way in a class. In a class though, there is a screen that’s used and there are exercises that are used and in the remote class there’s a new mechanism for delivering the contents being used and very interactive.
Sam Falco [26:51]: Yeah, I mean the class itself is very interactive. It is built on the idea of exercise, then lecture, uh, let the, let the participants figure some stuff out for themselves or experience something for themselves. Then a little teaching and then you layer on, um, in a, in a virtual environment, it’s crucial to make sure that, that that is the way it works because people are going to check out if you’re just presenting PowerPoint slides. So yeah, we’ve, a lot of people at Scrum.org have done a lot of work, um, and just PSTs who aren’t directly, uh, employees of Scrum.org, it’s a lot of work to bring these things together. And I, I’m indebted to Ralph Yalcom who is, uh, uh, the author of the professional product owner. He did some work that was just fabulous and I’ve relied on it heavily too. Cause he also teaches the Scrum Master course. So it’s really gonna be exciting. I’m really looking forward too.
Dan Neumann [27:46]: Very cool. AgileThought.com/events is where people can go to and find that class and we’ll put it in the show notes and it’ll be wonderful. So we usually wrap up with what are you learning? Reading anything, continuous learning journey. So let me, let me pull on that thread with you.
Sam Falco [28:05]: Yeah. Well. Um, because of COVID-19, we are all overwhelmed and I am no different. Um, so I have had to kind of scale back some of my activities in that domain just because I need some more head space. I’m reading a lot of fiction. Uh, I have a new book. I’m going to start, um, tomorrow. By I’m going to plug her book that’s by a friend of mine, Louisa Luna. It is called the Janes and it is a sequel to her previous novel, uh, two girls down, which was riveting. So I’m really looking forward to reading that, but that doesn’t actually mean I’m not learning anything. Continuous learning, we say that phrase a lot and it implies that you’re always reading, always, you know, testing yourself and continuous learning can also mean taking some time to just allow, allow your, your mind to lie fallow, to synthesize what you’ve learned with other things to just collect. And so that’s what I’m doing right now. I’m not, you’re specifically reading anything new. I’m not specifically going after any particular domain knowledge. I am just letting my mindless self.
Dan Neumann [29:21]: Good. Yeah, no, it’s, there’s certainly enough, uh, demanding attention right now that it, it seems appropriate to let it all bake in. So no excuse needed. Wonderful. Thank you for taking the time to explore the question of should a Scrum Master be technical?
Sam Falco [29:39]: You’re welcome. It’s a pleasure to be on the show. It’s been too long. We’ll have to do it again soon.
Dan Neumann [29:43]: And hopefully people have noticed you, the Trainer Talk series, the short series of um, podcasts, kind of bonus content that gets released every Tuesday with very short answers that you get and other trainers get in other classes.
Sam Falco [29:58]: Yeah, I think, uh, what do we have Eric Landes coming up next?
Dan Neumann [30:02]: We do. He’ll be coming up very soon.
Sam Falco [30:04]: Well it depends on what jobs, I suppose. That’s right.
Dan Neumann [30:06]: Well we’ll get them again. We’ll make that true. People can go find. Yeah, find your episodes then go find Eric’s episodes. And until next time then ciao.
Sam Falco [30:15]: Ciao.
Outro [30:17]: This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
