Keeping technical boundaries as a Scrum Master

What separates a solid Scrum Master from a great one? In this episode, Brian Milner sits down with veteran Scrum Master Brian Campbell to talk about the balance between being empathetic, staying grounded, and knowing when it’s time to move on.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner is joined by longtime Agile Mentors Community member and enterprise-level Scrum Master Brian Campbell to explore the core skills every Scrum Master needs, beyond the textbook answers.

Drawing from 13+ years of experience, Brian Campbell shares how flexibility, empathy, and situational awareness help Scrum Masters navigate real-world team dynamics, conflicting priorities, and tough leadership environments. Together, the Brians discuss how to support product owners without overstepping, when to gently push back with leadership, and how to foster effective teamwork even under pressure. They also dive into what it means to advocate for your team—especially during crunch time—and how to know when it’s time to walk away from an unhealthy engagement.

Whether you’re just starting out or deep into your Scrum career, this episode is packed with practical insight from someone who's been there.

References and resources mentioned in the show:

Brian Campbell
Rescue Your Daily Scrum videos
#113: Influence Without Authority with Christopher DiBella
#126: Mastering the Scrum Master Role with Gary K. Evans
The Daily Scrum Meeting - a detailed breakdown
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Brian Campbell is a seasoned Senior Scrum Master with over 13 years of experience helping enterprise teams in healthcare, insurance, and tech deliver real results with agile. He’s known for his calm leadership, strong facilitation skills, and a flexible, coaching-first approach that meets teams where they are.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back Agile Mentors. We are here for the Agile Mentors podcast. I'm here, Brian Milner, and I also have with me another Brian. I have Mr. Brian Campbell with me. Welcome in, Brian.

Brian Campbell (00:12)
Hi. Nice to be on the podcast.

Brian Milner (00:13)
⁓ I was, yeah, we're really happy to have you here. I always kind of joke with, with other Brian's and, and, Brian is one of the other ones I can joke with here about this and say, thank you very much for spelling your name correctly. Brian is, is, someone who's a member of our agile mentors community and he's, he's shared a lot of really great, advice and he's mentored people through there.

Brian Campbell (00:27)
I do know people too.

Brian Milner (00:39)
So we wanted to highlight that, but he's an enterprise level scrum master. He's been doing this for a while. He's got over 13 years experience as a scrum master and has had some really insightful comments in our and post in the Agile Mentors discussion forums. We're going to link to one in particular that's really interesting that hopefully everyone here will find interesting in the show notes. But we talked about what we would. kind of dive into here and seeing as Brian has all this experience as a scrum master, we wanted to focus on some scrum master issues. in particular, one particular quality that Brian brought up that he felt was really, really essential, and I agree with him, for a successful scrum master, and that's flexibility. So maybe we start there and just define that for everyone. When you talk about how important it is for a scrum master to be flexible, What does that mean to you, Brian?

Brian Campbell (01:33)
Well, there's three things. You've got to work with a product owner at their level. So you may have a brand new product owner who doesn't understand how to construct a story with acceptance criteria or a bug with steps to reproduce. Other times you have a product owner who's really, really on their game and very established. And then you're going to be more hands off and just providing a little bit of guardrails according to the way the company works. You're going to be flexible with the daily standup. I've had teams rebel against the idea that standup has to be run cookie cutter scrum. So you may find that they prefer to go person by person. And that's fine. You may find they prefer to go issue by issue. You may find that you do it a whole section at a time. Dev, QA. going down a column on a board just to try and work with the team the way they want to be worked with. But my goal as a Scrum Master is to make it efficient and effective. I'm not trying to keep them sitting on a call for the sake of being a Scrum Master. But get familiar with how each company does things. Don't try to radically improve things. Suggest incremental improvements where merited. So don't come in guns a-blazing trying to change everything in the environment. Come in, observe for a while, make a little course correction here and there. Suggest things if they're above your station that might allow you to allow the teams to work more effectively. So those are three ideas.

