Agile Mentors Podcast – Details, episodes & analysis

Join Brian and Scott Dunn as they unpack what “buy-in” actually means and what it takes to move from surface-level support to genuine commitment in this episode of the Agile Mentors Podcast.

Overview

In this episode of the Agile Mentors Podcast, Brian is joined once again by Scott Dunn to tackle a listener-chosen topic: how to get real buy-in for Agile initiatives, especially when shifting from a non-Scrum environment.

They explore why buy-in isn’t about enthusiastic cheerleading or deep Agile knowledge, but about leaders and teams aligning on desired outcomes. From the cost of performative support to the emotional side of change, Brian and Scott share practical strategies for securing support at all levels of the organization. Along the way, they dive into influence tactics, the importance of shared purpose, and how co-creation—not compliance—drives lasting change.

Whether you're guiding a large transformation or simply trying to influence up, this episode will help you rethink how to earn trust, build alignment, and inspire meaningful momentum.

References and resources mentioned in the show:

Scott Dunn
Elements of Agile Assessment
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 SVP of coaching and 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.

Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.

Auto-generated Transcript:

Brian Milner (00:01)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And I also have with me today someone that you probably know pretty well because he took over this podcast for about a month there. Mr. Scott Dunn is with us. Welcome in, Scott.

Scott Dunn (00:19)
Hey, thanks Brian. Yes, that podcast takeover was a lot of fun. So thank you for that opportunity. That was a hoot. Had a great time.

Brian Milner (00:25)
Absolutely. Well, I don't think I publicly thanked you for that. just ⁓ a public thanks.

Scott Dunn (00:28)
No, you didn't. No, not even an email. Not even a Slack message.

Brian Milner (00:33)
Well, very public thanks to you for doing that. Those episodes were great. I enjoyed them and it was fun to be a listener. It was fun to listen to it and just kind of hear the conversations and be a fly on the wall for those. So thanks again for doing that.

Scott Dunn (00:47)
Yeah. Yeah. It's a real treat.

Brian Milner (00:48)
We're having Scott on we kind of ran an experiment on this one because we were Scott was teaching a class for mountain goat and We thought maybe we'll just see what the class thinks so we pulled the class to see what topic do you want us to talk about and We thought we'd just go with the winner the winner that came out of that class was how to get buy-in How do you get buy-in in a? move from a non-scrum place to a Scrum kind of way of working. How do you get buy-in in the organization and buy-in from others? So when I was thinking about this as a topic, I think the first thing that popped in my head Scott about this was What do we mean by buy-in? So what does that mean to you?

Scott Dunn (01:33)
Right. So sometimes what I'm hearing is people saying like, buy in, you know, they, I would hear a common complaint, like they don't get it. They don't understand. don't, for me, buy in isn't that they need to understand agile or scrum and these types of things and how it works. Buy in is they get, they give their support kind of regardless. So my favorite example of that is walking into, this is a multi vendor effort we're doing on a Salesforce implementation. And we'd asked for the VP of the whole thing to come down and say some words before we had our first retrospective. You can imagine it's going to be kind of heated with different vendors trying to make each other look bad or whatever. And he'd said, yes. So we're coming down into this, you know, big high stakes meeting. And I just remember him saying, you know, I'm so excited to be doing this for you all. It's great. And he kind of falls in and looks at me says, what am I doing again? Cause he didn't, he didn't know, he didn't know what a retrospective was. He just knew he was asked to come and do something around that. And to me, Brian,

Brian Milner (02:21)
Ha

Scott Dunn (02:28)
That's fine. He's showing up. He's letting everyone know this way of working is important. It's important to me. It's important to success. And he probably couldn't tell you any of the meetings or artifacts or anything in scrum, right? But that's still what we need.

Brian Milner (02:39)
So. Yeah, I think that's a good way to think about it because I think a lot of people sometimes think of buy-in, like everyone's clapping and waving scrum flags around and all that stuff. And I don't think that's really buy-in. I think it's just the willingness to honestly try it, to give it a shot and be open about what would work and what doesn't work. The opposite of that is the resistance, know, of just being resistant to it and saying, I'm gonna put up hurdles and walls in the way of this being successful. That's, think, what needs to be avoided.

Scott Dunn (03:18)
Right, right. think that some of what was helped is to give them the, for me, the mindset of their buy-in isn't about doing things right. They're not saying, we're really wanted. We really want a new process. We were getting asked to come in because they're not getting the results they want. So buy-in for me from their perspective is how to help get the results that they're looking for. And they'll support us to get those results. So I don't talk to them about some of the aspects of an empirical process or any of that. I sort of say, you in order to get things faster or in order to improve quality, right? And that's how they get behind that. I think sometimes people are preaching some of the process part, even if they could understand that's not really what they're about. But I think they even struggle to understand what we're talking about. So yeah, it's hard for them to get behind and support us when they're not tracking. They simply know there's a pain point we're having. Can we talk about that and how to get what we need and what do you need from me to get that? Great. But I think we We can do ourselves a favor by helping point to the same target, make sure we're aligned with the same target they want. And maybe they'll give us more support if they feel like, yeah, you're tracking with me. I want to come in talk about, you know, more collaboration. Like we already have enough meetings. That's what, that's what I heard. Right. But I'll come and talk about faster time to market. Well, yeah, now they're interested in talking about what they need to do, you know, that I'm asking them to get behind that. I think that's fair.

Brian Milner (04:28)
Right. Yeah, I think there's also an element there, because I know we're both kind of fans of and users of kind of the path to agility framework from our friend David Hawks. And I love the part of that that's trying to establish the motivation, the purpose from the outset to try to say, What's the thing we hope to get out of this? And I think that's really crucial in getting buy-in that you can't just tell people, hey, we're gonna be a Scrum organization now. Why? Because I tell you that's what we're gonna do, because we're gonna check off the box and say that we're now Scrum. That's not motivating to anyone. if I can say, no, we're gonna... go through this change because here's the end result. Here's what we're trying to get to. Here's what we think will be better. If I can lay that out, then I've got a purpose behind it. And now I have motivation to go forward with this difficult change and learning what's expected of me and all that stuff. But if that's not done, I feel like that's a crucial misstep in that.

Scott Dunn (05:44)
Yeah, I wanted to add to that, that that point about the clarity of the goals is really something that has sticking power. And we had a client, I came and was working with him this year that he had remembered from the last year as the CTO. He's remembering from last year that we had done that same exercise or what are the goals that leadership has. And he remembered it was quality and customer satisfaction. That had been over a year since we had done that, but that not only stuck with him, but we came back to the group and kind of had a fun poll. Like, everyone remember? They remembered. And so every time we're having a decision we're trying to make about should it be this way or that way on the process, the different, were doing the race, the matrix work, et cetera, people kept coming back to, well, is that going to help us in terms of quality? Is that going to help us in terms of customer staff? We're not going into the nuts and bolts of Scrum or these other approaches. It's simply what's the business goal. will that help us hit the goal? And when the leader hears you using their language that they get, like that's my goal, they're feeling like, okay, whatever you need to do, sounds like you understand what I'm after, right? It's really powerful. But I like that you mentioned that, because when we go through that exercise, always super clear, we don't get confused. Times when we lead with, especially on the executives trying to lead with explaining Scrum, you can tell sometimes they're not really tracking or they're following along, okay, so what's the point?

Brian Milner (06:59)
Yeah.

Scott Dunn (06:59)
Yeah, you start off with what's their goals. They're like, great, this is exactly what I want to talk about. And then, Hey, you're not doing the things you need to do to hit those goals. Oh, okay. What are they? I mean, I remember one time a couple of years back, literally when the coach was presenting the results of that assessment towards their goals, they cut them off in the middle of his presentation. Just says, well, why, why is it, you why is that red? Why are we not hitting the goal? What do need to do? And they just started solving the problem right then he couldn't even finish his presentation. Talk about getting support. And he had been there six years saying,

Brian Milner (07:23)
Wow.

Scott Dunn (07:27)
Scott, they're not gonna buy into doing this transformation team and the scrum work. He couldn't even finish, I think, a couple of slides and they gave him everything he wanted, right? Powerful, powerful.

Brian Milner (07:36)
Yeah. Yeah. I think that's a good point. I also think one of the reasons that there's, you know, and that kind of parallels it. One of the reasons there's a lack of buy-in in general is that it's sort of targeted to just one area. You know, like this is a team thing. The teams are going to get trained, but the leaders have no idea really what's going on. They're kind of separated off from this. And I think that's a big part of the problem as well is you get buy-in when they see the leaders have bought in. So are the leaders bought in? Are the leaders on board with this? If they're not, then the rest of the group isn't going to be bought in either.

Scott Dunn (08:18)
People are smart. They're watching which way the wind's blowing. to be honest, Brian, I'd love to hear your thoughts. I tell people, I don't even care if they genuinely believe in that or not. If they're getting behind it because that's the way the politics are going, hey, they're getting out of the way. We're getting things done. Fine by me. Right. So partly when we're getting that by now, so make sure leaders, are you communicating this clearly? Because some of your people are either not on board or they're kind of waiting to see, this a fad or is this going to blow over? I need you to really communicate that clearly, et cetera, to see if people are get on board with that or not. Or, and on the other side, if I feel like some of these folks are not on board and I do feel like I have leadership support, I need to escalate that pretty quickly and make sure you understand, know, because they might get mad at you or me for talking about scrum and changing things. I'm like, I didn't knock down the door and come in myself. I was asked to come in here by someone who has authority. So maybe you need to clarify that with them, whether we're doing this or not. But don't get mad at me.

Brian Milner (09:04)
Right.

Scott Dunn (09:11)
So I will check them on that and clarify with the leadership to say, let's make sure your people are in alignment as well. If we do have that buy-in for sure.

Brian Milner (09:20)
Yeah. I saw another kind of quote about this that really got my brain working a little bit. Cause it was talking about the cost of fake buy-in and it was, it was kind of saying, you know, performative buy-in might actually, you know, it was asking the question, is performative buy-in worse than just outright resistance? And I don't know. Let me ask you that. What do you think? Do you think performative buy-in is worse than just someone who's resistant?

Scott Dunn (09:28)
Interesting. Yeah. As someone that just gave an example of performative buy-in. So if you would ask me a week ago, I might have gave a different answer, but someone was talking about this is a wildly different aspect of this, but you did ask me to join. So you get what you get. ⁓ They're talking about the difference of discrimination in the US versus South Africa. And they said, what's the difference? And they said in South Africa, it was blatant. no, you're a person of color. You cannot buy property here. That's how it is. Here, it's more like

Brian Milner (09:59)
You

Scott Dunn (10:14)
Yeah, we're looking at your loan application and I don't know if you can buy in this way. So it's subtle. And this person actually said, I'll take the outright blatant discrimination of South Africa, where at least you know what the issue is versus the subtle one. So maybe to that point with what you're saying, maybe it is better to have outright resistance and then say, well, at least I know who's on board or not. Rather than the person says they're on board, but every time they're in a meeting, they come out meeting and we don't get the decisions made we need. That's funny.

Brian Milner (10:39)
Yeah. Yeah. When I read this and started to think about it, I kind of had that same conclusion that like when someone's being outright resistant, yeah, it's an obstacle, but it's honest. And, you know, I'd rather have the honesty because they're trying to, they're still acting their way because they have a belief that their way is the right way to do it. And so they're throwing up a resistance because they're honestly resistant to it. Whereas someone who just sort of nods in meetings and claps along and, know, oh yeah, sure, great. But then they're kind of in the quiet, you know, behind the scenes and the hallway conversations. That's insidious. That's something that I can't really deal with. And it's like, you know, let's have the discussion. Let's talk about it. And, you know, if you win, then great. Why not have the courage to just have the conversation and see which idea wins?

