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.

Join Brian and his guest Bob Payne as they discuss the principles of lean thinking and how they apply to Agile methodologies.

Overview

In this episode of the “Agile Mentors” Podcast, Brian sits down with Bob Payne to discuss the intersection of Agile and lean thinking. As an experienced Agile coach and host of the “Agile Toolkit Podcast,” Bob shares his insights and offers practical tips for implementing lean thinking in your own team.

Listen in as they explore the fundamental principles of lean thinking in Agile methodologies. They discuss managing flow, not workers, and the importance of continuous improvement and experimentation to achieve sustainable, high-quality results in your organization and success in today's fast-paced business environment.

Listen Now to Discover:

[01:23] - Brian welcomes Bob Payne, the Senior Vice President of Training and Coaching at Lithespeed, as well as the host of the “Agile Toolkit Podcast” and the Chairman of the Agile DC Conference. Bob is here to discuss lean systems and lean thinking.
[03:57] - Bob explains how lean thinking is connected to Agile methods in knowledge work.
[07:30] - Agile methods generate value through teamwork that ultimately ends up in the customer's hands, and lean thinking is the larger circle that encompasses these methods.
[08:24] - Lean thinking involves discipline and continuous improvement, which are essential characteristics for any successful team.
[10:30] - Lean thinking also considers the sustainability of the workforce—workers are seen as producing value, while management is there to create the system that makes them the most effective.
[11:31] - Lean thinking provides inspiration for visual management systems (such as Kanban boards) to track work which is incredibly powerful (and were not invented by Agile methods).
[11:47] - Lean didn't just appear out of thin air; it built off of multiple things.
[12:17] - Lean principles are foundational, and empiricism is built into lean.
[14:34] - Bob shares that visualizing work is crucial to managing it effectively and citing the example of Toyota's electronic boards.
[15:52] - Managing the flow of work, not the workers. We aim for cross-functional, self-organizing teams in an Agile team to get the job done.
[17:05] - Bob shares an analogy about the workflow in a coffee shop.
[17:41] - Bob shares the lean thinking philosophy and discusses the use of on-demand planning and continuous improvement.
[19:14] - Brian introduces the sponsor for the podcast, Mountain Goat Software, which offers various training options for Agile methodologies. You can find their training schedule here.
[19:46] - The difference between fixing the system and fixing the people in terms of leadership— Brian highlights the importance of a holistic view of the organizational structure to support the work and the workers in lean thinking.
[20:36] - Brian shares the importance of limiting work in process within Scrum. He shares his experiences with XP teams and emphasizes the need to identify blockages and fix the source, not (just) the symptom.
[23:03] - Bob and Brian discuss how Agile methods often miss local optimization, focusing on fixing bottlenecks instead of making other parts of the process more efficient.
[25:23] - Bob shares how the focus on DevOps and better tooling has enabled Agile teams to go faster while maintaining safety (and avoiding burnout).
[26:30] - Bob shares a talk called "Project to Product: Practical Realities at Large Scale Enterprises,” Kevin Fisher gave at a DevOps conference about an end-to-end value stream analysis.
[27:40] - Bob discusses the need for a shift towards prioritizing rapid building and getting products to market, as Jeff Patton and Marty Cagan advocate.
[28:37] - Bottlenecks? What the Scrum Master should focus on.
[29:27] -Understanding the theory and philosophy behind Agile rather than just focusing on the practices is important. Brian shares why he believes it's crucial to recognize that the system needs to be fixed, not the worker.
[30:49] - Understanding the theory and philosophy behind Agile methodologies rather than just focusing on the practices for more successful teams is essential.
[31:18] - Bob talks about how teams should experiment with different ways of doing things and shares the early Agilists were making stuff up and pulling together ideas that worked. He spends the first hour and a half of his classes talking about the history and mindset of Agile and lays out these principles with case studies.
[35:24] - Check out Bob Payne’s work on his podcast, “Agile Toolkit Podcast,” and at Lithespeed.
[36:08] - 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:

Lithespeed
"Agile Toolkit Podcast”
Agile DC Conference
Project to Product: Practical Realities at Large Scale Enterprises
Mountain Goat 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.

Bob Payne is an industry-leading Lean+Agile Transformation leader with over 20 years of experience. He is the SVP of Enterprise Transformation at Lithespeed, the host of the “Agile Toolkit Podcast," and the Chair of the Agile DC Conference. With a wealth of practical experience, Bob has been a trusted advisor to executives, teams, and management at leading firms such as Walmart, National Geographic, and Samsung.

Join Brian and guest Christina Ambers on this episode of the "Agile Mentors" podcast as they discuss the importance of asking the right questions during a job interview to determine if a company (and its culture) is a good fit for you.

Overview

In this episode of the Agile Mentors podcast, Brian sits down with Christina Ambers to discuss the most important questions to ask during a job interview for an Agile role and the yellow and red flags to look out for.

Listen in as Christina shares her insights on which questions to ask in order to probe deeper and better understand the company's values and culture to assess whether the role is a good fit for you as a candidate.

Whether you're a job seeker or a hiring manager, this episode offers valuable insights into ensuring a good match between the company and the candidate.

Listen Now to Discover:

[01:13] - Brian welcomes Christina Ambers to the Agile Mentors podcast. Christina is an Agile Enthusiast, Enterprise Coach, Speaker, and owner of SMART ACE Formula. She’s also an active member of the Agile Mentors Community. Today we're discussing the topic of interview questions and why it's essential to ask questions during an interview.
[02:31] - Christina explains how asking questions during an interview allows the candidate to interview the company to see if it's a good fit for you.
[02:48] - Brian shares that having questions prepared shows a level of preparedness and readiness for the interview to determine if the company is the right fit for you, especially in today's job market with increased layoffs.
[03:54] - How asking the right questions can save you from frustration and a dead-end career
[05:01] - Christina shares a good starting point for asking questions that will help you determine what it's like to work at a company and help you get a sense of their culture.
[05:35] - Brian shares a tip on weeding out vague answers about culture and offers a warning of what to look for as an indicator that the culture isn't great.
[07:04] - Christina adds that if the interviewer relates culture to food or other benefits, it’s another warning sign that culture might not be taken seriously in the organization.
[07:58] - Christina suggests that these red flags could also be opportunities to improve the company culture if it's an area you excel in, offering a chance to make a positive impact and provide you with some job security.
[8:37] - Brian suggests asking a question that puts the interviewer at ease and helps them focus on the company's culture and offers an example
[09:09] - Christina shares her favorite question to ask in an interview, sharing that this question helps her understand what the interviewer expects out of your role.
[09:44] - Christina shares that if an organization's culture isn't conducive to improvement, that could be a red flag.
[10:36] - More than just a warm body—why it's essential to clarify what is expected of your role BEFORE you take the job.
[11:09] - How to avoid being the “new Dave.”
[11:46] - Christina shares how asking questions about the outcomes and responsibilities of the role can help a candidate identify any hidden or unexpected aspects of the position that were not included in the job description.
[12:30] - Asking the right questions to avoid misunderstandings (and wasted time and effort)— Brian shares his experience of being misled during the interview process by a company that claimed to be interested in agile methodology.
[13:50] - How flipping the question can help clarify what outcomes they expect from the role, especially when talking to the team, to understand how to be successful in the position.
[14:28] - Christina talks about clarifying whether the role is a replacement or a new role and how the company values the role.
[15:04] - Christina shares her concern about the company's expectations being too high, especially for a new role. She suggests asking whether the company is ready for the change and how much they value the new position.
[15:41] - Brian adds that asking how the team's performance is measured is essential. He recommends understanding what the company is trying to accomplish with the team.
[16:49] - Christina shares some yellow flags that provide room to grow and an opportunity for coaching.
[18:08] - Brian recommends asking how the company invests in employee growth to determine how they value individuals versus teams.
[18:40] - Brian shares the sponsor for today’s episode, Mountain Goat Software's Certified Scrum Product Owner Training which teaches how to use the product backlog as a tool for project success.
[19:17] - Christina talks about inquiring about how the company connects developers to actual customers.
[20:36] - A passion for continuing education: Christina recommends asking about how the company values additional learning experiences and how they reward individuals versus teams for continuing education.
[23:56] - Avoiding potential red flags.
[24:46] - Christina suggests asking about the company's changes since COVID-19 to find out how they respond to significant disruption and delving into employee longevity.
[25:58] - Brian emphasizes the importance of asking questions during the interview process to determine how Agile a company is right now and how they actually care for their employees vs. just what they can deliver.
[27:44] - The value of talking to other employees in the company.
[28:32] - How to determine how a company views work/life balance (and their flexibility for work from home).
[29:35] - Probing a company's attitude towards offshore or outsourced employees in relation to their in-office employees before starting to work for them.
[30:18] - Success isn't measured by simply sitting at a desk and typing—watching out for red flags indicating the company hasn't figured out what success means to its customers.
[31:05] - Determining the Agile framework of your future team.
[32:15] - What does Scrum mean to you—there might be more than one answer—how to find out and what follow-up questions to ask.
[32:50] - Connect with Christina in the Agile Mentors Community or check out SMART ACE Formula.
[33:39] - Join the Agile Mentors Community 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:

SMART ACE Formula
Mountain Good Software's Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Scrum Alliance
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.

Christina Ambers is a certified Scrum Master, Agile, and Kanban Coach with over 16 years of experience in software development and transformations. She is passionate about unlocking agile potential, inspiring teams to succeed, and applies agility and lean concepts in her everyday life. Christina is a founding member of the SMART ACE Formula and has worked with companies of all sizes and industries to help teams collaborate and work more effectively.

Join Brian and guest Scott Dunn as they share practical tips on navigating the challenges and achieving success in implementing Agile practices in regulatory environments on this episode of the "Agile Mentors" podcast.

Overview:

In this episode of the Agile Mentors podcast, Brian and Scott Dunn delve into the challenges of implementing Agile practices in regulatory environments. They discuss the importance of finding ways to work within regulatory frameworks, building trust with stakeholders, and adapting Agile principles to fit the unique needs of the organization. Listen in to discover practical strategies for navigating regulatory hurdles, effective communication with regulators and customers, and building a culture of continuous improvement in highly regulated industries.

Listen Now to Discover:

[01:30] - Brian welcomes Scott Dunn to the Agile Mentors podcast. Scott is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience. Today's show is focused on the listener-inspired topic of implementing Agile in regulatory environments. (If you want to hear something specific, you can email us at podcast@mountaingoatsoftware.com).
[02:31] - Change is hard. Sometimes you must dig deeper into the reasons for resistance, as it may not always be related to regulatory requirements.
[03:09] - Scott shares his experience working in a compliance-heavy environment, noting that the people responsible for compliance may not always fully understand the regulations.
[04:16] - Scott emphasizes the importance of researching the regulations independently. In his experience, mindset and willingness are key factors in successfully implementing Agile in regulatory environments.
[06:05] - Brian shares an anecdote about a pushback he received in a private class about whether Agile principles would work in the real world.
[07:59] - Scott shares a recent experience on a call with a Prime contractor for the government, where they discussed the government's modernization efforts and their shift towards agile methodologies. He also mentions the GSA's internal agile group, which requires funding recipients to adopt agile practices.
[09:19] - The issue of government contracts requiring specific roles rather than generalists and how this can limit the implementation of agile practices.
[10:20] - Scott discusses how contracts in government organizations can limit the ability to fully implement Agile principles and how to create change within their organizations.
[11:33] - Brian discusses the idea that a transformation is an ongoing process and not something that can be checked off as completed. He talks about the importance of continual learning.
[12:01] - Brian introduces the podcast sponsor, Mountain Good Software's Advanced Certified Product Owner course. He explains how the course can help product owners increase their confidence, credibility, and value.
[12:39] - The importance of collaboration over contract negotiation: Brian shares a story about Michael Sahota, who worked with the Canadian government on a bidding contract and revolutionized the government's fixed bid system.
[15:07] - Brian explains that while regulatory environments require more documentation, examining whether certain documentation is necessary is essential.
[15:54] - The need for empathy and understanding when working with regulatory environments.
[16:26] - Small nudges = Significant change.
[19:45] - The challenge of testing in regulatory environments, particularly regarding validation. Brian shares a story about a client with FAA regulations and how they tackled the issue, emphasizing the importance of collaboration.
[23:20] - Scott suggests a pragmatic approach to achieving work goals, acknowledging the external constraints that may prevent perfection.
[24:09] - Scott further explains that in some cases, there may be a sliding scale of achieving different levels of agility. Even small incremental steps towards agile implementation can provide benefits.
[25:37] - Brian shares what he considers the #1 win in implementing Agile into these types of environments.
[26:57] - What's possible? If you fast forward a year from now, what could be done now that gets us to the next step?
[28:10] - Think about how you are showing up: the importance of facilitating idea-generating conversations and the type of leadership it takes to start those conversations and helps make the right thing happen.
[29:30] - Scott and Brian discuss the quote, "if you're the smartest person in the room, you're in the wrong room," and how important it is to be around people who can push you and help you grow.
[30:52] - Join the Agile Mentors Community community to continue the discussion. If you have topics for future episodes, email us at podcast@mountaingoatsoftware.com.

References and resources mentioned in the show:

Mountain Goat Software's Advanced Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Agile Manifesto​​
Scrum Alliance
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.

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.

What does soccer, soda, and software have in common? According to Jim York—everything. In this episode, he and Brian Milner break down what great teamwork really means, why shared goals matter more than job titles, and how understanding your team’s unique contribution can unlock better flow and results.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner sits down with veteran Agile coach and trainer Jim York for a deep dive into what makes real teamwork tick. They unpack what separates a group of coworkers from a high-functioning team, explore the role of shared goals in driving motivation, and walk through value stream thinking using vivid analogies from sports and soda cans alike.

Whether you're part of a Scrum team or leading cross-functional initiatives, this episode will help you think differently about collaboration, flow, and how teams can work better together.

References and resources mentioned in the show:

Jim York
Jim's Blog
Jim's Video Library
Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James Womack & Daniel Jones
Liftoff Vision: Launching Agile Teams and Projects by Diana Larsen & Ainsley Nies
GoatBot
Join the Agile Mentors Community
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.

Jim York is a business owner helping teams discover how to delight their customers. He uses systems thinking, agile and lean to co-create resilient, learning teams. As a coach, he works with his clients to help them grow in directions that matter to them to achieve their goals. Jim is a Certified Agile Coach®️, holding both the Certified Enterprise Coach and Certified Team Coach credentials; Certified Scrum Trainer®️; Agile Fluency®️ facilitator; LeSS Practitioner. In 2007, Jim co-foundered FoxHedge Ltd with his wife, Melissa York.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the very distinguished gentleman, Mr. Jim York with us. Welcome in, Jim.

Jim York (00:12)
Well, thank you, Brian. Glad to be here.

Brian Milner (00:15)
Very excited to have Jim with us. We were just chatting before and Jim and I met years ago at a conference. We got introduced by a mutual friend, Mr. Kurt Peterson, who has been on the show. He came on a little bit earlier to talk about Kanban. And just for those people who aren't familiar with Jim, Jim is a co-founder of a company called Fox Hedge. And he has been an Agile coach, a Scrum trainer for quite a while now and I give him the title Luminary, kind of scrum luminary, thought leader, been around doing this for a while. I hope that doesn't sound insulting in any way, Jim, to call you that.

Jim York (00:55)
Nope, nope, just trying to shine my light and help others shine theirs. So that's what a coach does. So.

Brian Milner (01:00)
Awesome, Cool, well, we wanted to have Jim on because we had this topic that it's kind of a broad topic, but it's, I think, actually crucial to today's world. And that's just the broad topic of teamwork itself. So I'll start this way, Jim. I want to get your opinion. In today's world, with the changing kind of landscape with AI and everything else that we see that's kind of influencing how we work, has teamwork had its day? Is it time now for something new or is teamwork still the best way to build things?

Jim York (01:34)
Yeah, well, teams are universal. I think once you get more than one single individual and you get some task that requires more than what one person can do, it's inevitable. We've to work together. And so I don't see that going away. It might change a bit. But in many ways, think the things that we face today are, in many ways, things that we faced before. They might be showing up in a different way, but I think there's some universality. universality to teamwork. Brian Milner (02:03) Yeah, I agree. And so what do we mean by teamwork? Why don't we define that a little bit for everyone?

Jim York (02:09)
Yeah, I guess we have to step back and start looking at what's a team. If we talk about teamwork, there's this whole expression, teamwork makes the teamwork. So what's a team? And the classic definition of a team is it's a group of individuals working on a shared goal. And so it's kind of like built into the definition, we're working on a shared goal. So teamwork is that combined action.

Brian Milner (02:13)
Yeah. Yeah.

Jim York (02:32)
And so that's kind of the general concept. It's, you know, some of the parts, you know, is greater than the whole. And so it's taking that mix of experiences, knowledge, skills, and bringing them together and having that dynamic, that energy, and kind of focusing it in the same direction. You know, that's really what teamwork is about.

Brian Milner (02:55)
Yeah, it's good to clarify it, because I think the word team gets quite widely used in today's world. you'll hear people describe that, hey, that's my sales team. When you look at it and how they actually work together, there's not really a lot of teaming actually happening. It's just a group of individuals who have the same job and that. that format. I do think you're right. It's important to understand the difference between that kind of a team and what we're talking about here as a team.

Jim York (03:25)
Yeah, there are different kinds of teams and people in a sales team, even if they're not working with each other, the fact that they have a shared goal does create some sense of team. And there's different teamwork where everybody's providing kind of their unique thing. And then you have, I think like a team in a rowing, when you have like four people in a rowboat. they might have somebody who's steering the boat, you know, but they have the four people holding onto the oars and, you know, they're working at a similar cadence. You can say to a certain degree they're individuals. I don't know if they're fungible. I don't think they're necessarily fungible, but they're working together to accomplish that shared goal. know, the people in rowing, that's different from people on like a soccer team. You know, on a soccer team, you're... You got the whole pitch, you know, you're all over the place and the ball's moving around and there's this kind of coming together and going apart of various team members interacting at different places and at different times throughout the game. You're kind of acting dynamically to where the ball is and where the opponents are and where they are on the field. And so there's this creativity that occurs there that's kind of a different kind of creativity than you might see in a rowing type of competition.

Brian Milner (04:18)
Yeah.

Jim York (04:42)
But yeah, I think there are different kinds of teams, but I think that universal theme of being a group of individuals that are having that shared goal, I think that's the thing that's in common. It's not the nature of the work that some people might call agile versus predictive or planned work. mean, the concept of a team is more universal thing.

Brian Milner (04:43)
Yeah. Yeah. I like the example of kind of the crew, right? Of rowing and stuff. I think that's a good picture because you're right. I mean, it's very subtle, but there's a lot of combined movement. And if one person is off a little bit, it really affects how others are working. I've used the example sometimes in my classes as a contrast to think about like a golf team. You know, like the idea that you have the group of people who, again, I say this in classes. So anyone listening to this who's a golf expert, it really loves golf. Please, email in and tell me if I'm wrong about this. But this is what I say in my classes. You know, if you're on a golf team, it's a group of individuals who are each shooting their own 18 holes. But then at the end of the round, you just total up the score. And if you have the lowest lower score than another team, then you win, right? But it's, When I'm shooting my 18 holes, I'm not necessarily aware of what everyone else on my team has done or what they're doing at the same time. We don't play off each other, right? I don't take the first shot and then they take the second shot. It's all on me to do my best. And then hopefully everyone else has done their best and we just kind of see how it works out at the very last second. Yeah.

Jim York (06:17)
Yeah, so teams are different. know, teams are definitely different. And I think it's that idea of the shared goal that is the thing that kind of the glue that holds the team together and that shared goal that can be at various levels. I mean, it can be at this grand big picture level. You know, sometimes what's referred to as a product vision, it can be at a more discrete team level. Sometimes that's referred to as, you know, our our unique contribution to the product division. So that would be like our team mission. And then there's maybe, you know, a specific task. And so, you know, we might be working on a specific, very small, discrete task. And, you know, there's a potentially a group of people working on that thing. And, and, and those people have that shared goal of moving that task, you know, through a process to a completion state. And so there's, there's some variability here in the different kind of levels and Hopefully, there's some alignment between those different levels when you're talking about a team.

Brian Milner (07:14)
All right, so there's some different kinds of teams and it kind of is wide ranging in how we would describe it. There's different configurations, but we have a single purpose. We're working together towards a single purpose. That's kind of our unifying factor there. So then what makes teams work? What's the glue other than our purpose? How do we actually... Combine efforts, how do we play off each other's strengths? How does that happen?

Jim York (07:47)
Yeah, well, it depends, right? I mean, that's the classic consultant's answer. It depends. How do we play off of each other? If you're in an environment where you've got a known solution to a known problem and you're just executing steps in a plan, those dynamics are pretty well understood. People in that process can be trained to do different types of activities. They can gain experience in that.

Brian Milner (07:50)
Yeah.

Jim York (08:08)
That's a fairly predictable kind of process, but then there are others where it's emergent. And so we have to kind of figure it out on the fly as we go. And even those environments where it seems that we've got a pre-existing solution, there is a very clear variable there, and that's people. People show up different every day. I might have had a poor night's sleep, and people might think, well, Jim's normally fairly easy to work with, but wow, today he's... got a short temper or whatever it might be. And so we have to of figure out on the fly how we adapt to those variables. anything that has to do with people, you're going to have some variability. think stepping back, Brian, I think one of the things that is important to kind of understand or get a sense of what part of the system that we want to understand when we're talking about a team and they are dynamics, they actually are fitting within some sort of product ecosystem. And so where are the boundaries of what we mean by our shared purpose, our shared vision within that ecosystem? There's a classic book called Lean Thinking by James and Womack. And there's a really interesting example, simple diagram in the book of a value stream. And it's a value stream of a cola can. And it's kind of fascinating. You kind of see this very simple value stream in there and it starts with aluminum being, well, not the aluminum, but the bauxite actually being mined. And it goes through a reduction mill and then to a smelter. And then it goes through some hot rolling and cold rolling process. And so finally you get basically rolls of sheet aluminum that go to a can maker and the can maker is cutting the cans that are then formed into the cola can. You know, and that can maker is actually the middle of the value stream because all the things I've described so far are upstream. Downstream of the can maker, once they've made the cans, the cans go to a can warehouse somewhere and they sit there until a bottler says, hey, we need some cans because somebody's ordered some cola. And so, you know, the cans make their journey to the bottler and they get filled and then they get...

Brian Milner (10:01)
Hmm.

Jim York (10:17)
go to a bottling warehouse and of course there's transportation, there's trucks carrying these empty cans from the can maker to the bottler and then the filled cans from the bottler to the bottler warehouse and then ultimately they go to some wholesale operation and then to a retail store and then you and I perhaps will go into the store and buy a six pack of cola and we go home and we drink the cola. And so you see this very simple kind of journey, this little value stream. from the perspective of the can maker. And so, first time I encountered that value stream, I'm sitting there looking at the can maker and I'm asking myself the classic question that I ask my clients. One of the first questions I ask is, who's your customer? And so for the can maker, it can be very easy to look at that and go, well, it's the bottler because the bottler is the one who places the orders for the cans. So clearly the customer for the can maker is the bottler. Of course from a lean perspective we look further down the stream We were looking at the end of the stream to see you know, what's what's it all for? What's it all for? And if you look at the diagram you get to you know finally to the end of the stream and there's the home where the person's potentially sitting on their couch and enjoying you know that that cola and so you know if you think about all the different steps along the value stream from the mining to the to the smelting to the bottler and

Brian Milner (11:17)
Ha Yeah.

Jim York (11:38)
the can maker themselves, the retail store that's selling the cola. The thing that you would ask them that would be the glue that would hold them together for this would be what Diana Larsson and Ainsley Nees call in their lift off book, the product vision. And so the product vision is really kind of what's it all for? And the cool thing about a product vision is it's very concise, it's very succinct and everybody can hold it in their heads very easily because of that. It's typically one sentence. And so I'm going to speculate this because I'm not a, I'm not part of this value stream where Cola makes its journey to people in their homes. But I'm guessing the product vision for all of these various people along the value stream boils down to something along the lines of our customers enjoy a convenient, refreshing beverage. And so the cool thing about that simple statement is that

Brian Milner (12:23)
Mm-hmm.