Brian Milner (03:02)
Yeah, that's awesome. I agree with you on those. think those are really important. There's kind of this, starting with the last thing that you brought up there. There's kind of an idea that I've heard people say before. I've always subscribed to this as well. Kind of the evolution versus revolution kind of approach to doing things that you're going to be served better by trying to incrementally in small little doses change things rather than big bang. let's all of a sudden, Monday morning, everyone's going to be doing Scrum. It doesn't really work very well if you try to drastically change things. I know that's one thing with Kanban I've always appreciated is Kanban talks about start with where you are. And I think that's a good approach for us as Scrum Masters as well, is kind of start with where the team is,

Brian Campbell (03:31)
Yeah. Well, I've also done Kanban implementations and where people are doing scrim and they want to do Kanban and developers think there isn't a lot of, you know, I'm just going to be wild, wild west and do what I want. But Kanban has its own structure and way of doing things that you need to get the team, its own set of ceremonies, et cetera, that you need to get the team familiar with.

Brian Milner (04:06)
Yeah. Yeah. And you mentioned earlier as well, like trying to be flexible as you work with your product owners. I agree there as well. Product owners, you know, come in all shapes and sizes as far and all kind of levels of experience. maybe you'll get lucky and you'll have one that's really experienced and doesn't really need a lot of help. But maybe you'll get one that's brand new, that's never done this before. In which case you have to have a lot of patience and a lot of time to coach and help them get up to speed with what's really going to be valuable. Brian Campbell (04:38) Yeah, they need different kinds of support. I think the new scrum master may, new scrum master, new product owner may require, let's read, let's start that one over again. I think they will require different levels of support. The.

Brian Milner (04:48)
Yeah. ⁓

Brian Campbell (04:51)
the new product owner needs to have have stronger agile guard rails in place. The biggest problem I have sometimes is there's a product owner that's very set in their waste. I had one product owner who decided that he was going to map out all the work for this quarter and tell a sign by developer and even story point the items. And I had to go to management and say, Hey, this guy's bad. We'll get into that later. You have a time to move on thing. This was one of my times to move on because management was not supportive and changing his viewpoint. ⁓

Brian Milner (05:30)
Yeah. Yeah, I mean, that's part of just being agile that you expect the kind of same attitude towards being flexible from the product owner that, hey, you know, I'm going to grow and learn. And maybe that starts with kind of a humility of just saying, I may not be right.

Brian Campbell (05:49)
Yeah. I like to form a trika between, well, actually four people. I like to get the product owner, the dev lead and the BA all coordinating at the same time. So the product owner is not writing these stories blind. They're getting feedback from the dev lead and the BA. is learning how to support the product owner. It's kind of like that whole idea with Three Amigos where you get the product owner, developer and QA together and you just try and get them to work on an individual story. This is more like at the team level.

Brian Milner (06:24)
Yeah, if you do that, just have to make sure you don't kill the invisible swordsman, right? ⁓ Little three amigos reference for the listeners. Yeah, I agree. And I'm kind of curious there because you mentioned business analysts, mentioned dev leads, and that's always a hot button issue as well as we think about working with our teams because there's not really strong guidance from Scrum on

Brian Campbell (06:29)
That's it.

Brian Milner (06:50)
those roles and how they might interact or play with the Scrum team, what have you seen work well with those kind of roles?

Brian Campbell (06:59)
Just like I am an advocate for proper Scrum, know, agile guardrails, dev leads are people who have an ear towards the product owner and an ear towards the team. And if they had three ears, their third ear would be towards best practices in the company. So they have a very difficult job to wear where they're wearing, to do where they're wearing multiple hats. In terms of a BA, I think they just need to learn how the product owner thinks.

Brian Milner (07:31)
Yeah, that's good point. mean, they're assisting, they're alongside the product owner. it's back kind of like your three amigos reference, right? mean, it's somebody who should anticipate and assist and yeah, that's what I've seen work well also. Well, I want to talk a little bit more about the developer side of things as well, because they're the majority of our team. And if they're not working well, then our Scrum team is not going to work well. And that's always a fine line, I think, too. So I'm curious what your thoughts are here. It's always a fine line with how technical do I need to be? And how do I help my developers become the best version of a team possible without crossing over into getting into their realm and trying to tell them how to do everything?