Scott Dunn (11:39)
Right. on that note, think for everyone's sake, Brian, if we could be honest for a moment, not that we haven't been honest in these other podcasts, but in this, in this moment, we're really going to be honest. Would you, would, do you feel at times that our culture, our company cultures actually teach people to do just what you said to not be honest, but then like be like, you know, politically savvy, don't say what you really think, but then you're going to kind of be subversive and undermine that thing. And I've dealt with that so many times, I'll show up to a meeting like, I would have swore we were on board. had that one-on-one and now you're not saying in the meeting that you go on board with that. So people might've gotten coached. It's actually not safe to be honest and have good clear spirited debate because there's a price to pay if they do that. And they maybe 10 years in corporate can kind of teach you don't be honest or they're trying to read the tea leaves about what you think it's going to be. And so, yeah, I definitely would rather take it. Maybe it's part of the mindset of trying to really check, you know, where people are at. If I go back to my early days of coaching, those one-on-ones of having the level of honesty to really know where people are at. That was, think, some of the power. And I think some of that came from genuinely caring about the people, wanting them to succeed, wanting them win, even if it wasn't going to be at this company because of all the change or whatever. I did feel people felt like I really was open and honest with them and transparent and had their back. I would hear some real things about how they really felt because they didn't feel like there was a payback for that. And that allowed me to actually say, well, you know what, if you're really not on board, let's see what we can do as far as another opportunity. Maybe it's a positional switch we can do or whatever that was. Because I mean, this did affect people's jobs in some ways. And I think maybe if I don't have those one-on-ones, they're probably just going to give lip service because they don't know if anyone there really has their back in a turbulent time of change. AI is a great example of that, right? Hey, we want to move forward with AI. Well, what's the impact of my job if we do? But no one's really talking about that, right? It's all positive and all that. So I think people are trying to read that too. But you bring up a good point. I think I would take the direct as long as they feel like they can safely be open and honest.

Brian Milner (13:31)
Yeah. Yeah, well, even that question, right? What effect is AI gonna have on my job? And the honest answer I think that someone has to give right now is, don't know. I feel like I understand what it is today, but I don't know that that's gonna be the same way tomorrow because this technology changes so fast, so I can't promise anything. But here's what it is today and this is the paradigm we're trying to live in. So I think that there's an honesty component there that you've got a mirror to say, hey, I'm going to be honest with you. You be honest with me about this. And we'll be upfront with each other as we make our way through this. yeah, so yeah, think that kind of being honest and taking that approach, I think, is the right way to go. I also think that being kind of a reverting back before you get into things like, here's what a Scrum Master is, here's what a product owner is. You've got to start with the basics and mindset kind of culture things. You have to start with transparency, inspection, adaptation. That's really the way to go. And if we buy into those sorts of things initially, then we can start to say, well, here's a practice that supports that. Now you understand why we're doing this practice because it does this thing. Without it, it's just sort of one of those things of do as I tell you, you know, and that doesn't get buy-in. We've got to see the why behind it.

Scott Dunn (14:48)
Yes. Yeah, I think so. That's a great point. I was just making a note because sometimes we come in about agile. Some of the folks when I'm sharing this, it's maybe is new to them that I try to really present it. I want what you want. So even down to the words and then I kind of map back to that. So for example, if if we have quality problems now, I might believe in say an agile practice like mob programming, but I don't want to bring up like, hey, we should try mobbing. because it's cool or because you know, whatever, they don't care about that. But oh, they have a quality concern. Hey, boss, I've been thinking about, you know, these quality issues. I got an idea that I think it really could help with quality. But if I was to ask you, Brian, is is Bobby gonna, does Bobby help with quality? Does Bobby help me with, you know, cross training and tearing down knowledge silos and sharing learning? And I think, well, it does a lot of things, I pitch it towards what management wants. So agile as a means to an end. So I want what you want. And if I can't get that clarity that I want what you want, I need to be listening more because if I feel like I come to them talking, I've seen from my own experience, I come talking about better collaboration. That's not what's on their mind. I'm literally losing credit with them because they're like, why are you bringing this up? Like this isn't even our concern right now. Right. So I'm losing trust. I'm losing political capital. So I listen intently what their concerns are, the things I think that are important or that can get that. Then I'm going to pitch it. I'm going to pitch it in that language even like, you know, that what these are the things that would help on. I want what you want.

Brian Milner (16:00)
Yeah.

Scott Dunn (16:18)
the sport, I'll even research stuff to find out. So maybe I gave an example recently, when I was a manager for a web development, team that they wanted bigger monitors, of course, and I couldn't get approval for the bigger monitors. so I went and researched, I knew that always we had pressure to deliver more. I researched until I found somewhere someone had to study the show that larger monitors help productivity. And then I brought that to him and like, Hey, I'm looking for ways to improve the team productivity. I think I found something. What is it Scott?

Brian Milner (16:30)
Mm-hmm.

Scott Dunn (16:46)
Well, larger monitors, you can tell us, Smollick, really? You've been asking for this for months. I said, no, there's a study that proves it. Now he approved it right then. But partly I wonder, Brian, is I was also giving him air cover for when he gets flack from the other departments. Why does Scott's team get the special monitors? Well, it improves productivity. And right. He's got a reason now. Otherwise, it looks like maybe he's just playing favorites or something else. Right. We're all watching costs. So I will do the research to say, hey, I want what you want. I'll go and I'll go and dig it up.

Brian Milner (17:04)
Yeah.

Scott Dunn (17:13)
Someone somewhere must've said it's gonna help. So I'll bring that to them. It ⁓ worked.

Brian Milner (17:17)
Yeah. Yeah, I think you're right. you're giving him the why behind it. You're telling him, hey, here's something that's in. It's the old outcome argument that the outcome from having larger monitors is this, that we have this productivity. I know you want greater productivity, so here's a means to do that. And I think that's kind of the way that this, you in a nutshell, what we're trying to say here is, you know, I can't go into a company, your boss comes into your company tomorrow and says, hey everyone, we're switching to pens that write in green ink, because we're a green ink company. We just, we want to be known as the green ink company from now on, because it's better. So everyone, make sure you switch to green ink. I mean, they do it. But there's a difference between compliance and real commitment. ⁓ And that's the difference, I think, is, all right, you wanted to switch to green ink, but why? What's the point behind it? I'll do it, but I'll be committed to it if you tell me, well, studies show that when people read in green ink. I mean, that kind of thing can make an impact. But otherwise, it's like you're

Scott Dunn (18:08)
Yes. ⁓ Absolutely.

Brian Milner (18:31)
It's almost like an insult to the intelligence of someone, you know, to say, we're going to do this crazy new thing called a standup, you know, or daily scrum or whatever. And well, why are we doing that? I don't know. Cause right. That they tell us that's what we're supposed to do. Well, we have to stand up for a meeting. Why are we standing up? Why aren't we just sitting down? It's more comfortable. I don't know, but that's what you do in a daily scrum is you stand up. Right. I mean, it's, it's, it's that kind of a thing that I think.

Scott Dunn (18:34)
yeah. Yeah. I don't know.

Brian Milner (18:58)
if you don't lay the groundwork of here's why, then they're gonna just react with the way that you would switch to green ink. ⁓ Scott Dunn (19:05) I love that example. love that. And we've all been there, right? When someone says, why would we do this? I'm like, I actually don't know. It's a terrible feeling. I don't know. We go through all this effort to do just that. And you mentioned that compliance, compliance will never have their heart and soul and energy into this. So think that that's a big deal for them as well. When leaders are, we had something happen where it's a large financial institution and their data engineering group.

Brian Milner (19:11)
You're right. Yeah.

Scott Dunn (19:33)
You're like, yeah, AI is not really, you know, for us, not important to us. Which is interesting, right? Then the next week, like that, the head of that group, their boss's boss says, we need to be using, AI. Well, guess who makes it announced at the very next week. We need to get going with AI, So some of this is like, look, if they're pushing those things, we also want to make sure that they're in a position to look good for their bosses, those types of things. Right? So one, you know, giving them air cover, but two, listen to the winds of those things. If we make them successful, I mean, this is old school, right? Make your boss look good. My goodness. If they feel like that's happening, then you're going to get a lot more support. And this is a good example of a radical change for a whole data engineering team, just because the boss's boss says so. So now we're going to do it. I think looking for even those opportunities and following through on what that might be bringing them ideas that make them look good and generating that as well. I love the green ink one. just now it makes me want to be that we're the green ink company. You're we're going to be known for this.

Brian Milner (20:23)
Yeah.

Scott Dunn (20:29)
⁓ But why?

Brian Milner (20:30)
Yeah. I think it's also kind of important that you acknowledge that there is an emotional impact here. And this gets into kind of the idea of the whole Satir model of change and that kind of thing. And so I think maybe part of the equation of getting buy-in is really comprehending and understanding that you're not going to get buy-in right away. ⁓

Scott Dunn (20:56)
Hmm.

Brian Milner (20:57)
you know, there's going to be chaos and resistance. There's going to be a point where people are going to be resistant to it. And if you do the rest of it well, then that they'll turn that corner. But what makes them turn that corner is, is that they're connected to the purpose behind it. And so if you're, if you're going to try to implement this, if you're to try to do a change, and just expect it's gonna be, know, hunky dory from day one, you're fooling yourself. Humans don't take to change well. It's got an emotional aspect to it. I love the way David Hawks used to always say this. You know, I knew how to be a hero the old way, and I have no idea how to be a hero in this new thing. So I don't feel comfortable with this change because I don't know how to win.

Scott Dunn (21:41)
So true.

Brian Milner (21:47)
And I think that is a really accurate reflection of that emotional kind of impact of it. Everyone wants to do their job well and be seen as a smart person at work and everything else. And I knew how to do that before, but now I don't know how. And so I'm afraid I'm gonna look bad.

Scott Dunn (22:02)
Right? And I think that lack of awareness or knowledge is some of the things that we're asking them to do. Like you said, uncomfortable or new doesn't feel good. And we kind of think that, oh, if I don't feel good, this must be bad. It's just uncomfortable. But I think I love what you're saying. We can map it out and say, by the way, it's going to look like this as we go through that. And that hero part, a lot of our management, like 90 % of the management is going to be in that, you what we call expert or achiever. Like they're the smartest ones in the room, or they're ones that coordinate everything and they know who to talk to. you're trying to introduce something to someone who thinks they already know all the things. So how we're presenting that to them, including the fact that they're human too, right? They're gonna feel some things and maybe uncomfortable. It wouldn't hurt to explain a bit more, even if they're not gonna necessarily admit it, but like, hey, it's gonna feel different. The people might push back on this. So even when you're first beginning that, it reminded me of how I just knew I'd need to ask my boss like five times. Look, lots of people are asking him for stuff. They're partly just going by the simplest way of Who keeps coming to my office the most? And maybe on time five, like, wow, Scott, this sounds like a problem. Well, yeah, I've been here five times. Because they're kind of waiting, like, is it really a problem or do you just come in once or twice? So repeating that and then maybe framing it to say, and doing the change looks like this and that, giving them information so they don't have to admit that they don't know if they're priding themselves on knowing all the things. I really think that's a great addition to that. The Satir change model, knowing that it's going to get uncomfortable. I've seen execs jettison this just because people are bothered or upset or they're uncomfortable. So therefore this must be a bad idea. So I think we can do ourselves a favor by explaining a little bit like it's going to look like this moving forward as far as their support. Some people may not like it and here's why, but here's how I would answer those people. Like you're literally feeding them the responses. And I'll also do the get behind the expert and say, well, this is, this is what Harvard business review says, or this is what this expert says. You might be surprised because Again, back to them being experts, if you ask them what they think they know about Agile, I might have mentioned before, they score themselves on average about 8.5 out of 10. But their people would score them about 4.5 out of 10, right? It was what I've seen when I did the study, the surveys. So they think they know, so they're not gonna admit they don't know, but go ahead and give them the information they wish. If you know they don't know, I like what you're saying, kind of shrink the chain so they can understand, it's gonna look like this and feel like this. People might ask this way. But here's how I'd respond to them. know, remember this is where, you know, 90 % of the companies are doing X, Y, and Z. So they have backing. They can answer to the people. We kind of set them up for success. Otherwise that satiric change curve is going to hit them. They won't have answers. That feels really awkward. This must be a bad idea. And they're going to undo what you just asked for. Right. I've seen that happen. You just got approval and then a week or two later it got put on hold or undone.