Jim York (12:28)
If you were to go to the mine and ask a miner and say, some of this bauxite that you're mining, in the context of this soda, what's it all for? Now, they're probably mining bauxite for a variety of different customers and a variety of different products. But in the context of this particular value stream, they could look down to the end of the stream and say, it's all about that person sitting on their couch at the end of a long day who simply wants to have a convenient, refreshing beverage. And so that's what you know, this particular product vision is. And so that kind of calls into view a couple of things. One is context is important. So when we're talking about the product, we have to be very specific about what it is that we mean, who is that customer at the end of the stream, and what is the experience that we want them to have. And so this product vision is, as I said, very simple. our customers experience a convenient, refreshing beverage. Now, that makes it simple in terms of this particular value stream, but it also makes us aware that it's very complex for the miners because they've got to deal with competing interests from a whole lot of different customers. And so if they've got limited capacity, they may be trying to figure out, which customer do we satisfy? And so the usefulness of the product vision is being able to go to that mining company and say, do you find value in, do you want to support this activity of creating this experience for this customer with convenient refreshing beverage? And if they buy into that, if they agree with that, that's your leverage, that's your argument. why you should deliver against this value stream versus some other value stream. Now, you don't always win that argument, which is really what life is about, is we're always dealing with trade-offs and we're dealing with different options or opportunities. And so I think that's one aspect of this. But when we talk about the team in the context of a product vision, The team is huge. The team is absolutely huge because it's not just a can maker and the can maker team. It's also the bottler and the bottler team. It's maybe the truckers union that's providing transportation between these different things. the retail store. It's the retail warehouse. All of them potentially have their own concept of team. And in order to create value, it's not just what you do and provide to your next partner on the value stream. You have to really pay attention to the entire value stream because ultimately anything that doesn't come together in the right way at the right in the right place right time It puts it all at risk It puts it all at risk. So I think it's important that we kind of understand the product vision this highest level glue that holds us together and then at a more discrete level look at your team, for example the can maker and What is their unique contribution? In Liftoff, Diana Larsson and Ainsley Niece call this the team mission. And so what is the team's unique contribution to the product vision? And so for the can maker, it's also fairly simple. It's like, we make the cans. And they could flavor that a bit with, they use the latest technology and they use environment. sensitive manufacturing processes, know, they source things using sustainable, you know, approaches and the like. at the team mission level, we're getting a little bit more discreet in terms of what it is that that team is contributing to the greater whole. So think part of this is just kind of stepping back and thinking about what it means to be a team.

Brian Milner (16:12)
Hmm.

Jim York (16:24)
You know, are we talking about we're a team that's the collection of all of these things? At times that might be a useful way of thinking about it. At other times we need to kind put our heads down and focus on what our unique contribution is and make sure that we're doing the appropriate job there.

Brian Milner (16:24)
Hmm. Yeah, this is fascinating because so what I'm hearing is that really we have to expand our thinking a little bit about teams because teaming teams are, know, in one sense, the small group that you're working with on a on a regular basis, but it's there's a larger team concept as well of the entire value stream from end to end. All the people who are contributing, they all are are working towards that ultimate goal of, in your example, someone having a refreshing beverage at the end of their long, day at work? And how often do we actually realize that or look at that? Are the miners really even aware of the fact that they're contributing to that sort of a larger team goal? I think that's a great question.

Jim York (17:21)
Yeah, that's an excellent point. And what are the implications of either that awareness or lack of awareness? And I think this kind of comes to play when we think about what motivates teams. If all I know is that I'm mining bauxite, that might work for some folks. That's enough motivation. Sometimes people say my paycheck is enough motivation.

Brian Milner (17:44)
Ha ha.

Jim York (17:45)
But if you really understand what it's all about, that maybe ties into a bit of self-worth, that I'm a contributing member of society. It could also help you make the right decisions and perform the right actions if you know ultimately what this is gonna lead to. And sometimes that's a calculation that's done in terms of the quality. of the work that you're doing or the output that you're creating. For certain applications, the quality might have certain characteristics where the quality has turned up very, very high in some areas or maybe it's lower in other areas because it's good enough. And if you overbuild quality, you might be introducing some waste because it's not. It's not necessary for the job at hand. In other places, if you deliver below quality, you introduce some risk that the product is not going to be, or the ultimate customer experience is not going to be what it is. I don't know about you, but I've occasionally gotten one of these plastic soda bottles where they've made the plastic so thin for the soda bottle that the liquid is actually needed inside the bottle to maintain the structural integrity of the bottle.

Brian Milner (18:54)
Yeah.

Jim York (18:54)
And if I were that customer sitting on the couch at the end of a long hot day, let's imagine it's a white cloth couch and I'm drinking orange soda and I reach over to pick up the soda and my hand, you know, grasping around the soda bottle, all of sudden the soda bottle just collapses in my hand and orange soda goes all over me and the couch and everything else. mean, that's, you know, there's some quality characteristics, some specifications around that.

Brian Milner (19:02)
Ha ha ha.

Jim York (19:18)
container that that plastic container that has to integrate well into the rest of the process. It has to work with the bottler and it has to work with the consumer when they're actually using it. So it's understanding the whole can certainly help teams feel a sense of purpose and also can guide that decision making in those actions around it.

Brian Milner (19:30)
Yeah. Yeah, I think that's an important thing to keep in mind and remember because, you you mentioned, you know, some people would say paycheck is a motivator. And I, you know, I, I kind of subscribe to the Dan Pink kind of motivation philosophy that, know, that, can only do it so far that it is a motivator, but it is a motivator only to a certain point. Beyond that point, we need more. We need more to motivate what we're going to do. Cause you know, there's a million things out there that can give me a paycheck. I could work in a lot of different places, but I've chosen to do what I do for a reason. There's something that fulfills me from doing that, or I prefer it in some way to what my other options might be. I know I've heard people say this in classes before, the idea of how do you have a vision for somebody who builds clothes hangers? We have this talk about vision, this grand design. Big purpose. Well, how do you do that for someone who has clothes hangers? You know, like I get that, you know, there's not everything, every product in the world has, you know, a save the world kind of vision, right? But I think you can, in your example of kind of the mining thing, I think is a good example of this because you can connect it to that ultimate value. And when you connect to that ultimate value, it doesn't that motivate people more to think, hey, I'm helping someone who's had a hard day. I know what that's like. Have a hard day, sit down on your couch and you just want to relax a little bit. Yeah, I want to help that person. Like that, is something that that'll gets me out of bed, you know?

Jim York (21:06)
Mm-hmm. Yeah, and I think that does require you to think beyond what we often think of as being the team. Because to make it all come together and result in that ultimate product vision, that, you know, the person having the convenient refreshing beverage, in my example, you know, all of those different parts have to come together. And any one of them, if it doesn't happen, you know, that we don't have that value that's realized at the end of the value stream. And so having that connection to what it's really ultimately about is critically important. And understanding where you fit into that and what your value add work is, I think is critically important. And so we talked about like at high level product vision, we talked about this unique contribution of your team like the can maker, and so our team mission, we make the cans. And then we get to the practicalities of the task that's in flight, the work that we're doing right now. And I think that's a critical piece of this puzzle. What is it that's the thing that's being acted upon right now? The work in process or the work in flight. And depending on what the nature of that is, I think that drives a lot of... decisions and one of them is around, you know, who do we need? So who are the actual people, you know, that have the right skills, knowledge, experience in order to do that work? And also it informs our process and so, know, again, that process could be something where it's a known process and we're just, you know, turning the crank or it might be something where we're having to figure it out on the fly. Regardless of the nature of the work, there's going to be a workflow. When we're trying to get something done, the work is going to be flowing through some sort of process. And it's that flow that really intrigues me. we want to look at the flow, especially if speed matters. And why would speed matter? Sometimes speed matters because customers want what we are building yesterday. So they want it as soon as possible. So time to value is often what's considered there. If we're something new that hasn't existed before, sometimes we're also building quickly so we can get it in front of someone to get their reaction to see whether it's fit for purpose. So we might think of that as being time to feedback. But the flow itself is there's the workflow. And so work, the nature of it is a piece of work is something that maybe an individual can go work on. Other times there's a piece of work that requires more than one person to work on. So there's an element of collaboration with that. Even when it's an individual that can work on a piece of work, usually they've received something from somebody that allows them to start that piece of work. And when they're done with that piece of work, they're passing what they've done along to somebody else and that other person is picking up. So even if... there's an ability to work on a discrete task by yourself, there's still an interaction often on the front end of that and the back end of that. So work is still flowing and we have to figure out how to collaborate in such a way that the work that is not being held up in some queue somewhere where we're getting some bottlenecks and that they're constraints. so figuring out how do you enable the work to flow and how do you enable the people to flow? Years ago, I had an opportunity to coach soccer and on my team, I taught them, in addition to like skills, I taught them three concepts. And so the first one was, everybody on the team should know where the ball is. And so it seems pretty obvious, you should know where the ball is. But if you look at this from a team building software perspective, does everybody know where the ball is? You know, what is the work that's in flight and what's the current state of that? I mean, we use information radiators to try to help people understand where the ball is, but often I don't think we use them as effectively as we might. So I'm always challenging teams to figure out, you know, how do you use your communication systems, your information radiators to enable everyone in your ecosystem to understand, you know, what's the work in flight and what is its current state? And why do you need to know that?

Brian Milner (24:55)
Hmm. Yeah.

Jim York (25:24)
Well, if you know where the ball is, you can get a sense of what are the things that are in the way of that ball moving forward. So my second rule for the team was know where your obstacles are. And so in a soccer game, you're seeing your opponents. And so you might have a great plan on how you're going to advance the ball from where it is currently down the field towards the goal. But little problem with that. You've got people on the other team trying to keep you from getting there. So you're having to react real time in the moment to those obstacles. And so in addition to everybody on the team knowing where the ball is, everyone on the team needs to know where the obstacles are. And so when you have that information, and again, for a team building software, this is the kind of thing that should be readily available in some sort of information radiator, real time ability to see where the ball is and to see what's in the way. Why is that important? Well, if you know where the ball is and you know where the obstacles are, you can position yourself as a team member to be what I called the help. And so by the help, that's the one or two people on your soccer team that if you're the one with the ball, you know you can pass to them easily. You know, that they are constantly moving around and positioning themselves to be in the place where it's possible for you to get the ball to them. So who are those two people? Well, it changes depending on where the ball is. And so what the team has to do is kind of get a mental mob.

Brian Milner (26:41)
Ha ha.

Jim York (26:47)
in their heads of the actual position of people on the field and get a sense of if the ball's here and the obstacles are here, then I should put myself here. Now, it isn't for all the team members to position themselves to be the help because that would be crazy. Just as we see on Agile teams, when somebody picks up a task, the whole team typically doesn't swarm on that task. It would be too many people on the task.

Brian Milner (27:06)
haha

Jim York (27:16)
So who shows up to work the task? The right number of people with the right skills and knowledge. So how do they know to come? It's because the work is made visible. And so they come because they see that they're needed. How fast do they come? Ideally, they're there instantly. Now, why might they not be there instantly? Because they might be working on some other tasks. And so if this were to happen in soccer game, you would see the other opponent, you know, they would be... basically scoring goals against you right and left because when you try to pass the ball, you wouldn't have somebody there to receive the ball. So knowing where your help is, if you've got the ball and passing it to that person helps you continue the flow down towards the goal. So if you're not the person who has the ball and you're not one of those two people that are the help currently, What you're doing as another team member is you are. orienting yourself on the field so that you will be the help when it's needed. And so there's this constant movement of people down the field. And where this really brings it home, I'll use this example, and I'm coaching agile teams, is they'll talk about how all their work and stuff, and I'll use the example of the soccer game and the one ball, and they say, now let's imagine you put two balls in flight.

Brian Milner (28:16)
Hmm, that makes sense, yeah.

Jim York (28:36)
Can you optimally move those balls down the field towards your opponent's goal? And typically, there is a limit, right? How many balls can you put on the field? Two, three, 15? It's like, yeah, it really drives home the point of limiting the work in process. the teamwork is made more effective and efficient if we have some sense of where the work is, what is the nature of it so that people can come and go, I call this people flow. so we're looking at things like the, well, out of...

Brian Milner (29:05)
Yeah.

Jim York (29:09)
out of the concept of open space, the law of mobility. It's like within our organizations, within our teams, can we have people flow to where the work is needed and also have people flow away from the work when they're not needed? And so enabling that autonomy of the individual to be able to go where they need to go in order to optimize the flow is a...

Brian Milner (29:13)
Yeah, yeah.

Jim York (29:34)
is a key organizational design problem.

Brian Milner (29:37)
Yeah, yeah, this is fascinating stuff. mean, I love the analogy with the soccer teams and that I mean, I, that makes sense to me. I love kind of where you're going with this. If people are hearing this and thinking, well, I like to hear more about this stuff. We're going to put links in our show notes back to Jim's site on this because he's got a lot of blog posts. They're kind of around the same theme on this. And we'll link to those specific blog posts for you so that you can find them. But Jim, I want to be respectful of your time and our listeners' time. So thank you so much for taking your time out to share this with us.

Jim York (30:08)
Well, I've been very pleased to join you, Brian. Thank you for the opportunity.

Brian Milner (30:13)
Absolutely.

In this episode of the “Agile Mentors” podcast, Brian and Anu Smalley share their perspectives on the relationship between culture and Agile transformation and why people are key.

Overview

Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success.

In this episode of the "Agile Mentors" podcast, Brian and Anu Smalley chat about the importance of diversity in Agile teams.

Listen in as Brian and Anu explore how culture impacts an organization's ability to adopt Agile practices, the role of leaders in creating an inclusive culture, and the power of sharing stories in building a strong community.

Listen Now to Discover:

[01:17] - Brian introduces us to the guest, Anu Smalley, who has a lot of experience in Agile coaching and consulting. She’s also been instrumental in increasing diversity in the Agile community. She has a CST mentoring group for people who don't have the same background as the majority of people in the Scrum Alliance. Her company is Capala Consulting Group.
[03:34] - Metrics and methodologies are important in organizational transformation, but people are at the heart of it. Organizations cannot successfully transform without the right people.
[04:02] - Anu talks about how the Agile Manifesto emphasizes individuals and interactions as the key to success in transformation. She emphasizes the importance of having the right people in an organization to ensure a successful transformation.
[05:07] - Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success.
[05:55] - Brian notes that some businesses see their employees as replaceable parts in a machine. A diversity of perspectives is essential; having only one perspective limits the team's potential.
[06:52] - Each person is unique and cannot be replaced like a part in a machine. Anu stresses the importance of recognizing the human aspect of transformation to succeed and that metrics alone will not suffice.
[07:48] - Brian discusses the comparison between Agile software development and research and development. Having the right people for the job is critical. [08:30] - Agile transformation requires a focus on people and coaching, and the framework will fall into place once that focus is in place.
[09:14] - Anu highlights the importance of understanding what being Agile truly means rather than just knowing the techniques.
[09:59] - Brian notes that while many attendees may attend Agile training classes solely for certification, trainers can use this opportunity to teach attendees a deeper understanding of Agile and transform their approach to work.
[10:46] - Anu notes that there is a significant difference between implementing Scrum and transforming an organization—one can be learned in a two-day class, while the other requires a deeper understanding of what being Agile truly means.
[12:02] - Focusing on people is the key to success in Agile transformation; without it, organizations will not get very far.
[14:17] - Brian emphasizes the uniqueness of organizations and how Scrum is designed to be adjusted and custom fit for each group that uses it.
[14:49] - Anu highlights the importance of role clarity for individuals and teams to minimize conflicts.
[15:53] - The virtual world has made role clarity even more important. Anu shares an example of a client whose main focus for 2023 is to achieve role clarity amongst their teams, explaining what is essential to achieving this goal.
[16:19] - Clarity is achieved by bringing people together, resolving conflicts, and working towards common goals.
[16:19] - Anu emphasizes that coaching and resolving conflicts are key to achieving role clarity and smooth functioning among teams in an organization.
[16:37] - Brian compares learning the basics of baseball to attending a class on Scrum—a class can teach you the basics—a coach is necessary to grow and improve.
[17:50] - Anu shares that a coach is essential, even for the best sports people on the planet.
[16:19] - Anu emphasizes the importance of role clarity and resolving conflicts in an organization to ensure everyone understands their role and works together effectively.
[18:39] - Anu explains that the best players in any sport have personal coaches to keep them in the "being mode," focusing on the individual's growth to impact the company's growth.
[19:33] - Brian highlights that even the best athletes in the world have coaches, and we should always keep growing and never stand still.
[19:51] - Agile transformations are about the people we have—Anu reiterates the importance of focusing on individuals' growth to impact the company's growth.
[20:12] - Leaders need to ensure they have the right people and are continuously teaching, coaching, and helping them move forward.
[20:35] - Brian introduces the sponsor of the podcast, Mountain Goat Software's Certified ScrumMaster Class, and highlights its benefits for those interested in understanding Scrum.
[23:34] - Anu shares examples of clients who have decided to combine roles or accountabilities due to budget cuts and how it impacts the Agile journey.
[24:40] - Anu advises against continuing the Agile journey until it can be done properly.
[25:43] - Leaders often make the mistake of not understanding the importance of ScrumMasters, but ScrumMasters do, in fact, provide value (a little sarcasm here).
[26:00] - Without capable ScrumMasters, the transformation will stall or fail.
[26:39] - Brian notes that even with capable ScrumMasters, leaders must trust and empower them to drive the transformation forward.
[27:02] - Culture is all about people; if you don't have a culture supporting Agile transformation, it won't go anywhere.
[27:55] - Talking about trust issues between leadership and teams.
[28:55] - Anu explains that some leaders may have talented staff, but they are too scared to trust them with an Agile transformation because they are worried about the culture and power structure changes.
[29:35] - Brian suggests an innovation initiative, to which Anu sarcastically proposes an innovation sprint as a solution.
[29:47] - Brian encourages listeners to contact Anu through LinkedIn or through the website of her company, Capala Consulting Group.
[30:52] - Anu invites listeners to share their Agile transformation stories with her and promotes the importance of building a community through shared experiences.
[32:58] - The value of learning from different cultural perspectives.
[33:17] - Brian invites you to share your ideas for the show or feedback. Email Brian.

References and resources mentioned in the show:

Capala Consulting Group
Mountain Goat Software's Certified ScrumMaster Class
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Agile Manifesto​​
Scrum Alliance
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.

Anu Smalley is the President and Founder of Capala Consulting Group, where she specializes in Executive Coaching and Agile Transformations. She is a Certified Enterprise Coach and Certified Scrum Trainer®. She’s an active member of the larger Scrum and Agile community and enjoys giving back via volunteering at various conferences.

In this episode of the Agile Mentors podcast, Brian and Richard Cheng discuss the challenges of working in a virtual environment, sharing insights and strategies for maintaining team collaboration and communication. Listen in for practical tips and expert advice on navigating the changing landscape of remote work.

Overview

In this episode of the "Agile Mentors" podcast, Brian and Richard Cheng discuss the challenges and opportunities of the ever-evolving world of remote work in Agile teams and the role of technology in supporting Agile practices.

Listen in as they share their insights on the tools to use, how to maintain team cohesion and collaboration, and the importance of culture and personal connections. You'll find practical tips and inspiring ideas to help you navigate the virtual landscape and thrive in the new normal of work.

Listen Now to Discover:

[01:14] - Brian introduces Richard Cheng, founder of Agility Prime Solutions, trainer, teaching CSM, product owner, and combat classes. He is also working on a graphic novel about the adventures of a scrum master. He's here today to discuss the challenges of working.‌
[04:16] - Richard highlights the significant shift towards virtual work that was already happening before the pandemic and the adoption of virtual work tools such as Zoom, Miro, and Slack, which made the transition easier during the pandemic.
[06:22] - Richard emphasizes the importance of using tools that foster better communication and collaboration rather than replacing them. The tools and policies around them should enable people to work better together rather than create more distance.
[07:08] - Richard is relatively agnostic regarding specific tools, but he mentions that he is a huge fan of Zoom for instruction and prefers Miro or Mural for collaboration.
[08:03] - Brian tends to use Mural but also acknowledges the benefits of Miro (and shares a fun fact about Miro).
[09:42] - Brian advises against letting the tool drive the collaboration process and instead focusing on conversations and collaboration first, then finding tools that enhance that process.
[11:00] - Richard agrees with the idea that tools should not drive the team's workflow, but rather the team should drive the tools using the example of Jira™. He advises teams to tailor their tools to support their evolving needs.
[12:46] - Brian acknowledges the importance of standardization in big enterprises and advises teams to refer to items in their terms to better align with their workflow.
[14:20] - Brian shares why tools that allow deep customization are enormously useful because you can implement a wealth of plugins.
[15:01] - The key to keeping it simple—strip it down to the bare bones and then grow it. Richard shares an example from the best Agile shop he ever worked at, The Motley Fool, and their tools, including Bugzilla.
[16:00] - Brian shares the sponsor for the podcast, Mountain Goat Software, and the team home software they use for their Agile and Scrum Training.
[18:39] - Richard discusses the virtual challenges of creating culture and teamwork, including communication, collaboration, and cross-functionality.
[19:15] - The new frontier for companies: experimenting with different methods is essential while adapting methods to make them more effective.
[20:46] - Richard discusses the issue with the Scrum guide's statement that Scrum is immutable, stating that once you're an expert, you should take what works and tweak what doesn't, drawing on an analogy about CrossFit, where workouts can be scaled up or down, and suggest that Scrum should be approached similarly.
[23:48] - Promoting conversation and collaboration between teams, which is a big issue for many teams in the virtual world. Brian points out that time zone differences can be a problem. People on the other side of the globe must experiment more with asynchronous tools to communicate and collaborate effectively.
[24:49] - Collaboration is less about geography and more about times. He promotes time zone friendliness to enable teams to collaborate more effectively and independently. Richard recommends setting up time zone-aligned value streams to improve product and service delivery speed, particularly for organizations with teams in multiple time zones.
[26:25] - Brian emphasizes the importance of maintaining company culture in a virtual environment. He recommends virtual show-and-tell sessions to build a deeper connection among team members.
[27:51] - Richard suggests that events such as game nights and virtual chocolate tastings can help bring teams and organizations closer together, even in a virtual environment. At the same time, optional in-person events for geographically connected teams can also be a good way to foster a sense of togetherness and culture.
[29:15] - To help improve communication and strengthen the team's dynamics, create user manuals for team members: that includes their background, contributions to the team, and
[30:37] - As a Scrum Master and Coach, being there and having osmotic communication was a big part of the job. Without it, we have to engineer everything, which can be challenging.
[31:30] - Brian acknowledges that technology is rapidly changing but emphasizes the importance of not letting the tool drive the conversation. Instead, he suggests promoting collaboration and enabling teams to work better through policies and practices that bring the team together and rethink those that separate them.
[32:56] - You can learn more about Richard and his classes at Agility Prime Solutions or email him at richard.c@agilityprimesolutions.com.
[34:24] -Join the Agile Mentors Community for further discussion, and if you have an idea for the show or feedback, we'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Agility Prime Solutions
Mountain Goat Software Certified Scrum and Agile Training Schedule
Mural
Miro
Jira
Bugzilla
Private Virtual Chocolate Tastings– Bar & Cocoa
Join the Agile Mentors Community
Scrum Alliance
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.

Richard Cheng is the founder of Agility Prime Solutions, which provides training programs that focus on Agile, Scrum, Kanban, and Product Management. Richard is a founder and was an executive committee member of the Agile Delivery for Agencies, Programs, and Teams (ADAPT), an Agile government task force.

Join Brian and Bob Galen, Agile Coach and author, as they explore the significance of self-mastery in leadership and coaching.

Overview

In this episode of the Agile Mentors podcast, Brian and Bob Galen, Agile Coach, author, and podcast host, discuss the importance of self-mastery for leaders and coaches.

Bob emphasizes the significance of self-reflection, journaling, and introspection as tools to mine valuable information from one's history in order to move forward successfully.

Listen in to understand the crucial role emotional intelligence and self-mastery play in leadership and coaching and how one can balance their needs with those of the team and organization.

Listen Now to discover:

[01:09] - Brian welcomes Bob Galen as a special guest on the podcast.
[01:30] - Brian and Bob discuss the concept of inside-out mastery for an agile coach.
[02:32] - Bob explains that the agile coaching growth wheel emphasizes self-mastery as a central aspect for coaches to consider.
[03:42] - Self-mastery is a mindset that emphasizes coaching from the inside-out. It includes coaching presence, listening skills, and self-care.
[05:00] - Bob emphasizes the importance of having a coach and active mentors to improve self-mastery and humility.
[07:40] - Bob discusses the importance of continuous improvement of agile coaches and leaders for self-mastery and shares his own journey.
[09:12] - Bob emphasizes the importance of becoming a "feedback sponge" and activating self-awareness as a critical part of self-mastery for agile coaches while activating assessments to understand how they are perceived.
[09:53] - Developing emotional intelligence—a critical aspect of self-mastery.
[10:03] - Brian compares the concept of self-awareness to a principle in acting called "intention versus action." He explains that understanding the intention behind someone's actions is important for interactions with others.
[11:21] - Bob describes the concept of "meta skills," or mindsets that guide how coaches should show up with clients.
[13:02] - Bob suggests that coaches should take 5 minutes before coaching conversations to "clean themselves up" and get rid of biases and baggage.
[14:48] - Brian shares his approach to coaching when he’s had a bad day.
[15:09] - Why it’s important to show vulnerability as a coach, even though it can be challenging and how that creates space for clients to do the same.
[16:50] - Bob emphasizes the importance of modeling and how it can be used to highlight certain behaviors or values.
[17:39] - Brian adds that self-awareness is crucial for effective modeling and coaching and shares an example where he dropped the ball on that and how he corrected his behavior.
[18:38] - The power of modeling in coaching and the importance of making a conscious choice to model positive behavior.
[19:18] - Brian shares the sponsor for the podcast, Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster.
[19:59] - Bob shares the importance of journaling for capturing observations and reflecting on experiences to improve future behavior and why he requires it in his leadership class.
[21:03] -The journal is like breadcrumbs, not just for the past, but the future.
[21:16] - Brian shares his own experience with journaling and why he considers it a crucial tool in coaching.
[23:48] - How wonderful it would be if leaders felt comfortable enough to model their vulnerability to their organizations.
[24:03] - Leadership sometimes feels like putting on a brave face and being a strong presence, but vulnerability can actually create more safety and change the ecosystem in a positive way.
[25:15] - Bob shares that showing humanity can be a real advantage in creating a resilient organization and shaping its culture.
[26:44] - Brian reflects on how his actions as a leader shaped the culture of the organization (even when actions went against traditional ideas of what a leader should do).
[27:35] - Bob shares an example of how journaling helped a young lady who was struggling with her job to go back and mine her history for valuable information.
[29:36] - Brian reflects on the importance of reflection and learning from past failures.
[30:02] - Bob brings home the concept of historical learning and self-mastery through journaling and reflection.
[30:28] - Check out Bob's podcast, “Meta-Cast.”
[34:09] -Join the Agile Mentors Community for further discussion, and if you have an idea for the show or feedback, we'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Meta-Cast
Mountain Goat Software's Better User Stories
cORSC - CRR Global
The Agile Coaching Growth Wheel | Scrum Alliance
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
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.