Brian Campbell (08:20)
Yeah, I had an interesting lesson with the latter. think one of my first gigs as a scrum master, I was in a room full of people and there was a systems architect with all the developers doing something on a whiteboard. And I said something and they went, you're here to observe. And it taught me that there were boundaries. And on the other hand, there is something you can and should do, which is Try to have enough familiarity with what the team's working on and the other teams involved in the project to where you can anticipate what's coming down the line. try to, if you're trying to anticipate that you're forming good connections with the other teams and their product owners, you're forming maybe even with their BAs, and you're trying to make sure that the dependencies are addressed before the team comes to the work would be a really good example of that. So what else did I, I wrote some notes here because we went over the questions. ⁓

Brian Milner (09:22)
Sure. Yeah, you brought dependencies. I agree, the dependencies are kind of a huge area for teams and they can be a team killer, they can be a productivity killer. I know there are people who are focused really, really huge amounts of attention on how do we reduce our dependencies and how can we make our team more independent. So I think you're right, that's a huge key to unlocking the team's speed and productivity is just, you know, how can we have as few dependencies outside our team as possible?

Brian Campbell (09:58)
Well, that's true, but at the same token, you're going to have, for instance, if you've got a systems team, you're going to have dependencies with them. Right now I'm working at a company where there's a team that does, they're moving off a legacy system, they're moving on to a new system. So they have to sync the data with the old system coming out of the system, going back into the system. And there's a team that specializes in that. There are teams that specialize in different aspects of the system. They all come back to the team that synchronizes stuff in and out of the system. So there going to be dependencies from time to time, but you have to have a good working relationship with both, with any of those teams. you know, the idea is you get ahead of when the need is so you don't disrupt that other team and their work.

Brian Milner (10:49)
Yeah, I agree. I don't think you can ever really truly get rid of every dependency that you have. I think that's kind of a fantasy, but you you can you can try to limit them. You can certainly try to eliminate the ones that you can and then then try to just realistically handle the ones that are remaining. Right. Yeah. That's a great point. So the other area I was kind of curious to talk to you about is is the area of working with with leaders, because that's always a huge

Brian Campbell (11:06)
Right. Right.

Brian Milner (11:17)
hot button issue for us as Scrum Masters. I know there's been lots of surveys and things that have been published in the past saying that that's one of the kind of determining factors of whether it's going to be a successful adoption of these agile values and principles or not is whether the leaders are behind it, on board, supportive. But you know. I'm sure you've had the same experience I have. There's degrees. I've never had 100%, but there's been times it's been more than others. What do think the Scrum Master's role is in then working with leadership?

Brian Campbell (11:54)
they're going to set a tone and you need to work within the tone and realize that especially if you're in a contract job, you're not going to effectively facilitate change at a VP level, for instance. You're going to have to understand their paradigm and work within it. think you can advocate for your team, but often you'll be advocating across multiple teams. see a pattern, again, goes back to understanding more than just your team. You may be advocating for a pattern you see across multiple teams. And then you come at it from a suggestion that would be in their best interests or in the interest, usually in the interest of getting the project done on time. But I've had good leaders, I've had bad leaders. I think about three or four years ago, I was working for a company where There was a very, very good VP in charge of development and all of a sudden he was replaced by a guy that turned the company into a meat grinder and he was very difficult to work for. Well, you I think, I think that's a, you're, just have to understand what the leader wants and try and, try and mold to their vision along with those agile guardrails.

Brian Milner (13:13)
Yeah, I agree. mean, I think what you're kind of saying there is really important to, especially in light of the topic here across everything we're talking about, being flexible, of just trying to understand that there are things that you're not going be able to change, right? Sometimes you're going to have leaders that are kind of set in a certain way of doing things and you know, they're not going to be open to having, intellectual conversation about, whether there's benefits to doing things a different way. And should we examine it? They're just going to want it done a certain way. And when that's the case, I think the word flexible is, is the right one there to say, look, I have to recognize what's within my control and what's, what's not. And if these things are not within my control, then

Brian Campbell (13:53)
Yeah.

Brian Milner (13:56)
Yeah, how do I find the best compromise that really gets closer to what it is we're trying to do here?

Brian Campbell (14:02)
I think one thing that's really important to remember about that is you have to have empathy for the pressure they're under. And that goes for senior leadership, that goes for your lead developer, your product owner, to a lesser extent your business analyst. I think they're all under different kinds of pressure and you have to empathize with them. I think one of the biggest things that a Scrum Master can do in their role is have empathy.