Brian Milner (24:44)
Yeah, no, I agree. one of the areas, one of the other kind of things that I found in thinking about this in advance was a quote that was from the five dysfunctions of a team book that we all talk about quite a bit. But there's a quote from that that says, people don't weigh in, they won't buy in. And I love that. And I thought, you know, that really is a good point that there, it's not about

Scott Dunn (25:00)
Woo!

Brian Milner (25:08)
people need to feel like they're co-creating with you. And to do that, you need to be able to listen to them. If they don't feel like they have a voice, mean, put yourself in their shoes. If you felt like there was a big change happening and you had no say in it, that would feel pretty oppressive. But if they felt like they're building the change with you, then I think then that's what kind of can turn people around and say, no, I have a say in this, I'm a part of this. and I get to shape a little bit about what this is going to look like. They're going to shape it a lot. I mean, that's part of just the Azure way of working is that, hey, we're going to individualize this for this company, for this team. It has to fit here. And the more we can help people see, no, you're a co-creator in this. You're not just being told, but you're going to shape this with us.

Scott Dunn (25:54)
Right? Even with the leadership, I mean, it's easy. think everyone listening would agree. If you look at the common leaders, that's, even the, let's say director level and above personality types, right? For, for disc, it's going to be a high D for a strange pattern would be like command, um, computing values framework. They're going to be blue, get results, make it happen. But we need it to be, we need to be their decision for some of these folks. So when I would come to one of my bosses and say, I think we should do X every time he'd say like, yeah, let me think about. I'll get back to you. I kept thinking like, I don't understand because these are my people. I thought you trusted me. I realized, it has to be his decision. So part of what you're saying is invite him into the solution. So then I'd say, hey, we've got three options, good, better, best. What do you think we should do? Or I'd say, hey, I've done all the research, option A looks great, option B looks terrible. What do you think we should do? I mean, I try to simplify it. I tried to make it obvious, but I couldn't tell him I need to do X or we need this from you. It needed to be his input and to decide.

Brian Milner (26:44)
Right.

Scott Dunn (26:51)
once I framed it that way, he agreed every single time. I simply frame it, put it right in front of him so it's kind of an obvious decision, but I had to let him have that voice to decide. I'm really glad you brought that up. That one literally went from zero to 100 % if I changed my approach of how I had addressed it to let him be the one to decide and weigh in on that. Or even pitch it as a sales. Hey, I think it'd be great to move forward. What would that look like to you? Well, now he's talking about moving that change forward. without even realizing it, because you said to move forward, what would we need to do? And now he is co-creating, but it's already a yes, right? But by default, a little bit of sales, a little bit of sales effort there.

Brian Milner (27:24)
Yeah. Yeah, no, that's a, that's a good example. And that's a good example, I think for like the scrum masters listening and other people out here that are, feel like, you know, I'm not the leader in the organization. I'm not way up here and I can't, you know, have my decisions trickle down to other people, but, you know, kind of the, influencing up kind of mentality there. Yeah. It might sound like a little bit of a trick, but you know, if you can help. the boss co-create with you, right? Here's the problem. I've done some research. Here's some solutions. How would this look for you? Or what do you think of these options? Which one do you think sounds best? If I'm a boss and someone comes to me and says that I've researched this, here's the solutions that are possible. Which one do you think sounds best? That's really a service to me because you've just done a lot of work for me and I know that I'm doing my job by making the decision, but you've presented it and now I don't have to do anything but make the call. Yeah.

Scott Dunn (28:24)
Yeah, yeah. Simplify the decision-making or frame the decision-making is, think we might actually be kind of, I don't want to say teasing. I just hear some feedback from people at times like, leadership's was like, bright, shiny squirrel, right? And they get frustrated. But in some ways I'm thinking, well, at least someone in the org is decisive. I'll take that. But we can help them leverage that decisive trait they have.

Brian Milner (28:43)
Yeah.

Scott Dunn (28:48)
But for the good, instead of these random crazy things, you know, when the leader's like, I love Agile, I can change my mind all the time. We can, we can, we can guide them to better decision-making too. I love the influence both up and down what you're saying the Scrum Master can do. I think we miss, that we all have that ability to try to influence decision-making and shape some of this. Maybe there's more agency than we realized, I think for some of these folks, Scrum Masters, product owners, cetera, that you might be surprised. Like run an experiment, try some of these things out that we're talking about and see for yourself. I mean, all these personality types are different and your orgs are different. I totally understand that. Do something, inspect and adapt and see what you get. might, cause once you strike gold, you're like, you know, you're set on getting influence and buy-in from folks. It's really powerful network. Cause we don't need to give you a title or change the org chart in order to have results happen with you involved if you're that kind of a person. And I think you can really write your ticket in your career if you're able to do that soft skill of influence and buy-in up and down. It's great.

Brian Milner (29:43)
Yeah, yeah, that's awesome. Well, I hope that for at least the people that were in your class, this is is hit it right on the nail on the head for what it is they were they were thinking this would be about. But I think this is good. I think this is a good conversation and it's important, I think at all levels, because there's you know, this this affects us whether we're doing a massive transformation in an organization or

Scott Dunn (29:51)
Yeah.

Brian Milner (30:06)
We're just trying to influence up a tiny bit, you know, the food chain.

Scott Dunn (30:10)
Yeah, absolutely. Yeah, I hope that for the folks who were in that class, you better let us know if that was it. If anyone else is interested in other things, absolutely. We love hearing what your what those topics would be and bring on the right people. I will say that Brian, you brought in so many different voices. It's really, really great. So again, influence us. You can practice what we're talking about by putting those ideas up there. Other folks that we'd love to hear, because I love the the slated speakers you brought in. Brian's been really awesome. Thanks for this opportunity.

Brian Milner (30:34)
Thank you. Yeah, absolutely. Thanks for coming on again, Scott.

Join Brian and Mike Cohn as they unpack the five essential pillars that take Agile from “just the motions” to meaningful, measurable impact. Plus, get a behind-the-scenes look at their revamped course built for real team transformation.

Overview

In this episode of the Agile Mentors Podcast, Brian is joined by longtime collaborator and Agile thought leader Mike Cohn for a deep dive into what really makes Agile stick.

They explore the five foundational pillars—mindset, practices, roles, teamwork, and support beyond the team—and share stories of what happens when teams get them wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles.

Whether you're new to Agile or knee-deep in transformation, this episode will help you rethink how to build an Agile approach that actually works.

References and resources mentioned in the show:

Mike Cohn
#80: From Struggling to Success: Reviving Agile Teams with Mike Cohn
Scrum Team Roles and Responsibilities
Working on a Scrum Team Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
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 SVP of coaching and 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.

Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors podcast. Thanks for joining us. I'm with you, as always, Brian Milner. And today, I have the one and only Mike Cohn back with us. Welcome in, Mike.

Mike (00:12)
Thanks, Brian. Good to be here.

Brian Milner (00:14)
Always happy to have Mike on the show and really appreciate Mike making time to come on. Wanted to have Mike on because there's some things Mike's been talking about recently that are really interesting and people have been asking a little bit about this and I thought maybe it'd be just a good opportunity to talk through some of the stuff that Mike's been writing about. I know you spent, Mike, a lot of time helping teams to not just do Agile but to really get solid results from it. to see impact from it. And I know the topic you've been talking about recently is sort of these five pillars of supporting real agile improvements, the mindset, practices, roles, teamwork, and support beyond the team. So I thought maybe we could just dig in and drive through those and maybe learn a little bit about those as we go. Obviously also to talk a little bit about the exciting new course that's being launched here, the working on a Scrum team course, because I know that was originally just for private classes, right? And now it's being open to the public.

Mike (01:23)
Yeah, we've done working on a Scrum team as a private class for probably 20 plus years. It's been kind of our main offering to private clients. But we're hearing from a lot of people that they have one team and they can't really get a private class approved with the budget and such. So what we're doing is going ahead and making that course available as a public course. So two people from your company, five people from another company all in the same class the way we've done our certified courses for decades. And so we're going to start offering this as a public course. And the exciting thing there is that it's really meant to be a team-based class, where things like Scrum Master training, great class, but it's really meant for the Scrum Master, right? And working on a Scrum team is really designed, and you and I helped you and I design this course together, but it's designed to be something that is a whole team training, right? So good for anybody on a team.

Brian Milner (02:16)
Yeah, yeah, it's been really great teaching those in the private classes and I'm excited to think about the public being able to come in and take that now. Let's talk a little bit about these pillars and, I think people are gonna be really intrigued by the concept here. The first one is mindset, I think, and just wanna start there and say, what does it actually mean to... think Agile and what is the found, why is that kind of the foundation for successful transformations?

Mike (02:43)
Remember the kind of the early days of agile and there was a lot of conversation about could you be agile without understanding the principles, right? If you just did the practices, were you agile? Other people were saying, no, you have to start with the principles, right? And so do you start with principles? Do you start with practices? And I remember these early debates and they often devolved into a discussion of the karate kid movie, right? Remember that one, right? And, you know, can you just wax on?

Brian Milner (03:12)
Ha

Mike (03:12)
for long enough, just do the practices. And then all of a sudden, your karate instructor or your agile coach is, OK, you're agile. And it's like, wait, all I know how to do is wax a car, right? And so there were these discussions about practices versus principles. And I was kind of always on the side where you better understand the principles to do this. Just knowing the practices, waxing on all day, is kind of just going through the motions. And so you have to understand the principles. And the idea that I wanted was that if a team truly understood all of the principles underneath Agile, I don't just mean just the manifesto, but all the principles that are there from Lean, from Kanban, from everything, that if you really understood those, you'd kind of invent the practices, right? You do those and you go eventually to go, hey, we should probably meet every day. Or hey, if we tested first, that might be a really good thing.

Brian Milner (03:57)
Yeah.

Mike (04:05)
So you'd invent the practices if you really had that type of agile mindset. And so for me, when we're working with organizations to get them truly agile, and I don't mean like more agile than less agile, but agile in a way that's going to stick, you got to change mindsets, right? You've got to do more than just the wax on. So people have to get the mindset.

Brian Milner (04:27)
Yeah, I love that. I know that I've experienced some things in the course of working with people that's it's sort of like you, if you're not on the same page with the principles, then you start to talk through the practices and you run up against a problem. And really what you find out the core of it was, well, we weren't aligned on really the principle behind this. So why would I want the practices then, right? ⁓

Mike (04:49)
Yeah. Well, that's where you also end up then with a lot of team debates about things, right? Because you're arguing about the practice. if you'll say you and I are arguing about the benefit of some practice, if we agree on the principle, we might just have different views on it. But deep down, we'll probably agree on some practice, or we might find an alternative one. But if you don't agree on the principles, you end up with a lot more of these kind of annoying. mean, team debates are great. I mean, I love.

Brian Milner (04:54)
Yeah.

Mike (05:12)
you know, having a team debate, arguing stuff like that, but not about pointless things, right? And not without some sort of foundation. They just kind of get in the way. It's just frustrating for everybody.

Brian Milner (05:21)
Yeah. Well, I'm kind of curious, what kind of signs or signals do you think teams should look out for to kind of clue in and let them know that what might actually be going on here is more of a mindset issue?

Mike (05:36)
think sometimes it's when you hear the appeal to authority, right? Somebody says, you know, well, we got to do it this way because the scrum guide says, right? Or the one that annoys me is we have to do it this way because Mike Cohn says, ⁓ you know, that was like, no, I, somewhere else also said, think, right? Don't just, you know, don't just, you know, blindly do story points or something. Cause I say they're a good thing. I want you to think too.

Brian Milner (05:50)
You You