Bob Galen is a renowned Agile coach, speaker, and author with over 30 years of experience in software development. He has authored books such as “Extraordinarily Badass Agile Coaching:The Journey From Beginning to Mastery and Beyond,” "Scrum Product Ownership - Balancing Value from the Inside Out" and "Three Pillars of Agile Quality and Testing.” He frequently speaks at Agile conferences and events, sharing his knowledge and experiences in Agile testing and coaching. You can listen to him on his podcast, Meta-Cast.

Karim Harbott joins Brian to talk about the 5 levers of crafting a strong culture in an organization and the critical role of leaders in establishing it.

Overview

On this episode of the "Agile Mentors" podcast, Karim Harbott joins Brian to discuss the importance of crafting a strong culture in an organization through his 5 Levers for Changing Organizational Culture.

Listen in as they discuss the importance of aligning behaviors with the organization's strategy and the often-overlooked but critical role that leaders play in the cultural transformation of organizations.

Listen Now to Discover:

[01:34] - Brian introduces Karim Harbott, an Agile coach and CST, and highlights his book, “The 6 Enablers of Business Agility” He’s joining Brian to discuss culture change and the challenges associated with it.
[02:25] - Karim discusses where to begin to make cultural change.
[04:14] - Brian and Karim discuss the challenges of teaching culture and the importance of modeling desired behaviors.
[04:47] - Karim explains that behaviors are a key factor in shaping culture and shares that there are five levers for changing the culture of an organization. The first lever is the organization's structure, which can encourage collaboration or silos and is the first thing within your control to influence behavior and how people collaborate.
[07:15] - Karim emphasizes the importance of examining the system in place using the analogy of a gardener to explain that leaders need to create an environment that fosters the growth of the desired culture and behaviors.
[07:51] - Brian references a quote by Craig Larman highlighting that whatever you're seeing at the moment, your system is designed to output that—for a different output, you gotta change the system.
[08:21] - Karim explains that Craig Larman's and Deming's quote that "every system is perfectly designed for the results it's getting" both emphasize the importance of the structure in determining culture.
[08:47] - Karin shares the second lever for changing culture, which is that the policies and rules that leaders create can be used to control or influence behaviors.
[10:37] - Brian references the "Don't be evil" structure at Google and what it entailed.
[11:37] - Karin discusses the importance of weaving high-level values into every part of how the organization operates, even the low-level aspects of the organization, to truly influence behaviors.
[12:15] - Karin talks about the third lever of culture change, which is metrics and targets, and notes that what you measure and set as targets speaks volumes about what leadership values in the organization.
[14:18] - Measuring intangible things like respect and integrity can be difficult, but it is important to find a way to measure them even though they don’t fit neatly into a dashboard.
[15:51] - Brian shares an interesting paradigm they use at Mountain Goat Software, where they set goals with both a visual and emotional aspect to help them determine when they’ve reached their goal.
[16:56] - Karim discusses the importance of HR processes as a lever (Lever #4) for influencing and reinforcing behaviors in an organization.
[18:27] - Brian shares the sponsor for the podcast, Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster.
[19:12] Brian emphasizes the concept that the company is a team effort, not an individual sport.
[20:21] Karim highlights the difference between Henry Ford's production line and a team-based environment using the analogy of chopping onions in the kitchen but being asked to make a tiramisu.
[21:30] - If the culture incentivizes individuals to prioritize their own interests over the interests of the team, then there is a problem, and conflicting incentives will lead to failure.
[22:21] - Incentivizing individualism over teamwork will lead to failure (and unhappiness among 70% of employees).
[23:39] - Karim discusses the fifth lever, which he considers to be the most powerful: leadership behaviors.
[26:20] - Actions speak louder than words: Brian speaks about the importance of leadership behavior in promoting a healthy work culture with the example of unlimited vacation policies.
[28:23] - Karim talks about the importance of behavioral norms in an organization, citing descriptive and injunctive norms as examples. By using the example of a library, he illustrates how people tend to conform to social norms.
[30:39] - Karim shares the two things that are necessary to strengthen a culture; without these, a culture cannot be strong (it's important for leaders to be hypersensitive to this).
[31:47] - The disapproval of others can be a powerful tool to make sure people behave the way we want them to behave.
[32:47] - Brian shares how the TV show Brain Games demonstrated social norms and people conforming to the crowd.
[33:43] - Karim emphasizes the importance of crafting a strong culture as one of the most important things a leader can do and calls for it to be a core leadership capability.
[35:46] - Do you have an idea for the show or feedback you'd like to share? We'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Mountain Goat Software's Better User Stories
The 6 Enablers of Business Agility: How to Thrive in an Uncertain World
The 6 Enablers of Business Agility
5 Levers for Changing Organisational Culture
Lead and Disrupt
Larman's Laws of Organizational Behavior
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
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.

Karim Harbott is a leadership and business agility expert, entrepreneur, author, and international keynote speaker with over a decade of experience helping organizations with business agility. Karim is one of only a few people globally to hold the Certified Agile Leadership (CAL) Educator, Certified Scrum Trainer® (CST), and Certified Enterprise Coach® (CEC) status.

Chris Li joins Brian to talk about making informed decisions about going out on your own and navigating the challenges of entrepreneurship.

Overview

On this episode of "Agile Mentors," Chris Li joins Brian to discuss the journey to becoming an entrepreneur. They dive into everything from the importance of having a clear vision and passion to weighing the benefits of partnerships and investors.

Listen in for valuable advice from Chris and Brian on sidestepping the fear of going alone and the crucial things to consider before taking the leap.

Listen Now to Discover:

[01:08] - Brian introduces Chris Li.
[03:13] - Chris discusses the importance of taking stock of your threshold for comfort before determining the next step, especially in the current climate.
[05:33] - Brian emphasizes the importance of passion in making decisions about the next steps and recognizing when you've reached the pinnacle of your current position so you can explore other opportunities that align with your passions.
[07:05] - Chris shares his journey, from knowing he had an entrepreneurial spirit to finding the right people to help him as he took the leap.
[08:51] - Brian highlights the importance of having a network of people to fall back on and the value of mentorship for personal and professional growth.
[09:29] - Chris notes that going out on your own looks different for everyone and why it's essential to find the path that works for you and shares an example of someone who took a different route to improve their career.
[11:35] - Chris breaks down external and internal factors that can help you determine if you're ready to go out on your own, including the most critical factor to consider.
[14:22] - Brian discusses healthcare as a significant factor.
[15:15] - Brian discusses the importance of risk tolerance and mapping out income streams and costs to ensure that going out on your own is financially viable.
[15:49] - Chris discusses the investment period at the beginning of a move and why having an end goal is essential.
[17:37] - Taking stock - what will you have to give up to have this other thing?
[18:47] - The importance of a support team to help walk you through ALL sides of the situation—good, bad, and neutral.
[21:13] - Brian talks about why developing a backup plan is essential.
[21:43] - Chris shares why getting legal advice is vital.
[23:23] - Brian emphasizes the importance of hustling when you are your own boss.
[24:05] - Chis encourages listeners not to be discouraged by the elements of the process. Starting a business can be a valuable experience (regardless of its outcome).
[25:17] - Brian encourages listeners to be realistic about their situation but not to let fear hold them back from pursuing their entrepreneurial dreams.
[26:18] - Chris advises listeners to consider all the angles of any new opportunities that may come up, being realistic about their potential value.
[29:21] - Brian emphasizes the importance of hustling, working extra hours as an entrepreneur, and considering your own work-life balance priorities.
[31:32] - Think about how you will spend your time AND your money: Chris shares some practical things to consider, like how you will spend your time AND your money, and partnerships and securing funding.
[35:49] - No matter your choice, you can always change course.
[35:56] - Do you have an idea for the show or feedback you'd like to share? We'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
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.

Chris Li is the Founder of SparkPlug Agility and a dynamic and enthusiastic IT consultant with more than two decades of industry experience. He specializes in delivering exceptional learning opportunities and is passionate about delivering outstanding speaking engagements, mission-focused insights, and cultivating meaningful partnerships for individuals, teams, and organizations.

Mike Cohn joins Brian to share his experience facilitating story-writing workshops and offers insights on creating effective user stories that deliver value to customers and focus to your team.

Overview

In this episode of the "Agile Mentors" podcast, Brian is joined by Agile coach and trainer Mike Cohn to discuss the art of writing user stories through story-writing workshops.

Mike shares his expertise on the importance of creating user stories, including how to write them effectively and their benefits in the development process.

Listen in as Mike provides valuable insights on conducting effective story-writing workshops, including the role of a skilled facilitator, keeping the conversation on track, and how using the INVEST criteria can help you create high-quality user stories that meet the needs of your users.

Tune in for practical tips and strategies to improve your user story writing workshops to energize your team while giving them a clear focus on what they need to do.

Listen Now to discover:

[01:09] - Brian is sitting down with Mike Cohn today to discuss story writing workshops.
[01:57] - Mike shares team/stakeholder writing sessions during the early 2000s that morphed into "story writing workshops" to help teams understand what they were doing.
[03:37] - Mike explains why he prefers to write 20-30 stories at the start of a quarter, only writing a few new stories during the sprint, then doing another story writing workshop every three months.
[05:20] - Brian clarifies that teams don't have to wait for a story writing workshop to write stories. He shares his recommendations for holding story-writing workshops once a quarter to replenish the backlog and "refill the gas tank" with new ideas.
[06:03] - Mike expands on the gas tank analogy, explaining that, like filling up a gas tank, teams don't need to wait until the backlog is empty to have a story-writing workshop.
[06:52] - Mike shares why he prefers a quarterly approach to story writing for its big-picture view of the coming months.
[07:17] - Brian references the 2020 Scrum Guide and suggests using the product goal as the bigger idea to zero in on.
[07:32] - Mike agrees with Brian's suggestion of using the product goal as a focal point during story-writing workshops sharing his idea of the importance of something to aim for beyond just the single sprint goal.
[07:59] - The importance of focusing a story-writing workshop on a single goal, i.e., setting a product goal for three to six months and using it as the workshop's focus to generate necessary stories.
[09:29] - Who should attend a story-writing workshop? Mike offers his suggestions to bring creativity and new ideas and build better products.
[11:33] - Mike shares why he believes involving team members in story-writing workshops is a time-saving, worthwhile investment that will improve product outcomes.
[12:06] -The tools for a successful story-writing workshop for everyone involved.
[13:57] - Mike explains why story-writing workshops might work better online than in person.
[17:19] - To keep the conversation on track, having a skilled facilitator for your story-telling workshop is crucial.
[17:58] - The importance of having a scrum master or agile coach facilitating story mapping sessions for guidance through any issues with sequencing or organization of ideas.
[19:16] - Collectively writing the same story simultaneously vs. brainstorming different stories and then coming together—Mike shares which he prefers and why.
[21:34] - Mike shares why saving the story refinement for later is best.
[24:05] - The importance of striking a balance between the level of detail in the stories and the time spent on the story-writing workshop.
[25:21] - Brian shares a story about an organization he worked with recently at Mountain Goat Software that used the INVEST criteria as a definition of Done to check off every story they wrote.
[25:58] - Mike explains the six attributes a team should know to create good user stories.
[27:20] - Mike shares why story-writing meetings energize teams, leaving them excited about the product and the upcoming period while giving them a clear focus on what they need to do.

References and resources mentioned in the show:

How to Run a Successful User Story Writing Workshop
Better User Stories Video Course by Mike Cohn
2020 Scrum Guide
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
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.

Mike Cohn is the CEO of Mountain Goat Software and the Co-founder of Agile Alliance and Scrum Alliance. He’s passionate about agile and finds it rewarding when a company really understands agile, commits to doing it well, and succeeds dramatically. Mike’s focus is coaching, training, developing new courses, sharing ideas in his blog posts and tips, and participating in the Agile Mentors Community, especially with the live Q & A sessions.

Kubair Shirazee, Founder of Peace through Prosperity, joins Brian to share his experiences using Agile tools for social and societal transformation, helping to empower marginalized communities and break the cycle of poverty.

Overview

In this episode of the Agile Mentors podcast, we explore how Agile can be applied outside of software development as a powerful tool for driving societal transformation with Kubair Shirazee, the Founder of the Peace through Prosperity project.

Kubair takes us on his journey of using Agile methodologies to empower marginalized communities by supporting business owners in creating long-term solutions that are helping to break the cycle of poverty.

Listen in as he shares some of the challenges he has faced in implementing these methodologies and offers listeners detailed information on how to get involved in the Peace through Prosperity Scrum Masters Experience Academy and insight into ways you can make an impact in your community.

Listen Now to discover:

[01:07] - Brian introduces to UK-based Kubair Shirazee, Agility Coach through Agilitea and Founder of the Peace through Prosperity project that uses Agile to foster social and societal transformation.
[02:33] - Kubair discusses how Agile, which emphasizes people and relationships, can be applied to social and societal transformation.
[04:43] - Kubair explains how marginalized solopreneurs in conflict zones and developing countries can use Agile principles to maximize their potential.
[07:18] - The targeted way entrepreneurs with mobile businesses in marginalized communities use Agile to leverage what they've learned in the past to help them capitalize on future opportunities.
[08:42] - How Agile coaching and support helped a barber named Anwar to go from having a beat-up chair on the street to owning a salon.
[11:14] - Not just increased revenue—touching the lives of over 2400 marginalized micro-entrepreneurs in 12 short years.
[12:57] - Back to Anwar's story, how focusing on the pillars of empiricism and developing a product goal helped him shift his mindset and grow his business.
[16:27:] - We don't just hijack people's lives; it's all about creating relationships and collaborating with people to co-create solutions that work for them.
[20:21] - How finding out you have the power to write your own story is the first crucial step towards realizing your full potential and overcoming the challenges of marginalization.
[21:55] - Brian explains how Agile helps people manage challenging goals in any and every environment.
[22:55] -How Peace through Prosperity helps provide long-term, sustainable, and impactful solutions to help create an environment of financial stability.
[27:34] - Peace through Prosperity aims to empower marginalized communities to create a better future without resorting to extremism or outside help.
[28:42] - The exciting opportunity to get involved with Peace through Prosperity through the Scrum Masters Experience Academy and work with teams in Pakistan, Yemen, and Egypt to gain valuable Scrum experience in just six months.
[30:10] - Kubair shares how to become involved with the mission to meet the needs of marginalized communities in your own location (using Peace Through Prosperity's open-source programs).
[34:41] - How individuals like Dominique de Cooman, CEO of Dropsolid, are helping fund Peace Through Prosperity and how you can, too.
[36:39] - "Scrum is industry agnostic. Scrum is something if we if we all just embrace it, its principles, and its values. It can enrich not just our individual lives, but it can enrich us as an entire community on our pale blue dot."—Kubair Shirazee

References and resources mentioned in the show:

Peace through Prosperity
Agilitea
#32: Scrum in High School Sports with Cort Sharp
#23 How Agile Works in Education with John Miller
#21: Agile Marketing Teams with Stacey Ackerman
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
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.

Kubair Shirazee is a highly experienced Enterprise Agility Coach with over 20 years of experience helping people, teams, and businesses transform using his coaching skills. He has worked with a range of prominent brands in the pharmaceutical and non-profit sectors, including Novartis and Bayer, helping them to improve their product, service development, and operations. In addition to his coaching work, he is also the founder of the Peace through Prosperity project, which leverages Agile methodologies to promote social and societal transformation.

Brad Swanson joins Brian to explore the concept of servant leadership and share actionable takeaways to help you lead with compassion and empathy.

Overview

In this episode of the Agile Mentors podcast, Brad Swanson joins Brian to discuss the concept of servant leadership and how it can be applied in an Agile environment.

Learn how to create strong personal connections with your team members, the power of asking powerful questions to foster collaboration, and how to be more assertive as a leader while remaining flexible about the process.

Listen in as Brad shares three practical ways that listeners can cultivate a servant leadership mindset and build a positive and productive work environment.

Listen Now to discover:

[01:48] - Brian introduces Brad Swanson, who has the trifecta of certifications with Scrum Alliance: CST, CEC, and CTC.
[02:54] - Brad shares his belief that servant leadership involves prioritizing the needs of the team while cultivating a culture of trust and collaboration.
[04:43] - Since the 1970s, the servant leadership concept introduced by Robert K. Greenleaf has involved empowering team members rather than seeing them as subordinates.
[07:48] - Brian shares his experience playing football and how it relates to management styles, highlighting that a calm and empowering approach can be more impactful than an authoritative one.
[09:55] - Brad shares the idea that effective leadership involves the ability to balance and leverage multiple power styles and shares the book "Leadership Agility" by Bill Joiner and Steven Josephs, which emphasizes the importance of situational leadership.
[13:30] - Brad shares his perspective on the shift in the last version of the Scrum Guide from using the term "servant leadership" to "true leadership" and why he prefers the term situational leadership.
[15:05] - Brian acknowledges that people have a natural predisposition towards being either assertive or accommodating and how stepping outside of one's comfort zone can lead to both personal growth and an expansion of your skill set.
[16:05:] - Brad suggests there is a difference between being assertive and directive.
[19:38:] - The effectiveness of asking powerful questions to invite collaboration and reach a mutual goal.
[20:17] - The key to being more assertive as a leader without attacking the individual (and remaining flexible about the process).
[21:55] - Brad shares three ways listeners can implement a servant leadership mentality.
[23:35] - Brian shares how to use a notebook to process your thoughts and ideas while giving others a chance to speak up.
[24:38] - Brad shares why listening is a skill that requires frequent practice.
[25:15] - Why it’s a good idea to keep your team in the loop about the changes you are trying to make in your leadership style.
[26:13] - Why being open and transparent about your efforts to improve can help create a learning environment where improvement is both expected and accepted.
[27:05] - Why creating strong personal relationships with the people you are leading is crucial to effective leadership and developing the team's skills.
[29:05] - Listeners of the Agile Mentor’s Podcast can get a 10% discount on the Certified Agile Leadership class Brad has coming up on March 27th by using promo code friend10. Find out more by visiting Agility 11.
[30:34] - Join the Agile Mentors Community to continue the discussion. You can get a free 12-month membership into the community by taking a class with Mountain Goat Software.

References and resources mentioned in the show:

What is Servant Leadership?
"Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness"
"Leadership Agility"
Agility 11
Certified Agile Leadership - CAL Essentials & Organizations with Brad Beginning March 27, 2023 - Promo Code: friend10
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
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.

Brad Swanson, Founder and Principal Coach and Trainer at Agility 11 helps organizations achieve sustainable success through Lean and Agile principles. With extensive experience as a trusted advisor to executives and organizations worldwide, Brad holds certifications as a Leadership Agility 360 Coach, Agile Leadership Educator, Scrum Trainer, Enterprise Coach, Professional in Agile Coaching, and LeSS Practitioner.

Dallas Jackson joins Brian to explore the human aspect of work and the challenges that come with prioritizing the team while ensuring everyone is heard.

Overview

In this episode of the Agile Mentors podcast, Dallas Jackson joins Brian to delve into the human side of work and why it's essential to create work that fits people's lives rather than forcing humans to fit the work.

They delve into the importance of understanding and appropriately responding to conflict in the workplace as a Scrum Master and prioritizing the team while ensuring everyone is heard.

Listen in as they explore the challenges of adapting to change, why prioritizing human factors is essential for driving cultural shifts, and how to create an Agile culture that supports the human element of work.

Listen Now to discover:

[01:13] - Brian introduces Dallas Jackson, a native Texan, living in New Zealand who is a Teaching Assistant with Mountain Goat Software and certified team coach with Scrum Alliance.
[03:18] - Dallas highlights the importance of recognizing individuals as human beings and creating work that fits their lives rather than forcing humans to fit into work.
[05:17] - Brian shares the value of remote work to allow individuals to gain insight into each other's personal lives and encourages virtual show-and-tell sessions to foster stronger team bonds.
[06:43] - Connecting to foster deeper relationships as a team.
[07:42] - Dallas shares how showing her humanity helped her build a connection with colleagues, leading to a development of trust and a better quality of teamwork.
[10:41] - Why it's important as a leader to prioritize taking care of employees.
[12:21] - Dallas shares why creating a positive environment where people feel cared for and supported is crucial for producing good work.
[15:22] -The importance of building connections in team relationships through reciprocity and sharing personal stories, even those unrelated to work.
[16:39] - How opening ourselves up allows us to give the best to our fellow humans because we're ALL members of the same tribe—the human race.
[18:06:] - Brian shares the importance of understanding and appropriately responding to conflict in the workplace, including avoidance.
[21:08] - What about conflict—Dallas shares the importance of playing the long game and how not to handle it as a Scrum Master.
[23:39] - How using crucial conversations helps everyone stick with the facts and avoid misunderstandings caused by differing perspectives.
[24:43] - Brian shares the mantra he uses with teams to move beyond personal conflicts and focus on finding solutions.
[26:08] - Acknowledging that facts are the foundation, but feelings in the workplace matter too.
[27:17] - Dallas explains the significance of goldfish memory in conflict management, completing the stress cycle, and prioritizing the team while ensuring everyone is heard.
[28:07] - Brian shares why the Scrum Master's job is similar to that of a football coach in that you need to be clued into the emotional temperature of your team.
[30:32] - You can't process your way to a better culture—cultural shifts change when we take humans into account.
[31:38] - Agile is a philosophy that requires a shift in thinking about work and a departure from following step-by-step instructions and can be a difficult transition for organizations to make.
[32:39] - Dallas shares a football vs. rugby analogy about how to help managers make a mindset shift.
[34:53] - Brian shares that working with humans requires a different approach than working with machines because repeatability isn't always possible—adaptation is the name of the game.
[36:26] - Dallas shares the Cherokee saying that we die a thousand deaths to become our true selves.
[37:54] - You can hear more from Dallas at Scrum Australia in March.

References and resources mentioned in the show:

Burnout: The Secret to Unlocking the Stress Cycle
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
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.

Dallas Jackson is a Teaching Assistant at Mountain Goat Software with a multitude of Scrum and Agile qualifications, including CSM, CSPO, CAL-E.

Join Lance Dacy and Brian Milner as they discuss the use of metrics in an Agile environment to ensure optimal performance without taking things in the wrong direction.

Overview

In this episode of the Agile Mentors podcast, Lance Dacy joins Brian to delve into the intricacies of utilizing metrics in software development to ensure optimal performance while avoiding incentivizing adverse behaviors.

Listen in as he walks us through the three tiers of metrics that are crucial for Agile teams to consider in order to stay on course.

He’ll share the tools required to gain a holistic understanding of an individual's performance and how leadership styles and stakeholders influence team-level metrics.

Plus, a look at the common challenges that teams may encounter during their Agile adoption journey and how to overcome them.

Listen now to discover:

[01:18] - Lance Dacy is on the show to discuss metrics.
[02:09] - Brian asks, are there ‘good’ ways to track performance?
[02:32] - Lance shares why Agile doesn’t really lend itself to tracking performance.
[03:57] - How to handle performance reviews.
[04:32] - Lance shares the best way to measure individual performance.
[06:40] - Measuring team contribution vs. standalone rockstar.
[07:48] - What Ken Schwaber and Jeff Sutherland say about the completeness of the Scrum Framework and why having a superhero on your team is bad.
[09:45] - Lance shares the 3 tiers of metrics to measure when working as an Agile team to be sure their team is going in the right direction.
[11:09] - Using tangible business-level metrics such as time to market for products, NPS, and support call volume to evaluate performance.
[12:20] - How metrics, such as the number of work items completed per month, and cycle time, can be used to evaluate performance at a product level in an Agile environment.
[14:10] - Lance shares standard metrics such as velocity, backlog churn, and work-in-process that can be used to evaluate things at the team level.
[14:45] - Brian shares the importance of having a broader perspective to avoid having a distorted view of performance.
[16:53] - How using tools such as Ishikawa (fishbone) diagrams can help you identify the root cause of the problem instead of the apparent cause.
[17:22] - Individual velocity and other big metrics to avoid.
[19:02] - How the balanced scorecard can help managers use ALL the information available to develop a comprehensive understanding of an individual's performance.
[19:25] - The detrimental effects of using the wrong metrics to evaluate an individual's contribution.
[21:29] - Brian shares the story of how a manager's bug squashing endeavor led to incentivizing the wrong behavior
[22:31] - Lance references Stephen Denning's statement and reminds us that assumption testing is what developers do every day.
[24:00] - Referencing the State of Agile Report statistics on what's stalling your transformation to Agile.
[25:15] - Lance shares a behind-the-scenes look at how team-level metrics are affected by leadership styles and stakeholders.
[27:05] - Lance shares the spreadsheet he's been using to track data for a Scrum team for over 5 years to understand why the team is not predictable and what they can do to improve.
[31:38] - Got metrics management questions? Reach out to Lance.
[31:46] - Why it’s imperative that you think of software development as R&D rather than manufacturing to arrive at the right metrics measurements.
[33:26] Continue the conversation in The Agile Mentors Community.

References and resources mentioned in the show:

• Join the More than 24k People Who've Trained to Succeed With Mountain Goat Software
• Mountain Goat Software Certified Scrum and Agile Training Schedule
• #30: How to Get the Best Out of the New Year with Lance Dacy
• #31: Starting Strong: Tips for Successfully Starting with a New Organization with Julie Chickering
• State of Agile Report
• HBR's Embrace Of Agile
• The Agile Mentors Community

Additional metrics resources mentioned by Lance Agile Metrics

• Business outcomes, product group metrics, unit metrics)
  • KPI/OKR (Business Outcomes)
  • Time to market, NPS, Support Call Volume, Revenue, Active Account, New Customer Onboarding Time, Regulatory Violations)
• Product Group Metrics
  • Work items completed per unit of time (quarterly)
  • % of work in active state vs. wait state
  • Cycle time of work times (idea to done)
  • Predictability (% of work items that reach ready when planned)
• Unit metrics
  • Velocity, backlog churn, work in process, team stability Metrics Spreadsheet 

• Team Size
  • Tracking the size of our cross-functional team (typically Dev and QA), allows us to pair that number with velocity to play “what-if” scenarios in the future. Whether you count half of a person if shared, or whole, keeping it consistent throughout your tracking is what is important. Most teams simply count the number of developers and testers.
• Team Days
  • Tracking the iteration length is also helpful in understanding a team’s performance. If the team has a 2 week sprint, then usually that is 9 development days of actual work. The 10th day is set aside for sprint review, retrospective, and planning.
• Committed
  • Tracking what the team committed to completing within a sprint is crucial to understanding their predictability. The are the most uneducated at the beginning of the sprint and tracking what they think they can complete helps us in long term planning.
• Completed
  • Tracking what the team completed is actually just tracking velocity above, but comparing it what they committed helps us understand their predictability index.
• Predictability Index (Pi)
  • Software development is complex, risky, and uncertain. A skill that is sought after in this type of environment is predictability. The better we are at understanding what we can accomplish, then finishing what we said we would accomplish builds trust with our management team and customers. If we aren’t very good, tracking this metric often helps us get back to good by committing to less or more depending on our index.
  • Example:
    • Completed Items / Committed Items = Predictability Index (Pi)
    • 25 Story Points / 20 Story Points = 125% 20 Story Points / 25 Story Points = 80%
    • Just because a team has a high Pi, does not mean they are good at predictability. Don’t let high and low numbers fool you, focus on the variance from 100% instead of the actual number. An arbitrary number to shoot for is +/- 15% Pi (85% or 115%).
• Story Points / Per Day (SPD)
  • Story points per day is just that, tracking how many story points per day of the sprint did we complete (Completed / Team Days).
• Story Points / Per Day / Per Person (SP/PD/PP)
  • This perhaps is the most useful metric to capture throughout the process. Most of our teams do not have the luxury of maintaining a consistent size or make-up. Inevitably over the course of a few months, the team make-up will change. Once the teams change, velocity has to be reset.
  • In addition, we may actually change our sprint duration over a long period of time (don’t change it each sprint). Once we change sprint lengths, it can jeopardize our pure metrics, velocity has to be reset.
  • However, over all of our teams in a product, if we can capture the SP/PD/PP that our teams complete on average, we can begin to play “what-if” scenarios in long- term planning.
    • Example:
      • Completed / (Team Size * Sprint Days)
      • 24 / (4 * 9) = 0.67
      • You can then average that number over 4-6 sprints or even the year.
• Defects
  • While we understand that we won’t ever likely have a zero defect product, it is useful to track how many defects our teams are creating over time. There are usually 2 types of defects, internal and external.
• Internal
  • Our definition of done should at minimum include that testing is taking place during the sprint with the idea that we would not allow a story to be called DONE if it had remaining defects. As such, an internal defect are the ones that were created while working on a backlog item in the sprint, that we have fixed before calling the item DONE.
• External
  • External defects are those that have “escaped” our development process and were not discovered during our testing. In a sense, our customer discovered the defect and the work item will become a new backlog item for a sprint.
• Warranty
  • We should strive to have the warranty concept built into our process. If you bought a car yesterday and the radio fell out, you could take it back and they would fix it fairly quickly. Our customers deserve the same service. Don’t manage a defect backlog, get used to fixing escaped defects immediately, while they are fresh on your mind (right after a sprint). It doesn’t take a long time to fix defects, it takes a long time to find them once identified by a customer.
• Defects per Story Point
  • Tracking defects per story point help to understand velocity a little better. If you have a team that has drastically increased its velocity, have the defects have increased along with it? Defects per story point help us understand the relationship between a velocity and defects created.

Want to get involved?

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

• Enjoyed what you heard today? It would be great if you left 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, known as Big Agile, is a dynamic, experienced management and technical professional with the proven ability to energize teams, plan with vision, and establish results in a fast-paced, customer-focused environment. He is a Certified Scrum Trainer® with the Scrum Alliance and has trained and coached many successful Scrum implementations from Fortune 20 companies to small start-ups since 2011. You can find out how to attend one of Lance’s classes with Mountain Goat Software here.

If your team keeps revisiting the same issues over and over again, Groundhog Day-style, this episode is for you. Leadership coach Marsha Acker shares why it happens, how to recognize hidden conversational patterns, and what to do when you feel stuck.

Overview

In this episode, Brian Milner sits down with executive team coach and author Marsha Acker to unpack one of the most frustrating challenges teams face: circular conversations that never seem to resolve. You know the ones; same issue, different day.

Marsha introduces a practical framework, structural dynamics, to help leaders and Scrum Masters decode what’s actually happening beneath the surface of their team’s conversations. From identifying communication patterns to creating space for dissent and inquiry, they explore how to break out of those conversational loops, build psychological safety, and foster real change.

Whether you're leading meetings or just stuck in too many of them, this episode will help you shift the dynamic for good.

References and resources mentioned in the show:

Marsha Acker
The Art and Science of Facilitation by Marsha Acker
Build Your Model for Leading Change: A guided workbook to catalyze clarity and confidence in leading yourself and others by Marsha Acker
#137: Stop Wasting Time with Guests Kate Megaw
#94: Connecting Teams and Leadership with Anthony Coppedge
Retrospectives Repair Guide
Better Retrospectives
Join the Agile Mentors Community
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.

Marsha Acker is an executive coach, author, and the founder of TeamCatapult, where she helps leadership teams break out of communication ruts and lead real, lasting change. With two decades of experience guiding everyone from startups to Fortune 500s, Marsha specializes in transforming how teams talk, decide, and grow—one conversation at a time.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back, Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the honor of having Ms. Marcia Acker with us. So welcome in, Marcia.

Marsha Acker (00:12)
Hi Brian, it's good to be here.

Brian Milner (00:14)
Very very happy to have Marcia with us. Marcia is the CEO of a group called Team Catapult and she is a team coach. She does a lot of work with teams and leaders. She's an author. She's a speaker and we wanted to have her come on because of a book that she has out recently called Build Your Model for Leading Change. She also has another book called The Art and Science of Facilitation, which I'm sure is really appealing to a lot of people here as well. You know, as Scrum Masters, if you're a Scrum Master out there, we do a lot of facilitating. So that's probably a really interesting pickup for you also. But we wanted to have Marsha on because we wanted to talk about an issue that I hear a lot about in classes. This is something that I hear a lot of questions around, and it can be a really big source of issues when you think about working together in close, tight units as a team. And that's how teams communicate. kind of the issues and problems that we have with communication amongst teams. So, you know, when we're talking about this, we're talking about teams not listening to each other, not understanding each other, misunderstanding someone's motives, something like that. And one of the things I know that I've seen a lot, I've encountered this a lot, and this is one of the things that I know you talk about quite a bit in your book, is this kind of loop that we get in a little bit, right? We have these conversations where... It just feels like we're stuck in a loop. We're saying the same things over and over again. it's like, I in Groundhog Day? Am I reliving the same thing we just went through? So let's start there and just say, why do you think that that happens? Why do you think that teams have this kind of Groundhog Day effect where you might have these conversations that just kind of keep popping up over and over again?

Marsha Acker (01:35)
Mm-hmm. It's a great question, Brian. think a number of years ago, I had a background in facilitation, but I got really interested in this particular question because I found not only in my own experience, I had multiple examples that I could give you of conversations that I felt like I'd have with somebody. then we would be, a week or two later, we'd be back talking about the same thing. And I'd think, I, you know, from my perspective, I thought we resolved that. So, so why are we talking about it again? And then I noticed in my work with teams that they would do the same thing. So, you know, I'd be in a session with a team, I'd help them facilitate a decision. They'd make the decision and then I'd be back with them a month later and the same topic would be up. And I'm I just found myself confused. So I think, I think there are many reasons why that happens. But if I were to, If I were to create a theme for that, think there's a couple of big themes that I see play out. I think there are many places on our teams today where we stay at the surface level of the conversation. Like we get super focused on what we're talking about. So whether it's the tool that we're using, the features that are gonna be in the next release, like we get so super focused on it. And then we're hyper. aware of time boxes. So we want to make sure we talk about the thing, get the decision, and we want to do it in 30 minutes or less. I saw a post on LinkedIn the other day where someone was advocating that there shouldn't be any meeting that would need to go past 25 minutes. And I thought, see it really differently because I think while there are places where we absolutely do need to maybe just quickly exchange information or keep things moving along, or we just want to hear briefly from people. I think if we're advocating that every meeting should only take 25 minutes, we are likely going to have those Groundhog Day conversations because it doesn't give us the space to get to the real topic. So I think that's where we spend a lot of time talking about the thing, the topic, and we really don't create enough time to drop down into focus on are we really, there space here for me to share what I really think or do you just want me to show up here in this meeting that you're running? You clearly have maybe your own agenda. You feel like you've already got the decision made. And so you'd really like my role to be to just receive your information and go off and do it. So I think there's a complexity here of

Brian Milner (04:27)
Yeah.

Marsha Acker (04:32)
What's the topic we're talking about? Is it the real topic that we need to talk about? Or is there, is it sort of the mask for what we might be able to drop into a deeper conversation to have? Are we being super focused on a time box? And are we creating enough range in our meetings that we've got spaces where we are efficient and fast and very deliberate about the conversation and then other spaces where, you know, those topics that keep returning. They're great places to go, there's data here for us. I think of them as yellow flags. there's something here for us to explore further. So let's take this topic and let's carve out a little bit more time for it. I'm curious what you see.

Brian Milner (05:15)
Yeah. No, that's a great observation. And I think you're right. It is a frustration. Looking back over my career and looking back through corporate meetings and things I've been a part of, there is frustration with someone who's coming in and not really having a meeting planned and not really having an agenda. But I think there is another kind of side issue there that can cause a lot of misunderstanding about

Marsha Acker (05:33)
Yeah.

Brian Milner (05:44)
what we're trying to achieve and that's the purpose. If we're here for a certain topic, I can understand that, but then what is it that's expected of me in this meeting? Am I here to just receive information? Is this a knowledge dump or a status update from someone else? is this, we have an issue and we need to talk through it and fully understand it.

Marsha Acker (05:47)
Yeah. Mm-hmm. Yeah.

Brian Milner (06:13)
And I think sometimes that's what I've kind of seen is that there's this mismatch of, well, I thought I was here for this. And now it's clear that you don't really want my opinion. You just want to tell me what it is. And so now I'm refocused or the opposite. I thought I was here just to receive information, but now I'm realizing that you really need me to dig in and give you my educated advice on this. Well, I wasn't prepared to do that.

Marsha Acker (06:20)
Yeah. Yeah. Yeah. I think this notion, and I see it happen a lot with Agile teams, like somewhere in our professional careers, and I think there's very good reason for, like we get rewarded for, know, from the time we're in very early school all the way through the end of school, we get rewarded for having answers. And then we end up in the workplace and we find ourselves in collaborative spaces. And so I think there's this belief that, you know, someone who's calling the meeting, they will have a little bit of this internal story that if I come with only questions and no solutions, then what value am I adding? Like that's, how am I useful to this organization? I've actually had people say to me, why would this organization hire me to come in and ask other people questions?

Brian Milner (07:28)
Wow.

Marsha Acker (07:29)
And so I think that's really, I love giving voice to that because I do think that there's a narrative that sits in our organizations that I, and a little bit of a fear. Like if I come to a meeting and I'm asking people to collaborate or I'm truly asking them open ended questions and I want to hear what they have to say and we're going to listen to, you know, I talk a lot about wanting to create this collective intelligence. And I think it takes a while to access that in a group of people. that it requires us to be able to suspend this idea that we're not adding value if we're asking questions and to reframe our value as helping to tap into a collective. And you can certainly have a point of view or a perspective, but if you're really wanting to tap into that intelligence, then I think it requires something different of us if we're the meeting host or the meeting leader. I think the other thing that will happen too is depending on who's in charge, like senior architects or somebody senior in the team can also get caught in that trap. Like, well, I'm supposed to come with answers. And I think we can come with ideas. But if we're really wanting to collaborate, and then this gets to your point about why are we gathering? Because sometimes I think there will be places where somebody has already made the decision and they're not asking for input on the decision.

Brian Milner (08:42)
Yeah.

Marsha Acker (08:50)
but they're wanting to share the decision that's been made and enroll people in the decision that's been made and invite them into collaborating on actually how that's gonna get implemented. But we're not opening this conversation up for what's been decided about architecture, what's been decided about what's going into a release. So I think this clarity and intentionality like you talk about around purpose, why am I here? What do you want from me? It's huge. And I think it's really tied to also some of our thinking about how are we adding value.

Brian Milner (09:23)
Yeah. The comment about, know, people not feeling like they're adding value if they're just asking questions that, kind of, maybe it's just for my recent experience with coaching and everything, but to me that, that just, it's so contrary, you know, to, to my way of thinking now, I guess I would say in that, you know, when I've been a part of discussion, when I've been part of a meeting, that I've looking back, that I feel like has gone really well.

Marsha Acker (09:26) .
Mm-hmm.

Brian Milner (09:48)
Uh, or, or a person that I feel like has really contributed to the meeting. Oftentimes it, it is that person who is asking questions that get us to think in a different way to get us to consider from a different perspective. So, you know, that that's why it feels a little strange to think about it. I agree with you. I agree that that's, you know, the attitude of some people or that's the way they see, you know, how I contribute to a meeting, but it just feels like it's such the opposite of that. That might be the most valuable thing we could do is to get people to see things from a different perspective or consider maybe things they haven't considered about this issue.

Marsha Acker (10:25)
Yeah, I think it's one of the first mindset shifts in a transition from being a contributor to maybe managing or leading, whether it's you're just leading a team or whether you're leading a whole organization. I think this idea of where does value come from and what's my role in the value creation, it's a shift, I think, for us. I love when people can get to a place of thinking about creating containers in organizations where people get to be their best. And then it does, your thinking does shift from, what's the piece of content that I can contribute to? What's the question that would really unlock different perspectives? And I think the other piece about that is what's the question that would elicit a... I talk about it being opposed, but you know, a contrarian perspective or point of view, because I think that's the other thing that can keep us in these circular conversations is when what we're really thinking doesn't get said. So if I don't feel like I can tell you in the room what I'm really thinking, I'll tell everybody else offline.

Brian Milner (11:34)
Right. The meeting after the meeting, right? Yeah. Yeah. And that, course, gets to the heart of psychological safety and kind of those dynamics within a team. We started this off talking about kind of this feeling of getting stuck. And so I want to kind of come back to that a little bit and say, I want to ask you, what are some of the causes of that? Why do we find ourselves trapped in these loops?

Marsha Acker (11:36)
Yes. You Mm.

Brian Milner (11:59)
that just, know, whatever we decide doesn't actually do anything or we find ourselves right back in the same place. Why do these, what's causing this?

Marsha Acker (12:08)
Yeah, well, let's play around with a bit of a framework to help us think about what's happening in the conversation. Yeah. So there is a theory of structural dynamics. It comes from work of David Cantor. And what it allows us to do is sort of think about being able to code the conversation that we're happening. And by code, I mean it helps us focus not on the topic. So whatever the topic might be. It doesn't matter. It helps us focus on how we're engaging in that conversation more of the how. And so there are four actions. Everything that we say could actually be coded into one of four actions, which I think is really kind of fascinating. So you just made a move by taking us back and pointing to the topic about stuck conversations, right? So what keeps us stuck? And that's a move because you're pointing in a direction. So moves kind of set direction in the conversation. I could make a new move and say, you know, let's talk about, yeah, where we might meet at a conference sometime, Brian. But that's a totally different topic. So moves set direction in a conversation. The second action is a follow, which gets behind and supports. So I followed your move by saying, yes, that's great. Let's do that. Here's, and then.

Brian Milner (13:12)
Right. Yeah.

Marsha Acker (13:26)
And then a bit of a new move from me, let me introduce a language for thinking about that. So you made a move, I followed, and then brought in another move. So now we're starting to, by being able to name actions, we're starting to get a sense of patterns. So there's two more actions, the action of a pose. So a pose offers like really clear pushback. It says, no, hang on, stop. Let's not go off the bridge or. I really disagree with this piece about what you're saying. So it offers a clear pushback or constraint to what's been said. And then the fourth action is a bystand. And a bystand is a morally neutral comment that names what's happening in the conversation. So I could bystand on myself in a conversation and say, you know, I'm really feeling engaged by the dialogue, or I might say I'm really confused. or if we're noticing a pattern, somebody might say, I notice we're getting stuck. So a bystand is a way for people to name what's happening or bridge competing ideas. But the other thing, the benefit of the bystand is that sometimes it also slows down the conversation. So to your question about what gets us stuck, it's really helpful if we can separate. what we're talking about and start to briefly look at how we're talking because what gets us stuck in conversations is when one or more of those actions is missing over the course of time. So we need all four of them to be voiced. One of the biggest problems in our stuck conversations is that a pose goes offline. Not in every team. There will be teams for whom a pose is stronger. But in my experience in American business, for sure, a pose is often the thing that is missing or it goes offline. So the way it will play out, there's a couple of different patterns. One will be what we call serial moving. And those are teams. Like a meeting with serial moving will have lots of fast pace. So somebody says this. then we're talking about this topic, now we're talking about this. And it will, like, you'll have a feeling like we accomplished a lot, but then you walk out at the end of the session and you go. So we talked about, exactly, we talked about this, this and this, and I don't know what we decided.

Brian Milner (15:52)
What just happened, right?

Marsha Acker (15:58)
So people that leave those kinds of meetings, they'll have this sort of false sense of, yeah, we got somewhere when we really didn't, we didn't close things out. So serial moving can be a pattern that can keep us stuck because we don't close things. There can be another pattern where there's a lot of move and follow. We call it courteous compliance. Another word for it would just, I forget the other label that we can give to it, but there's the sense that somebody makes a move and everybody else just says, sure, fine. So it's lacking the energy of the dynamics that you would get if the other actions were active and being voiced. And then there's a pattern where we might have too much bystand. So in a team that starts to complain about why did we use this tool or, know, I'm noticing nobody's using Slack or I'm noticing, you know, when we, when something gets posted in Slack, nobody acknowledges it. So if you find yourself in a meeting where, people are sharing a lot of context or perspective, maybe we can, I call it a hall of mirrors. Like we've got lots of perspective, but what's needed is for somebody to really make a move and say, all right, so given that now, what do we want to do about it? So what's really fascinating about those, we can also get locked in a move and a pose, a really strong advocacy or argument. And what's needed in that kind of argument is we need more follow and bystand. But what I find fascinating, so a pattern that I see play out over and over again will be one of two, the serial moving or the courteous compliance. So we've got a lot of moves or we've got move and follow.

Brian Milner (17:25)
Yeah.

Marsha Acker (17:45)
And if I'm someone in the meeting that either doesn't feel like my voice is welcomed or that it would be a career limiting move to oppose you, what I'll do is start to use one of the other actions in place of my oppose. So if it's not okay for me to push back and say, Brian, I don't want to talk about that, or I disagree, I think we're going off track, then what I might start doing is just making new moves.

Brian Milner (18:02)
Hmm.

Marsha Acker (18:15)
So rather than say to you, hey, Brian, I don't want to do that, you'll be talking about something, and now I'm introducing another topic. Hey, can we talk about where we're going for lunch next week? Or can we talk about the meaning behind that word over there that we were using last week? we don't do it intentionally. It comes for really good reason.

Brian Milner (18:36)
Right.

Marsha Acker (18:39)
We will all have our own reasons about why we do or don't do that. But I think some of the greatest work to do in teams is to talk about those four actions, to normalize them, and to invite them.

Brian Milner (18:52)
I love this. what kind of fascinated me, caught my attention the most about what you were saying is when I saw these, and kind of reading up here and reading through your work prior to our discussion, those four modes, when I read it, the first time it seemed to make sense, move, follow, oppose, bystand. But when I saw bystand, it really did seem, my first initial gut response was, yeah. That makes sense. There are bystanders that are happening in meetings that just do nothing. They just kind of sit back and they're not going to be, you know, they're not going to get in the way of the flow of something. But the way you described it is really fascinating because it's not a passive thing. It is an active participation.

Marsha Acker (19:35)
Yeah. Yeah. Yeah. Actually, if somebody is, well, I love that you're naming that because I get asked that question all the time. So again, American business trends. So if you step into the mind of someone who believes that I'm really only adding value if I'm bringing ideas and the way we would code that would be often you're making moves. So people will tend to value. making moves and opposes because a lot of times that's what the culture values. If you're in an organization that says, bring me problems, bring me solutions, you will find a cultural pattern in there of people showing up and making moves and opposes throughout their whole meeting. It'll be a stuck pattern. It'll be overused actions. But if we think about, so bystand could be questions, asking powerful questions. what's that mean to us falls along the line of bringing inquiry into the conversation. And so it gives us a way to balance advocacy and inquiry. But bystand is, bystand and follow are active. If somebody was not saying anything in the conversation, we wouldn't know, we wouldn't be able to code them because they're not speaking. And those four relate to speech acts. So, We have to speak in order for it to be coded as something. But those people who are sitting back often have some of the best bystands. Like if you were to tap that person on the shoulder and say, hey, I would love to know what you see right now in the conversation, they'd probably be able to tell you.

Brian Milner (20:57)
Yeah. Yeah. Yeah. I love this. And, you know, one of the things we teach in our advanced Scrum Masterclass is having people kind of understand how to deal with conflict in their teams and stuff. And we talk about the Thomas Killman kind of five responses to conflict. And I'm seeing a lot of overlap here in these modes too of, some of these things sound like a certain response to conflict in certain ways as well. But before we run out of time, I want to...

Marsha Acker (21:30)
Mm. Yeah.

Brian Milner (21:43)
I want to make sure that we get to, if we're in this situation, what are some steps, what are some things we can do to break that chain and not just have the same conversation again next week.

Marsha Acker (21:48)
Yeah. Yeah. So I would love for people to just think about using those four actions, especially if you work with a team on a fairly frequent basis, right? You will likely, even as I describe those, you will likely start to be able to identify what's the pattern that might be showing up. So I think the first step is can you identify or create a hypothesis for yourself about what might our structural pattern be? So do I hear like really clear poses? You know, do we make a lot of moves? So if you can find the actions that are predominant in your conversation, that's really the first step. And then the second step, there are a couple of different things to counteract each of them. So if move is really strong and it's coming from certain people, designing your facilitated session or even inviting participants to other participants to be the ones to make the move. So inviting others to speak first is one way to do it. limiting the number of moves that people can make. So sometimes if I'm working with a team that has that pattern, I'll give them some kind of, I'll give them a poker chip or I'll give them a card that says move on it. And I will limit everybody to one move per meeting. So structurally, I'm asking people to start to constrain their own moves. And then asking them to then step into, know, if somebody makes a move, staying with it long enough. as, so as a facilitator, you might say, if you noticed that you've got multiple moves on the table, you might just say, Hey, we've got four topics. This, this, this, and this, which is the one that we want to dive into first. So that's another way of just prompting a group to follow a move that they've made. And I think if you're noticing, you don't have a pose. You. chances are that is not going to come naturally. So I think you've really got to design questions that surface it. asking for what are the risks or who sees this differently. A lot of times if I'm leading a session, I will ask people, where did I get it wrong or what do I have wrong?

Brian Milner (23:47)
Yeah.

Marsha Acker (24:12)
What am I missing? What might I not be seen? So those are all ways for me to prompt. And I think if you've got some hierarchy in the room or differentials about that, that's really got to come from the person who's sort of holding some of that positional power maybe.

Brian Milner (24:29)
Yeah, I love that because there's there's sort of a maybe it's an American culture thing. I don't know. But but I know in the business world I've experienced if you call a meeting if it's your meeting there there's sort of an expectation that you're in control, you know, you know, it feels like there's there's sort of a you're not invited to say something like, what am I missing?

Marsha Acker (24:52)
Yeah. Yep.

Brian Milner (24:53)
because that's sort of admitting that you weren't prepared for this meeting. But I agree completely with you, that's not really the case. It's just saying, I can't know everything, so what don't I know about this, I should.

Marsha Acker (25:09)
Yeah. And it's hard. That can be a hard question. And I often say to people, don't ask the question. Don't elicit a pose if you're not really ready to hear it. It can be hard when somebody says, I think it's a two-ee. I totally disagree with the direction that we're going. Because if I, as the person who's asked the question and now receiving that feedback, If it starts to show on my face or I disconnect from it, what's gonna happen is that gets registered across everybody in that room. And that'll be the last time anybody steps up to answer that kind of question.

Brian Milner (25:36)
Right. Yeah, I love as well when you were talking about, you know, the actions and maybe having tokens or stuff for people to have actions. think I don't, I'm sure this is maybe part of the intention of this as well, but I love the side effect of that, that yes, I'm limiting people who would be controlling to not, not take control of the entire meeting, but once they've spent theirs, now I'm in a situation where the people who maybe wouldn't be those people that would normally step up. They're the only ones who have that ability left. So you have that side benefit of I'm kind of making space for the quieter voices in this group to have a chance to speak up. And I think that's a really important thing in these kind of meetings too.

Marsha Acker (26:35)
Yeah, when we find ourselves in stuck patterns, there will be very good reason for, or the Groundhog Day conversation. There will be a pattern to the structure of that conversation that keeps repeating itself. And a lot of times what will be happening is somebody will make a move and very often the person that follows them will be the same person every time. So if Marsha speaks and then Brian follows and that's a pattern that gets set up. every single time. All it does is reinforce me to make more moves because I know you're going to be right behind me. And then over time, we're really unconscious, I think about it, as a structural pattern. But the rest of the team will start to fall back and be like, well, they seem to have it. There's no need. No need. So yes, what we're trying to do is change the behavior by looking at structure and finding ways to invite it.

Brian Milner (27:34)
That's awesome. This is fascinating. I want to be respectful of your time and everyone's time listening, I could go on for another hour in this conversation. This is just really fascinating stuff for me. And I want to point out to everyone again, if this is fascinating to you, we're going to put all the links to this stuff in our show notes so that you can easily just click on that and find it. But just to call it out again.

Marsha Acker (27:41)
You

Brian Milner (27:55)
Marcia has a couple of books out there that are in this topic area that could be really useful to you. One is the art and science of facilitation. And the one that I kind of took a deep dive into is called Build Your Model for Leading Change, which by the way, there's a subtitle of this, a guided workbook to catalyze clarity and confidence and leading yourself and others. And I just, would underline the workbook. Right? Because I think it's true. It is something to kind of work your way through. And it's not just a beach read. Yeah. Yeah.

Marsha Acker (28:27)
No, it's not. I like to think of it as a Sunday morning, maybe with a cup of coffee and a little bit of quiet space.

Brian Milner (28:36)
Yeah, love that. I love that picture. Well, Marsha, I can't thank you enough. You know, we've been kind of trading schedules and trying to align this to get Marsha on for a while. And, you know, when that kind of thing happens, for whatever reason, it always seems to be like, when the person comes on, it's like, wow, that was worth it. I'm really, really glad we went through that because this was a great conversation. So thanks so much. Thanks so much for sharing your research and wisdom here on this.

Marsha Acker (28:56)
I appreciate it.

Brian Milner (29:02)
and for coming on the show.

Marsha Acker (29:04)
Thank you for having me. It was great.

Join Julie Chickering and Brian Milner as they provide exclusive insight on utilizing your Scrum training, expanding your expertise, and passing your knowledge on to others.

Overview

In this episode of the Agile Mentors podcast, Julie Chickering sits down with Brian to discuss getting started in the key Scrum roles.

They highlight the value of establishing relationships with like-minded individuals for both support and greater success. Plus, a look at some ways to use Scrum outside of the software development arena.

Listen in as they guide you through the initial steps you can take when you are just starting out on your Scrum journey and how collaboration and continuing education can aid your career growth and advancement.

Listen now to discover:

[02:26] - The framework is simple. Then we put people into the mix. Julie shares the most crucial aspect for those starting in key Scrum roles.
[04:04] - Brian shares Mike's foundational philosophy for approaching this work from Mike Cohn's popular conference keynote session, Let Go of Knowing.
[05:58] - How communities online like The Agile Mentors Community and local groups like DFW Scrum help members achieve more success.
[07:02] - How being part of a community was foundational to Brian's Scrum journey.
[8:33] - Julie shares her introduction to Scrum and how the connections and support she received from the community were crucial to her growth and advancement.
[09:42] - Brian shares his regrets about not getting involved with a community sooner.
[11:56] - Brian shares how mentoring is like dating and why taking the time to have the discussions needed to form the foundations for authentic relationships is vital.
[13:08] - Read the room. Julie offers guidance on avoiding mistakes while searching for a mentor.
[14:46] - How cross-pollination and venturing out to form connections in other industries helps you grow in your own.
[15:41] - Being part of a safe community can help you advance your skills while helping others.
[16:57] - Julie shares how to get started as a Scrum Master after you've been trained and the overall value of finding the right fit.
[18:50] - Successful product ownership requires two key components.
[19:16] - Where the rubber meets the road: expanding what you've learned in your training through real-world experience.
[20:45] - Start where you are: how applying your Scrum training to other areas beyond software development can help enhance your skills.
[22:55] - Brian and Julie share some examples of Scrum hidden in the non-software world, including in education and marketing.
[25:32] - How to use your skills to help a nonprofit in your area.
[27:11] - Brian explains how A-level classes can help you overcome hurdles as you advance in your career.
[28:53] - Learning never stops: the importance of obtaining knowledge for now and later. [29:10] - Julie shares the value of debriefing with someone else.
[30:31] - Problem-Solving Leadership (PSL)
[31:22] - What classes and tools have you used to advance your skills? We'd love to hear. Reach out to share your experience.

References and resources mentioned in the show

• Let Go of Knowing
• The Agile Mentors Community
• DFW Scrum
• Book Early for Savings on Mountain Goat Software Training Classes
• Agile Mentors Podcast EP#32: Scrum in High School Sports with Cort Sharp
• Agile Mentors Podcast  EP#23 How Agile Works in Education with John Miller
• Agile Mentors Podcast  EP#21: Agile Marketing Teams with Stacey Ackerman
• Agile Mentors Podcast  EP#31: Starting Strong: Tips for Successfully Starting with a New Organization with Julie Chickering
• Finding and Becoming Great Mentors and Sponsors with Carla Harris on WorkLife with Adam Grant

Want to get involved?

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

• Enjoyed what you heard today? It would be great if you left 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, 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 Woody Zuill and Brian Milner as they discuss the benefits of teams working together through Mob Programming.

Overview

In this episode of the Agile Mentors podcast, Woody Zuill, a 40-year veteran software developer specializing in team interaction, joins Brian to explore the concept of Mob Programming.

Woody shares the benefits of working together rather than separating tasks in software development and how removing things like queuing, multitasking, and context switching can actually make teams more effective.

Listen in as he walks us through the collaborative software development approach's perks.

Listen now to discover:

[02:22] - Brian introduces Woody Zuill, a 40-year veteran software developer specializing in team interaction.
[02:51] - Woody explains how he discovered the term Mob Programming.
[04:56] - Where the idea of Teaming came from.
[06:20] - Woody explains why he's changing the name from mob programming to teaming.
[07:23] - Teaming = collaboration brought to software development, where more than one brain connects to do the work that needs to be done.
[11:11] - Painting the Mob Programming picture: it's when "all the brilliant minds work together on the same thing ‌in the same space, at the same computer."
[13:40] - To work efficiently in software development, one team member acts as the driver at the keyboard while everyone else acts as the navigator.
[16:41] - The drawbacks and disconnect of breaking software development down into smaller pieces.
[18:34] - Isn't six people in one room working on one computer a waste of resources?
[21:07] - Do you want to be productive or effective? Examining the Lean concept of flow.
[24:57] - Enhancing the effectiveness of software development by removing the negative impact of waiting, queuing, multitasking, and context switching.
[25:22] - The benefits of working together vs. separating tasks in software development.
[26:53] - Team Flow: how collaboration adds to our ability to work in the zone.
[28:38] - Working together is often more effective, so why have we gotten better at it?
[31:25] - The strength of experimentation.
[33:09] - Woody explains that since the software development process is a discovery process, innovations such as mob programming can benefit the process.
[35:25] - Woody shares resources where you can find more information on Mob Programming (see the resources section below for more) and how you can contact him to schedule a workshop.

References and resources mentioned in the show:

• Software Teaming: A Mob Programming, Whole-Team Approach by Woody Zuill
• Teaming by Amy C. Edmondson
• Code with the Wisdom of the Crowd: Get Better Together with Mob Programming by Mark Pearl
• The Mob Mentality Show on Apple Podcasts
• Diffusion of Innovations by Everett M. Rogers
• Online And In-Person Training To Help You Succeed With Agile Through Mountain Goat Software
• The Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left 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.

Woody Zuill has been a software developer for over forty years. Woody is one of the pioneers of Mob Programming, a method of teamwork in software development that involves the entire team working together. Woody gives remote and in-person workshops on the topic. You can find out more about him on Twitter @WoodyZuill or on LinkedIn.

Join Cort Sharp and Brian Milner as they discuss experimenting with Scrum in other out-of-the-box environments, including how Cort uses it to train the high school swim team he coaches.

Overview

In this episode of the Agile Mentors podcast, Cort Sharp joins Brian to explore how to use Scrum tools in other environments outside of the software development arena.

Cort shares the lightbulb moment when he realized Scrum might help him become a more effective coach for his high school swim team.

Listen in as he walks us through his real-world experience using Scrum to coach swimmers, including what worked and what didn't and how he redefined things to make using Scrum successful for the team.

Listen now to discover:

[01:27] - Brian introduces Cort Sharp, the Agile Mentors Community Manager and high school swim coach.
[02:49] - Scrum is used chiefly in software, BUT there are other options. Examining out-of-the-box uses from Scrum.
[03:46] - Cort shares the story of how he got started as a high school swim coach.
[06:26] - Cort meets Scrum.
[08:39] - The discovery during Certified Scrum Training that led Cort to believe he could use Scrum to become a more effective swim coach.
[10:20] - Brian shares his own light bulb moment from his first exposure to Scrum.
[11:53] - What’s the product: Cort shares the process of translating Scrum to the swimming world.
[15:57] - How the sprint review brought everything home for Cort.
[17:03] - Evaluating how things were working with the parents of the swimmers (the stakeholders) at the weekly invitational swim meets.
[17:48] - Brian describes how Scrum helps you break things down into smaller, digestible chunks when you want to reach a big goal but don't see progress every day.
[19:02] - Cort shares how they developed the user stories for each swimmer and used feedback to develop the backlog for swim practices.
[19:44] - Cort shares the process of developing the backlog for swim practices.
[21:19] - How Agile principles (i.e., sustainable pace) translate into arenas other than software.
[24:30] - Cort explains how Scrum events like daily stand-ups and sprint reviews helped the team organize practices.
[24:47] - Which Scrum practices were harder to implement for the team? [26:47] - Opening yourself up to experimentation. (And how to reach Cort with your coaching ideas and suggestions).
[27:36] - Cort shares the biggest changes he had to make to make things work for the swim team.
[28:00] - So, who is the Scrum Master for the swim team? Redefining the Scrum roles and responsibilities to make them work in other environments.
[30:04] - Cort shares what he’s learned in the process of using Scrum with the swim team.
[33:29] - Do you have a topic or guest you'd like to see on the Agile Mentors podcast? If so, send us an email. We'd love to hear from you.

References and resources mentioned in the show

• #21: Agile Marketing Teams with Stacey Ackerman
• #23 How Agile Works in Education with John Miller
• The Agile Mentors Community

Want to get involved?

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

• Enjoyed what you heard today? It would be great if you left 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 as 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.

Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

Join Julie Chickering and Brian Milner as they discuss strategies you can use to get started on the right foot with your new organization.

Overview

It's the new year, and for many people, that means starting a new chapter in their life, maybe in a new position, with a new team, or possibly an entirely new organization. It's the perfect time for reflection to determine what you can do in these first few days and weeks to set yourself up for success.

So, we thought it would be a great time to take this episode of the show to highlight some strategies you can use to hit the ground running.

In this episode of the Agile Mentors podcast, Brian Milner and Julie Chickering discuss some strategies to set the stage for success in your new position. We will walk you through the vital steps for settling into your team and making an impact no matter what level of the ladder you are on. Plus, what to ask when you are interviewing to ensure you find the right fit.

Listen now to discover:

[01:40] - Julie Chickering is on the show to discuss starting strong with your new organization.
[02:15] - How to use team retrospective to identify where things are going well to amplify the good stuff while on a discovery mission of what needs work.
[03:35] - The one thing that Julie cautions about in one-on-one conversations that will help you avoid being influenced by others' opinions of their team members.
[05:22] - How to create curiosity instead of animosity by offering reciprocal grace to help everyone work better together.
[07:17] - Brian shares how to use an improvement board to keep a running track of things while identifying your next target, stay on the right track and avoid the worst-case scenario (as referenced by Henrik Kniberg in the Spotify Model - Part 2).
[09:23] - What Brian calls his 15-minute' cheat code" for understanding the dynamics of a team.
[11:31] - Julie shares her improvement backlog one-on-one ONE thing for Scrum Masters.
[12:08] - Essential techniques to help developers make an impact and utilize their skills in their new team.
[13:57] - How to get off on the right foot with a new team as a product owner.
[14:14] - Julie shares how to determine if an agile framework like Scrum is helping you meet your business goals (or not).
[15:34] - If you cannot communicate and collaborate with your stakeholders… you'll never deliver value to them.
[16:32] - How story mapping exercises can help product owners.
[18:31] - Why communication is the key to top-to-bottom team success.
[19:40] - The most important questions to ask when you are interviewing to determine if the organization is a good fit for what you bring to the table.
[22:17] - Why it's important to remember every interaction during an interview is a part of the job interview.
[22:33] - Brian shares a story of why it's crucial to determine if the company you are going to work for is looking for someone agile or Agile.
[24:42] - Why it's essential to do a background check on a company you're considering hitching your wagon to.
[25:38] - Start with where you are: how to start strong if you have the skills and are certified but need to gain experience.
[28:30] - How can you use your skills to give back and advance in your career?
[29:38] - How to highlight your experience and use it to your advantage when seeking various roles within a company.
[32:40] - The most powerful question you can ask your team that will help you start the new year fresh.

References and resources mentioned in the show

Spotify Engineering Culture - Part 2 (aka the "Spotify Model")
The Culture Code
How does project management work in Agile? with Julie Chickering
#7: The Sprint Review is not a Demo with Julie Chickering
Agile Mentors Community
Meetup
#13: What Does Cross-Functional Really Mean? with Lance Dacy
Mountain Goat Software
Scrum Alliance
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? Please 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 Lance Dacy and Brian Milner as they discuss how to get the best out of the new year.

Overview

Something about that turn of the calendar from December to January makes us want to dig into planning, goal setting, and change.

In this episode of the Agile Mentors podcast, Brian Milner and Lance Dacy discuss how to get the best out of the new year. They’ll walk through why personal retrospectives are the key to determining where to look for change. From 30-day challenges to building relationships with others in the Agile community, to fostering a fertile learning culture, listen in for insight into what might work for you to accomplish the change you seek to make this year your best.

Listen now to discover:

[01:15] - Welcome to our first podcast of 2023. [01:55] - How opening up our calendars to a new year sets us up for planning new things.
[03:17] - Lance walks us through the two types of leaders, the visionary and the executor.
[04:13] - Brian shares the benefit of personal retrospectives.
[07:15] - How 30-day challenges catapult us to success by breaking things down into smaller chunks.
[10:56] - Lance shares why New Year’s resolutions set us up for failure.
[12:35] - How to plan goals using backlogs and the cyclical nature of organizations.
[13:09] - How to use cross-training to challenge team members to broaden their horizons in the new year.
[13:09] - Why you need to think about your intentions when trying to influence up.
[14:03] - Why do 30-day challenges work well to engage in a new task, project, or skill with an experimental mindset.
[15:29] - Lance shares why it’s critical for Scrum Masters to help leadership and management formulate career plans to help grow the people in the organization.
[16:33] - If you’re doing the same thing you did last year, you’re not Agile.
[17:16] - How plugging into a community can help you maintain your focus for growth.
[19:48] - Why being a Scrum Master and a lone wolf don’t mix.
[22:36] - How networking can help you take your career to the next level.
[24:10] - Why it pays to keep an open mind (even to that which you don’t agree with), so you don’t miss out on vital information that can change your trajectory.
[26:07] - Growing as a Scrum Master and as a person.

References and resources mentioned in the show

Agile Mentors Community
Meetup
#13: What Does Cross-Functional Really Mean? with Lance Dacy
Mountain Goat Software
Scrum Alliance
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? Please 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 heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Join Scott Dunn and Brian Milner as they discuss how to influence up, including the tools you can use to overcome difficulties and step into a partnership with the influential people in your organization for influence that creates lasting change.

Overview

While we all want to be heard, but we are sometimes met with leaders in our organization who are uninterested in our concerns or resistant to giving needed support.

And sometimes, it's our approach that's causing our conversations to fall flat.

In this episode of the Agile Mentors podcast, Brian Milner and Scott Dunn share their real-world experience on what to do from your side to earn the right to influence up. They discuss what bosses, managers, leadership, stakeholders, and other higher-ups in the organization want and tools you can use to overcome the gaps and step into a partnership with the powerful people in your organization for lasting change.

Listen now to discover:

[01:06] - Today, Brian and Scott Dunn discuss influencing up.
[01:40] - Scott shares how it's easier to influence if you meet people where they are.
[03:46] - How to create a win-win by adjusting your communication style.
[04:25] - Scott shares how to earn the right to influence up by making things happen on your side of the fence.
[06:17] - How a mind of curiosity can help you negotiate your position when the higher-ups say they are 100% onboard with Agile except for…
[08:22] - How to challenge management without losing your job or credibility.
[10:05] - Why it's vital to look for opportunities to influence an organization at every level.
[11:07] - Organizational taxes are the price of the privilege of working in an organization.
[12:07] - Brian shares how even small iterations of Agile can move the needle in organizations.
[13:09] - Why you need to think about your intentions when trying to influence up.
[14:28] - Scott shares how you can introduce tenants of Agile to show people how to work differently, show up differently, and make a difference to improve an organization.
[16:05] - How returning to values on the Agile Manifesto helps organizations create team dynamics that inspire respectful team dynamics.
[18:59] - Scott shares how making your boss look good makes a big difference for everyone in the organization.
[20:09] - Brian shares how to think like your boss so you can frame your approach in a way that speaks their language.
[23:58] - The opportunity to 'choose your own adventure' within your organization through sharing information.
[25:29] - How to use the power of story to give your boss the tools to help make the change to Agile.
[27:11] - Scott shares how resources such as the Agile Mentors Community can help you delve deeper into community for insight into solving your influence issues.

Listen in next time when Lance Dacy will be on the show.

References and resources mentioned in the show

Agile Manifesto
#24: How Agile Organizations Respond to Challenging Economic Times with Scott Dunn
#1: Scrum vs Agile & Keys to Success with Mike Cohn
Lyssa Adkins
How To Be Successful with Agile in Any Culture
Christopher Avery - CEO & Founder -The Responsibility Company | LinkedIn
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
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? Please 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.

Julie Chickering sits down with Brian to share the best gift books for the Scrum masters in your life.

Overview

We all have those books on our bookshelves that we’ve had for years and still refer back to time and time again, or that new title that we’ve just read that blows our mind with the way it makes a new concept more relatable.

Julie Chickering is a Certified Scrum Trainer (CST), PMI Agile Certified Practitioner (PMI-ACP), and a traditional Project Management Professional (PMP).

Today on the show, Julie joins Brian to discuss the most valuable books they’ve read, the lessons they’ve learned from them, and the best ones for giving to the Scrum Master in your life this holiday season.

Listen now to discover:

[01:06] - Today, Brian and Julie Chickering will be sharing the most valuable books we’ve read.
[02:10] - Julie shares how a book called Two Beats Ahead is helping her learn to let go of her creations.
[04:00] - Julie shares an interesting story of how Beyoncé invited musicians in for collaboration and how that opened her mind to learning from her community.
[05:07] - Brian shares why Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larson is his #1 book recommendation for Scrum Masters.
[06:29] - Julie shares why she’s also a fan of Agile Retrospectives: Making Good Teams Great for the mix-and-mash recipe for creating menu selections.
[08:06] - Julie shares why The Culture Code: The Secrets of Highly Successful Groups insight into the three main things that make high-performing teams high-performing is her favorite book to give to the leaders on her list.
[10:36] - Brian shares the three things from Daniel Pink’s Drive: The Surprising Truth About What Motivates Us that align with Scrum.
[12:34] - Julie shares how she learned to flip the script, start with the hard topics in a conversation, and finish with the positive from Daniel Pink, as included in his book, When: The Scientific Secrets of Perfect Timing.
[15:53] - Brian shares why Dan Pink’s books are most enjoyable via audio.
[16:15] - Julie shares how a podcast interview with author Scott Sonenshein led her to his book called Stretch: Unlock the Power of Less -and Achieve More Than You Ever Imagined, which helps teams unlock their potential to achieve more.
[17:11] - Brian shares Frédéric Laloux's concept of the different colors of organizations as laid out in his book called Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness and how we can better enable change in organizations.
[18:57] - Julie shares a book she recommends in Scrum Master class that’s great for sports fans called The Captain Class by Sam Walker, which walks the reader through what makes great sports teams great.
[22:15] - Brian shares why sports analogies are great for teaching Scrum.
[23:28] - Julie shares how even the Rolling Stones delve deep into figuring out how to improve.
[24:30] - Why retrospectives are a great tool for improving the outcome of any mission.
[28:25] - Brian shares why we still need to adjust to the current climate, even when the goal remains the same.
[30:11] - Brian shares books by recent guests on the show, including Lead Without Blame: Building Resilient Learning Teams by Tricia Broderick, Strategise by Roman Pichler and Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) by Lyssa Adkins.