Brian Milner (14:30)
I agree. I think that's such a huge point. Not only from just trying to think about and feel what might be important on their end, to then also try to speak at a level with them that connects and resonates. Because if you understand what's important to them or what kind of pressures they're under, what kind of strains and what they're trying to accomplish as a result of that, then as you present some of these things, you can put it in a language that might be more impactful and resonate with what they're trying to accomplish. ⁓

Brian Campbell (15:04)
Yeah, you're going to be a more effective communicator if you speak in terms of what they want to do or need to do.

Brian Milner (15:11) "Yeah, it's a tricky thing and I agree. It's sort of like there's leaders within the company and then there's subtle ways we can spread and help to populate the organization with these ideals. So we have a role there as well as leaders to try to. try to help people understand why this is important and kind of the benefits they might see from it.

Brian Campbell (15:34)
Yeah, especially the team members.

Brian Milner (15:36)
Yeah. Well, I know another big area we talked about that we were talking about being flexible and, you know, important area to consider as a scrum master is kind of the whole dynamic of working on a team of teamwork. And there's a lot that comes along with that. I know one of the things we talked about was just kind of the whole concept of how you help your team with conflicts and how you help them to learn how to compromise on things. What kind of things have you seen, what kind of tips have you collected through your years on how to help your team through those sorts of issues?

Brian Campbell (16:16)
It's important to have an ear with a team to be able to hear when they're having a problem and try to connect them with the right person to solve the problem. You're not going to be the person that solves the problem majority of the time. You're going to be the person that facilitates the connection to get the problem solved. So it's another form of advocating with the team, but that's probably the best approach that I would recommend to people.

Brian Milner (16:46)
Yeah, that's such a hard thing to do. And you're absolutely right. It's just so hard to, you know, a lot of times we just want to fix things. You see a problem, you know a solution, you just want to fix it. And, you know, we can do that on occasion, but if that's what we're doing as a majority of our job, then we're not really, as you said, making those connections that would then enable it to happen. on an ongoing basis, not just a one-off.

Brian Campbell (17:18)
But it's important also to remember that sometimes a team will have a gripe and it's something that can't be changed. So you have to, especially in a retro, you kind of have to work with them to find the solution that works within the framework or the environment they're in. Both are important.

Brian Milner (17:35)
I've had some experience in this area as well. And I know this is one of the things I talk about in classes because it's kind of a personal thing to me with how I've worked with teams. I'm just curious, Brian, have you had some really hairy conflicts on your teams, some really kind of bad blood between different members of the team? And if so, how have you handled that?

Brian Campbell (18:04)
Um, I think my favorite example of that, I was working for a company. were rewriting all the systems, the main part of the business and everybody was under a lot of pressure. And at one point I got pulled into a meeting where, um, the, this was during the pandemic, so everybody was on zoom and I got pulled into a meeting where the product owner was at loggerheads with the lead developer. And my job became one of being a mediator to make sure both of them were heard, to make sure that they felt their points were valid, but then to guide them towards a place where they could work better together. And I like to think at the end of that conversation, it's a working relationship, but it was very touch and go. That was a very, very difficult project.

Brian Milner (18:59)
Yeah, that's such a great story because it's a tough thing. I know, we talk about empathy. I empathize with all the scrum masters out there that find themselves in those positions because I've been in that too. And I'll be the first to admit, I haven't always handled those situations so well. Sometimes I've left it up to them to try to resolve and have had bad consequences as a result. But I think your approach there, Brian, is absolutely the right one to take. It's not fun to dive into the middle of two other people's conflict. No one would do that naturally in life. It's just something we'd try to, you hey, that's their thing. I'm going to leave it up to them. But when we're talking about our team, I mean, we're kind of framing this part of this in the frame of teamwork. That's kind of the concern, I think, when those conflicts start to become really bad. Well, how is that going to affect the team? It may just be those two people, but it's not going to stay those two people. It's going to spread. It's going to get wider in the team. your approach of kind of just, hey, I'm going to roll up my sleeves. I'm going to get in the middle of this with you. And it may not be fun, but I'm not going to abandon you. I'm here with you, and we're going to find our way through this.