Mike (06:01)
And so I think that kind of appeal to authority when teams are debating things. It's where we also see teams who think they're agile because they do a set of practices. We use a particular agile tool, so we must be agile. We do daily meetings. We must be agile. And those are not the things that make you agile. Those are artifacts of being agile. If you're agile, you're going to meet a lot. You're not going meet a lot, but you're going to talk a lot. Um, and so those are the artifacts of behaving in an agile way. And so I want to understand why we're doing those things. So I look for those kind of appeals to authority. Um, you know, emphasis on that type of stuff in an argument talking about how this is the right way saying there's only one right way to do something.

Brian Milner (06:49)
Yeah, yeah, that's great. How does working on the Scrum team deal with this? How does that address it?

Mike (06:55)
Well, one of the things we do, it was actually one of my favorite exercises. We do this exercise at the start of the class where we ask people to kind of map out how the organization talks about certain adsel principles and then how does the organization behave. And so for example, if a company says, people are our greatest asset, and then they treat people like dirt, we've got this kind of problem between what we say and what we do. And so I like to kind of map this out. And so we do this with the principles in the Agile Manifesto. And once we map those out and we start to see things that we say we value, but we don't behave that way, really helps us understand if we've really embraced that mindset. Or are we just doing things because an Agile coach told us to, or a boss told us to, or we did it that way in our prior company. Those are all bad reasons to do something.

Brian Milner (07:48) Y
eah. So this is great. So I agree. The mindset's really foundational. And there is this symbiotic relationship between mindset and practices, which came first and which comes first, as we talked about. I know a lot of teams get stuck doing Agile, though, in really only name only. So when we talk about practices, what makes the difference between going through the motions?

Mike (08:00)
Mm-hmm.

Brian Milner (08:11)
and actually doing things that work.

Mike (08:13)
Well, practices is kind of our second pillar, right? You have to have the mindset, right? But you also have to have the practices that come from having that mindset. so, again, I try to think of that team on a desert island, right? And they're isolated from the world. They've never talked to anybody, but they have an agile mindset. What practices are they going to invent, right? And I think those are kind of the core practices. We see a lot of problems with as an example, teams that misunderstand sprint planning. And I know when I first started teaching about sprint planning, I'd have a slide up there to have a picture of a sprint backlog. And the sprint backlog listed tasks like code this, design this, test this. And then there were estimates next to code this. It's going to take four hours testing. It's going to take three. And so we were able see all these numbers and think the point of a sprint planning was these numbers. And Even in the early days of this, I was always saying, no, it's not about those numbers. It's about deciding what product backlog items you can pick. if taking a, I don't even want to call it an estimate, but taking a wild guess about, it probably can take four hours to code. If that helps you decide how many backlog items you can commit to, great, put those numbers up there. But it was never about the numbers. And it's one of the most common problems that I see with teams in sprint planning is they get obsessed with How many hours did we bring in? How many points did we bring in? And I remember one team I worked with where we did sprint planning. Having those estimates were helpful for them on their sprint back. They were helping. And we finished the meeting. And we're using Google Sheets in a meeting to do this. We've got a row with the estimates in there. And as we start to wind down the meeting, I deleted that column that they'd spent so much time talking about. They're all kind of pissed off at me. Why'd you delete that? We spent all this time talking about it. I said, because we got the benefit, right? You got the benefit of those numbers. The benefit isn't a week from now remembering that you said five hours, because it's going to take what it takes. The benefit was the discussion that it led to of can we take more or are we already full? So I see teams get obsessed with that. This is one example, but that's one of the problems with sprint planning as a practice.

Brian Milner (10:25)
Yeah. Yeah. I think you're absolutely right. And that's one of the things I know I've talked about with people going through the course is sort of understanding the purpose behind the things. Just going back to, know, harkening back to what you said about, don't just do it because someone told you, you know, understand why the purpose behind it. And, know, otherwise we, I'm sure we've all had that experience before where someone just tells you to do something and says, you know, why? Cause I told you so, you know, that, that doesn't, that's not very convincing.

Mike (10:52)
Thanks, Mom.

Brian Milner (10:53)
Right, right, thanks mom. Yeah, not very convincing, but it's much more convincing when they can tell you, well, no, you do this because this is what we're trying to do. And I think you're right, that makes all the difference there. ⁓

Mike (11:05)
It just, don't know anybody that responds well to being told what to do, right? My instant reaction is no, right? mean, you it could be, you know, a really, you it could be a really good thing. Eat more vegetables, you spend more time outside. No, right? Don't tell me what to do. So.

Brian Milner (11:09)
Right. Right. Yeah. It's almost like our default response is no until you convince me. Are there other common practices? We talked about sprint planning. Are there other kind of practices you see teams struggle with?

Mike (11:28)
Yeah, yeah, for a lot of people. think a huge one is product backlog refinement. I don't know what a better word would be than refinement. refinement is about making the backlog better. It's not about making it perfect. And I see teams that get stuck on backlog refinement and feel like they have to resolve every open issue, that everything has to be tiny and answered and buttoned up before we can start a sprint. And that's not the case. For me, the goal in refinement is to make sure things are small enough and sufficiently well understood. I don't want to bring in a backlog that's bigger than my velocity. If our velocity is 25, I don't want bring in a 50-point story. how about the problems of a 50-point story anyway? But I don't want to bring in some massive epic like that into a sprint. And so refinement is about making it small, making sure it's sufficiently well understood. Sufficiently well understood, not perfectly. And so

Brian Milner (12:18)
Yeah.

Mike (12:28)
The problem is these teams, and I know you've seen this, but teams who get in there, want to resolve every open issue. It's like, no, we can resolve that during the sprint. If we think about the goal and planning to make sure we know what to bring into the sprint, not too much, not too little, we're fine just enough that you're at that point. Is the button blue or red? Who cares? If it's a log in story, we're going to lock people out after some number of failed attempts. Who cares how many? Figure that out during the sprint. If it's five or three or eight, who cares? Figure that out later. So I think refinements won. Another big one would be reviews, ⁓ where sometimes teams demo too much in a sprint review. And they feel like they have to justify their existence, show everything you did during the sprint. And the most egregious example of that was this was a handful of years ago. But I literally remember a team showing

Brian Milner (12:58)
Yeah. Yeah.

Mike (13:18)
how they had updated the copyright notice on the footer of the web page, know, copyright, you know, whatever year our company, right? And it's like, my God, you didn't need to show that to stakeholders, right? We all either know there's a copyright notice on the bottom of the web page or we've seen one before. I don't need you to bring it up and scroll down to it. Now only took 15 seconds of the meeting, but that was 15 seconds of people's lives. They were never going to get back. you know, show stuff that you need feedback on, right? If you'd...

Brian Milner (13:41)
Right.

Mike (13:45)
You fixed a bug and you fixed it only way it could be fixed. Mention it perhaps, but you don't need to show it, right?

Brian Milner (13:51)
Yeah, yeah, know teams I've been on often it's just it's suffice it to have a list sometimes and just say here's a list of things if you want to know more about these come talk to us but we're move on to the stuff you care about.

Mike (14:02)
Yeah, I always have like a will show, will not show list. you know, I often, if I'm writing the meetup present, that'll put that up on Zoom or, you know, show it on a screen if we're in person. And often somebody wants to see something that's on the will not show list. Or they just want me to describe what bug was that again? What was that? You know, and I'll explain it really quickly. But if nobody wants to see it, don't bother showing it. So.

Brian Milner (14:26)
Yeah, I know we talk about these scrum practices quite a bit in the working on the scrum team class, but if someone signed up to take this class, what can they expect to hear or what can they expect to learn about these practices in the course?

Mike (14:39)
Well, I think one of the things that you and I did together in creating the newest version of the course was to look at what do you actually need to practice doing, and it's feasible to practice doing in a classroom setting, versus what should you just kind of talk through. And not everything needs to be practiced to get the hang of it, right? Everybody in the world has taken something big and split it up into smaller things before, right? I need to make. spaghetti dinner tonight. What do need to buy? Right? OK. Well, that's that's that's test decomposition by noodles, by sauce, by tomatoes. Let's make it from scratch. Right. By some garlic. Right. So everybody in the world has done decomposition. We've broken a big thing into small things. And I remember, you know, iterating over I'm still on sprint planning, I guess. But I remember iterating over exercises in sprint planning and in courses over the decades by now. And I would have one where you're planning a party for your kid, break it down into tasks. It's like, nobody learns anything from this. And so that's one where I'd rather say, OK, this problem occurs in sprint planning. How could you solve it? Other things like, let's say, splitting user stories or splitting job stories, that's a skill worth practicing together, getting feedback on. And so those type of things we try to practice in the course. other things we just talk about. mean, I'm curious on your thoughts on that. What do you think about some things being worth practicing, some things worth being better talked about?

Brian Milner (16:01)
Yeah, I agree. I agree fully. it's, it's, you know, there's some things, it's kind of like what you said before, there's some things that's not worth spending the time on, and it's better to just have a discussion and move on.

Mike (16:13)
Yeah. Yeah. I guess that's one of the things we always talked about. We always talked about return on investment of the exercise. What's the return on the exercise? And if you're going to have a one hour exercise, cool. One hour exercise. But it better have a pretty healthy return because that's a lot of time in class. And so what's the return on exercise? Is this worth a practice? Is it worth just a discussion? And if we can discuss two hard problems and give people advice on two common problems, they're probably going to face.

Brian Milner (16:21)
Yeah.

Mike (16:41)
Might be better than spending 20 minutes practicing something that they've probably done before.

Brian Milner (16:45)
Yeah, I completely agree. Let's move to the third pillar then, because I know this is a big one, just thinking and talking about the roles. And just as far as communication issues are concerned, even outside of Scrum, I know that's part of the big problem with teams and organizations just not being clearly defined about who does what and who's responsible for each thing. So those misunderstandings are really common failure points. ⁓

Mike (17:09)
Mm-hmm.

Brian Milner (17:10)
How do you see teams getting that wrong and how's that derailing a Scrum team?

Mike (17:15)
Well, think we see it all the time on Scrum teams between Scrum Master and Product Owner and even the development team, right? Who does what? I was responding to some comments on LinkedIn this morning on some post I'd made last week and somebody had some comments. And it had to do with whether the Scrum Master or Product Owner does something. And it was interesting because in the comments on that post, I... I don't remember which one it was, but I shared a certain perspective. I feel pretty strongly that I have it right. I mean, I this is how we do it. But there were other people saying the opposite, right? And so, you know, these are people that are probably fairly experienced with Scrum, if they're following me on LinkedIn and feel comfortable commenting on a post, probably feel comfortable with it. And so there's a lot of confusion about what role does what thing. And I don't think this is something where the Scrum guy is going to have the answers for you. I think it's, I mean, you can look at the Scrum guy, oh, this. Here's my starting point answer, but we always want to play to people's strengths, right? And if you've got a scrum master who's got a lot of skill in one area, maybe they shift a little work from the PO to themselves, right? With the PO's permission, right? And the opposite, right? Between maybe PO and team. So it's fine to have default starting positions on who does what, but you always want to play to people's strengths. So I think PO scrum master, I think we see it with project managers and scrum masters, roll confusion on those type of roles as well.

Brian Milner (18:38)
Yeah, completely agree. A lot of those roles that are not named Scrum team roles and how they interact with the team, that's often a source of confusion as well. What are maybe some signs or symptoms that teams might be having confusion or problems in this area that maybe they don't even recognize or realize they're having an issue with roles?

Mike (18:59)
Any sort of conflicts, right? You know, you and I arguing over which one of us should do something. The other one would be kind of the opposite, which would be like a dropped ball. I was watching some YouTube video. I love baseball. I was watching some YouTube video the other day of like missed catches or something like that. And some team hit a baseball way up in the air and it was landing near three players, right? Three players are all looking at it.

Brian Milner (19:12)
You