Listen in next time when Scott Dunn will be on the show.

References and resources mentioned in the show

Two Beats Ahead by Panos A. Panay and R. Michael Hendrix
Agile Retrospectives: Making Good Teams Great by Esther Derby, Diana Larsen
The Culture Code: The Secrets of Highly Successful Groups by Daniel Coyle
DRIVE by Daniel Pink | Animated Core Message
Drive: The Surprising Truth About What Motivates Us by Daniel Pink
When: The Scientific Secrets of Perfect Timing by Daniel Pink
The Power of Regret: How Looking Backward Moves Us Forward by Daniel Pink
Stretch: Unlock the Power of Less -and Achieve More Than You Ever Imagined by Scott Sonenshein
Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness by Frédéric Laloux
The Captain Class by Sam Walker
Lead Without Blame: Building Resilient Learning Teams by Tricia Broderick
Strategise by Roman Pichler
Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) by Lyssa, Adkins
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
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? Please 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).

Tricia Broderick joins Brian to discuss how to lead without blame.

Overview

Vince Lombardi said, “Leaders aren’t born, they are made,” Great leadership is a learned skill, but in companies focused on the blame game, transparency and problem-solving becomes secondary to self-protection.

Tricia Broderick is a leadership and organizational advisor.

Today on the show, Tricia joins Brian to discuss how the blame game stifles great leadership and how the 4Cs can help leaders create safe spaces for highly connected, motivated teams to achieve better results and more impactful outcomes.