Brian Campbell (20:09)
It is really important that both sides feel they're heard and that both sides understand the merit of what the other side's saying from a third person.

Brian Milner (20:19)
Yeah. Such a great point. And isn't it amazing how sometimes that's really all it takes? Sometimes it just, people need to feel like they were heard. That they're not being, their point isn't glossed over. That we've really heard their concerns, we've processed it, it's been considered. And it's such a defeating feeling when you feel like that doesn't happen, when I'm not being heard. So you're absolutely right, I agree with that. One of the other things that we touched on and talked about in this section was the whole idea of navigating the thing that none of us wants to navigate. That's when we're in that crunch time mode for projects. I remember being told early on as a developer, hey, everyone works nights and weekends in crunch time because that's just part of the industry. You just have to be ready for it. How have you handled and helped the team navigate some kind of crunch time moments?

Brian Campbell (21:12)
Well, first of all, you leave with empathy. Uh, I remember going into a big project that I had a lot of experience with this kind of thing, but the team and I said, things are going to get really crazy and very disheveled. And I just want you to know I'm here to support you, but don't be surprised if you get a lot of curve balls turn along the way. And I remember the business analyst thinking I was absolutely crazy, but. especially with large enterprise projects, there's going to be crunch time. you're going to be the person who kind of soothes nerves a lot like that confrontation we talked about earlier. You're going to be the person who lends an empathetic ear but maintains agile guardrails to make sure a process is being dealt with correctly, but not being an agile Nazi either. I think those are all really good things. Again, you want to keep meetings efficient and minimize the team from being, minimize wasted time and also minimize distractions because the team's got to be heads down during those times. And you've got to be really proactive about forging connections and getting familiar enough with what they're doing that you can foresee when there's going to be an issue.

Brian Milner (22:35)
Yeah. Yeah, that's such a good point. Yeah, it's not a position you want to be in, but it does happen, even in agile projects. You do find from time to time when you just are kind caught in that crunch time moment. when that happens, I love your approach of being empathetic with the team also. But it's sort of. I was kind of thinking, well, how can I serve the team through this? know, like they're going through a tough time right now. It's not fun. How could I make it easier? You know, what's something I could do? Can I hop in there and do something that maybe grunt work that no one else wants to do, but it doesn't take a lot of brain power. It just is going to be time consuming. Can I? go buy lunch, can I bring coffee? Things that I wouldn't do on a normal basis, but they're in a unique position.

Brian Campbell (23:25)
⁓ Yeah, I've done those things. Although I had to say that there was one company I left shortly after this. But there were two teams of developers working on a project for three months. And of course, because they were not doing agile correctly, there was no feedback from the stakeholders during that period. So they dropped this project in the lap of the stakeholder. Stakeholder doesn't like it at all. teams given two weeks to correct the flaws. And unfortunately, there are a bunch of people on H1B visas. So if they don't like it, they can get on a boat and go home or a flight. And it's more modern nowadays. But I remember working two weeks, nights and weekends with them. And the only thing I was allowed to do was bring donuts in the morning. And it was

Brian Milner (24:20)
Ha

Brian Campbell (24:23)
extremely frustrating to have my hands tied like that as the Supreme Minister.

Brian Milner (24:27)
Yeah, yeah, it's, it's, it's bad too, when it becomes the expectation. Hey, where are the donuts today? you know, that kind of thing. you know, I think there's, there's a middle ground and there's somewhere to say, Hey, if things are tough, I can do that without it being the expectation. I can find ways to kind of make life better for them, to help us get through this. Yeah.

Brian Campbell (24:47)
yeah, you should always be advocating for the team. ⁓ Even when they're beat down, you should be saying, we're under a lot of stress right now. What can we do to make things easier on the teams that already having enough problems without us making it harder?

Brian Milner (24:51)
Yeah. Yeah. Yeah, well, I want to kind of get and bring us around a little bit full circle here because you referred to this earlier. And I think it's an important thing for us to talk about in this section as well. And that's kind of, there are times when it's time to move on. And maybe the best thing I can do for the organization, for the team is to move on. So. I guess the question then is how do you know that? How do you know when it's time to maybe pack up and find somewhere else?