Mike (19:23)
One guy waves the other two off, he's going to catch the ball and he must have been blinded by the sun because he's like six feet from the ball when it lands on the ground, right? And, you know, if we have a responsibility to catch the ball, run this meeting, right, right the backlog, the kids dropped, right? And so I think either arguing over who does something, two of us trying to do the same thing or neither of us doing it. I don't mean trying to get out of the work, right? All three players have been happy to catch the ball, but I think you've got it. You think I've got it, right? Those type of things are pretty good signs. think getting clarity around these roles can really optimize how a team works. And I think a really key thing here is that it changes over time. So I'll go back to my example of maybe the Scrubmaster has some skills that can help the product owner early on. Because maybe the product owner is new to the company. The product owner doesn't know the product as well. So they might rely on the Scrubmaster for guidance on things. Well, a year from now, we might shift responsibilities a little bit because now the PO is the expert on all things related to the product. So it's not like we want to establish clarity on roles one time and leave it forever. It's going to change. We get a new tester on the team, things might change. Product owner moves. It's going to change again. So we need to realize these responsibilities are dynamic.

Brian Milner (20:39)
Yeah, that's a great point. Your point about baseball just made me think about how, when you watch any youth sport in the world, when you go watch your kids play a sport, what's the one thing you always hear people scream from the sideline? Talk to each other. Call the ball. Well, that too. That too. Ump your blind. Those kinds of things. Well, let's talk a little bit about

Mike (20:52)
I thought you were going say, put my kid in.

Brian Milner (21:00)
I know this course addresses the roles and how would you say this course really helps address that issue of role confusion?

Mike (21:07)
think a big part of it is that we designed it to be for everybody on the team, right? Suppose you send a scrum master to a class, and it's a great class. Scrum master is going to back to the certain set of impressions about their role. Product owner goes to an equally good class about the product. They might have different impressions. Even if they took the course from the same instructor, they're hearing it a little differently. They're hearing it through their filters, right? And so when they're in a course together, there's more opportunities to clarify their understanding about those things, especially in the classes designed as we did with this one to bring out some of those differences. So I think the course helps with that. we've also designed it to mention the rules we haven't talked about, like managers and things like that.

Brian Milner (21:53)
Yeah, yeah, I think those are so important. And there's a lot of great discussions that come out when we have those topics. ⁓ Let's talk about the fourth pillar then, teamwork, because this, I think, builds really well on what we just talked about. And the idea that there's actually, Scrum is a team sport. ⁓ So beyond just normal human personality conflict type issues, what do you see that gets in the way of teams actually

Mike (21:58)
Mm-hmm. Mm-hmm.

Brian Milner (22:18)
working as a team.

Mike (22:19)
think ego is probably one, right? I can do everything better, just leave me alone. There's an old book that says basically, beware of a lone developer in a room, right? You know, it was referring to the developer who wants to close their door and say, I'll it done in a month, trust me, right? And one of the companies I worked with, and this one's going back like 15 years ago, but it was a really good story.

Brian Milner (22:36)
Yeah.

Mike (22:43)
is they would literally grab one unit of work. Each person on the team would grab a unit of work and take anywhere from three to 12 months to do the thing. So they were big things, but the person would do everything on it. They'd coded, tested everything. And the organization was putting out very little because of this. When they moved to Scrum in the first year, by their estimate, they said they delivered 540 % more work. over five times the amount of new features delivered. And that was through the collaboration, through the short iterations, those type of things. But it was about getting people to collaborate more. So I think there's huge opportunities to do that. One of the problems I see is when we don't overlap work. If we think about that organization I just described, you grab your thing, you're done in six months. I grab mine, I'm done in seven months. If we'd work together on those things, what's not make us any faster? No faster. But you and I could have worked on your one thing and been done in three months. OK, we're delivering value in three months, right? And so one of the things I look for a lot is how much teams are overlapping work, right? And if we're not overlapping work, there's huge opportunities to improve at that. I'll a little example of this. One of my favorite restaurants is, I don't know, barely call it a restaurant. It's a fast food deli. It's called Jimmy John's. Have you been to Jimmy John's, Yeah. Yeah, there's one near my house where I can go there and the wine will be out the door. Right. And you know, normally you see a wine out the door and it's like, crap, I'm going somewhere else. Right. These guys are so fast. They're so fast. When I get to the front, I place my order. I play this little game of can I fill up my cup? You know, I get an iced tea and they give me an empty cup and can I go fill up ice and put the tea in before they hand me my sandwich? And it's about 50-50. Right. It doesn't take long to fill up your iced tea. But the way they do that is the overlap work. As soon as I order my Italian club sandwich, somebody's already got the bread open, somebody's got a slab of meat they're ready to drop on there, somebody else has their hands over the vegetables and they're dropping the vegetables on there, and then a fourth person wraps it up. And so like four or five people touch my sandwich. Hopefully their hands are clean, but four or five people touch my sandwich as opposed to like most delis where I go and it's like you watch one person plod along making the sandwich, right? Overlap work is huge.

Brian Milner (25:07)
Yeah. Yeah, this episode sponsored by, no, just kidding. Use code Mike Cohn when you go to, no, just kidding. Yeah, I agree. And yeah, yeah, I'm familiar with Jimmy John's. Probably too familiar. ⁓ Yes, yeah, no, that's, I think that's part of their shtick is that they're, you know, they're known for being fast. So yeah.

Mike (25:10)
You Is yours just as fast? Yeah. Yeah. They call it Freaky Fast. They actually have a competition. I've seen YouTube videos of this where they get like the best teams at various restaurants race, right? And so they have like the Jimmy John sandwich making Olympics or something, but it's a skill.

Brian Milner (25:36)
wow, wow, yeah. You should pair that up with the hot dog eating challenge in some way and see if we could have a team sport going there. ⁓

Mike (25:48)
Well, that's a good point because think about the hot dog eating. That's one guy, right? That's Joey Chesnett shoving hot dogs down. The Jimmy Johns is a team. They get the best crew at a restaurant and it's a team, right? How fast can the team go? Not how fast can one guy make a sandwich, right?

Brian Milner (25:51)
Yeah. Yeah, yeah. That's awesome. So what are some tips? What are some ways that you can really unite a team, especially those new teams? Because that's the fascination point for me is, how do you take this group of humans that really don't know each other and haven't worked together in the past and unite them together and have them gel as a team? How do you do that?

Mike (26:21)
I'll give you a couple. One, I think having really crisp sprint goals helps. So we all know exactly what we're trying to get done in the sprint. We don't lose sight of that because sometimes in the middle of a sprint, you lose sight of it. And you get myopic and you just focus on a list of tasks. And I'm going to say that it's probably similar to the team doing sprint planning and just getting them assessed with the numbers. It's not about the numbers. It's not about the tasks. It's about the backlog items that lead to some goal. So crisp sprint goals help. That's a hard phrase. Crisp Sprinkles helps. The other one I'd say is having a shared vision about where you're headed over a little bit longer term. Probably the biggest change to the Scrum Guide ever that I've liked is the inclusion of a product goal. And that was something I'd been talking about forever. mean, literally since I started doing Scrum was that sprinkles are great, but they're pretty short, right? You want to have something bigger.

Brian Milner (26:52)
It is.

Mike (27:14)
And so I like having product goals that are a few months out there. And one of the things I like doing for product goals is have teams do something like write a press release that describes their goal or create a vision in some way, write a review that you want to see come out on the App Store, Play Store, and a magazine. And one of my clients made software and they were reviewed by a major magazine and they were given an editor's choice runner up award. And they actually estimated that being runners up for that was probably worth about $10 million. First place, first time was worth about $10 million a year to them. And so they decided to get serious about this and they wrote a review. Their scrum master, she was actually combo scrum master product owner, Erin. She had the team write a review and she said, let's go earn this review. And I literally remember the email I got from her three months later. It was because it was Halloween night. I just like, you know, brought in the candy from outdoors. We're done trick or treating. And I checked my email. I a three word email from her from Erin. said we did it. And the magazine had let her know, hey, we're reviewing you. be out on, you know, like Tuesday's edition. And the review had quotes in there that were from their vision review, right? The things that they had wanted to achieve.

Brian Milner (28:22)
Ha ha.

Mike (28:35)
And that team had just really jelled around that and just became so much more productive and collaborated so much better because of that shared vision.

Brian Milner (28:43)
Yeah, that's amazing. getting back to the course then, I know in the course we're trying to kind of some of those collaboration muscles. What are some of the ways that the course helps to build that?

Mike (28:56)
think one of the key things that we're doing, and I'm excited about this, is that we're, you know, we of course use Zoom breakout rooms, right? You you go talk about this, we'll see you in eight minutes or something like that. And for this course, we're doing something where a group of three or more, when they register, can have a private breakout room. And this to me is exciting because people get the benefit of having a private breakout room. They can have sensitive discussions if they want. They can talk very specifically about. you know, what do we do about our jerk product owner? mean, whatever it is, right? You know, they can talk about their specific issues, yet have the context of a broader class. Because I think in one of the benefits of any public class is hearing how other teams are doing things. And sometimes that's because you get a good advice, you know, how did you solve that problem? We have that problem. Other times, it's just feeling that you're not alone in the world. they've got that problem too, right? And they don't have any solution for me, but I know I'm not alone in the world with this. And so I like these private breakout rooms for three or more. I think it's a novel thing we're doing with this class. And it's with the intent of combining the best of both worlds of private and public training for this. I'd the other thing is probably consistency, having everybody on the team hear the same message, having those discussions with an experienced instructor like you or me in the room to provide guidance when they have questions. know, go back to the role clarity, right? You know, they can talk about it and they're there. Then they're back in the main room with you or me and we can kind of answer questions. So I think that consistency will be huge as well.

Brian Milner (30:25)
Yeah, yeah, I love that idea of the private private breakout rooms that that's that's gonna be huge for a lot of people I know. ⁓

Mike (30:31)
I'm excited to try it with this. This will be the first classes we do that for. I'm excited about it.

Brian Milner (30:36)
Yeah, yeah. Well, let's bring it home then and talk about the fifth pillar because the fifth pillar is really interesting as well. It talks about support beyond the team and teams can only do so much. Every team struggles when they're not supported well. And there's lots of studies that show leadership support is one of the biggest hurdles or obstacles to the adoption.

Mike (30:46)
Mm-hmm.

Brian Milner (30:59)
What does that support look like from outside the team and how can a team influence that?

Mike (31:06)
Yeah, if you're trying to be agile and your HR group has quarterly reviews of personnel that are all based on individual performance and has nothing to do about teamwork in there, it's going to be hard to focus on collaboration. So we have to kind of fix these issues. I think what we have to do here is to have team members educate those outside the organization. And we have information that we share about, you here's how to talk to a boss that's maybe mandating deadlines, things like that. And so we try to coach people through having some of those challenging conversations. And one of things I want teams to do is kind of become an example of what good agile looks like. And if you have a team that's excelling with agile and they're doing it from a kind of principles first, that mindset first approach. You're going to see other groups look at that and let's say the marketing group. They're going to look at that go, hey, that's an interesting way to work. I wonder how we could do that, right? And it's going look different for a marketing group than a tech team. the mindset is going to be the same. Principles will still be the same. And so when we get teams to do really well with this, other parts of the organization start to get interested. And then they stop being as much in our way.

Brian Milner (32:20)
Yeah. I know one of the most important aspects here and that we talk about is, is that you don't need to, to wait, right? If you're the team level, you don't have to just sit around and wait for the organization to make changes. you, you have opportunities to make changes as well. So how does that happen? How's the team change, you know, bring about those changes that, improve the agile process, the results.

Mike (32:42)
I think that's by being the example so that people see it. I think it's by having those conversations. You know, one of the things that we'll get is, you know, it's so common is the product owner that wants to change their mind all the time. I was reading something, I guess this is in our Agile mentors community, I think is where it was, but it was about the, you know, the product owner who said his favorite thing about Agile is that he can reprioritize every week. ⁓ And it's like, you can, you know.

Brian Milner (33:05)
Hmm. Yeah