Listen now to discover:

[01:37] - Brian introduces us to Tricia Broderick, co-author of the new book, Lead Without Blame: Building Resilient Learning Teams.
[02:36] - Is there a difference between a leader and an Agile leader?
[04:18] - How exposure to the Agile community framework organically promotes leadership.
[06:47] - How the blame game stifles leaders.
[08:28] - When you're afraid of blame, you’re focused on self-protection instead of moving forward.
[09:38] - Why impact is more important than intention and why taking responsibility for your impact is vital.
[11:57] - Tricia shares what we really need for the most creative, quality-based results and outcomes.
[14:43] - Tricia shares why we need to break free from a culture of blame and instead focus on shared goals for quality outcomes.
[16:43] - Tricia shares the 4Cs of leadership.
[17:52] - Great leaders aren’t afraid of complexity; they embrace uncertainty.
[18:37] - Leaders instill confidence in others—having a leader that believes in you before you even believe in yourself has a huge motivating impact.
[19:53] - Brian shares the concept of ‘dark leadership.’
[20:42] - Why compassion is the key to defeating imposter syndrome.
[22:37] - It takes a courageous leader to create a safe space to challenge the status quo and seek out alternative ways for your team to operate.
[25:37] - Why investing yourself personally and compassionately in the personal development of your team members isn't for the weak.
[26:08] - The importance of the investment in a connection.
[26:37] - Tricia shares the biggest takeaway for leaders.
[27:31] - Tricia talks about resilient transparency and the leadership learning curve.