Brian Campbell (25:41)
I think the example I just gave is a really good one where they were being asked to work insane hours. And I had been on prior projects with this company where one example they had given me, a team with five developers and no product owner. And I worked around that by having the team write the stories. I didn't even have BA. It was really, really difficult. And I ended up advocating for them when they didn't have enough testers. It was just a real nightmare. And then they put me on this other team that was given two weeks to do probably two months worth of work. At that point, I didn't like the way they were treating the teams. And I said, OK, it's time to move on. Luckily, the company that I moved on to was three floors above where I was working, so that made it really easy transition. There was the meat grinder mentality, when it went from being a good environment to a meat grinder, disposed company for meat grinders. And then there was another example where they wanted the scrimmasters to take on project management duties and I was already in this case. They had given me a 25 person team, which we broke into five teams and we had, we had kind of made it so that I taught the lead developers and all the schemes, to facilitate the daily scrum. And we all came together right after that for a scrum of scrums. And they wanted me to throw project manager duties on top of that. And that was like, I don't think that's a feasible thing for me to do so I kind of kind of stepped away from that job

Brian Milner (27:18)
Yeah. Yeah, I think there's moments like that where you just have to look at things and say, I know I've had moments where I've had to look and just say, I'm not going to be of any help. You know, with with kind of the things I do well, and the direction this organization is going in, I don't see how I can come alongside and really help them because they're headed the other direction. ⁓

Brian Campbell (27:41)
Yeah.

Brian Milner (27:42)
And if that's the case, I don't want to tell them, hey, the whole organization has to change and come around to my way of thought. That's not going to happen. Mike tells a story. Mike Cohn tells a story about even experiencing this as a trainer of going into different places and private companies hiring him to come and train and him experiencing things while training. that he just realizes, hey, no one's going to, nothing's, this isn't going to make an impact, right? Either the culture here is everyone has their laptops open and they're all doing their emails the entire class anyway, or, you know, they just say, well, we're not doing that. We're not going to be able to do it that way or something. And at a certain point, you just have to say, well, then I don't want to waste your time.

Brian Campbell (28:25)
Yeah.

Brian Milner (28:25)
I'm wasting your time and it's wasting my time and it's not helping anything.

Brian Campbell (28:31)
Yeah, I actually was at that same company that had, you know, no product owner on one team and developers working two months for their work in two weeks. They were doing scaled agile. So they had a scaled agile scrum master class where they invited a bunch of people from all over the company. And all they wanted to do was gripe about how they really didn't want to move to agile and how horrible it was and how they wanted to do things the way they've always done them. And the facilitator had lost control of the room and I had to, I had to subsequently go study to get my certification with them on my own because it was so incredibly off the rails. But yeah, I've been in environments like that.

Brian Milner (29:17)
Yeah. Well, this has been great. I really appreciate the topics here. And I appreciate your approach to this, Brian. I think that it shows your years of experience, just that especially the initial thought seems to always be one of, let me try to have empathy for the. the person in the other shoe and lead from that standpoint, right? Try to understand them at that level. So I appreciate you coming on and sharing this information. Any kind of key takeaways you'd leave everyone with here?

Brian Campbell (29:49)
You do want to leave with empathy, but you want to have firm guardrails, like I said. Sometimes they, particularly in crunch time, they want to bend the rules. ⁓ So that's one thought. But the other thought is support your product owner. They're already under enough pressure. Maybe it's as simple as

Brian Milner (29:59)
Yeah.

Brian Campbell (30:10)
making sure that the tags on the stories are correct or making sure that, I mean, if you're in person, making sure that you show up for meetings on time and that you corral the troops, you know, make it easy on the product owner because they're under usually quite a bit of pressure. And that's probably one of the bigger ones too.

Brian Milner (30:32)
Yeah, that's a great point. Well, Brian, thank you so much for your time. I appreciate you making time for this and coming on and sharing your wisdom with us and kind of helping us to see from a different perspective a little bit about what it's like to really be out there and working as a Scrum Master today. So thanks for your time, Ryan.

Brian Campbell (30:50)
Thanks, it's a pleasure being on the show.