Mike (33:10)
I'm not sure it's good. And I think about that, a team gets momentum, right? And you're working on a certain feature. Next sprint, it would be nice to work in that same area of this system, right? Your head's there. Just kind of keep going a little bit. And I've often described this as like, let's say you're working on three backlog items that are in a certain area of this system. Let's make it concrete. Let's say it's the spell checker in Microsoft Office, right? And you do three backlog items related to the spell checker this sprint. Next sprint, maybe your top priority is not more spell checker stuff, but maybe items, I don't know, 25, 26, and 27 on the backlog are still in the spell checker. You know what? It might be better to do those. There are probably two or three sprints away. Let's bring them into this sprint. Just get them done while my head's into spell checking. And so getting product owners or stakeholders to stop doing that, one of the ways that I like to talk about doing that is using an example of ordering a meal at a restaurant. I can order, let's say, the chicken entree. And then as the waiter is taking the orders around the table, I change from chicken, no, bring me the fish. Not a big deal. The waiter is going to cross off chicken and write down fish. If the waiter goes away, brings me back my salad, and I change my mind then, I say, hey, bring me the fish. Might not be a big deal. It's going to be a big deal if I've already taken three bites of the chicken. right? Or if he brings me the chicken. So yeah, we can change our mind, but there's a cost, right? And we want to educate stakeholders about that cost. They don't overdo it.

Brian Milner (34:31)
Yeah. Yeah. Well, speaking of the leaders and the organization, managers, leaders, do you think this course is appropriate for managers and leaders to attend as well? you feel like they might need to in order to really have this be an impact?

Mike (34:55)
Yeah, that's a good question. Is it appropriate? Yeah, I think it's appropriate. When we do this privately, we've had plenty of leaders and managers attend. I think it's great. I don't think that's required because they're not on the Scrum team. You said the name of the course is working on a Scrum team. And so they're not on the Scrum team. They benefit by knowing more how their Scrum team works. But I think what we found is that having just a key subset of people who hear the same message work through the training together, and then go back to the organization. That's enough to bring the passion, conviction, and skills that we want. So we don't truly need leaders. They're great. I would never talk a leader out of going, but I wouldn't. If I were a team and I could take the class this month or with my leader next month, I would just get the class done, right? And educate the leader afterwards.

Brian Milner (35:41)
Yeah. Yeah, yeah, I think that's a good plan. All right, well then we've made our way through the five pillars and for people who have come this far with us and are at this point, if they're listening and they're recognizing some of these problems we've been talking about, what would you recommend to them as next steps here?

Mike (35:49)
if Well, take a look at our website. If you go to mountaingoatsoftware.com. And then I think there's a courses link on the top. You can go up there and find the link to this course. It's an exciting one that we're doing. I've literally been teaching this, I think the first time I taught a class called Working on a Scrum Team was 2003 or 2004. it's a time tested course. You and I kind of redesigned it a couple of months ago to make it appropriate for public. or little better just in general and more appropriate for public. But it's a time-tested course that's now designed to be available for public settings instead of, you know, have to have 25 people or something.

Brian Milner (36:36)
Yeah, yeah, that's really exciting. I can't wait to see kind of how people are in, you know, react and interact in the course to some of these concepts and ideas. And we'll, we'll of course link to all these things that we've talked about in our show notes and make it easy for everyone to find the course listing and, and, you know, where the dates and everything that we're going to offer them. So make sure to check that out. Mike, thanks so much for coming on. This has been really enlightening and I appreciate you making time for it.

Mike (37:01)
Of course, thanks for having me, Brian. Always a pleasure.

Real Agile forecasting runs on math, not magic. Brian and Lance dive into Monte Carlo methods, DORA metrics, and how AI is shifting the future of project management. All with a human-first approach that builds better teams, not bigger spreadsheets.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner and Lance Dacy unpack why Agile teams need to rethink how they forecast work—and why math, not magic, is the real secret. 

From the roots of Taylorism to today's Monte Carlo simulations, they explore how to navigate uncertainty with data-driven tools like DORA metrics, flow metrics, and probability theory, while keeping the heart of Agile leadership focused on trust, transparency, and better decision-making.

References and resources mentioned in the show:

Lance Dacy
Free Chapters of Agile Estimating and Planning by Mike Cohn
Join the Agile Mentors Community 
Mountain Goat Software Certified Scrum and Agile Training Schedule
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 SVP of coaching and 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. 

Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

In this episode of Agile Mentors, Brian sits down with Lance Dacy to discuss integrating Agile and Scrum practices into the world of data science.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Lance Dacy to discuss integrating Agile and Scrum practices in the world of data science.

Tune in to gain insight into the importance of feedback, the stages of the SAS Enterprise Miner initiative, and how frameworks like OSEMN can enhance the data science process.

Listen in to learn how to strike the right balance between technical knowledge and product ownership and why culture is crucial in successful Agile implementation within the data science domain.

Listen Now to Discover:

[01:16] - Brian introduces his guest Lance Dacy, referring to him as "our San Diego Zoo guy" and the topic of today's show using Agile or Scrum practices in a data science world.
[02:27] - Lance shares his background in data science and how it fits into the world of Agile.
[05:06] - The big reason so many people are against using Agile for data science and where the big rub is.
[09:02] - Who cares if it’s Agile or not? Lance shares Jeff Salts's poll about data science and introduces CRISP-DM.
[11:05] - The six steps of the cross-industry standard process for data mining.
[14:18] - Adopting a Scrum-like approach and treating data science work as smaller phases makes it possible to classify and organize tasks effectively.
[15:59] - Does anyone remember the Rational Unified Process?
[17:57] - It’s up to you to come up with ideas—once you have them, here's how we get it done.
[18:18] - In the world of data science, implementing frameworks like Scrum can lead to misconceptions and failures—the key lies in understanding the layers of data science, navigating the complexities of the work effectively, and making informed decisions.
[23:06] - The vital importance of feedback.
[23:45] - The stages of the SAS Enterprise Miner initiative.
[27:25] Brian introduces the sponsor for the podcast, Mountain Goat Software, and their two-day Certified ScrumMaster Course that’s perfect for anyone who wants to understand Scrum and add value to any team.
[28:23] - How the product owner fits in when discussing working with big data.
[29:50] Lance introduces the OSEMN process and explains how to solve a problem like a data scientist.
[30:47] - When it comes to the role of a product owner, the technical knowledge required depends on the nature of the product.
[31:42] - While Scrum lacks explicit guidance on backlog construction, the OSEMN framework themes (obtain, scrub, explore, model, interpret) can be incorporated to align sprint goals with specific aspects of the data science process.
[33:47] - The framework or the structure of how you carry it out is less important than the kind of agreement.
[35:07] - It's a cultural rather than a process problem. Lance delves into the debate on applying Agile Scrum to research.
[36:37] - A fundamental misunderstanding about daily scrums.
[37:18] - None of us are smarter than all of us together. Agile and Scrum work well when you know how to solve the problem, and there's a relatively clear path to victory.
[38:49] - Brian shares his biggest piece of advice to people considering this in the data science
[39:28] - “Data science is just the work that we're trying to do, tailor your process for your team and your culture and always inspect and adapt to try to make it better.”
[41:08] - If you have feedback for the show or topics for future episodes, email us by clicking here (if you have yet to get a response, send another one as something has gone wrong in the process). And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode. And if you are a data scientist or work in big data and found the information in this valuable, let one of your co-workers know about it.

References and resources mentioned in the show:

Data Science Process Alliance
CRISP-DM
OSEMN
Scrum and Data Science
Agile Mentors Blog Topic: Decision Science - What methodology fits best?
Certified ScrumMaster Training and Scrum Certification
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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 the SVP of coaching and 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.

Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Unveiling the truth behind Agile coaching! Brian sits down with Lucy O'Keefe to debunk the misconceptions, share the keys to effective coaching, and share their insight on the one-two punch of training and coaching for sustainable success.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Lucy O'Keefe to debunk the misconceptions and unveil the true role of Agile coaches.

They share their personal stories and revelations and explore the pros and cons of moving from Scrum Master to Agile coach.

They'll walk listeners through the transformative power of external perspectives, navigating conflicts, and the collaborative mindset that fosters meaningful change. Plus, hear Lucy's invaluable advice on finding mentors and embarking on the journey to becoming a certified Team Coach.

Listen Now to Discover:

[01:10] - Brian welcomes CTC Agile Coach & Trainer Lucy O'Keefe, to the show for today’s discussion on the true role (and the common misconceptions about) of an Agile coach
[02:17] - Lucy shares her initial misconception about agile coaches and how it shaped her perception of their role.
[03:02] - Brian relates his experience with the term "Agile Coach" and his revelation when delving into the subject.
[04:16] - Lucy and Brian reflect on their transitions from exceptional Scrum Masters to agile coaching roles.
[05:53] - The pros, cons, and trade-offs of transitioning from a Scrum Master to an Agile coach.
[06:32] - The shift in focus that comes with Agile coaching and what to consider to determine if this change aligns with your preferences and career aspirations.
[07:12] - There's nothing wrong with being a kick *** Scrum Master. The world needs lots more like you.
[07:51] -How your role as a coach involves assisting your team and organization in their pursuit of progress (or debunking the myth of perfection in Agile).
[08:11] - An Agile coach is NOT merely an elevated Scrum Master.
[08:33] - The two opposing misconceptions about Agile coaching and the multifaceted aspects of coaching by Bob Galen.
[09:20] - Lucy emphasizes the importance of wearing multiple hats and the diverse skills required as an Agile coach.
[10:26] -Avoid the “Ferris Bueller's Day Off” scenario and ensure effective communication.
[11:16] - Learn to read the signs and strike the right balance to avoid frustrating situations and empower meaningful progress.
[11:54] - Professional coaching requires a willingness to engage deeply and tackle tough issues.
[13:38] - Knowing where to step in and when it's time not to step in.
[14:07] - Brian introduces the sponsor for this podcast episode, Mountain Goat Software, and their exceptional Scrum certification classes that go beyond a traditional online whiteboard for a fun and effective way to achieve learning objectives.
[14:52] - Effectively communicating the value proposition of having a team or enterprise coach.
[15:41] - The dynamics of internal and external coaches within organizations. And the transformative impact that external coaches can have on an organization’s ability to address impediments effectively.
[16:58] - Lucy shares how to approach coaching with a collaborative mindset, helping organizations see the value of change rather than imposing it and the questions. Agile coaches conduct assessments to uncover hidden issues to guide organizations to the areas for improvement.
[19:18] - Resistance to change often stems from fear of the unknown rather than change itself.
[19:57] - The most important thing to understand to help organizations reach the outcome they want and make the changes they need to make to get there.
[20:15] - Brian draws a parallel between the value of a coach and that of a therapist and how an outside viewpoint proves highly beneficial in understanding and addressing systemic issues within teams.
[21:29] - Asking the right questions to resolve the underlying issues through Agile coaching.
[22:42] - What coaches can and can't help with—knowing your limits as a coach and the lines NOT to cross to keep your coaching journey on track.
[23:40] -Don't settle for just training; go for the one-two punch of training and coaching—the winning combination that propels sustainable change.
[25:48] -Why would you need to take a class? Even Bob Galen realizes he always needs to grow and learn in what he’s doing to avoid becoming irrelevant.
[26:37] - Act with curiosity, but not curiosity for our own sake.
[27:30] - Lucy offers her advice for people who want to become a Certified Team Coach (CTC).
[29:02] - How to find the mentors that will offer you the most growth.
[29:55] If you have feedback for the show or topics for future episodes, email us by clicking here (if you have yet to get a response, send another one as something has gone wrong in the process). And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.
[30:49] - Remember that Brian and Mike will speak at this year's Agile 2023 Conference in Orlando in July.

References and resources mentioned in the show:

#42: The Importance of Self-Mastery with Bob Galen
Agile2023!
Certified Scrum Master Training and Scrum Certification
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the "Agile Mentors" Podcast on Apple Podcasts

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 the SVP of coaching and 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.