Listen next time when Julie Chickering will be on the show.

References and resources mentioned in the show

Lead Without Blame: Building Resilient Learning Teams
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
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? Please 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.

Tricia Broderick’s transformational leadership, at all levels of an organization, ignites the growth of leaders and high-performing teams to deliver quality outcomes. Tricia has more than twenty years of experience in the software development industry. She is the author of Lead Without Blame: Building Resilient Learning Teams.

Lance Dacy joins Brian to discuss breaking down stories to get things done.

Overview

There are ways to break stories down into two- or three days worth of work across the team. But sometimes, they can be taken down to a level that devalues what your team is trying to deliver.

Lance Dacy is a Certified Scrum Trainer® with the Scrum Alliance®

Today on the show, Lance joins Brian to discuss some of the questions you need to ask when breaking stories down. We discuss how to organize teams for the best outcome and share different systems and processes to determine how far is enough when breaking down stories to help your team deliver a usable product to the end user.

Listen now to discover:

[01:37] - Brian introduces us to Lance Dacy, his guest and neighbor.
[02:29] - Brian shares how you can suggest a topic for a future podcast episode by emailing your suggestion to podcast@mountaingoatsoftware.com.
[02:57] - Today, we're talking about getting work into its smallest component.
[03:21] - Lance shares the four things teams need to do to be sure they are all speaking the same language when transitioning to Scrum.
[03:44] - The make-or-break consequences of organizing teams for the best outcomes.
[05:49] - Lance shares his insight on breaking things down into tasks in the product backlog.
[07:47] - Lance uses a car cleaning analogy to break down the story into smaller tasks.
[09:40] - In backlog refinement, we will start rounding out those acceptance criteria or conditions of satisfaction and make them their own story.
[10:58] - Lance shares his system for determining how far is 'enough' when breaking down stories to be ready.
[12:33] - The goal for each sprint planning session.
[13:09] - Using the INVEST criteria to assess the quality of a user story.
[13:48] - How small is too small?
[15:17] - I love metrics, BUT metrics CAN BE misused.
[15:55] - The key to not being surprised.
[16:37] - Brian shares the importance of the V in the INVEST criteria.
[18:14] - Vertically slicing stories to deliver something usable to the end user (the product owner).
[21:42] - Using the SPIDR approach to splitting stories.
[22:24] - Asking the right questions to create paths that lead to stories that turn into relevant products.
[25:55] - The importance of interfaces when splitting up stories.
[28:22] - The pros and cons of spikes—why they should be the exception and NOT the rule.
[32:01] - Lance circles back to the consequences of creating your teams—focusing on the deliverables.
[33:37] - Remember, releasing the product is independent of your sprint time box.

Listen next time when we'll be discussing…

Transformational Leadership with Tricia Broderick

References and resources mentioned in the show

What does INVEST Stand For?
The S.P.I.D.R. Approach to Splitting Stories
HOW TO SPLIT A USER STORY by Richard Lawrence
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
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? Please 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, known as Big Agile, is a dynamic, experienced management and technical professional with the proven ability to energize teams, plan with vision, and establish results in a fast-paced, customer-focused environment. He is a Certified Scrum Trainer® with the Scrum Alliance and has trained and coached many successful Scrum implementations from Fortune 20 companies to small start-ups since 2011.

Henrik Kniberg joins Brian to talk about creating the Spotify Model.

Overview

There are ways to get things done, and then there are the best ways to get things done. But the only way to arrive at the right way of doing things is to try and fail, to see what works and what doesn't.

Henrik Kniberg is a Certified Scrum Trainer who has worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He's also the co-creator of the Spotify Model.

Today on the show, Henrik joins Brian to discuss his accidental introduction to Spotify and how he inspired the company to transition to Scrum. We discuss the leadership model that helped the startup scale while holding its own against behemoths like Apple and Google. Plus, an inside look at his time as a designer with Minecraft.

Listen now to discover:

[01:55] - Brian shares Henrik's Agile Product Ownership in a Nutshell that's become required viewing.
[02:22] - Brian shares some of the places on Henrik's resume, including Lego, Minecraft, and Spotify.
[03:42] - Henrik shares his love for playing accompaniment musical instruments.
[04:08] - Brian shares his professional musical background.
[04:35] - Introducing the Spotify engineering culture videos that have sparked a thousand conversations about scaling challenges.
[05:10] - Henrik shares the story of his accidental introduction to Spotify and how he inspired the startups to transition to Scrum.
[8:26] - Henrik describes how the lack of off-the-shelf scaling frameworks led to his work with Spotify.
[08:45] - Standard Scrum, by the books, works for small teams, but for scaling at larger teams like the one at Spotify, it's hard to find a "one size fits all" approach.
[10:59] - How realizing 'this is what's helping us swim' during their impressive growth got all the technical leaders of Spotify on board with using Agile.
[12:50] - Henrik shares the leadership model that helped Spotify scale up.
[14:58] - How Spotify used the speed of innovation to stand against goliath-like competitors like Apple and Google.
[16:30] - Convincing the investors that being able to iterate quickly (rather than through roadmaps) was the key to winning the game.
[18:09] - Fueling future inspiration—why Spotify instituted the twice-a-year hack weeks for their entire organization.
[21:36] - Henrik shares why leadership is the key to culture and driving change in an Agile organization.
[24:19] - Brian shares why it's wise to make a change where you can benefit a company rather than hanging on to the now-extinct gold watch at retirement.
[25:53] - "Go ahead and copy the Spotify model… and don't worry about someone telling you that you're doing it wrong because that's just you adapting."
[26:44] - How the Spotify culture videos had the opposite outcome from what Henrik had planned.
[29:54] - Brian asks Henrik an important Minecraft question (as posed by his daughter.)
[30:36] - Henrik shares insider information about the guiding principles for designers at Minecraft (and how that led to the creation of Striders).
[32:34] - Brian shares why copy/paste is only sometimes best.
[32:46] - Henrik shares how creating video games differs from life applications.

Listen next time when we'll be discussing…

Getting to Small with Lance Dacy

References and resources mentioned in the show

Agile Product Ownership in a Nutshell
Spotify Engineering Culture - Part 1 (aka the "Spotify Model")
Spotify Engineering Culture - Part 2 (aka the "Spotify Model")
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
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? Please 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.

Henrik Kniberg is former member of the board of directors of the Agile Alliance and enjoys helping companies succeed with both the technical and human sides of software development. A Certified Scrum Trainer he’s worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He’s also the co-creator of the Spotify Model.

Tired of “What went well?” and “What didn’t”? Brian Milner is here to help you cook up retrospectives that actually get your team thinking, collaborating, and improving. From creative themes to actionable frameworks, this is your behind-the-scenes guide to better retros.

Overview

Do your retrospectives feel more “check-the-box” than game-changing? Brian Milner shares his full recipe for planning and facilitating retrospectives that actually matter.

Whether your team is stuck in repetition, tuning out, or phoning it in, Brian’s step-by-step approach will show you how to bring structure, creativity, and energy back into the room.

Brian walks you through the five essential components of a retrospective, including how to match formats to your team’s personality, align activities with Agile's three pillars (transparency, inspection, and adaptation), and spark meaningful change with every session.

References and resources mentioned in the show:

Stranger Things Retrospective Download
Agile Retrospectives by Esther Derby & Diana Larsen
Retromat
Blog: Overcoming Four Common Problems with Retrospectives by Mike Cohn
Blog: Does a Scrum Team Need a Retrospective Every Sprint? By Mike Cohn
#139 The Retrospective Reset with Cort Sharp
Retrospectives Repair Guide
Better Retrospectives
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.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast, like we always do. And I'm with you as always, Brian Milner. Today we have with us, me, just me. Now, before you get frustrated with that or think we're copping out in some way, this is intentional. I wanted to have an episode to myself because and working through all this stuff around retrospectives, I thought that it might be good to take an episode here. And I kind of thought of it sort of like a cooking episode, right?

Like if you watch a cooking show, you know, Gordon Ramsay show or something, they'll walk you through how they make something. And it's from start to finish. They show you the ingredients. They show you how everything's put together. And then you see this beautiful dish at the end. Well, I've often compared the way that you can format a retrospective to a little bit like a meal, because a meal has different courses in it. And a retrospective should have these themed areas or repeatable sections of it. And so I thought of it a little bit like making a meal.

So I thought I'd just walk you through a little bit step by step. what I'm thinking here and how I would go about doing it. this is, you know, we're cooking up something special here. It's a kind of a recipe here that's, you know, equal parts creative and effective. It's a way to try to keep your retrospectives interesting, but also keep them to be solid and where you can have an actual outcome that comes from this.

And you actually make definitive changes here with your team as a result. So there's a couple of retrospective courses that I have coming out where I go into detail about all these things, but I wanted to take an episode where I could walk you through and just have you kind of peer over my shoulder a little bit about how I might do this if I was going to create a retrospective for a team.

So first starters, I think we have to understand that there is a menu to follow, right? And I kind of use this menu metaphor because one of the great things about when you go out and you have a meal at a nice restaurant is there's a repeatable pattern to it. You kind of expect that they're gonna bring you a drink first and then maybe you have, if it's a really fancy restaurant, maybe you have appetizers first or hors d'oeuvres even before appetizers, then you maybe have appetizers or not. Then you have a main course and maybe you have a salad even before the main course and then you have a a meal, and then you have some kind of a dessert afterwards, maybe even some kind of a cocktail at the end of the meal or coffee at the end of the meal.

But there's sort of a pattern to it. And regardless of what restaurant you go to, you kind of repeat that same pattern. Now, I know that there's times you'll be, this is where the metaphor kind of breaks down a little bit, I get it. You may not have the same pieces every time. And what we're going to be talking about here as a retrospective pattern is that, yes, you should sort of follow the same pattern.

You can't really get to, let's say, dessert. You can't just skip and go to dessert, right? You've got to go through this journey of the other sections so that you can end up at dessert and really fully appreciate it, right, and get the most out of it.

So that's where this metaphor is a little bit of a, starts to break down a little tiny bit. But. I want to talk about here first why retrospectives matter and why they often go stale. I think they often go stale for a lot of reasons, but one of the chief reasons I've encountered when I work with teams is that the Scrum Master on the team really only has a small amount of formats and styles that they have to work with. They have a small little set in their toolbox. And they may even rotate through a few of them. But at the end of the day, it's kind of a small toolbox. There's only a few tools in there. And if I'm a team, if I'm a member of that team, you can imagine how I might get bored.

And I might think this is not really worthwhile if I'm showing up every single time and I'm hearing the same exact questions. What did I do? What do we do well? What do we not do so well? Do I have any roadblocks? If I'm just asked that same thing every time, then I might not feel like this is a very worthwhile thing. Or I might get to the point where I feel like, gosh, I've answered the same question, you know, three sprints in a row. I just, got nothing more for you Scrum Master. I just, I can't dig any deeper.

I've given you everything and it just feels like this is the, you know, groundhog day. We're doing the same thing over and over again, but nothing's really changing. So. I think it's important that we be able to switch things up, but it's not change just for change sake. That's why I think that having a structure of some kind can give you that pattern to fall back on that can make it effective, but then also can provide variety, can make it something that changes over time as you do this with your team. Doesn't mean that you can't ever repeat a format that you've used. I don't think that's a bad thing.

I just wouldn't want to repeat the same, just handful, small little number of them over and over again. That's going to get repetitive and it's going to make people a little frustrated. The other thing is I think you have to match these to the personality of your team. Your team might be more outgoing or they might be more introverted. You might have people who prefer activities or little more, you know, kind of quiet activities or some that are more verbal, you know, require more discussion. That's really an individual thing for your team.

So I think you have to think as you go through this, what's going to work for these people, right? For this set of individuals that I am working with. You know, I always say there's kind of a first commandment for Scrum Masters, know thy team. And I think that's really something that's important for us to grasp onto is we have to know our team. can't coach to the average.

Right? We have to coach to the individual, to what we have on our team, because your team is unique. That set of individuals has never come together anywhere else in the world. Right? Those personalities. And what you want is to find out how to make that set of people work well together. Right? How do they work best together? Not how does every other team in the world work best or how does the average team work best? How does your team work best? Right? So with all of this is sort of setting this and saying that there should be a pattern.

I do want to give the hat tip here and say that the Esther Derby Dinah Larson book on retrospectives is one I strongly recommend. In fact, pretty much my whole career as a trainer, I have said, when people say if there's one book, if I'm to be a Scrum Master, if there's one book that you would say would be really impactful to me from pretty much day one, I have pointed to that book. It's called Agile Retrospectives, Esther Derby, Dinah Larson. And in that book, they lay out a pattern of kind of five phases that go through it.

I'm going to distill it down because to me, it's sort of the three middle ones that are the most important. I will talk about the two on the ends here as well and kind of put that on top of these three. But sometimes I find people find it easier if they just remember what I'm gonna teach you here about the three that are in the middle. So in Scrum Master classes, we will talk often about how there's these three pillars of the Agile process or three pillars of empiricism. Empiricism says that we learn through experience. Well, I always say in class, it's not enough to just do the wrong thing over and over again. I gain a lot of experience by doing the wrong thing over and over, but I don't learn from it.

And the three pillars are what's needed to make sure you learn from them. And I'm sure you've heard these before, but if you haven't, transparency, inspection, adaptation. Those are the three. Transparency meaning we're not going to be clouded about how we do the work. We're going to be very transparent, open about it. We're going to try to reveal how we work best as much as possible. Inspection, that we're going to actually take time and pause and try to figure out not just what happened, that would be transparency, right?

What's the reality of what just happened? But inspecting says, why did this happen? Right? What's the root cause of it? I don't want to just deal with the symptoms, right? If we just try to cure the symptoms over and over again, we still have the same disease, we still have the same illness, and we're not really getting to the root cause.

So inspection says, we're going to take time out to actually get to the root cause. And then adaptation, the last one, is probably the most important step here, because if you figure out what's wrong, but you don't ever do anything about it, well, we're doomed to have the same exact discussion again. So adaptation says, now that you know what the problem is, what are you going to try different? We may not even know exactly what the right thing to do is, but we got to try something. What we know for certain is what we did didn't work.

That's the one thing we absolutely can't do again, is exactly what we did. We've got to try something new so that we move on, right? So that we find out more information and get closer to whatever our final solution is. So transparency, inspection, adaptation, those three actually serve as a good guideline or three phases you can think about for your retrospectives.

There needs to be a transparency phase where you try to figure out what happened this last sprint. there needs to be an inspection phase where now that we know what happened, we got to ask the question, why did it happen? And we need to get to the root cause of why it happened. Now that we know what that is, then we have to move on to adaptation to say, what are we going to do about it? How are we going to take this knowledge we just gained and actually make a change? So we need activities around all three.

And what I'm saying here to you is that can serve as your menu. I can do lots of different activities that would match these three areas. Now, I do, again, want to go back to the Esther Derby, Dinah Larson book, because their five phases adds one on the beginning, one on the end, which I actually do think are very helpful. The first one is kind of opening the retrospective. It's a way of trying to just start to get voices in the room. And this is something I will often do as well. Just a quick, quick exercise to just get people to start talking.

And that's one of the ways you can start to get a quieter group to get involved is throw them something really easy to respond to right out of the gate. And then the last one is to close the retrospective. Closing the retrospective is a great way to then try to sum it all up and say, well, here's the takeaways, here's the things we're going to do about it, and we're going to move forward from here.

Opening the retrospective to that introduction can also then review what you talked about at the end of the last. retrospective. You can say, here are the things that we decided, and let's talk about what's been done about them before you start to inspect the current retrospective. So given that, right, I know I'm going fast here, but you can rewind and listen back to this if you need to.

But if you think about that, that you have these kind of phased approaches, and think of it like a menu, right? There's different courses to my menu. Well, I'm not going to serve the same meal every time. That would be boring. So I got to find out different things I can serve for each course of my retrospective. Now, here's where it gets interesting, right?

Because there are lots of tools out there. And there's a website that I often recommend called RetroMAT. RetroMAT is a great site where you can go to, and it has those five phases. You can kind of scroll through different exercises for each of the five phases. they sort of have, you you can kind of mix and match and create your own menu based off of that.

And doing that is absolutely free. Now they have paid things there as well. They're not a sponsor. I don't get any kickbacks or anything from them. But they have some paid activities as well as far as having things like Mural and Miro templates that you can use if you want to do that as well. So there's lots of things you can do there to thank them for what they put together. But there are times when Maybe you're trying to fit this to your team specifically, or you've grown tired of the exercises that you're used to, and you want to find some new dynamic to add into your retrospective.

So what I'm going to do is kind of walk you through what I would do if I wanted to take some kind of a theme and create a new retrospective that's themed around a certain topic. Now I will say that this theme is gonna go just in one of our sections. So it's not going to go throughout it. I'm not gonna be that creative here with you on it, because I don't think you need to be. I don't think you need to have this, it's not like a theme to party, right? You can just take the theme and use it in one of the sections. So what would I do for something like this?

Well, I'd start with, as I said, some way to kind of open the retrospective. And I like to have little quick activities as I said, that just get voices in the room. an example of things I've done in the past. Ask the team a quick question like, if this last sprint were a song title, what song title would you use to describe this last sprint? And people can use whatever kind of music they like, right? It doesn't matter.

They can just call it any songs that they're familiar with. Or do movie titles. I've had a lot of fun in the past doing that with teams where I'll say, hey, shout out a movie title that might represent this last sprint. You just want to find something quick that people can shout out like one or two word answers, right? Or a small sentence in the case of a song title or movie title or something like that.

But something that they can tie it into, right? And it doesn't have to be anything that makes perfect sense, right? It can be kind of crazy. It can be... You know, if this last sprint were a flavor of Starburst or, you know, an color, what color would it be and why? And just have people, you know, shout out whatever they think the answer would be.

They might have to be a little creative with their answers when they do that. But that's okay. You're just giving them an opportunity to have a few voices start to enter the conversation. Don't force anyone, right? Don't force anyone to shout out, but give them an opportunity to. So I'm going to open the retrospective with some kind of fun, quick exercise like that.

Probably won't take more than five minutes, okay? Then I want to move into that transparency section. And the way I frame transparency is what actually happened this last sprint?

What was the reality of what happened this last sprint? So here's where I'm going to inject a themed kind of approach. And I just, I go through a couple of examples in our courses where I talk about doing this, but I picked a different one here for this podcast episode that I've put together right before this recording to try to walk you through a little bit of how I did this.

So I tried to pick something that was a little more relevant to today. I know that this is popular and people are looking forward to the next season, which is about to come out. sometime soon, I know they've been shooting it, but I picked the theme, Stranger Things. And I just thought, what if my team, you know, had, I knew there were some people on my team really into Stranger Things, or what if I just knew they were aware of it, they knew what it was, and I wanted to have a theme built around this.

So here's how easy it is to do this. I went to chat GPT, and I asked it to give me some, you know, putting together a retrospective that I want to theme it around stranger things. And give me some major themes from Stranger Things that might align to Some different ways of collecting information around what actually happened this last sprint. And. They gave me a long list of different things.

And I read through these and kind of tweaked them, talked back and forth with it a little bit, kind of refined. And I distilled it down to five sort of themes or categories I thought would be fun and would kind of challenge the group to think along different lines of thought. So here's what I came up with with Chat GPT's help. My first category. I called running up that hill.

And what I put for the prompt for this one is what felt like an uphill battle this sprint? Now just think about that, right? In traditional sprints, there's lots of things that are just, I'm essentially asking what was the obstacles?

What were the hurdles in this sprint? But I'm getting them to think about it in little different way by saying, what was an uphill battle in this sprint? And even that subtle rewording, of that prompt can trigger people's brains to work in a different way and get them to think along different lines. If I just ask over and over again, you know, what was a blocker of this sprint or what blockers do we encounter this sprint? If I use those same words over and over, I get sort of immunized against them and I can't really think about anything new.

But just phrasing it that little slightly different way, what felt like an uphill battle this sprint I think can really trigger some new ways of thinking. So that was my first category. The second one that I came up with, big theme here in Stranger Things, was the upside down. And I related it this way to say, what is completely upside down right now?

What is the opposite of what it should be right now? Now here, I'm trying to get them to think about things that are not really going well, right? Things that are going the opposite direction that they should, and it's upside down from what should be the normal. Right? And again, we're just thinking along this theme of stranger things and I'm tricking their brains a little bit into thinking along a different line, right? To examine it from a different point of view. My third category that I thought would be fun was I titled Vecna's Curse.

And what I prompted here for this one was what haunted the team this sprint or kept coming back up to bite us. And The idea here is to get them to think about things that were maybe decisions we wish we had made differently. These could have been decisions in the past. It didn't have to be a decision from this sprint. But what are those things that we felt kind of like was like Vecna's curse?

It was just something that kept rearing its ugly head. And it was just a struggle for us to get around. My fourth one, just to have a little fun. I call the fourth one Surfer Boy Pizza. And what I put as a prompt on this one was, where did we bring the chill? Where did we bring the creative spin to a tough solution during the sprint? So here I'm wanting to celebrate good things, right?

And I'm asking that in a funny way. So it brings some humor to it, puts them in a better mood, and also gets them to think along a maybe a little bit of a different line in this area to think, all right, well, what do we get really creative about? What do we have to be really creative about in this sprint? What kind of tough solutions did we really conquer? Did we really nail in this sprint?

And I'm just theming around that loose theme of that surfer boy pizza from the last season. And then the last one, I couldn't have categories here without mentioning Hellfire Club. So the last one was Hellfire Club. And the prompt I put for it was, where could we bring more of kind of that Hellfire Club vibe, planning, teamwork, shared adventure, right? Just the fun.

Where could we put more of that vibe into our team and to how we operate? Now, this is getting them to think about something that might otherwise be a little bit of a uncomfortable thing to think about, right? Because Now we're getting into interpersonal dynamics. We're getting into how the team actually works and fits together. And that's why I chose this theme, because I wanted it to be just kind of a, even maybe a sneaky back doorway of getting their brains to start to examine, yeah, what would have made this more fun?

Or what would have made this, how could we have, I've asked often in retrospectives, what would it take for us to be the team that everyone else wishes they were on? Well, That's what I'm asking here, essentially. So I've got my five themes. And I even then went forward and created and kind of get some images for each one of those, like icons for each one of those things.

Just created a board and mural for this and put each of those things up. Had a big block space next to each one where people could put Post-it notes. So what I would do here in the retrospective is I'd introduce this. I'd give them the prompts for each of the section and say, all right, let's take a few minutes. Everyone can add Post-its to any of these sections, but try to think through several of them and put several of them up here on the screen or physical board if we're in the same space. But take a few moments here to think through each category and see if there's anything that you can think of that you would add to each area.

So we take, I don't know, five, 10 minutes to do that. normally time that, I just see when it starts to slow down. And there's generally a point there where you can kind of intuitively feel it and feel like, you know, the group's ready to move on. So whenever that time comes, I'll call a halt to it and I'll say, all right, now that we've done this, I want us to try to narrow down what's on the board. So let's give you each three votes.

And I do this usually with dot voting or something along that line. where they have three dots they can place on three different sticky notes across all five categories. And what I tell them is find the three that are the most important of all the things here, what are the three that are most important and put your vote on those top three. And by doing this, having the team vote on it, then we surface the most important three out of the entire group, right? It's not to say we ignore the others, but we're going to try, we can't focus on everything in our time that we have.

So, whether our top three, and then I start with the first one, right? So right now, all we've done is kind of the introduction of the sprint. We've done a transparency section. Now we move into the inspection. Now there's lots of different things you can do here, but what I put together for this retrospective was taking them through sort of a five whys activity.

So I would take that first one, I'd have them examine it and look at it and say, all right, let's ask the question why five times for this one. Why did this happen? whatever they answer, then we say, all right, well, why did that happen then? And we ask why, it doesn't have to technically be five times, but you need to ask it enough to where you get down to something that you can say, yeah, that's definitely the root cause, right? That's what's underneath all this. All that followed it, all that came afterwards was all stuff that came as a result of us making that decision.

So once we have our root cause, we can repeat that again for the other two. if we have time, but if we're starting to run out of time, I kind of watch my time box there. And once I realize we need to move into solutioning, then we'll move on into the adaptation portion. In adaptation, we just take each single one, and we kind of repeat this process of getting possible answers across the team.

So for the number one issue that you guys identified, here's our root cause. Let's take some post-its here. or let's take some suggestions of what we might possibly do to counteract this in the next sprint. So we get those things that come up. Then we'll talk through each one, and we'll try to build consensus as a team as to the most important step to take. So for each item, I want what's the one most important thing to do. So we'll identify that, again, as time allows, I want to at least do the most important thing.

If we have time for more than that, great, we'll get to the second and third. But I think it's so important to just, whatever the biggest, most important thing is, make sure you have an action item for that thing. And here's where I just caution you. It doesn't have to be, hey, we've knocked it out. We've cleared it. We've solved it in the next sprint. It just has to be that we've taken a step towards solving it, right? What's the old phrase, a journey of a thousand miles starts with a single step. Well, the same thing goes for our teams.

And this is oftentimes why teams get stuck, is they just feel paralyzed. Hey, there's nothing we can do about this. It's such a huge issue. Well, that's not true. What's the next step you can take? So take the next step.