Lucy O'Keefe has over 28 years of IT experience and has worn multiple hats in the Agile world - developer, Product Owner, and Scrum Master and now, as a Teaching Assistant, where she leverages her diverse background to ensure students have an exceptional training experience.

Join Brian and Agile pioneer Jim Highsmith as they dive into the riveting saga of 17 tech rebels who defied convention, unleashed their passions, and revolutionized the world of software development.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Agile pioneer Jim Highsmith to share how 17 tech rebels reshaped the software landscape.

Jim shares captivating stories from his time working with NASA and Nike to the collaboration of 17 nonconformists that led to the Agile Manifesto and transformed the software industry.

Listen in for a behind-the-scenes look at the circumstances that led to the birth of Agile and how camaraderie, collaboration, and a human-centric approach sparked a wildfire of support for the Agile movement. Tune in to this episode for insights, lessons, and a glimpse into the future of Agile from an industry legend.

Listen Now to Discover:

[01:10] - Brian introduces Jim Highsmith, a renowned figure in the Agile community. Jim is an experienced software developer, writer, and storyteller. His latest book, "Wild West to Agile," has become a sensation in the industry, earning the top spot as a new release on Amazon. He also co-authored the Agile Manifesto and the Declaration of Interdependence for Project Leaders, co-founded the Agile Alliance, and served as the first president of the Agile Leadership Network.
[03:57] - Jim recounts his journey working on the NASA Apollo program and how the constant advancements in technology shaped the course of the Apollo project, offering valuable insights into the era's challenges and adaptability.
[08:47] - Jim shares a fascinating story from his time at Nike, where outdated requirements left a project stagnant for 18 months.
[10:34] - How waterfall methodologies left companies trapped and projects taking too long and costing too much.
[11:53] - Setting the stage for the revolutionary Agile movement.
[13:16] - A problem so painful leadership was on board to find a solution.
[14:48] - A message from our sponsor: Mountain Goat Software has courses from Certified Scrum Master Training and Scrum Certification to Certified Scrum Product Owner Training that equips you with the sought-after skills valued by top-notch teams. Visit the Mountain Goat website for all the details.
[15:40] -Jim reveals the connections and common ground that started the manifesto meeting.
[18:21] - An agenda-free meeting with 17 nonconformist experts seeking common ground and how an encounter with Steve Mellor led to an unexpected alignment of intent.
[21:01] - 17 individuals, each with nonconformist perspectives, agree.
[21:17] - Why did 17 audacious techies revolutionize the world? And what lessons can we learn from their experience for the future?
[23:39] - Where Agile's lasting impact lies and what keeps it at the forefront of change.
[24:39] - Putting aside competition for collaboration and cooperation that led to change.
[25:30] - What keeps Agile at the forefront of change? Brian shares a nugget of wisdom from Jim's book about Agilists.
[26:38] - Finally, a language that spoke to us all!—how the Agile movement shattered the notion of interchangeable cogs and embraced our humanity, sparking a wildfire of support.
[27:59] - Jim shares his thoughts on where he thinks the Agile movement is headed and why he thinks the agility of organizations and people will be a definite advantage in the future.
[29:56] - Brian mentions his high recommendation for listeners to pick up Jim’s book, Wild West to Agile: Adventures in Software Development Evolution and Revolution.
[31:38] - There are a ton of podcasts out there; thank you for taking the time to listen to this one. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.
[32:05] - If you've considered taking a CSM or CSPO class, check us out at Mountain Goat Software. Or join the conversation in our Agile Mentors Community.
[32:32] - If you have feedback for the show or topics for future episodes, email us by clicking here, and I'll get back to you ASAP.

References and resources mentioned in the show:

Jim Highsmith
Jim Highsmith on LinkedIn
Wild West to Agile Agile Manifesto
Agile Alliance Agile Leadership Network
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the "Agile Mentors" Podcast on Apple Podcasts

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 SVP of coaching and 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.

Jim Highsmith is an experienced software developer, writer, storyteller, and industry pioneer recognized for his instrumental role in the birth of the Agile movement. His latest book, "Wild West to Agile," has become a sensation in the industry, earning the top spot as a new release on Amazon. Jim continues to inspire and guide Agile enthusiasts worldwide through his insightful stories and expertise.

Gain insights into building cohesive and agile teams that bleed into each other and explore how conflicts can be transformed into opportunities for growth and improvement when Brian and his guest Julie Chickering delve into how to create team safety.

Overview:

In this episode of the "Agile Mentors" podcast, Brian sits down with Julie Chickering to explore the topic of team safety. They dive deep into the concept of psychological safety and its impact on team dynamics and productivity. From navigating conflicts and encouraging participation to embracing multiple perspectives and detaching personal worth from ideas, Brian and Julie provide valuable insights and actionable advice for Scrum Masters and team members alike. Join them as they uncover the secrets to creating a cohesive and psychologically safe environment where teams thrive and excel.

Listen Now to Discover:

[01:12] - Brian welcomes Julie Chickering back to the show. Teams need to feel safe and agile to be successful; that's a foundational aspect of a team. So, we're talking about team safety today.
[02:12] - Julie shares how one Manhattan bartender described her team that works well together; she says it feels like "we bleed into each other."
[04:11] - Sometimes people misuse or abuse the safe space, having each other's back as a license to be rude.
[04:57] - From pointing fingers to fixing problems together.
[05:39] - Julie shares a book called "The Culture Playbook" by Daniel Coyle and a quote on distinguishing between relational conflict and task conflict.
[06:38] - Protecting team dynamics: Learn how to navigate conflicts that escalate into personal territory and regain focus on improvement.
[07:37] - Effective strategies to steer discussions back to areas of agreement and keep the focus on facts.
[08:09] - Embracing multiple perspectives: Explore scenarios where opposing ideas are equally feasible and the importance of making a choice and moving forward.
[08:51] - Sometimes safety is misconstrued and used to stop discussions.
[09:17] - How to encourage participation based on comfort levels and through smaller group sharing.
[10:00] - The true meaning of safety.
[10:54] - Tension-free environments don't always lead to productive cultures: why disagreements are vital for meaningful discussions.
[11:33] - Detaching personal worth from ideas so you can focus on finding the best solution (vital as the Scrum Master).
[12:42] - How to facilitate conversations by focusing on facts and using visual aids to encourage objectively analyzing multiple ideas.
[13:00] - Nurturing sensitive team members: strategies to create a sense of safety for individuals who are more susceptible to critique to ensure them of the value of their contributions.
[14:13] - Why you should avoid labeling opinions as “wrong” and how assuming positive intent fosters a sense of safety.
[14:45] - The challenge of assuming positive intent (especially in written communication).
[15:21] - How to empower team members to define operating agreements that foster a sense of safety and a respectful working environment.
[17:23] - This podcast is sponsored by Mountain Goat Software's Certified Scrum classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM), and Advanced Certified Scrum Product Owner (ACSPO). Mike Cohn taught his first Scrum classes in 1997, and since then, more than 24K people have chosen to train with Mountain Goat Software. All certified classes include a twelve-month Agile Mentors Community membership.
[18:08] - How to open communication lines when unintentional offenses occur during interactions.
[18:49] - Scrum, though a simple framework, becomes complex when people's dynamics come into play.
[19:22] - Brian shares that achieving psychological safety requires a cultural shift and agreement among team members to express opinions freely.
[20:54] - Julie shares why psychological safety matters.
[22:09] - When the swirl of uncertainty and lack of safety is removed, teams can accomplish more due to increased productivity and effectiveness.
[22:34] - Brian shares some tips for Scrum Masters to make psychological safety a focal point if it is lacking within their teams.
[23:40] - Julie discusses the importance of understanding and supporting team members beyond Scrum practices and offers advice on ensuring everyone on the team is heard.
[25:15] - The secret to team cohesion: how sharing coffee preferences can build a sense of safety and collaboration within your team.
[25:51] - Julie explores the challenge of fostering a sense of team and safety at the corporate level and why starting at the team level is the key to cultivating a culture of trust and psychological safety, even in the face of external obstacles.
[27:31] - Julie delves into why teams work in a particular way and how aligning work practices with the desired outcomes can positively impact results.
[28:04] - How fostering psychological safety improves human interactions and drives better products, higher quality, and faster delivery.
[28:51] - How to address safety concerns with higher-ups.
[29:53] - The dangers of dismantling high-performing teams prematurely: the importance of nurturing team cohesion and the pitfalls of overlooking this critical aspect.
[30:42] - Brian shares how protecting the team sometimes involves making tough decisions and advocating for a better fit for both the individual and the team.
[32:06] - Julie’s parting advice encourages teams to assess their current state, ask critical questions, and collaboratively work towards creating a more cohesive and psychologically safe environment.
[33:06] - If you have feedback for the show or topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.
[33:46] - Look for a different type of show coming to you during our July "break."

References and resources mentioned in the show:

The Culture Playbook: 60 Highly Effective Actions to Help Your Group Succeed
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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 SVP of coaching and 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.

Julie Chickering is the brains and brawn behind JC Agile Consulting, believes that Lean and Agile practices are packed with potential — to enable positive culture change, business agility, and breakthrough results. Julie is a past president and board member of the Agile Project Management Network (APLN), a Certified Scrum Trainer (CST), PMI Agile Certified Practitioner (PMI-ACP), as well as a traditional Project Management Professional (PMP).

Join Brian and his guest Lance Dacy as they explore the key differences, skill sets required, and the exciting opportunities in the roles of Scrum Master and Product Owner.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Lance Dacy to explore the dynamic roles of Scrum Master and Product Owner. They delve into the fundamental differences between these roles, highlighting the unique skill sets required for each.

Lance shares his valuable insights and personal experiences, shedding light on the challenges and opportunities that arise in these pivotal positions.

Whether you're considering a career in Agile or seeking to enhance your understanding of Scrum, listen in to this episode for practical advice and guidance for aspiring Scrum Masters and Product Owners and a deeper understanding of the crucial roles they play in driving successful projects and maximizing team productivity.

Listen Now to Discover:

[01:17] - Brian Milner has Lance Dacy on the show today to talk about a question emailed to the listener email address about the two different approaches to Scrum and which class would be a good fit for you, a Certified Scrum Master (CSM) or a Certified Scrum Product Owner (CSPO).
[02:28] - Lance shares how he looks at the two different designations and what he looks at as the centerpiece of the process of Scrum.
[03:24] - Things to consider when deciding whether the CSM or the CSPO is right for you.
[04:34] - Where to start your Scrum journey as a beginner and when taking both the CSM and the Certified Scrum Product Owner (CSPO) classes might be beneficial.
[05:28] - You don't have to be a Scrum Master to benefit from the CSM class.
[05:54] - The dual focus of the Product Owner roles and the diminishment of Scrum roles.
[06:45] - The challenge of combining these roles effectively.
[07:54] - The goal is to be agile rather than just doing Scrum-Lance shares the importance of delivering value efficiently and early. Relegating the Scrum Master to facilitation and metrics tasks yields minimal ROI.
[08:28] - Do you ever see the coach playing the game?
[09:10] - Scrum is a tool - you have to know the tools, how to apply them, and, more importantly, how to use them for the appropriate case.
[10:16] - The distinction between programmers (those who code) and developers (anyone working to produce the product) and a look back at the developer role in Scrum.
[11:34] - What confuses most people about the different classes and roles.
[12:28] - The importance (and top challenges teams face) of capacity planning, Sprint planning, and daily work management in Scrum teams. Lance shares why addressing these aspects is valuable for software and product teams, including marketing and infrastructure teams.
[13:44] - The value of certifications as a standard and an advantage in certain situations, but it's like learning to drive - experience is crucial.
[15:42] - The importance of learning the values, principles, and tools associated with Agile methodologies to engage in experimentation and gain practical experience, whether a CSM, CSPO, or CSV.
[16:25] - How active involvement in user groups and communities (such as the DFW Scrum user group) provides valuable insights and career benefits, fostering collective knowledge sharing and continuous learning in Scrum (and beyond).
[17:23] - Mountain Goat Software, the sponsor for this podcast, offers certified LIVE online Scrum classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM) and Advanced Certified Scrum Product Owner (ACSPO) classes. Book more than three weeks in advance for an early bird discount of $100.
[18:38] - Lance shares the three characteristics of a great product owner.
[19:28] - Advice for what you should do if you’re starting from scratch and aiming to become a product owner to gain exposure and valuable experience in the field.
[21:28] - The likelihood of moving from Scrum Master to product owner rather than vice versa.
[22:47] - The four requirements of becoming a Scrum Master requires strong facilitation, teaching, mentoring, and coaching skills, and the demands of being a product owner that makes it a higher barrier for entry.
[23:52] - The focus of a Scrum Master vs. a product owner.
[24:48] - It's like being the Zamboni for a hockey team—as a Scrum Master, you have the opportunity to work in diverse industries, ranging from space science and astrophysics to finance and software development, without being an expert in those domains.
[26:34] - A safer environment for experimentation and growth without the high stakes of individual accountability.
[26:58] - Brian shares the primary determining factor in deciding between product owner or Scrum master.
[27:51] - In the movie-making industry, like in software teams, there are distinct roles and responsibilities. You can choose to define the problem, manage the process, or contribute to building the product—pick your door and start running (and if you don't like it, you can always switch).
[29:06] Real knowledge comes from doing, BUT a class can get you started on the right foot to understanding how to do things and getting your hands dirty to cement further what you want to do.
[30:26] - Lance shares how obtaining a CSM or CSPO certification is like earning a black belt in karate—it's a pathway that empowers you to explore.
[33:24] - Still on the fence? Send us a note, and we'll gladly help you find your path.
[33:40] - Check out the Mountain Goat's training schedule to attend a class with Lance or Brian.
[34:01] - Exciting news! We have introduced an Agile Professional Directory to our Agile Mentors community. As a member, you can now sign up and claim your certifications, allowing you to showcase your expertise when interacting with others on the site.
[34:35] - Don’t forget, Mountain Goat Software offers a range of classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM), and Advanced Certified Scrum Product Owner (ACSPO). We love having podcast listeners join our classes to explore further the topics discussed on the show (click here to subscribe).

References and resources mentioned in the show:

Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
#4: The Developer Role in Scrum with Sherman Gomberg
DFW Scrum (Dallas, TX) | Meetup
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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 SVP of coaching and 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.

Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Join Brian as he rediscovers and relives the most captivating topics, memorable guests, and impactful topics from the first year of the “Agile Mentors” podcast.

Overview

From deep dives into Agile methodologies and practical tips for using your knowledge to benefit others and foster change, the first 50 episodes of the “Agile Mentor” podcast have been filled with fascinating topics and memorable guests.

In this episode, Brian Milner embarks on a retrospective journey through the inaugural year of the show. Listen in as he shares the real stars of the podcast, the moments that surprised him, those that took him out of his comfort zone, and the ones that inspired him to push to be better every day! Plus, what’s next for the show.

Listen Now to Discover:

[00:45] - Brian introduces the retrospective episode to celebrate one year and 50 episodes of the "Agile Mentors" podcast and share what's next.
[01:54] - A thank you for YOUR role in the show.
[02:17] - The role of marrying the right topic to the right guest.
[02:56] - The format that allows listeners to choose the episodes that interest them the most.
[04:03] - Pointing you toward the best of the best. Our first several episodes were focused on the Agile Framework and some core topics, including having Mike Cohn on to talk about the different roles and generally accepted practices.
[05:13] - Sending out thanks to a few of our guests, including the trainers at Mountain Goat Software, including Lance Dacy.
[05:45] - Kert Peterson joined us to share his knowledge, and Scott Dunn shared his insight from the product owner's perspective.
[06:05] - On episode 16, Mitch Lacey joined us to discuss The Hidden Secret Ingredient And Julie Chickering brought a great perspective from a project management background and applying that to some of the stuff we've discussed here on the show.
[06:39] - The time when one of my mentors joined us on the show to discuss transformation.
[07:08] - Learning about coaching and marketing from the best!
[07:27] - Roman Pitchler joined us to discuss product roadmaps and planning things from a product owner perspective. And John Miller shared about using Scrum in the education environment.
[07:46] - On EP25, Henrik Nieberg came on and talked to us about scaling, and on EP27, Tricia Broderick walked us through leadership without blame.
[08:18] - How Scrum can be applied outside of software development and mob programming.
[08:42] - The key to working with humans.
[09:03] - The episode that surprised Brian a little bit.
[09:34] - Three episodes all about change: The first one was about how one organization uses Scrum to help impoverished micro-entrepreneurs succeed (and change their lives). The second featured Chris Li sharing his insight on how to know when it’s time to strike out on your own, and Karim Harbott walked us through the difficulty of transforming an organization's culture.
[10:25] - The episode that inspired Brian to try to push in different ways to get better. And how to cultivate an Agile culture in a virtual world.
[10:53] - Why transformations take people, how to assess a company’s culture before you accept their job offer, and lean thinking in Agile with Bob Payne.
[11:49] - The real stars of the podcast.
[12:30] - What’s ahead for the podcast?
[13:02] - Stepping off the gas a bit.
[13:45] - Virtual dial—targeted tips.
[14:32] - The lifeblood of the “Agile Mentors” podcast.
[15:06] - Mike Cohn and Brian are both presenting at Agile2023 in Orlando, July 24 through 28th.
[15:39] - The most significant benefit of BIG conferences.
[16:41] - Thank you for getting us to a year and 50 episodes! Join the Agile Mentors Community to continue the discussion. If you have topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.

References and resources mentioned in the show:

Agile2023 | Orlando, Florida | Agile Alliance
#1: Scrum vs Agile & Keys to Success with Mike Cohn
#3: What Makes a Great Product Owner? With Lance Dacy
#9: Scrum Artifacts with Kert Peterson
#10: Why User Stories are the Best Way to Capture Requirements with Mike Cohn
#17: Getting There From Here: Agile Transformations with David Hawks
#18 Coaching in an Agile World with Lyssa Adkins
#21: Agile Marketing Teams with Stacey Ackerman
#22: How to Create Helpful Product Roadmaps with Roman Pichler
#23 How Agile Works in Education with John Miller
#25: Scaling with Henrik Kniberg
#27: Leading Without Blame with Tricia Broderick
#29: Influencing Up with Scott Dunn
#32: Scrum in High School Sports with Cort Sharp
#33 Mob Programming with Woody Zuill
#34: I'm Trained, Now What? with Julie Chickering
#37: Servant Leadership, Not Spineless Leadership with Brad Swanson
#38: Using Agile for Social and Societal Transformation with Kubair Shirazee
#40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li
#41: Cultural Transformation in Organizations with Karim Harbott
#42: The Importance of Self-Mastery with Bob Galen
#43: Cultivating Agile Team Culture in a Virtual World with Richard Cheng
#44: Transformations Take People with Anu Smalley
#46: How to Assess Company Culture Before Accepting a Job Offer with Christina Ambers
#47: Exploring Lean Thinking in Agile Development with Bob Payne
Mountain Good Software's Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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 SVP of coaching and 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.

Join Brian and his guests, Janet Gregory, and Lisa Crispin, as they share their expertise on integrating testing into Agile teams. Discover how to bridge the gap between programmers and testers for collaboration and success.

Overview

In this episode of the "Agile Mentors," Brian Milner sits down with Janet Gregory and Lisa Crispin, founders of Agile Testing Fellowship, to discuss integrating testing into Agile teams.

They discuss the history of the divide between programmers and testers and the importance of collaboration and communication between the two groups.

Listen in as they explore the different levels of holistic testing, the mindset shift needed for bug prevention, and the tools and strategies for planning and estimating testing activities. Plus, the role of AI in testing.

Listen Now to Discover:

[00:05] - Brian Milner introduces the guests for this episode, Janet Gregory and Lisa Crispin, who are advocates for integrating testing into Agile teams and the Founders of Agile Testing Fellowship.
[02:25] - Lisa explains the most important goal for collaboration and success.
[03:34] - Janet talks about the history of the gulf between programmers and testers.
[05:09] - How to bridge the gap between programmers and testers and the value of collaboration.
[07:29] - What the values of Agile and Extreme Programming emphasize.
[09:49] - The mindset shift needed for bug prevention.
[11:17] - Managers behaving badly—Brian shares a story about how measuring the wrong things can drive the wrong behaviors.
[12:13] Brian discusses the micro view of testing instead of a system view.
[12:17] How to handle intense forms of testing that take a long time to complete.
[14:02] Janet explains the different levels of testing and that teams should determine where testing belongs based on when it can be performed earliest.
[15:23] Avoiding a "hardening sprint."
[16:48] Lisa shares how to use visual models like the agile testing quadrants and the holistic testing model to help plan and communicate the testing activities needed throughout the software development lifecycle.
[17:25] The website where you can find the training written by Lisa and Janet, including “More Agile Testing” and “Agile Testing Condensed” (recently released), and where you can download the FREE Mini-book "Holistic Testing: Weave Quality into your Product."
[18:29] - Brian introduces the sponsor for the podcast, Mountain Goat Software. If you are thinking about getting certified as a Scrum Master, check out the resources and training options where certification classes are available every week.
[19:26] - The key to fitting testing into a normal sprint cycle and integrating testing with other system pieces.
[20:52] - Janet shares a tip for ensuring testing is not overlooked.
[20:59] - Lisa shares how to remind teams to do testing at the right time.
[22:31] - Why have a visible reminder for testing?
[23:54] - The importance of accounting for testing and not treating it as a separate thing to do.
[24:37] - Lisa shares her experience using planning poker for estimation and her preference to get every story the same size so they can be completed in a day or two.
[25:50] - Janet suggests sizing stories and estimating tasks, why she estimates her tasks herself, and what she’s learned in that process.
[26:44] -How to reduce the time needed in estimation meetings: Lisa shares some insight to identify when a story is too big and needs to be split up.
[27:35] - The importance of conversation and understanding to avoid creating a wall between programmers and testers during estimation.
[28:03] - Another tool in the toolbox: how Chat GPT will revolutionize testing (and who it might replace).
[29:01] - There will never be enough time to do all the testing required.
[29:31] - Lisa highlights how AI as a tool saves time with testing and allows more time for critical thinking skills.
[30:12] - The need for a human presence in the use of AI.
[31:19] - Janet shares information about her and Lisa's two courses, Basic Strategies for Agile Teams and Holistic Testing for Continuous Delivery, based on the Holistic testing model of looking at testing activities throughout the software development lifecycle. These courses can be found here.
[36:37] Lisa mentions that her book, “Assessing Agile Quality Practices” helps teams identify where they are and where they can improve, using a framework that looks at ten different quality aspects. Plus, information on the book they are working on now on how to facilitate an assessment.
[39:03] - Brian provides a list of resources available from Lisa and Janet, including their books “Agile Testing Condensed: A Brief Introduction” “Agile Testing,” “More Agile Testing,” and Assessing Agile Quality Practices and their "Holistic Testing: Weave Quality into Your Product” free download.
[40:14] - Join the Agile Mentors Community to continue the discussion. If you have topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.

References and resources mentioned in the show:

Agile Testing Fellowship
Agile Testing - The Book
Agile Testing Condensed: A Brief Introduction
More Agile Testing
Holistic Testing: Weave Quality into Your Product
Assessing Agile Quality Practices
Mountain Good Software's Advanced Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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 SVP of coaching and 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.

Lisa Crispin is the Co-founder of the Agile Testing Fellowship, an author, and an Agile tester and coach, who helps practitioners deliver quality software frequently and sustainably.

Janet Gregory is the Co-founder of the Agile Testing Fellowship, an author, and a consultant, specializing in building quality systems and helping companies promote agile quality processes.