Make sure that the team understands what it is. And make sure we understand who is going to be responsible for that. And do that for as many as you can get through. Then get to the closing the retrospective part of it. Kind of wrap up. Remind them, here's the journey we've taken, here's what we've uncovered, and here's what we're gonna do differently for next time.

And now those items, they should go straight into your next sprint backlog, not product backlog, sprint backlog, right? They don't need to be prioritized because the product owner has been with you, they should have been with you in this meeting, it's the entire Scrum team. So the product owner has weighed in as well. This has been a team collective decision. So now those items should go into your sprint backlog, and you should do something about them in this next sprint. That's the whole concept of the Kaizen comes first, right?

The good change should happen before we do anything else so we can get the benefit of it over a longer period of time. So that's kind of the idea here. And I wanted to give you that kind of really quick flyby to help you kind of see how to go about doing something like this, right? And I just picked one theme. I just picked Stranger Things because I thought it would be fun to work on. I thought it would be a fun kind of theme. And it might be fun for a team I was working with. But maybe that's not something that aligns to your team.

Maybe your team has a bunch of people who are really into cricket. Well, do a cricket-themed one. Maybe you have a team that's around the Academy Awards time. And everyone's talking about, and now people don't do this as much anymore, but. Maybe they're all talking about who's going to Oscars this year or something. Well, do an Oscar-themed one. Or it can be around anything. Do it around award shows in general. It doesn't have to be just Oscars, but do it around any kind of award show. And you can pick up different themes.

Again, if you're stuck, ask your favorite large language model and see what it comes up with. It's not all going to be gems that comes from that, but you can pick and choose and refine it, which is exactly what I did with my five themes for this. So I hope you see how easy it is to do that. It doesn't have to be complicated. You don't have to be extremely creative to do this.

You can make use of the tools that you have available to you. And as a Scrum Master, you can keep this fresh. You can tailor this to the team that you have. What is your team really into?

What's the theme that they would really resonate with? Choose that. Go with that. Create a theme around that and see what they think about it. Afterwards, ask them, hey, did this work all right? Did you like this? I hope that's been useful to you. If you like this and you want to hear more like this, come to our website to mountngoatsoftware.com and check out our courses that we're launching actually this week, Better Retrospectives and the Retrospective Repair Guide. Those are the two that we really want to have you kind of think about.

Come to our site, find out more about them. Better Retrospectives is all about just the expert level retrospectives course really gets into the heart of a lot of these issues at a very, very deep level. The retrospectives repair guide is taking the 10 most asked questions that we have about retrospectives at Mountain Goat Software and giving you really deep dives on how to solution those, how to problem solve those top 10 issues. And the great news for you is if you're listening to this in real time, right, when we've launched this, We're launching this as a two-for-one special. We'll not have that special again. So it's $99 that you get both of those courses. You don't have to pick and choose from them. You can give $99.

They're prerecorded. You can watch them at your own pace. This is for people who want this knowledge, who want these answers. And I know when I was a Scrum Master starting out, there was a lot of, I followed a kind of the pattern that Mike established with his sprint repair guide. I bought that when I was coming up as a scrum master because I needed answers to some of the questions that he had in that scrum repair guide. Well, take a look at the 10 that we have for our retrospective repair guide. Maybe you'll find one of those things that's really tripping you up and maybe just getting the answer to one of those is going to be worth the money for you. I encourage you to go to our site, check it out.

Don't miss this. It's a limited time cart that's opened. It's only going to be open for a week. So if you're listening to this when we launch it, don't delay, don't wait until next week. If you hear this next week, then you're running out of time. So make sure that you take advantage of the time that you have here so that you can get these two courses, two for the price of one here at our launch.

Again, we won't do that again. So I hope you found this to be useful. It's just a little taste of the kind of thing that's in those courses for you. And if retrospectives are something that you're struggling with, or if retrospectives are something that you just feel like, man, it really could be more. It really could deliver more for my team. Check out these two courses. I really think they're gonna help a lot of teams out there. That's why we put them together. So that'll wrap it up. I hope you've enjoyed this and we'll talk to you next time. on another episode of the Agile Mentors Podcast.

Scott Dunn joins Brian to talk about how Agile teams and organizations respond in difficult economic times.

Overview

Right now, the word recession is being bandied about, and big companies like Apple and Facebook are already beginning to scale back. But economic downturns can present opportunities for the right individuals.

Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with more than 20 years of experience.

Today on the show, Scott joins Brian to discuss why now is the moment to hone in on your mission and determine your job market value and how Agile training can prepare you for any opportunity that comes your way.

Listen now to discover:

[01:52] - Brian shares how the word recession triggers companies to batten down the hatches.
[03:19] - How leaning into Agile in an organization creates a natural operating cost reduction.
[04:52] - Studies show organizations that invest during recessions are better positioned at the back end of it to, you know, accelerate like a rocket out of it.
[06:55] - Scott explains how the Japanese concept of ‘danger opportunity’ offers teams a chance ‘to really do Agile’ and operate efficiently with less.
[9:34] - How difficult times help companies prioritize and hone in on their mission and vision and stop trying to be everything to everybody.
[12:57] - How organizations create unease and lack of employee trust.
[14:46] - How Agile can help workplaces bring humanity back when responding to change.
[16:18] -Scott shares a conversation with his daughter about voting with your feet and your values.
[19:16] -Scott explains why companies need to invest in top talent to lower their technical debt.
[20:17] - Why times like these require ruthlessness in proving out your theories.
[22:10] - Scott shares why down economic times are opportunities in disguise for individuals to determine the types of environments they want to help flourish.
[25:13] - Determining your job market value and the importance of looking at the total package of an opportunity.
[28:30] -Is it really Agile, or is it Agile in name only?
[31:33] - How taking classes at Mountain Goat can prepare you to bring your knowledge and skills to any opportunity.

Listen next time when we'll be discussing…

Scaling with Henrik Kniberg.

References and resources mentioned in the show

Mountain Goat Software
Agile Mentors Community
Scrum Alliance
Jim Collins The Hedgehog Concept

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? Please 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.

John Miller joins Brian to talk about Agile in the classroom.

Overview

Agile classrooms help students develop skills that will serve them long after they've left the classroom.

John Miller is a Certified Enterprise Coach (CEC) and the Chief Empowerment Officer for Agile Classrooms.

Today on the show, John joins Brian to share how he started introducing the Agile framework to educators. He walks us through how Agile classrooms help students solve complex problems while developing decision-making skills. He'll share how converting to an Agile classroom creates deeper, more fulfilling student and teacher relationships and the steps teachers can take to make their classroom an Agile classroom.

Listen now to discover:

[01:27] - Brian introduces John Miller and explains how, as a CEC, he's reached the highest rung on the Scrum Alliance certification ladder.
[03:33] - How John got started with bringing Agile to the classroom.
[06:09] - The collaboration between John and the educators to achieve the goal of creating a self-managing classroom.
[09:45] - John shares how he went from thinking he'd ruined one class's education to watching them become one of the best self-managing groups he's ever seen.
[12:16] - How children's lack of preconceived notions about how things are supposed to work helps them create teams that work.
[13:48] - How an Agile classroom empowers students of all levels and learning abilities.
[14:36] - The five levels of choice in an Agile classroom.
[15:44] - John shares the objective of Agile classrooms to help students solve complex problems by developing choice-making skills.
[17:55] - Brian shares that "Scrum is a sports analogy."
[19:33] - Dark Scrum vs. Bright Scrum. John shares the formula he created using Ron Jeffries' term Dark Scrum.
[24:06] - Is Agile dead, or are people just doing it wrong?
[25:13] - John shares the levels of classrooms where Agile works best. Plus, which one did he work with that made him more nervous than high-level CEOs?
[27:12] - John explains how the different dynamics lead to different success outcomes for incorporating Scrum into the classroom.
[28:42] - What size classrooms achieve the most benefits from working with Scrum?
[29:44] - John shares the steps teachers can take to make their classroom an Agile classroom.
[31:20] - How converting to an Agile classroom creates deeper, more fulfilling teacher-student relationships.
[31:53] - How Agile in the classroom acts as a bridge to industry and a life skills primer.

References and resources mentioned in the show

Agile Mentors Community
Scrum Alliance
Agile Classrooms
Dark Scrum
Agile Manifesto
McGregor's Theory

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? Please 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.

John Miller is a Certified Enterprise Coach (CEC) and the Chief Empowerment Officer for Agile Classrooms. Since 2012, John's mission through Agile Classrooms has been to help educators take a more innovative and creative approach to guiding faculty, managing their schools, and teaching students.

Roman Pichler joins Brian to talk about Product Roadmaps.

Overview

Product roadmaps help teams plan their everyday work and how their products will change over a year. But then, products evolve, and new data is collected and shared. Companies must then decide how to adapt and progress. So, how can we then create a product roadmap?

Roman Pichler is an internationally renowned product management expert specializing in product strategy, leadership, and agility.

Today on the show, Roman joins Brian to discuss how to create helpful product roadmaps that create value for the end users in a Scrum based context to move forward and simplify product management.

Listen now to discover:

[00:06] - Brian introduces Roman Pichler, one of his 'agile heroes.
[00:35] - Brian shares about the book Strategise, 2nd Edition.
[02:54] - Roman answers the question, "What is a Product Roadmap?"
[03:58] - Roman explains if product roadmaps are helpful in an agile Scrum based context.
[05:31] - Roman discusses using outcome-based goal-oriented roadmaps to determine a company's product value.
[07:33] - Roman shares some examples of goals on a product roadmap.
[08:12] - Why a goal-oriented based roadmap is all about outcomes.
[09:35] - Brian shares insight into Roman's downloadable Go Product Roadmap.
[10:07] - Roman shares how the latest version of the Scrum guide fits in with protocols, product goals, and outcome-based roadmaps.
[11:54] - Why Roman adds time frame constraints into his product end goals.
[14:41] - Roman shares the two things you need to succeed with collaborative product road mapping in an agile space.
[16:40] - Roman explains how to incorporate time frame constraints into your roadmap.
[19:40] - The difference between an internal and external product roadmap for public consumption.
[21:11] - The importance of an impact analysis when determining whether to stick with a specific delivery date or fully meeting a goal.
[25:00] - How to get precise estimates for your team.
[26:15] - Roman shares his 'sweet spot' for making outcome-based investment decisions.
[28:40] - Roman advises setting dates on (internal) roadmaps for contract-based environments.
[29:06] - Roman shares Apple's trade-off decision when they launched the original iPhone in 2007.
[31:40] - How to use goals to track the most valuable metrics.
[34:41] - The importance of understanding the needs of the stakeholders.
[35:19] - Roman shares the importance of balancing expectations with empathy for improved collaboration.
[39:12] - Brian shares a funny story about the difference in polite communication between Americans and our friends on the other side of the pond.
[40:46] - Roman shares why you shouldn't relinquish product road mapping in an agile space too soon.

Listen next time when we'll be discussing…

Agile and education with John Miller.

References and resources mentioned in the show

Roman Pichler
Strategise
Go Product Roadmap

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? Please 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.

Roman Pilcher is a leading product management expert specializing in product strategy, leadership, and agility. He has advised product leaders and taught product managers and owners for over 15 years, pioneering agile product management practices. Roman shares his knowledge through his training courses, books, and podcast. You can find his popular Product Vision Board and Go Product Roadmap on his website.

Brian speaks with Stacey Ackerman about working with Marketing teams using Agile.

While the majority of teams using Agile are based in software, one of the fastest growing areas for Scrum teams is in Marketing. There’s a natural fit as Marketers are used to using such practices as A/B testing and getting quick results that feed their next steps.

As you can imagine, there are a unique set of challenges that a marketing team presents that other Scrum teams don’t necessarily have to deal with as well. In this episode, Stacey talks us through the process that marketing teams follow when attempting to apply agile principles to their work.

Listen now to discover:

- 2:28 - what’s different about the way marketing teams approach agile?
- 8:51 - what is the Agile Marketing Navigator and how are teams using it?
- 15:05 - Stacey goes over the different roles
- 17:43 - what are the chief problems marketing teams deal with in adopting this?

Listen next time when we’ll be discussing…

Product Roadmaps with Roman Pichler!

References and resources mentioned in the show

• Agile Marketing Manifesto

Want to get involved?

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

• Enjoyed what you heard today? It would be great if you left 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 as 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.

Stacey Ackerman is one of the few agile coaches and trainers that got her start in marketing. After graduating from journalism school, she worked as a content writer, strategist, director, and adjunct marketing professor. She became passionate about agile as a better way to work in 2012 when she experimented with it for an ad agency client. Since then she has been a scrum master, agile coach and has helped with numerous agile transformations with teams across the globe. Stacey speaks at several agile conferences, has more certs to her name than she can remember and loves to practice agile at home with her family. As a lifelong Minnesotan, she recently relocated to North Carolina where she’s busy learning how to cook grits and say “y’all."

Mike and Brian take audience questions in the “best of” from the Agile Mentors Community’s monthly coaching calls.

Overview

Twice a month, there is an open Q&A session we offer as part of the Agile Mentors Community where anyone from the community can join in and ask either Mike or Brian questions. These are open discussions and allow the users to ask their own questions that are unique to their situations. We call these “Coaching Calls” because they are there to help coach the members and help them overcome obstacles along the way. 

Everyone who takes a class with Mountain Goat Software receives 12 months membership in the Agile Mentors Community and they are able to attend these calls and ask questions. Take a listen to some of the best questions we’ve received over the past few months to get an idea of what these sessions are all about.

By the way, we are aware there are a few places where the audio is not perfect in this episode and apologize for the less-than-ideal audio in several places. This is because these answers come from live sessions and there were a few streaming hiccups while delivering them.

Listen now to discover: 

• 3:10 - Brian: How to conduct fun retrospectives when you aren’t allowed to use cloud-based tools?
• 7:40 - Mike: How much planning is needed to ensure we complete items in a Sprint?
• 11:50 - Brian: Do you change the story points on an item if it turns out to be bigger than you thought?
• 14:50 - Mike: Why use Fibonacci numbers to estimate?
• 18:05 - Brian: Should Product Owners attend a Daily Scrum?
• 20:25 - Mike: What’s the best practice for capturing Non-Functional Requirements?
• 23:00 - Brian: How do you get your first experience as a Scrum Master if you have none?
• 26:46 - Mike: Tips for starting out with a new team?

Listen next time when we’ll be discussing…

Next week we will be taking a very short break of just one week. We are trying to practice a sustainable pace approach and are taking just one week off in order to do that.

References and resources mentioned in the show

• Funretrospectives.com
• Agilementors.com

Want to get involved? 

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

• Enjoyed what you heard today? It would be great if you left 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 as 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 is co-founder of the Scrum Alliance, and founder of Mountain Goat Software. He’s a veteran of applying Scrum and agile principles and practices to help organizations build better products and ship them on time.

This week, Brian Milner is joined by Julie Chickering to talk about the wild world of Project Management.

Overview

Brian Milner and Julie Chickering discuss how the world of project management can blend successfully with an Agile approach. There seems to sometimes be an attitude that it’s an either/or decision with these two. In this podcast, we take a look at how to blend them, how project managers fit in, and how these two disciplines can coexist.

Julie brings her experience to this discussion having come from the project management realm. 

Listen now to discover:

• 3:42 - Brian asks Julie about the general distrust between these communities
• 6:15 - Julie shares that 50% of the PMP exam now is on Agile practices
• 8:38 - Julie brings up the dreaded status report - Green / Yellow / Red
• 12:10 - Julie brings up the politics of Green / Yellow / Red
• 15:10 - Julie talks about the cost of poor quality
• 16:26 - Are we in the Agile community making PMs feel wrong?
• 17:22 - Brian discusses Outcomes vs Output
• 26:10 - Brian asks about PMs who are in companies making transitions. What happens to the project managers?

Listen next time when we’ll be discussing...

Brian and Mike Cohn share some of the best questions from their live coaching calls on the Agile Mentors community.

References and resources mentioned in the show

• Monty Python
• Project Management Institute
• The Cowman and the Farmer Should be Friends from Oklahoma!
• HBR article on Output vs Outcomes
• From Project Manager to Scrum Master - 3 Tips for Making the Transition
• Agile Project Management by Jim Highsmith
• The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick
• PM Illustrated: A Visual Learner’s Guide to Project Management by Mike Griffiths - free on Kindle

Want to get involved?

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

• Enjoyed what you heard today? It would be great if you left 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 a certified Scrum Trainer as well as a CST, PMP, PMI-ACP CSM, CSPO, and Path to CSP Educator. She believes that Agile practices are packed with potential — to enable business agility, and breakthrough results. Julie loves to help people implement agile even when the environments are messy, people are complicated, and situations are challenging. She brings real-world experience working with people at all levels to adopt and roll out realistic Agile strategies organization-wide.

Lyssa Adkins joins Brian to talk about the wonderful world of Agile coaching.

Overview

When you think of the term “Agile Coach,” what comes to mind for you? This term has meant many different things over the years. Are we talking about a role or an approach? Lyssa Adkins, author of Coaching Agile Teams, joins Brian to dive into this topic. Lyssa has written and spoken about this topic for years and many would say she had a large hand in defining what we now call agile coaching.

Listen now to discover: 

02:05 - Brian shares a story about Lyssa from the Vienna Scrum Gathering conference

06:40 - Lyssa answers the question, “What is an Agile Coach?”

08:10 - Lyssa explains the unintended consequence of using the term “coach” in her book

12:02 - Lyssa talks about the “X-Wing Diagram” and the 5 coaching stances

18:50 - Lyssa talks about not colluding when someone in power pushes something you disagree with

27:04 Lyssa talks about coaching in a remote world

Listen next time when we’ll be discussing… 

Project Management with Julie Chickering.

References and resources mentioned in the show

Coaching Agile Teams by Lyssa Adkins

Agile Coach Competency Framework

Developing Great Agile Coaches whitepaper describing 5 coaching stances

What is an Agile Coach? talk with Lyssa Adkins and Michael Spayd

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. 

Lyssa Adkins has been one of the foundational voices in the Agile community for years now. Her book Coaching Agile Teams has been a best seller for over 12 years now. She released an audio version of this classic book on its 10th anniversary. In 2010, Lyssa co-founded the Agile Coaching Institute which has developed over 10,000 people in the knowledge, skills, and being-ness needed to yield genuinely competent agile coaching. She is a member of the ICAgile working committee and has served as a reviewer for the Scrum Alliance’s Certified Enterprise Coach certification program. Lyssa is also dedicated to amplifying women’s voices and is a founder of TENWOMENSTRONG #WomenInAgile programs.

 

Show edited by Rhett Gill.

David Hawks joins Brian to discuss the process of an organization becoming Agile.

Overview

When you read through the Scrum Guide, the picture it paints is of the desired end result - what the team/organization should look like when finished. There’s surprising little said though about how you get from where you are to where you want to eventually be. Enter the topic of Agile Transformations. There is a journey that organizations undertake when they decide to adopt Agile and like any journey, it’s always helpful to have a guide to help you get there who has been through it before. David Hawks joins Brian to share his experience in helping countless organizations make this journey to become Agile.

Listen now to discover: 

03:10 Brian asks David what the biggest hurdle is that organizations have when adopting Agile?

05:24 David explains that multiple levels the organization needs to focus on in the process

11:00 David talks about “Implementing Practices over Outcomes”

16:30 Brian asks what individuals who aren’t leaders can do to help?

20:20 Brian asks David to explain how his Path to Agility helps address these issues?

29:35 Brian talks about the Spotify Engineering Culture videos example

Listen next time when we’ll be discussing… 

Agile Coaching with Lyssa Adkins!

References and resources mentioned in the show

Path To Agility & Agile Velocity

SAFe and LeSS

Yellowstone spinoff 1883

Oregon Trail

Spotify Engineering Culture Video 1 and Video 2

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. 

David Hawks is the CEO of both Agile Velocity and Path to Agility. He is a Certified Scrum Trainer as well as a Certified Enterprise Coach with the Scrum Alliance - their top two certifications. He received his Bachelor of Business Administration in Management Information Systems degree from the University of Texas at Austin. His love for his beloved Longhorns from UT is only eclipsed by his love (and expertise) in tailgating prior to their home games!

 

Show edited by Rhett Gill.

Mitch Lacey joins Brian to talk about building quality into our work.

Overview

The Scrum Guide says the developers own quality and that it is both a right and responsibility of the team. What does that look like though? What do we mean when we say quality? How do teams practically go about building quality or is it just “baked in?” Join Brian and Mitch Lacey as they discuss this all important secret ingredient to the Scrum framework and hear why it’s so vital to a team’s success.
 

Listen now to discover: 

2:25 Mitch explains what we mean by quality

6:48 Brian asks Mitch how to tell when you are “gold plating” things?

12:30 Brian asks about the developer who thinks the code needs to be perfect before they release

16:55 Brian talks about the last stage of the creative process is releasing

21:25 Mitch relates self-accountability to a recent Soccer(Football) match

22:34 Brian and Mitch discuss the infamous “Squirrel Burger” story

Listen next time when we’ll be discussing… 

David Hawks joins us as we discuss transformations.

References and resources mentioned in the show

Test Driven Development

“Squirrel Burger” story

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. 

Mitch Lacey is an agile practitioner and trainer. Mitch has been managing projects for over fifteen years & is credited with many plan-driven & agile projects. He is the author of “The Scrum Field Guide,” a book targeting teams adopting agile and Scrum practices. He has published many papers, including “Adventures in Promiscuous Pairing,” “Transitioning to Agile: Key Lessons Learned in the Field,” “The Impacts of Poor Estimating -& How to Fix It,” plus a variety of papers for Microsoft and “Immersive Interviewing -Building Great Agile Software Teams.”

Show edited by Rhett Gill.

Brian takes some of the most popular questions about Scrum from Quora.com and answers them.

Overview

If you are unfamiliar with it, Quora.com is a site people in the technology industry go to to ask and answer questions. For a change of pace, I decided to take a batch of the most popular questions from the site and provide my own answers to them. If you have questions you’d like to include in a similar episode in the future, make sure to email them to podcast@mountaingoatsoftware.com.

 

Listen now to discover: 

01:14 Brian explains the premise behind this episode’s topic

02:25 Question 1: Why do iterations in Agile start from Wednesday to Tuesday rather than Monday to Friday?

09:00 Question 2: Are Burndown charts even useful?

16:14 Question 3: Who decides sprint duration in a Scrum project?

18:50 Question 4: As a Scrummaster, how do you deal with people being late or refusing to come to Daily Scrums?

24.32 Question 5: Can a User Story be used for bugs?

26:54 Question 6: Can Agile work without a Scrummaster?

 

Listen next time when we’ll be discussing… 

Join us next time where we will be discussing the topic of Quality with our guest Mitch Lacey. 

 

References and resources mentioned in the show

Send your questions for a future episode to podcast@mountaingoatsoftware.com.

 

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 presenter is:

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. 

Show edited by Rhett Gill.

What do Spotify, Google Meet, and your expense report tool have in common? They could all delight your users—if you design for more than just function. In this episode, Dr. Nesrine Changuel breaks down the emotional motivators that transform average products into unforgettable ones.

Overview

What separates a good product from a great one? According to Dr. Nesrine Changuel, it's not just meeting functional needs—it's creating emotional delight. In this episode of the Agile Mentors Podcast, Brian Milner sits down with Nesrine, a former product leader at Google, Spotify, and Microsoft, to explore how emotional connection is the secret sauce behind the world’s most beloved products.

They dive into Nesrine’s “Delight Framework,” reveal how seemingly mundane tools (like time-tracking software or toothbrush apps!) can create joy, and explain why delight isn’t a nice-to-have—it’s a competitive edge. Whether you're a product owner, product manager, or just want to build better user experiences, this episode will change how you think about your backlog forever.

References and resources mentioned in the show:

Dr. Nesrine Changuel
Product Delight by Dr. Nesrine Changuel
Blog: What is a Product? by Mike Cohn
#116: Turning Weird User Actions into Big Wins with Gojko Adzic
#124: How to Avoid Common Product Team Pitfalls with David Pereira
Join the Agile Mentors Community
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.

Dr. Nesrine Changuel is a product coach, advisor, and speaker with over a decade of senior product management experience at Google, Spotify, and Microsoft, where she led major consumer products like Chrome, Meet, Spotify, and Skype. She holds a Master’s in Electrical Engineering and a PhD in Media Processing and Telecommunications and is based in Paris.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always Brian Milner and today I have a very special guest with me. I have Dr. Nesrine Changuel with me. Welcome in Nesrine.

Nesrine (00:14)
Hi, Brian. Thanks for having me.

Brian Milner (00:16)
I'm very excited to have Nesreen with us. I think this is going to be a really, really great episode for all of you product owners out there or product specialists, anybody who works in the product area. I think you're going to find this really interesting and you're going to want to bookmark this one. Maybe even come back to this a little bit. Nesreen is a coach, a speaker, particularly in the product area. She has previously worked at Google. She's worked at Spotify, at Microsoft, so no stranger to large enterprise, very high profile products that she's worked on in the past. She has a book coming out in May, so look for this book. It's called Product Delight. And that's really what we're going to be focusing on here is the concept of eliciting or generating kind of an emotional response to our product. I guess I'll start by, did you stumble upon this? What drew your interest to people's emotional response to products?

Nesrine (01:19)
Yes, so maybe I can share the story how I came to this topic and how I became so vocal about it. So in addition to being a product manager and leader over the last decade, I was always and I always enjoyed being a speaker. So I always wanted to go on stage and share insight. This is probably coming from my research background, because when I used to be a researcher, I traveled the world to go and present my research work and When I became a product manager, I kept this habit with me. So I always been on stage and I spoke about different topics like product discovery, product operation, different topics. Until one day I got reached out by a conference organizer and he said, Hey, Nisri, we want you on stage, but we have an idea for a topic for you. I'm not that used. Usually I come up with idea myself, but I said, okay, what do want me to talk about? And he said, Hey, Nusreen, you have been working for Spotify, for Microsoft, for Google Chrome and Google Meet, and we all admire those products and we consider them very successful products. What if you come and tell us what's the common thing that probably is there any common thing that made those products successful? Being an insider, being within those company, could you share with us something that you consider in common between those products? To be honest with you, I found it challenging at the same time interesting as an exercise. I was not, by the way, able at that time to answer the question, what's in common? So I sat down and I did the exercise myself and I started to think what was really in common? What made Skype Skype? What made Spotify Spotify and those Google products so successful? And I came to the following conclusion. I found that what made those products so successful is that they don't only solve for functional needs, but they also solve for emotional needs. So when we use a particular product, we use it for a certain functional need, but we also use it for an emotional need. And without even knowing that I have been doing it for more than 12 years, I came to the conclusion that, my God, during all those years, I have been focusing so much into users need from both angle, functional and emotional. So I came on stage and I spoke about that topic and from that day, I started to give it a name. I'm calling it emotional connection. I'm calling it product delight. And I'm here to share more about it as well.

Brian Milner (03:50)
That's awesome, yeah. I mean, I think we do hear a lot and we focus a lot on that functional kind of need, the way you differentiate there. think that's a good differentiation, functional and emotional kind of needs or motivators there. yeah, I mean, I've always heard, know, kind of that kind of general product advice is, you know, find the things that... people really, really have as huge needs, the things they would pay someone to do for them. And that's the key to success is finding those huge needs. But we're actually going beyond that to say, yeah, those are important. It's not to say that we should skip that, but it's when there's the emotional connection to a feature or to something that we do that really the light bulb kind of comes on for our customers. Is that kind of what your research is leading to?

Nesrine (04:40)
you're getting it right. Don't get me wrong. Of course you have to honor the functional needs and serve the functional feature, but the delight or the emotional connection happens when you go beyond exactly how you said it. Let me explain. If you serve only functional needs, you know what you get? You get satisfied users because they are asking for something and they are satisfied about what they are receiving. Now,

Brian Milner (04:41)
Okay, okay. Haha.

Nesrine (05:05)
If you surprise them by going beyond, by anticipating their need, by exceeding their expectation, you're not only satisfying them, you're surprising them in a positive way and delight is the combination of surprise and joy. Actually, the theoretical definition of delight is a combination of two emotions, surprise and joy. So going beyond, anticipate need and exceed expectation. is what we should aim for in addition to the functional needs.

Brian Milner (05:35)
That's awesome. Yeah, I use this example sometimes in, we use this example in the agile world to talk about, you know, the part of the agile manifesto that says customer collaboration over contract negotiation. And, you know, there's an example I use from my past where I used to work at a company that was very contract driven. And, you know, the thing that I always used to kind of take away from that was the very best we could ever do or hope to do. was to meet our customers' expectations. We could never, ever exceed it because we were only doing exactly what they told us to do. So I think this is a really important distinction here to make that just meeting the customer's needs, just meeting the minimal customer satisfaction bar, that's not going to keep you with loyal customers. That's not going to have repeat customers, or they're not going to tell their friends about, you know. That product did exactly what I hoped it would do. But it didn't really surprise me. It didn't really go beyond that. I know you talked about, because I've read your blog and a little bit of the discussion about this. So I know you talk about in the blog kind of the connection to Kano analysis. And I've always thought that's a really great way to try to determine things to target and go after. So talk to us a little bit about that, about Kano analysis and kind of what that uncovers and how that connects to what your research has shown.

Nesrine (06:51)
Yes. I love Kano by the way. I, I mean, that's one of the framework I have been considering throughout most of my product career. But this framework comes with a limitation and let me explain. So first of all, for those who are not very familiar with Kano, Kano is a visualization or categorization, let's call it. It's a categorization framework that allows to categorize features among different categories. One of them is must have. So these are the things that absolutely have to be in the product. Other that are performances, which are the more you have, the more satisfied users are, the less they less satisfied they are. And of course there are the delighters and delighters are those feature that when they are in the product, users are surprisingly happy. And when they are not, are not even the satisfaction is not even impacted. So the limitation of Kano is that it doesn't tell you how to achieve delight. Let me explain. I think we live in a world that everyone agree that we should delight our users. I mean, this, this concept is now globalized and everyone is talking about delighting users. The issue is that we don't know how to delight them. So we know category, there's a category that called delight, but we don't know how to. So the, the framework that I'm introducing and I'm calling it the delight framework is the framework that allows to first identify. So it's usually, represented into three steps. The first step is to start by identifying the emotional and functional motivators. So let me give you an example. I've been working at Spotify for about four years and as a Spotify user, imagine yourself, you are a Spotify user. You do have, of course, functional motivators. What could be the functional motivators? Listening to music, listening to podcasts, maybe listening to an audiobook. So all those are functional motivators. Now, what could be the emotional motivators as a Spotify user? It could be feeling less lonely. It could be feeling more productive because when you're working you need to listen to something. It could be about changing your mood. It could be about feeling connected. So all those are emotional motivators that drive users to use a product like Spotify. So what I encourage every product manager or every product team to do at first is to dig into identifying, of course, the functional need. And everyone is good, by the way, in identifying the functional needs. But also, while doing that exercise, pay attention to what could be the emotional motivators. So that's step number one is about listing the functional and the emotional motivators. Once you have those, Now we get to the second part of the framework, which is look at your backlog. And I guess you have a very busy backlog and take those features one by one and see for this particular feature, which motivator am I solving for among the functional ones and among the emotional ones as well. So the delight grid, for example, is a visualization tool that I came and created in order to allow product teams to visualize their backlog and see how many of my features are only solving for functional motivators. In that case, we call that category low delight. How many of my features are only solving for emotional motivators? These are very rare, but the best example I would call is, for example, I'm having an Apple watch and one month ago it was New Year Eve and at midnight I get fireworks popping out of my

Brian Milner (10:35)
Ha

Nesrine (10:36)
Apple watch and it was a happy new year there's nothing functional in there but it's all about creating some smile I call this surface delight and then how many of your features are solving for both functional and emotional motivators and I call this deep delight so maybe I deviated a bit from your question compared to canoe but it's actually about adding this dimension of connecting features to the real motivators of the users.

Brian Milner (11:07)
No, maybe a little bit, but you connected it to where we end up going anyway. So I think that's a great connection there. And by the way, for anyone listening, we'll link to all of this so that you can find this and follow up. But I like that differentiation between surface delight and deep delight. I know some of the examples that I've heard used kind of frequently in looking at Kano analysis and kind of trying to find those delighters. And that is kind of the area that it specifies there in Canoe, right? You're trying to find those things that are not expected, but when people find that they're there, they like that it's there, but they don't expect it's there. So if it's not there, there's no negative response that it's not there, but there's a positive response if it's there because they like seeing it. And my boss, Mike Cohn, tells this story about this

Nesrine (11:59)
Yes.

Brian Milner (12:03)
There's a hotel in California that became famous because at the pool, they have a phone that's by the pool that's the Popsicle Hotline. And you can pick up the phone and you can order a Popsicle to be brought to the pool. And it's the kind of thing where you're not going to go search for a hotel. Does this hotel have a Popsicle Hotline? I'm only going to stay at hotels with Popsicle Hotlines. It's not that kind of a normal feature. It's a delight feature because when you see it and you find out it's there, it's like, that's really cool. And it can be the kind of thing that says, yeah, I want to search that hotel out again next time I'm in this area because I really thought that was a nice little attention to detail and it was fun. But I think what I'm hearing from you is that might be more of what we would classify as a surface delight. It's not really meeting a deep need.

Nesrine (12:35)
Yes.

Brian Milner (12:56)
But it's fun, it's exciting, it's not expected, but it doesn't really cross that threshold into, but it also meets kind of functional delights. Is that kind of what you're saying there? Okay. Okay.

Nesrine (13:08)
Yes, actually I heard about that hotel story just to tell you how much viral it went. It came to me. So actually you get it correct that I consider that as surface delight and I have nothing against by the way, surface delight. You can add surface delight. The issue is you can end up doing only surface delight and that's not enough. So the idea is to do a combination and I do have two stories to share with you just to compliment on this hotel story. One is personal and one is professional. Brian Milner (13:21) Yeah. Okay.

Nesrine (13:37)
The personal one just happened to me a month ago. I went to Sweden and I went to Stockholm. That's where I worked for eight years. And I went there for business and I decided to meet some friends and some ex-colleagues. So we all gathered and went to a restaurant, a very nice restaurant in Sweden. And came the time where we had to say goodbye and to pay. And I guess you can feel it immediately when it's about paying and we are a large group and you start to get that anxiety about who's paying what and what did I order? What did I drink? What? I mean, I honestly hate that moment, especially in a large group where you don't necessarily have a lot of affinity with us. Like, should we split in 10? Should we pay each one paying its piece anyway? So that was a moment of frustration, of anxiety.

Brian Milner (14:09)
right. Yeah.

Nesrine (14:28)
And I loved how the restaurant solved it for it. You know how they solve for it? I mean, maybe it exists in the U.S., but for me, that's something I never seen before. The waiter came with a QR code on a piece of paper and you scan the QR code. And when you scan your QR code, you get the list of items that got purchased by the table. And all you have is to pick, and that happens automatically real time. Everyone is picking at the same time. You pick the things from the list and you pay. for the things that you order. You can even tip on the bottom. You can give feedback. Everything happened on that QR code. And you can guess how much that anxiety could be removed. So that's the personal story I wanted to share. The second story, which is more professional, I want to share how we try to improve experience at Google Chrome. So I've been the product manager at Google Chrome.

Brian Milner (15:13)
Yeah.

Nesrine (15:25)
And we started from the observation that people do have plenty of open tabs. I guess you are one of them, especially on mobile. Like on mobile, you go and check how many open tabs you do have on Chrome and you realize that they are have, we realized at least out of numbers, out of data that people do have plenty of open tabs. So it started as

Brian Milner (15:32)
You

Nesrine (15:47)
technical issue. Of course, the more tab you have, the heavier the app is, the slower the app could be, et cetera. So we wanted to reduce the number of unnecessary open tabs in Chrome. So we interviewed users and we started to check with them, why do they even leave their tabs open? So some of them leave tabs because they consider them as a reminder. I mean, if tab is open, it means that you need to finish a task there. Some people really leave tabs just for ignorance. mean, they moved from a tab to another and they completely forget about them. Actually, we realized that the fact of leaving tab open, the reason for leaving tab could be completely different from a person to another. And the other interesting observation, and when I say identify emotional motivators, you will realize that people feel a bit ashamed when they show to us that they do have plenty of open tabs. Some of them would say, sorry, I usually don't even have so many open tabs. It's only now. And I'm like, it's okay. But the point is, if you have this mindset of trying to track the emotional insight from your users, you will take note. And the note was anxiety, feeling ashamed, blah, blah, blah, blah, blah. And that was in introduction for in...

Brian Milner (16:42)
You Yeah, right.

Nesrine (17:04)
improving the tab management experience later on in Chrome.

Brian Milner (17:07)
That's actually a really good parallel, though. I think that's a good example because it reminds me, too, even going back, I remember one of the things, and I'm going way back here, but I remember one of the things about Gmail that was kind of a selling point initially was the concept there of you don't have to worry about maintaining an inbox. keep all your mails and search. And you can search through your mails and find whatever it is. And I remember prior to that, most people would use something like Outlook or something like that to have their mail, there was always this constant struggle of, I've got to keep it down. I've got to delete things. I've got to categorize things. And Google had this different approach of, don't worry about it. Just leave it. And that's a good, I think, example as well of kind of that emotional response of,

Nesrine (17:48)
Yes.

Brian Milner (17:56)
Gosh, I'm kind of anxious. I feel bad that my inbox is so big. And I know that's bad, but Google comes along and says, don't worry about it. You're not bad. It's OK. Yeah.

Nesrine (18:05)
Yeah, yeah. And by the way, I think Gmail is filled with plenty of deep delight features. One of them I can quickly highlight is, you know, when you send an email, we're saying attached file and the file is not there. And when you try to hit send, you get that pop up like a be careful or like a mind, there is no attached file inside. These are for me like very attached to the fact that You don't want to feel ashamed. You don't want to look stupid later on saying, Hey, sorry, I forgot the file. Here's the file. That's, that's a great example. And the other example that come to mind again in Gmail, you know, that smart compose when you're trying to answer an email and you can just hit tab, tab, tab to complete the sentence. I mean, the functional need is to write an email. The emotional need is to get it in a relaxed way. And the combination would allow for something like.

Brian Milner (18:49)
Yeah.

Nesrine (19:00)
Smart Compose.

Brian Milner (19:01)
That's awesome. Yeah, so I guess that leads to the question though, when we're talking about something like Spotify, mean, music intrinsically is emotional anyway, right? It's something that you have an emotional connection to and you feel a certain way when you hear music. But if my product is a, I don't know, expense reporting software, right?

Nesrine (19:23)
Mm-hmm.

Brian Milner (19:25)
I can just hear people out there kind of asking, know, and kind of thinking to themselves, yeah, but my product, right, my product is not that kind of, it doesn't elicit that kind of emotional response in people the same way music would. So does this apply to me as well? So how would you answer those people who feel like my products might be a little bit more bland or boring and don't really intrinsically have an emotional connection to them?

Nesrine (19:47)
Mm-hmm. So my answer is that if your product is boring, then it's even more priority now to focus on emotional connection. But let me elaborate. So that's one of the reflections that came to my mind while writing the book. So while writing the book, I wanted the book to be a storytelling book. So I was writing a lot of my stories, stories from Skype at the time, Spotify and all the Google product. But at some point I said, hey, hey, Nisreen, you need to get more insight from other people and other experiences. So I get to interview product leaders from completely different industries and completely different domain. I interviewed leaders from B2B like Atlassian or Intuit and so many other companies that I don't have so much insight from. I even interviewed people from hardware, like I interviewed someone from Dyson and I was, hey, what makes Dyson so emotionally attractive for me? Cause I love my Dyson vacuum cleaner. But let me get to your point because when I interviewed someone from Intuit, that person told me something super interesting. She told me that at some point she was working at a tool called Tsheet. And Tsheet is a tool that allows you to enter your time report. There is nothing more boring than that. I think I'm picking the one that you're looking for here because it's, it's as a user. The only reason I would use this tool is to report my time so I can get paid.

Brian Milner (21:06)
Hmm. Right. Yeah.

Nesrine (21:19)
There is nothing exciting, nothing emotional. And what I got out of that product leader who used to be the head of product at the time, she told me that they were completely aware about the fact that the product is not that attractive. And instead of living with that observation, they did all what they could do to make it even more attractive. So they added some fun. They made the messaging less aggressive and less about enter your time. report but rather into more playful and even the images are more playful. When you press the enter time report you get the congratulation and some confetti if needed. So they explicitly turned and that's a strategy. They turned that boring moment into something even more attractive and they had to do that otherwise the experience will keep on becoming more more boring and the perception of users toward the product will be even less, more and more gray, I would say.

Brian Milner (22:22)
Yeah, yeah, just that little dopamine kind of kick, right? Just that little bit of chemical reaction in your brain can make a huge difference. That's awesome. That's a great story and a great answer to that question. So I'm curious, we're talking about trying to find these things and trying to see, your matrix here, it thinks about the emotional motivators, the functional motivators, and trying to find those things that kind of cross both planes.

Nesrine (22:24)
Yep.

Brian Milner (22:52)
How do you verify at the end? Because if you're lining your features up and think, I think this solves this emotional thing. I think this solves this functional thing. Is there a way to follow up to ensure that it actually is doing that? How do you follow up to make sure it's really doing what you thought it would do?

Nesrine (23:09)
Yes, so let's imagine you did the exercise well, you filled in the delight grade and you observed that you do have plenty of low delights, which is most of the cases by the way. The very first thing I recommend is to see opportunities for moving or transforming these features into deep delight. And in the book, for example, I talk about the nine delighters. Nine delighters are ways that could be sometimes cheap even to introduce. in order to make those low delight features into more deep delight. This could be, for example, through personalization. We love when the features are personalized, and that's one of the reasons, for example, why Spotify is so successful, is through features like Discover Weekly or RAPT or these kinds of super personalization related features. It could be through seasonality. That's, for me, the cheapest and the most delightful feature you can or aspect of feature you can add to your product. So for example, when I worked at Google Meet, I've been working at the background replace features. So we have been, of course, introducing static image. We have been introducing video backgrounds as well. But from time to time, we always use seasonality to introduce what we call seasonal background. So when it's Easter, we introduce Easter background. When it's Christmas, we introduce Christmas background. Guess what? Even like for Olympic game, we introduce Olympic game background. When it's the Earth Day, we introduced Earth Day background. So there is always an opportunity to introduce some seasonality to the product. And guess what? We relate to those, especially if the product is global. We relate like last, when was it? Like last Wednesday. It was the new year, the Chinese new year. And I was checking when is exactly the exact date for the new year, the Chinese new day. And I put that and you know what happened in Chrome? It got these dragons and those like the celebration within the product, like within Chrome. These of course are surface delight, but you know what? Why not? You see? So there are some tools. Some of them are not that...

Brian Milner (25:17)
Right.

Nesrine (25:22)
expensive to introduce to the product. Some would require a bit more thoughtful and thought into it, but there are ways that I detail in the book in order to introduce more delight. And then if you want to validate through metrics, and I guess that's your question where it's heading to, then the good news, and that's something that I discovered recently because there's been a study that was conducted by McKinsey. And you know what they studied? They studied the impact of emotional connection on product adoption. So they actually studied over, I don't know how many industries die, like tourism, IT, energy, whatever. And they interviewed more than 100,000 users or whatever. So the conclusion that they found out of that very interesting study is that emotionally connected users will get you more twice as more revenue, twice as more referral, and twice as more retention compared to satisfied users. I'm not talking about the non-satisfied. So if you take two groups of users, those that you satisfy their needs and those that you go beyond and they are emotionally connected, those that are emotionally connected get you twice revenue, referral and retention.

Brian Milner (26:19)
Hmm.

Nesrine (26:43)
So this is just to highlight that for people who say, no, but this is the cherry on the top. This is just like the extra. It's not the extra, it's the way to stand out. I don't know any company that is standing out nowadays without investing into emotional connection, none.

Brian Milner (26:54)
Yeah. That's a really good point. Yeah, I mean, the example that comes to my mind when you talked about seasonality and other things like that, know, I love my, you know, they're not a sponsor, Oral-B toothbrush, you know, the electronic toothbrush, and you know, there's an app with it and it keeps track of, you know, did you get all the areas of your teeth and did you hold it there long enough and... One of the things I always love about it is when it gets to December, the opening screen when you open up the app starts having snowfall. It's kind of a funny little emotional response, but you look at that and you think, that's cool. Yeah, it is kind of that season where now it's time to get ready for Christmas and it's that special. It's only this month that it's going to be like that. It's going to go away at the end of the month.

Nesrine (27:45)
Yes.

Brian Milner (27:49)
feel little sad when it's gone, it's back to normal. But it's such a silly little thing. Does that make any difference in really brushing my teeth at all? Does it change how well I brush my Not really. It's just a fun little thing that when it pops up there. And think how little that took from someone to do that. It's a little animation that they just pop up on a loading screen. But that little tiny bit, think, again, maybe a little bit surface.

Nesrine (28:10)
Yes.

Brian Milner (28:16)
but it takes something that would have been routine. It takes something that would have been kind of boring otherwise, and it just added a little bit of fun to it, you know? And I think you're right, that emotional connection is really, really important in situations like that, yeah.

Nesrine (28:21)
Yes. Yes. Yes, yeah. And the thing that I'm very vocal about nowadays is the fact that this emotional connection is actually not a new topic. It's something that has been extremely popular among marketers. For example, if you think about the best marketing campaign, they are all very emotional. The most successful marketing campaign are. If you think about designers, there are plenty of resources about emotional design. There is a great book by Don Norman. It was called emotional design. Aaron Walter as well wrote something called Designing for Emotion. But you know, the problem is that among engineers and among product manager, we don't talk that much about that. And you know what happened when we are not informed about this topic? There is a gap between the language of marketers, designers, and the engineers and product manager. And that gap doesn't allow things to succeed. I'm trying to educate the engineers and the product world towards this well-known domain outside of the product in order to have this consistency and start making real impactful products.

Brian Milner (29:40)
Yeah, yeah, this is such a really deep topic and it just encourages me, think, even more to recommend the book there. It's not out yet, time of this recording it's not out, but it's going to be in May of 2025. That's when this book is coming out. And I know it's gonna have a lot of really good information in it. Again, the book is gonna be called Product Delight. by Nesrine Changuel, Dr. Nesrine Changuel. I should make sure I say that. But I really appreciate you coming on because this is fascinating stuff. And I think the product managers, the product owners that are listening here are going to find this really fascinating. So I appreciate you sharing your time and your insights with us, Nesrine.

Nesrine (30:26)
Thank you, it's my pleasure. I love talking about this topic.

Brian Milner (30:29)
Ha

Scott Dunn joins Brian to talk about what it means to be product-centric

Overview

Being product-centric has become a recent buzzword and objective for companies. But what does it mean? Is it the next stage of becoming agile? Or is it something that should drive an agile transformation in the first place? In this episode Scott and Brian discuss their definitions of what it means to be product-centric, and whether this is different to being customer-focused. They also look at the limitations that can stop teams from being more focused on the customer and long-term product value, such as being forced to fight those daily fires. 

Listen now to discover: 

00:23 - What does the term product-centric mean? 

07:13 - Is there a difference between being product-centric and customer focused? 

14:47 - Are nonprofits customer-focused entities?

22:02 - Does product-centric mean putting quality first? 

28:23 - How does a disconnect between leadership and teams affect things? 

Listen next time when we’ll be discussing… 

Next time, I’ll be answering questions you’ve sent into the show as well as addressing other common agile questions. 

 

References and resources mentioned in the show

Impact Mapping and Story Mapping

The Scrum Guide

Kano Model for prioritization

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 Certified Scrum Trainer with more than 20 years of experience in management, project management (PMP), engagement management, and software development (MCSD). He is passionate about strengths-based teams and a solutions-based approach to people and organizational issues.

Show edited by Rhett Gill.

Lance Dacy joins Brian to dig into cross-functionality.

Overview

You will often hear people say that Scrum teams are cross-functional. But what do we mean when we say that? Are we talking about a jack of all trades but master of none? Do we want team members who can do anything? How does a cross-functional team actually work together and what should we do as agilists to support and nurture cross-functionality in our teams? Join as we discuss these and other aspects of cross-functional teams.

Listen now to discover: 

02:00 Lance tells us how he defines cross-functional teams

04:34 Brian compares cross-functional teams to the A-Team

08:58 Lance talks about generalists vs specialists

12:39 Brian talks about T-shaped individuals

18:05 Brian discusses the Equity Couch

24:10 Brian describes the Market of Skills tool

27:45 Lance talks about personality profiles

29:20 Brian asks Lance about how to handle cross-functionality on specialist teams

Listen next time when we’ll be discussing… 

Scott Dunn joins us again to discuss the term ‘product-centric.’ 

References and resources mentioned in the show

The A-Team

Market of Skills by Lyssa Adkins

OSEMN Process

What does Scrum mean by Cross-functional?

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 heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Show edited by Rhett Gill.

Kert joins Brian again to talk about Kanban

Kanban is a pull system of working where work is ‘pulled’ in based on a team’s capacity. Whether it’s a card from a backlog, or a bin of items on a manufacturing floor, the concept of pulling in work is common to both kanban and scrum. It supports the idea of being agile because whenever you’re pulling work in, you’re basing it on the latest feedback and emergent needs so that you can focus on delivering the most value. Listen now for an overview of Kanban as well as common mistakes to avoid. 

Listen now to discover: 

00:48 - The origin of Kanban’s meaning

04:34 - How the principles of Kanban are expressed in Scrum 

07:00 - Common misconceptions people have about Kanban

09:00 - The five pillars of Kanban

12:58 - How to get started 

19:41 - How to improve your current Kanban process

Listen next time when we’ll be discussing… 

I’ll be joined by Lance Dacy as we talk about cross-functional teams. 

References and resources mentioned in the show

Kanban University

The Official Guide to the Kanban Method

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. 

Kert began his professional career as a Software Engineer in NASA's Space Shuttle program, affording him practical insights into the daily challenges faced by engineers, designers, and testers. Driven by the belief that learning unlocks potential, Kert has pioneered educational programs for Dell, Rockwell Collins, Amazon.com, and Capital One Financial. Kert is one of the few trainers world-wide to be actively credentialed as both a Scrum and Kanban trainer by Scrum Alliance and Kanban University, respectively. 

Show edited by Rhett Gill.