Agile Mentors Podcast

Even the most capable professionals can struggle in interviews. In this episode, Brian and job interview coach Tali Shlafer break down why, and what to do instead. Overview In this episode of the Agile Mentors Podcast, Brian welcomes interview coach Tali Shlafer for a practical, clear-eyed conversation about how to approach job interviews as a skill, not a personality trait. Tali shares why being great at your job doesn’t automatically translate to interview success, especially in collaborative fields like product development, Agile coaching, and project management. She outlines a straightforward way to prepare for interviews by identifying the real challenges behind a role and building stories that speak directly to them, without sounding rehearsed or robotic. From reframing “bragging” as problem-solving to handling tough questions with clarity and self-awareness, this episode is full of grounded advice for professionals navigating their next move. References and resources mentioned in the show: Tali Shlafer Free Job Interview Tip Vault Tali's LinkedIn Tali's Instagram #93: The Rise of Human Skills and Agile Acumen with Evan Leybourn #111: Adapting to the Future of Work with Heather McGowan Blog: Entry-Level Scrum Masters: Seven Tips on How to Get Your First Scrum Master Job by Mike Cohn AI Prompt Pack for Product Owners & Scrum Masters Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Tali Shlafer is a certified interview coach who helps high performers turn nerves into clarity and confidence so they can land roles they’re truly excited about. Her practical frameworks—rooted in psychology, communication, and performance—ditch the gimmicks and empower candidates to show up as their best, most authentic selves. Auto-generated Transcript: Brian Milner (00:00) Welcome in everyone. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have Miss Tali Schläufer with us. Welcome in Tali. Tali Shlafer (00:11) Thanks, Brian. I'm excited to be here. Brian Milner (00:13) Very excited to have Tali with us. She is a job interview coach so you can kind of See the direction we're going in here one of her tagline is that she she helps you know professionals get offers they're really excited about and She's got some really interesting insights here because I know in today's world in today's environment There is a lot of shifting going on. There's a lot of transitioning between different places of work. And that interview is always kind of the forgotten portion of it, right? You get past all the other stuff, you get to the point where you're in the interview. So Tali, from your perspective, I know you see and help a lot of people with that portion of it. What are some of the biggest mistakes that people make that you see routinely as you help people prepare for their interviews? Tali Shlafer (01:01) Yeah, absolutely. I think one of the things that you just mentioned where, you know, people really struggling with the interview piece, you do all this work in your job search to update your resume, update your LinkedIn network, all this stuff, and then you get to the interview and it's like, okay, we're close. It's actually the interview is actually a completely different stage than anything else. And one mistake that I often see people making is just the mindset around interviews. A lot of people think, if I'm great at my job, I'll just interview really well. Like I'm a top performer. I'm good to go. But interviewing is actually a skill that's completely separate from anything else we do in the workplace. It requires you to be able to articulate what you've done in the workplace and the results and the impact that you brought in a way that most of us don't have to do in our day-to-day jobs. And you have to do it better than everybody else. So just because you are a top performer doesn't necessarily mean that that translates into your ability. to talk about yourself and talk about your career, especially in a way that resonates with the specific job culture and the specific job that you're applying for. So I think that's kind of the top mistake that I would just from a mindset level, is seeing interviews as something that you're naturally good at rather than as a skill that you can really develop and build in order to set yourself up for success. Brian Milner (02:12) Yeah. Yeah, that's a great point because, know, just because, as you said, just because I'm a top performer in something that I do, have a huge skill set or knowledge area that I'm really good at, doesn't mean that I'm necessarily good at an interview process because it is kind of a whole set of other communication skills that you have to have in that kind of environment. I know when I've talked to people about it sometimes, they feel sort of this, I don't know, dichotomy a little bit back and forth about... I know I'm supposed to plug myself here. I know I'm supposed to kind of brag a little bit, but I also don't want to sound cocky. I don't want to sound, you know, I don't know, just brash or anything. How do you help people or what do you advise people about in that area? Tali Shlafer (03:06) Yeah, and I think this is really common for people who are top performers and people who are very team oriented and collaboration oriented. It's really difficult for those folks to go, hey, I did all this stuff by myself and to kind of put themselves in that spotlight. So it's a very common challenge. It's also very common for folks who are really good at their job and have been doing this for a long time to actually be able to articulate. what that secret sauce is, like why they're actually good at their job, which is part of the challenge. Remind me the question that you just asked. Brian Milner (03:38) No, I'm just, in talking about kind of like how people prepare for these kind of things, the way they communicate this stuff, sometimes it's kind of more this worry about am I being a little too overbearing or brash in how I'm bragging about myself? Will I come off seeming cocky? or overconfident, how do they walk that fine line? Tali Shlafer (04:03) Yeah, I think this is a really big mindset piece where a lot of people who are those top performers and are very collaborative in nature are afraid to talk about themselves and be in the spotlight and kind of take credit where, especially in something like in the agile world or project management, product management, it's a very collaborative space. people are afraid to like, people are afraid to say, here's what I did. And Part of the mindset shift that I really encourage clients and job seekers to have is rather than to see it as, hey, the interview is all about you and the spotlight's on you and you're a used car salesman trying to promo yourself and it feels really icky so we don't want to do it. We end up not doing it at all. Think of it rather as you're trying to help this employer solve a problem. You're on the same side of the table with them. You're essentially a consultant for them. Their problem is... Hey, I've got this role. I have this challenge in my company. I have this opportunity. I have this thing that I need help with and I need to find who's going to be able to help me do that. And so you're essentially being an advisor for them and sharing here's how my previous experiences and what I've done in the past might be able to help you with your challenges. So it's really, it's really a partnership type of conversation where you're exploring, well, what are you struggling with? and how, let me share ways that I think I might be able to help. I think having that mindset is a lot more helpful for people who are more collaborative in nature. I think there's also a part of it that is getting really clear on how your work has actually delivered results. Being really confident, a lot of folks who are more collaborative in nature, which is a lot of people that I work with. tend to really get stuck in the we. So they say, we deliver this, we manage this, we strategize in this way. And then the interviewer ends up losing the thread of, well, what did this person sitting across from me do? What did they lead? What did they manage versus what did they do collaboratively? so getting really clear and even getting some language around how to talk about your contributions with respect to the team. So saying, I led this strategy session or I facilitated the collaboration of this, or I made the suggestion to people who then made a decision. Those kind of nuanced pieces of communication can help us feel more comfortable with actually owning our story in a way that doesn't feel gross. Brian Milner (06:39) Yeah, I think you make a great point there about the partnership aspect of it because having been on both sides of the table there, I know when I was hiring people as a software manager of some kind, the thought is always when the person comes in, you want to hire them. When they've reached that stage, when you finally bring them in, you're excited about the people that you decided to bring in and you're pulling for them. You want them to actually be successful. So I think it's i

Join Brian and Barnaby Golden as they dig into a surprisingly common roadblock in Agile teams, the underpowered product owner, and how it quietly derails decision-making, flow, and team momentum. Overview In this episode of the Agile Mentors Podcast, Brian welcomes Agile coach and community contributor Barnaby Golden to explore the risks and ripple effects of placing a product owner in the role without the authority to own it. They discuss the stark difference between empowered and underpowered product owners, why availability without authority is a setup for frustration, and how misalignment at the leadership level creates more theater than agility. From trust gaps to political decision-making, Barnaby and Brian unpack the hidden reasons teams get stuck and what it takes to create real, empowered ownership that delivers actual value. References and resources mentioned in the show: Barnaby Golden #104: Mastering Product Ownership with Mike Cohn #3: What Makes a Great Product Owner? With Lance Dacy How to Engage and Help Busy Product Owners by Mike Cohn What Happens When For Product Owners 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. Barnaby Golden is an experienced Scrum Master and Agile Coach with a knack for helping teams truly live Agile, not just adopt it. Lately, he’s been diving into the real-world use of AI—helping organizations, including nonprofits, turn tech hype into practical, high-impact tools with smart governance Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors Podcast. I'm here with you as always, Brian Milner, and we have a very special guest with us today. We have Mr. Barnaby Golden with us. Barnaby, welcome in. Barnaby Golden (00:14) Thank you, it's good to be here. Brian Milner (00:16) Very excited to have Barnaby here. Barnaby is an Agile coach, also a Scrum Master. He is known to us because he is part of our Agile Mentors community. And he is an active member there and has weighed in on several issues and helped people and mentored people through things there. So we wanted to share some of the wisdom of the crowd that we have there at Agile Mentors. Just a few select people that have really contributed. and giving us some really good advice there with the podcast audience as well. So you guys can kind of hear what kind of stuff is there on the Agile Mentors discussion forums. But we were talking about topics here with Barnaby about what we were going to talk about and he proposed one that I really found intriguing. It was focusing around the underpowered product owner, the underpowered PO. And I think that's probably a good place for us to start then, Barnaby. Why don't you kind of just explain to everyone what that idea is, what you mean by the underpowered PO. Barnaby Golden (01:12) Sure, of course. So in fact, what I'll do is I'll explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like? And I was working for an organization a few years back, it was a publishing organization. And we had the head of the editorial team was the product owner for a particular Scrum team. Brian Milner (01:16) Okay. Barnaby Golden (01:38) And this head of editorial had a lot of power and influence in the organization. They were pretty much a decision maker in terms of the products that the team was building. And I remember a particular conversation where the team was talking to this product owner and the team said, look, we know you want to get this, this release out this week, but we've got some technical debt. really need to fix it. And I remember the, this guy saying, look, okay. I'm going to let me think about this for a second. Okay. I can make the decision on this, which is, yep, you can have your time. I'll communicate with others within the organization. The release will be delayed. And that was such a powerful moment because in that second, the decision was made. The product owner trusted the team, the team completely trusted the product owner. And it felt slick and efficient and worked really well. Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role. So I've seen the situation where you have a whole hierarchy of product people and the most junior role in the product organization is the product owner. And what happens in that scenario is the product owner is powerless to make a lot of decisions. So they have to push them up the tree. And in that situation, the conversation between the team and the product owner is the team says, yeah, we need to do this thing. And the product owner says, okay, give me some time. Might be a day and I'll get back to you. Hopefully I can get in contact with other people within my hierarchy and the flows broken. What's the team going to do now? They're going to maybe find something alternative to work on. It's very frustrating. And you sometimes get the situation as well where the the underpowered product owner will sympathize with something the team is saying, but will not be able to make a change because they haven't got the authority to do the change. So they'll say, yeah, I agree with you. I know what you're saying. This is a really bad idea what's being suggested, but I have no choice. We have a roadmap. We've got to meet the roadmap. Brian Milner (03:45) Yeah, that's a clear picture. I agree with you that those are two stark contrasts. And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other, right? It's just, it's such a dramatic difference when that person is able to make the decisions on the spot. go forward, and the team is just free to move as quickly as possible. Whereas the other one, it's just holdups. It's just delays and obstacles, roadblocks in the team's way. So yeah, a really clear picture there. Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking about this. is trying to understand a little bit about the why behind it. ⁓ Because I think there's, just in thinking about it, I think there's maybe several causes for this or several things that might lead to having an underpowered PO. What's been your experience? What kind of things have you seen that might contribute to an underpowered PO? Barnaby Golden (04:36) Hmm. I think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend with the team. So you've got your head of product or the real decision makers in the organization. They are saying, I can't spend two, three hours a week with a team. I can't go to a planning meeting. got, you know, I'm a busy person. I've got things on my schedule. So they see the product owner role as a stand-in for themselves with the team. And this stand-in has lots of time to spend with the team, which is good. And that's a powerful thing. But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent. Brian Milner (05:41) Yeah, it's almost as if they just want a warm body there. It's a placeholder. You're here as a placeholder for me because I can't be two places at once. I've heard a couple of things that people will frequently point to that a product owner needs to be successful. And there's sort of this dichotomy of these two things that are part of that. And that's the kind of empowered Barnaby Golden (05:44) Yeah. Brian Milner (06:05) product owner that is empowered to make decisions versus having the availability to actually be present with the team. it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, hey, I need to make all the decisions, but I don't have the availability. and the people that they know have the availability, they don't want to empower to make the decisions. So they're kind of setting up their product owners to fail. Barnaby Golden (06:35) I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility. You can't just have a scrum team and say, well, that's where we'll be agile in this scrum team. The entire organization as a whole has to think in the agile mindset. And if you want to be able to adapt to change, then one of the ways you're to have to do that is you're going to have to have the decision makers close to the teams that are implementing the decisions. and so you can't have your, your cake and not eat it. If you see what I mean in terms of, you, you can't pick and choose the aspects of agile that you want. need to, as an organization, adopt the whole thing. Brian Milner (07:17) Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when you're trying to decide who's the right person to be the product owner for this team, those are two of the things you have to really consider strongly is does this person have the availability to be here with the team and is this person empowered to make decisions? I've run up against leaders before that don't want to empower someone and Kind of the counterpoint I give

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

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) We

We’re taking our own advice and hitting pause to recharge this July. While we’re off the mic, revisit past episodes packed with timeless insights and conversations you may have missed. Overview This week, we're pressing pause to model the sustainable pace we teach. Brian shares a quick update about our summer break, what’s ahead in August, and how you can make the most of the podcast archive while we’re away. Whether you’re poolside or simply stepping back from the daily sprint, we hope you’ll join us in creating a little breathing room and we can’t wait to be back with a fresh season soon. References and resources mentioned in the show: Subscribe & Listen to Previous Episodes of 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) Hey there Agile Mentors, this is Brian Milner and I'm just gonna take a moment of your time today because we're actually going to be practicing what we teach here at Agile Mentors and we're gonna be working at a sustainable pace. So for us that means we're gonna take a few weeks off. It's summer and I know many of you are going to be taking time off with your families and we're gonna be doing the same thing. So we won't be around for the next month. We're gonna be out of here for July, but already have some plans for when we come back in August. So stay tuned when we come back in August, we've got a new season of shows that will begin there in August that I think you'll really enjoy. While we're off, might I suggest you go back through our archive. Look at some of the previous podcast episodes we've done. There's quite a few now. And maybe you've missed some of the episodes from the past. Go back and find some of our great guests that we've had over the years when we've been doing this. I think you'll find some really great guests and some really interesting topics. So fill your diet of Agile Mentors with that while we're at taking a little bit of a break here at Agile Mentors. I hope you're having a great summer and we look forward to seeing all of you back here in August. Take care.

Is AI underdelivering? Or are we asking the wrong questions? This episode breaks down what actually leads to business ROI with AI (and no, it’s not more automation). Overview What if AI isn’t the silver bullet—yet—but the bottleneck is human, not technical? In this episode, Brian Milner chats with Evan Leybourn and Christopher Morales of the Business Agility Institute about their latest research on how organizations are really using AI, what’s working (and what’s wildly overhyped), and why your success might hinge more on your culture than your code. References and resources mentioned in the show: Evan Leybourn Christopher Morales Business Agility Institute From Constraints to Capabilities Report Delphi Method #93: The Rise of Human Skills and Agile Acumen with Evan Leybourn #82: The Intersection of AI and Agile with Emilia Breton #117: How AI and Automation Are Redefining Success for Developers with Lance Dacy AI Practice Prompts For Scrum Masters 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. Evan Leybourn is the co-founder of the Business Agility Institute and author of Directing the Agile Organization and #noprojects; a culture of continuous value. Evan champions the advancement of agile, innovative, and dynamic companies poised to succeed in fluctuating markets through rigorous research and advocacy. Christopher Morales is a seasoned digital strategist and agile leader with over 20 years of experience guiding organizations like ESPN, IBM, and the Business Agility Institute. As founder of Electrick Media, he helps U.S. and European businesses harness AI to make smarter, more sustainable decisions in a rapidly changing world. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. We've kind been a little bit off and on recently, but I'm back, I'm here, I'm ready to go, and we've got a really good episode for you today. I've got two, two guests with me. I know that's not a normal thing that we do here, but we got two guests. First, we have Mr. Evan Layborn with us, who's back. Welcome back, Evan. Evan Leybourn (00:23) Good morning from Melbourne, Australia. Brian Milner (00:26) And Christopher Morales is joining us for the first time. Christopher worked with Evan on a project and we're going to talk about that in just a second, but Christopher, welcome in. Christopher Morales (00:35) Yeah, good evening. Nice to be here. It's very late here in Germany. So this is an international attendance. Brian Milner (00:42) Yeah, we were talking about this just as we started. I think we have pretty much all times of day represented here on this call because we've got morning here from Evan. We've got late evening here for Christopher and I'm kind of late afternoon. So we're covered. All our bases are covered here. But we wanted to have these two on. They both work for a company called the Business Agility Institute. And if you have been with us for a while, you probably remember Evan's episode that we had on last year when we kind of talked about one of the studies that they had done. Well, they put out a new one that I kind of saw Evan posting about. And I thought, wow, that sounds really, really interesting. I really want to have them on to talk about this. It's called From Constraints to Capabilities, AI as a Force Multiplier. The great thing about the Business Agility Institute is they get into the data. They do the research, they put in the hard work, and it's not just speculation. It's not just, that's one guy's bloated opinion, and do they know what they're talking about or not? So that's what I really, really appreciate about the things that come out of the Business Agility Institute is they're factual, they're data-based. So that's what I wanna start with, I guess, is... What was the genesis of this? What did you guys, how did you land on this as a topic and how did you narrow it down to this as a topic? Where did this start? Evan Leybourn (02:07) Well, quite simply, it started from almost a hypothesis around so much of the conversation around AI. And let's face it, there is a lot of conversation around artificial intelligence and specifically generative, predictive and agentic AI. Focuses on the technology. And yet when we talk to organizations, a lot of them don't seem to be seeing a positive return on investment, a positive ROI. And we needed to understand why, why these benefits of like three times products or operational efficiency product throughput, three times value creation, Why weren't companies seeing this? That's really what we were trying to understand. Why? Brian Milner (03:01) Yeah, that's a great basis for this because I think you're right. There's sort of this, I would imagine there's lots of people out there who are kind of going through their business lives and hearing all these incredible claims that people are making in the media about how this is gonna replace everyone. And now it's, yeah, we can, I mean, you said 3X, I've heard like, 10 or anywhere from 10 to 100X, the capabilities of teams and that they can now do all these amazing things. And if I'm just going through my business career, I'm looking at that from the outside going, is this fact or is this fantasy? this just a bluster or is this really, really happening? So I really appreciate this as a topic. A little bit of insider baseball here for everybody. You guys talk about in this report that you use a specific method here, the Delphi method. for data geeks here, or if you're just kind of curious, would you mind describing a little bit about what that means? Evan Leybourn (04:00) Chris, do you want to take that one? Christopher Morales (04:01) Yeah, well, so the idea behind using the Delphi method was actually inspired by my sister. She had done a periodic review that utilized this method. And essentially what it is is we utilize rounds of inquiry with an expert panel to refine the research, the feedback that we're getting. And so we collected an initial set of data. reviewed that data, tried to analyze it to come up with a consensus, and then repositioned our findings back to the experts to find out where they stood based on what they gave us. And really trying to get all of the experts to come to an agreement in specific areas. In the areas that we found gray space, for instance, or let's say, data was spread out, right? Those were really the areas where we're really trying to force these experts to get off of the fence and really make an assessment. And it was proved extremely helpful, I think, in this research because what I find in the AI space is that there is plenty of gray. And we really wanted to get to some stronger degree of black and white. I'm not going to say these findings are black and white, but I will say that in order to guide people, you need to give them degrees of confidence. And I feel like that's what we wanted to do with this. Brian Milner (05:31) Well, that's the great thing about research though, Is it can give you information, but there's always the story. And it's really kind of finding that story that really is the crux of it. So we open this saying, fact or fiction. So just hit us up with a couple of the, maybe some of the surprising findings or some of the key things. For the people you talk to. Christopher Morales (05:38) Mm-hmm. Brian Milner (05:53) Were they seeing these amazing kind of, you know, 100 X of their capabilities or what was the reality of what people reported to you? Evan Leybourn (06:01) In a few cases, yes. Maybe not 100x, but 8x, 10x was definitely being shown. But the big aha, and I won't say it was a surprise, was really in a lot of organizations, the teams that were using AI were seeing Brian Milner (06:03) Okay. Evan Leybourn (06:23) absolutely massive improvements. People talk about going from months to minutes in terms of trying to create things. And so there's your 100X. But when we look at it at a business level and the business ROI, when we look at the idea to customer from concept to cash, when we look at the overall business flow, very few of those organizations saw those benefits escape from the little AI inner circle. And so that 10x or the 100x improvement fizzles into nothingness in some cases. negligible improvement in the whole organization. Some organizations absolutely saw those benefits throughout the entire system. And those were organizations who had created a flow, who created organizational systems that could work at the speed of AI, especially some of the younger AI native organizations, if you want to think of them that way. But no, most organizations those 10x, 100x kind of goals were unachievable for the business. And so when I was saying 3x, by the way, what we sort of tended to find is those organizations, mature organizations with mature AI programs and systems. we're generally seeing between a 1.2 to 1.4x improvement to about a 2.8 to about a 3.2x improvement. So that's like a 20 % to a 300 % improvement if you want to think of it this way. Brian Milner (08:15) Wow. Well, that's nothing to sneeze at. That's still really, really impressive. Christopher Morales (08:19) yeah, it'll make a significant difference. I think for me the interesting thing about the findings

Laura Kendrick and Cort Sharp hijack the mic to share what it’s really like behind the scenes at Mountain Goat. From Zoom bloopers to unexpected team bonding, they unpack how a fully remote team built a thriving, human-centered workplace. Overview In this special takeover episode, Laura Kendrick and Cort Sharp pull back the curtain on what goes into running hundreds of Scrum and Product Owner classes virtually—and why Mountain Goat's remote team still feels so close-knit. With stories of early tech headaches, Slack banter, hilarious costume moments, and the quiet rituals that keep the team connected, they explore how remote work can actually foster strong relationships and top-tier collaboration. If you’ve ever wondered how to make a distributed team work (or just want a peek at some Zoom-era growing pains), this one’s for you. References and resources mentioned in the show: Laura Kendrick Cort Sharp #61: The Complex Factors in The Office Vs. Remote Debate with Scott Dunn #147: The Power of Quiet Influence with Casey Sinnema Run a Daily Scrum Your Team Will Love Subscribe to the Agile Mentors Podcast Join 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? 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: 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. Laura Kendrick is the producer of the Agile Mentors Podcast and a seasoned Scrum Master who keeps virtual classes running smoothly. Outside the podcast, she helps clients apply Scrum techniques to their marketing and business strategy, bringing structure and momentum to big, creative ideas. Auto-generated Transcript: Laura Kendrick (00:00) Welcome in Agile Mentors. As you may have noticed, I am not Brian Milner. I am Laura Kendrick, and this is Cort Sharp. And if you have taken a class with us at Mountain Goat in the last five years, there is a good chance that you have met one or actually both of us. Cort Sharp (00:19) I think it's like 90 % chance, 95 % honestly. We've been in so many of these classes. Laura Kendrick (00:26) Definitely, and oftentimes together too with one of us TAing, one of us producing, sometimes one of us teaching court. Cort Sharp (00:33) once in a while, once in a while. Yeah. Laura Kendrick (00:37) So we thought we would come on over here and hijack the podcast to share a little bit about some of the insights that we have gained from doing about a billion, maybe a little exaggeration. Cort Sharp (00:49) Roughly. Roughly. We've done roughly a billion classes with Mountain Goat. Yes. Laura Kendrick (00:56) We have seen a lot in the certifying of Scrum Masters and product owners and advanced product owners and Scrum Masters and all of the evolution of the classes that we have done. We actually hold quite a bit of insight into what is happening in this world. And so we thought we would come in, steal the podcast, and share a little bit of what we have seen, learned, observed, and really just kind of Honestly, some of the laughs and fun that we've had along the way. Cort Sharp (01:25) Also, I think, I don't know, just your intro right there is talking about, hey, we've seen the evolution of these classes. That just got my brain going of like, remember the first class that we did? Way like 2020. I mean, I was in my parents' basement with really terrible internet. It was a struggle. Laura Kendrick (01:40) Yeah. Cort Sharp (01:49) But we were working on like Miro boards or mural. One of the two, forget which, which tool it was, but that was, yeah, that was before team home. And then we got to see the first version of team home. We helped do a little testing with it. And then we've seen it grow all the way into this awesome tool that we have nowadays. And I don't know, just, just to me, I think it's cool to see how we've been iterating and be part of that process of the iteration process, um, to develop these classes and these courses into. Laura Kendrick (01:52) Mm-hmm. Mural. Yep. Mm-hmm. Cort Sharp (02:20) the truly awesomeness that they are today. Personally, I'd rather take a virtual class than an in-person class with Mountain Goat at this point. Laura Kendrick (02:27) It's funny that you say that because I notice actually the iteration of the experience like outside of the tech piece because you know, that's where my brain goes. Here's the difference between court and I. I'm noticing the interactions. But I've noticed, mean how people are interacting a little bit differently in the online space, how even our team interacts, like all of those things has become so much more sophisticated and amazing and Cort Sharp (02:39) Yeah, just a bit. Laura Kendrick (02:54) I mean, honestly, we sometimes talk on our team between like the producing and TA team where like I've referred to it as a perfect game if we don't need anything from the outside team, which occasionally we need a lot of support from the outside team, but we've we've got this down at this point. And it is it's become those first classes. I remember them being super stressful, like, my gosh, the breakout rooms and all the things and just being like, I mean, you couldn't do. Cort Sharp (03:17) Yes. Laura Kendrick (03:21) It was almost like learning how to drive where you felt like if you turned the radio knob up, you might actually turn the whole car. And it was like, so much anxiety. Cort Sharp (03:31) I mean, but we just didn't know Zoom then. Zoom didn't even know itself then, right? What Zoom is, ⁓ for those of you who don't know, we host all of our virtual classes on Zoom. And learning that platform, like I'd used it once maybe for some just, yeah, here's Zoom exists in one of my college classes. That was about it. But yeah, totally. was like, man, what does this button do? Hopefully it doesn't end the meeting and kick everyone out. Laura Kendrick (03:34) Yeah. Yeah. Yeah. That's so true. Yeah, no kidding. But you know what's really interesting too, though, is that it's been over five years now for both of us being part of the Mountain Goat team. And we all work remotely. And other than you and Mike for a little while being right down the road from each other, none of us had any actual interpersonal interaction with each other outside of Zoom email and Slack and the occasional, know, fretted text message of like, are you late? Where are you? Cort Sharp (03:58) Absolutely, yeah, totally. Yeah. Laura Kendrick (04:26) But other than that it like we truly were of and still are a fully remote team and the crazy thing about it is we have at this point once gotten together as a full team in person and it was such an interesting experience being having been fully remote and then being in person and in particular the team that is live on the classes Cort Sharp (04:39) Yep. Yep. Laura Kendrick (04:51) It was a very different interaction because we have this time built into our classes where the team gets on the Zoom call 30 minutes earlier than the students do. And we get this time to just honestly have like water cooler chat and like friend chat or occasionally see Mike get on and you can't hear him, but you can see that he is quite angry at his very elaborate tech system that is not working correctly. Cort Sharp (05:14) you That does happen. Yes, it does. ⁓ Laura Kendrick (05:21) these moments, I feel like they really bonded us together. Because when we got together in person, it was old friends. wasn't even fast friends. It was old friends. And the banter even that goes on in Slack is fun and engaging and not rigid and confining. Cort Sharp (05:31) Yeah. Yes, absolutely. I agree with that. I mean, I'm just thinking back to like the first time because that was the first time I met you in person. aside from being like, wow, she's a lot shorter than I thought she would be. Laura Kendrick (05:47) Mm-hmm. shorter. By the way, court is like 6-4. Cort Sharp (05:55) Yeah, yeah. Not that you're short. But I've just always ever seen like, the profile like the profile picture. That's all that it's really ever been. So I'm like, yeah, you're like, what I would consider normal height, which you totally are. But in my mind, I was like, yeah, it's weird seeing, you know, your legs. That's funny. ⁓ Laura Kendrick (06:14) We digress. Cort Sharp (06:15) But aside from that, was like we've known each other for three, four, four years because we've had that time to get to know each other. We've had that time to talk about just life events, what's going on, where we live, what's happening, what the deal is going on with life. Because we've been very intentional about having that time with that. The 30 minutes before each class were originally very much so used to take care of any tech problems. As the years have gone by, we've for the most part figured out the tech problems. Sometimes, you know, we'll change something out. Laura Kendrick (06:48) Except, hold on, except last week in Lance's class, we were talking about his dog and suddenly it looked as though Lance in his entire room did a cartwheel because the camera just fell. This is not a small camera. Cort Sharp (07:02) It said, nope, I'm out. ⁓ man. Laura Kendrick (07:06) So we still occasionally have the tech problem. Cort Sharp (07:09) Yes we do, yes we do. That's why we still do the 30 vimits. Laura Kendrick (07:14) The crazy thing about that is that when we landed at this in-person meeting, there were members of the team that at that time, and I in particular had never had any interaction with. so like other than the odd email or Slack message, so it w

What does it really mean to have a bias toward action and how do you build that into your culture without skipping strategy? Boris Gloger joins Brian Milner for a deep dive on experimentation, leadership, and the difference between tactical work and true strategic thinking. Overview In this conversation, Brian welcomes longtime Scrum pioneer, consultant, and author Boris Gloger to explore the tension between planning and doing in Agile environments. Boris shares how a bias toward action isn’t about skipping steps—it’s about shortening the cycle between idea and feedback, especially when knowledge gaps or fear of mistakes create inertia. They unpack why experimentation is often misunderstood, what leaders get wrong about failure, and how AI, organizational habits, and strategy-as-practice are reshaping the future of Agile work. References and resources mentioned in the show: Boris Gloger LinkedIn Leaders Guide to Agile eBook 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. Boris Gloger is a pioneering agile strategist and Germany’s first Certified Scrum Trainer, known for shaping how organizations across Europe approach transformation, strategy, and sustainable leadership. As founder of borisgloger consulting, he helps teams and executives navigate complexity—blending modern management, ethical innovation, and even AI—to make agility actually work in the real world. Auto-generated Transcript: Brian Milner (00:00) Welcome in 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 one, the only Mr. Boris Glogger with us. Welcome in Boris. Boris Gloger (00:11) Yeah, thank you, Eurobrein, for having me on your show. Brian Milner (00:14) Very excited to have Boris here. For those of you who haven't crossed paths with Boris, Boris has been involved in the Scrum movement, I would say, since the very, very earliest days. He's a CST, he's a coach, he's an author, he's a keynote speaker. He had a book early called The Agile Fixed Price. He runs his own consultancy in Europe. And he has a new book that's been, that's going to be coming out soon called strategy as practice. And that's one of the reasons we wanted to have Boris on is because there's kind of this topic area that's been percolating that I've heard people talk about quite often. And I see some confused looks when the, when the topic comes up, you hear this term about having a bias toward action. And, we just wanted to kind of dive into that a little bit about what that means to have a bias toward action. and really how we can apply that to what we do in our day-to-day lives. So let's start there, Boris. When you hear that term, having a bias toward action, what does that mean to you? Boris Gloger (01:12) The fun thing is I was always in tune with the idea because people said my basic mantra at the beginning of doing agile was doing as a way of thinking. So the basic idea of agile for me was always experimentation, trying things out, breaking rules, not for the sake of breaking rules, but making to create a new kind of order. the basic idea is like we had with test-driven development at the beginning of all these agile approaches and we said, yeah, we need to test first and then we have the end in our mind, but we don't know exactly how to achieve that. So there is this kind of bias towards action. That's absolutely true. On the other hand, what I've always found fascinating was that even the classical project management methodologies said, Yeah, you have to have a plan, but the second step is to revise that plan. And that was always this, do we plan planning and reality together? And actually for me at the beginning, 35 years ago, was exactly that kind of really cool blend of being able to have a great vision and people like Mike and all these guys, they had always said, we need to have that kind of a vision, we need to know. Yeah, if the product owner was exactly that idea, you have to have that vision, but you really need to get the nitty-gritty details of, so to say, of doing this stuff. Brian Milner (02:40) Yeah, that's awesome. And the thing that kind of always pops to my head when I think about this is, we hear this term bias toward action and there's sort of this balance, I think a little bit between planning and action, right? I mean, you wanna plan, you wanna plan well, but you don't wanna over plan. You don't wanna waste too much time trying to come up with a perfect plan. You wanna... you want to do things, but you also don't want to be, you don't want to rush into things. So how do people find that balance between not just, you know, going off, you know, like we say in the U S half cocked a little bit, you know, like just not, not really not ready to really do the thing that you're going to do. Cause you didn't really invest the time upfront, but on the other hand, not spending so much time that you're trying to get the perfect plan before you do anything. Boris Gloger (03:28) You know, the problem, for me, the issue was solved by when I figured out that the teams typically struggle not to achieve, for instance, the sprint goal or the end or whatever they wanted to accomplish when they have not the right know-how. So it's a knowledge problem. So for instance, I don't know if this is still the case, but sometimes developers say, need to... to immerse myself with that I need to figure that out. I need to get the new framework before I can do something about estimates or something. So whenever you hear that, that you know that person that just tries to give you an estimate or the team that would like to come into a sprint goal or whatever it is, they are not really knowing what topic is about. It's a knowledge gap. And then people tend to go into that analysis paralysis problem. They don't know exactly what they need to do. So therefore they need to investigate. But by doing investigation, you start making that big elephant in the corner, larger and larger and larger and larger because you go that ishikara diagram, you have too many options. It's like playing chess with all options at hand and not have enough experience. What kind of gambit you would like to do. So everything's possible and by, because you have not enough experience, you say everything's possible, that creates too much of a planning hassle. And Agile, is the funny thing is, made us very transparent by just saying, okay, let's spend maybe two weeks. And then we figured out two weeks is too much. So let's do a spike, then we call it a spike. The basic idea was always to have a very short time frame, timeline where we try to bring our know-how to a specific problem, try to solve it as fast as possible. And the funny thing was actually was, as if I I confess myself that I don't know everything, or anything, sorry, that I don't know anything, then I could say, I give me a very short timeline, I could say I spend an hour. And today we have chat, CVT and perplexity and all that stuff. And then we could say, okay, let's spend an hour observation, but then we need to come up with a better idea of what we are talking about. So we can shorten the time cycle. So whenever I experienced teams or even organizations, when they start getting that planning in place, we have a knowledge problem. And a typical that is, is, or the classical mindset always says, okay, then we need to plan more. We need to make that upfront work. For instance, we need to have backlogs and we need to know all these features, even if we don't know what kind of features our client really would like to have. And the actual software problem is saying, okay, let's get out with something that we can deliver. And then we get feedback. And if we understand that our kind of the amount of time we spend is as cheap as possible. So like we use the tools that we have. We used to know how that we have. We try to create something that we can achieve with what we can do already, then we can improve on that. And then we can figure out, we don't know exactly what we might need to have to do more research or ask another consultant or bring in friends from another team to help us with that. Brian Milner (06:46) It's, sounds like the there's a, there's a real, kind of focus then from, from what I'm hearing from you, like a real focus on experimentation and, you know, that, that phrase we hear a lot failing fast, that kind of thing. So how, do you cultivate that? How do you, how do you get the organization to buy in and your team to buy into that idea of. Let's experiment, let's fail fast. And, and, we'll learn more from, from doing that than just, you know, endlessly planning. Boris Gloger (07:12) I think the URCHAR community made a huge mistake of embracing this failure culture all the time. We always tell we need to call from failure because we are all ingrained in a culture in the Western society at least, where we learned through school our parents that making failures is not acceptable. Brian Milner (07:18) Ha ha. Boris Gloger (07:32) And I came across Amy Atkinson and she did a great book to make clear we need to talk about failures and mistakes in a very different kind of way. We need to understand that there are at least three kinds of mistakes that are possible

Can you lead meaningful change without burning people out—or yourself? Sherri Robbins thinks so, and she’s sharing how she’s done it in high-stakes, high-complexity environments (with her sanity intact). Overview In this episode, Sherri Robbins joins Scott Dunn to talk about what it actually takes to lead large-scale change across teams, departments, and vendors without losing sight of your values—or your people. From agile leadership lessons and real-world mistakes to personality-aware management and learning how (and when) to let teams fail forward, this conversation goes far beyond frameworks. If you’ve ever tried to implement something new and wondered why it didn’t stick, this one’s for you. References and resources mentioned in the show: Sherri Robbins Switch: How to Change Things When Change Is Hard by Chip Heath & Dan Heath Start With Why by Simon Sinek Five Lessons For Agile Leaders 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: 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. Sherri Robbins is a 20+ year veteran in the medical device industry, blending strategic execution with deep regulatory and quality systems expertise to lead enterprise-wide transformations. She’s a thought leader in Agile implementation, known for aligning cross-functional teams, building psychological safety, and driving change that actually sticks.

How do you lead change when you’re not the boss? Casey Sinnema shares what it takes to build trust, influence outcomes, and make Monday feel a little less dreadful. Overview What happens when you give a self-proclaimed utility player the freedom to poke holes in broken systems and lead cross-functional change without official authority? In this episode, Scott chats with Casey Sinema about navigating ambiguity, building trust without a title, and leading impactful change through curiosity, clarity, and a deep understanding of what people actually need. References and resources mentioned in the show: Casey Sinnema Wolf Pack by Abby Wombach The Let Them Theory by Mel Robbins Micromanagement Log Subscribe to the Agile Mentors Podcast Join 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? 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: 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. Casey Sinnema is a self-described utility player who’s built a career by asking great questions, poking holes in broken systems, and leading meaningful change across teams—without ever needing the official title to do it. With a background in accounting and a talent for cross-functional problem solving, she brings curiosity, empathy, and real-world savvy to every challenge she tackles. Auto-generated Transcript: Scott Dunn (00:01) Well, welcome everyone to another episode of the Agile Mentors Podcast. I am your takeover, not your normal host, of Brian Miller, who's done a smash up job over a hundred plus episodes if you haven't checked those out. But part of the podcast takeover was not only a fresh voice, but also perspective and a lot of what I typically focus on for the people who know me. On leadership and culture and leading change. And I thought of no one better that I'd rather talk to about some of this. Casey Sinnema and I'll give you a little bit of introduction about who she is, what she does. Maybe also I think it'd be fascinating Casey on how you yourself in the role that you have. I think it's kind of a cool role, at least on paper. You can flesh that out a little bit more but I'll hand off to you. Tell us a little about yourself. Casey (00:46) Yeah, hey, thanks for having me. Yeah, so I currently am most often referred to as a utility player. And I'm still trying to figure out my elevator speech for how I talk about what I do because my role, my title is manager, which doesn't say much, right? And I actually don't do a function, but the easiest way to talk about it is I'm a project manager of sorts. I'm involved in a wide variety of projects from a varying level of involvement, from leading the project to leading the change to being a key stakeholder to just being the voice to leaders or executives or that type of thing. So yeah, I am a little bit of everything. And I got here on accident. I have... Scott Dunn (01:32) I was... Casey (01:34) You know, way back in the day when I was, you know, doing the like, what am I going to do for the rest of my life? I'm like, I just want a marketable skill. So I have a business degree and I went into accounting and I quickly became the troubleshooter. So I would go into a company, troubleshoot, fix the process, fix something broken, and then find myself in another company doing the same thing. And, so throughout my career, I've just sort of built this unique set of skills that allow me to poke holes in processes. and help companies fix them and then kind of find the next thing. So that's just kind of how I wound up here. I've been at my current company for almost a decade, which is going to be a record for me. And, but I'm still doing the same thing. I'm moving around the company and finding new places to, you know, rock the boat a little bit. Scott Dunn (02:20) Cool. Very cool. Yeah. It does sound like you have a number of things on your place to where that makes kind of expand on that a little bit and where you comfortably share those stories as we go through some of this because there's a lot, there's a lot more underneath based on what Casey shared before. And I love it that you found yourself like a happy accident and I guess have enough challenges and learning and growth there as long as they move you around that you're, you know, you need to be working on that are meaningful. things to be working on. Casey (02:51) Yeah, absolutely. That's the biggest thing, right? Is to like find work that you find valuable and that has an impact on the people around you, which is, know, squarely aligned with my values. Scott Dunn (03:01) Well, you touched on one thing that I know a number of other people could relate to and I could too as well as the kind of troubleshoots process can just easily see that things aren't working at a larger view. Some of that. maybe add on a little bit. What is it like about your role? For those who are kind of thinking they're in quasi space, they can hear you talk about that role and like, hey, that sounds like me too. What are the points of that different projects, different things you're involved with that that's what really lights you up? Casey (03:27) Yeah, I, it's so interesting because a lot of us find that the things that we're good at are the things that, you know, give us energy and that motivate us, right? I happen to be uniquely skilled at poking holes in things, including in my own life. So it works in my personal life as well. I could just sort of see things from different perspectives and find the gaps. And so it just sort of on accident. I think what's interesting is Scott Dunn (03:43) You Hmm. Casey (03:53) throughout my career and throughout my life, the biggest challenge has been to hone that skill for good, right? To lead with kindness and to manage my expectations along with the expectations of the world around me and troubleshoot the things or poke holes in things that need holes poked in instead of like everything. You know what mean? Scott Dunn (04:15) I love that. Two things that I want to, I guess, add on a little bit more there. One, you mentioned something and the other thing is I think you might just put out there like, same thing from different perspectives. I imagine for the people, we've all been around folks who just they only think their way. And you're just kind of reflecting on that. But Keith, it sounds like you can go into a meeting and you can hear three different state views and you can genuinely understand from their perspective why that's important to them or why that's a problem to them, right? If I'm hearing you. Casey (04:42) Yeah, absolutely. That's really key in all of the different types of projects that I've played a part in, right? Like hearing things from different people's perspectives and really understanding what they're looking to get, what they need and what's in it for them and being able to connect those things across stakeholders. Scott Dunn (04:59) Yeah, that's powerful. Yeah, but looking for commonality, alignment, et cetera. I do think there's a specialness, and we've talked about it a bit, like in the facilitation class, that looking for those folks having common and generating alignment is a unique gift that we just don't see a lot in corporate people kind of lobby for what they want. And actually, it's, it would be an afterthought to think about other people's perspectives and yet who draws different areas of the company together who are to get some new about the door or whatever like that. So you're kind of touching on that, which I think is really powerful. Is there anything that you see as like a go-to mindset that you bring in those situations or go to like tools that you're kind of using, whether that's things you're doing in writing down or in mural or even just how where your head is at when you walk into some of those meetings where you feel they have different perspectives and on the same page, you're supposed to walk out of that session on the same page. Casey (05:51) Yeah, the first one is to sort of leave my ego at the door, right? What I think is the right thing can't come in the door with me, right? Like I, of course I'm influencing, right? Where I feel like it matters. But it's not, I'm probably not the decision maker and the people that are not on the same page, when they need to get aligned, they need to be able to get there on their own. So what I think is the right way, I got to leave it at the door. So that's my number one thing. Scott Dunn (05:57) heheheheh. Casey (06:18) And then the next thing I do is just really stay curious, ask lots of questions, actively listen, model that active listening behavior so that everybody else is also actively listening. That's a big thing. And really just sort of helping people find a common language, I think, is really important. So I do a lot of restating what I'm hearing so that other people can maybe hear it from a different set of words and connect it. Scott Dunn (06:29) Hahaha Casey (06:42) more readily to the way that they're thinking about the topic. Scott Dunn (06:45) Yeah, you say these as if they're like, I mean those are short little pithy statements, but boy, powerful. I think it reflects an attitude beginning with what he said as the ego is like, we might know a whole lot, we gotta leave that at the door. Just at work, awesome. Here and you say something, I'm making notes like this would be good in life too, right? In personal life and relationships, stay curious, active. Don't assume that the way you see it is rea

What does it look like to lead a 300-person software org inside a 1,000-person company—and still stay focused on people first? Brendan Wovchko shares what he's learned about leadership, agility, and building a culture that actually works. Overview Brendan Wovchko, CTO at Ramsey Solutions, joins Scott Dunn to talk about what it really takes to lead Agile teams inside a large, fast-moving organization. From developing leadership habits to navigating team dynamics and staying grounded in purpose, this conversation is full of thoughtful takeaways for anyone working at the intersection of people, process, and product. References and resources mentioned in the show: Brendan Wovchko Ramsey Solutions #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York What Is a High-Performing Agile Team? by Mike Cohn Four Quick Ways to Gain or Assess Team Consensus by Mike Cohn Elements of Agile Assessment 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: 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. Brendan Wovchko is the CTO of Ramsey Solutions and a lifelong student of what it takes to build great software, lead great people, and scale both with purpose. With roots in engineering and startups, he brings decades of hands-on experience in product, leadership, and agile culture—plus a knack for turning big ideas into results that matter.

How do you grow a remote-first team from 30 to over 100 while still being voted a "great place to work"? Ginger Boyll says it’s part Agile mindset, part trust, and part Dungeons & Dragons—and we’re not arguing. Overview In this episode of the Agile Mentors Podcast, guest host Scott Dunn sits down with Ginger Boyll, Director of Client Experience at Stable Kernel, for a refreshingly candid conversation about leadership, collaboration, and creating cultures where people thrive, even remotely. From the magic of psychological safety to timesheet woes, CliftonStrengths charts, and the underrated art of letting someone else just do the thing, this episode is a masterclass in how empathy and agility show up far beyond process. References and resources mentioned in the show: Ginger Boyll Stable Kernel The Fearless Organization by Amy Edmonson Range by David Epstein Built to Last by Jim Collins Unreasonable Hospitality by Will Guidara The Tipping Point by Malcolm Gladwell The Coaching Habit by Michael Bungay Stanier Paul Graham’s Maker’s Schedule, Manager’s Schedule 25 Questions That Will Help You Know Your Teammates Better 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: 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. Ginger Boyll is the Director of Client Experience at Stable Kernel. She is a natural problem-solver with a passion for people, bringing deep experience in Agile delivery, tech strategy, and cross-functional collaboration to every project she touches.

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.

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 differen

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 use

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

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 sati

Retrospectives shouldn’t suck the energy out of your team—or get skipped entirely. In this episode, Brian and Cort share how to fix the most common retro fails and announce two brand-new tools to help you run retros that actually work. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Cort Sharp break down why retrospectives are more than just a “Scrum box to check.” They’re the powerhouse behind continuous team improvement. From battling retro fatigue and quiet-room energy to creating psychologically safe environments and tying retrospectives to real results, they cover it all. Plus, Brian reveals the launch of two new on-demand courses—Better Retrospectives and The Retrospectives Repair Guide—designed to help teams stop skipping and start optimizing their retros. Whether you're a Scrum Master, coach, or facilitator, this episode is your practical guide to making retrospectives worth everyone’s time again. References and resources mentioned in the show: Cort Sharp Blog: Retrospectives With a Quiet Team Blog: Does a Scrum Team Need a Retrospective Every Sprint Mike Cohn’s Better User Stories Course Scrum Repair Guide 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. 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. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. Welcome back for another episode of Agile Mentors podcast. I'm with you as always, Brian Milner, but today we're gonna have a continuation of something we tried, a little experiment we tried a few weeks back here. I've got Mr. Court Sharp back with us. Welcome back in court. Cort Sharp (00:18) Hey, Brian, thanks for having me on again. I had lot of fun last time I was on here and it was a great discussion. So thanks for bringing me back. Brian Milner (00:21) Yeah. Yeah, it's, oh, absolutely. Yeah, know, got a lot of people said, hey, we kind of like that court guy. Kind of like hearing from court. So we wanted to have court back, you know, because you guys told us that you liked him. And we also wanted to have him back because we just thought this format kind of worked for various reasons. And last time we kind of hit on some things that were kind of more hot button issues of the day. things that have been flowing through social media or other things around Agile. But we wanted to have a little bit more of a focus for today's episode. And we're going to focus really on the topic of retrospectives. And maybe make a little announcement here along the way as we go along. But we're actually going to switch roles here a little bit. I'm going to kind of pass the ball over to Court. And I'm going let Court drive this, just like he did in the last episode. Ball's in your court. Ha ha, get it? Cort Sharp (01:18) Ha ha, court, there you go. Well thanks, Brian. Once again, I love coming on here, I love chatting with you. And like you said, yeah, we're gonna be talking about retrospectives today, mostly because I have been struggling with answering questions about retrospectives. I think this is one of the more common meetings within Scrum that just gets skipped over, just people don't find value in it. Brian Milner (01:42) Yeah. Cort Sharp (01:43) or people just struggle with understanding why we have retrospectives. And sometimes I get a little slipped up and I struggle with answering the questions about why do we do this? So can you give me some clarification? Why do we have retrospectives? Why do they matter? Brian Milner (01:58) Yeah. Yeah. I mean, it's a great question. And I think everyone should, should, you know, want to know that answer. If you're doing this, you one of things I say in class all the time is, you know, it's important to know the purpose behind the meetings that we have in scrum. If you don't know the purpose, then, you know, that, how are we gonna, how are we gonna have a successful meeting? How are we gonna get the most out of it? so yeah, it's, it's a funny kind of meeting, because all the other meetings and scrum are, are really, around one ultimate purpose and that's building the increment. This is not, right? This is sort of a timeout. It's an intentional kind of timeout to step away and say, all right, now that we've done that, how did it go? What kind of happened along the way? I think it's a vitally important meeting. And when I hear people sometimes say, is it okay to skip it or should we do it once ever so often? you know, again, I try to be pragmatic and say, you know, I don't, I don't know any possible situation out there, but, you know, I would tell you, I would advise you not to, I don't think that's the right path to go. I know scrum doesn't teach to do that. I think it's really, really important because it is that, that moment of let's pause for a little bit. Let's figure out what we need to do differently and then let's actually take a step to do it. There's actually an interesting little background for this. So I'm going to take a little side trip here. Retrospectives actually come from an idea that has been around for a while that actually started kind of in lean manufacturing, some of the things that came out of Japan. There was actually a phrase that they would use on the assembly line at the auto assembly plants there in Japan. They referred to this concept of Kaizen. Kaizen was kind of a, I don't speak Japanese, but what I understand is the word loosely kind of translates to good change. And they had this concept there on the assembly line floor that anyone who was on the floor had access to the big red button that could stop the entire thing. They could stop the entire assembly line, which you know, on an auto assembly plant, that's a huge deal to stop the entire production. And they were very deliberate about it and said, no, we want everyone to have access to that because the phrase they use was the Kaizen comes first. And what they instructed the employees was if you along the way, as you're doing your job, if you see something that we could change that would make it more efficient, that would be a better way of doing this, then we want you to hit the red button because we want to implement whatever that change is as soon as possible. The sooner we implement the change, the longer we have as a benefit, like an investment. The earlier I invest, the more I get as a return. So the same thing here, the earlier I invest in this good change, the longer I have to have a return from it. So that phrase, the Kaizen comes first, is sort of a central thing that we think about here with retrospectives. It's identifying those good changes. there's actually even an intention behind it that it doesn't go on the product backlog. It goes in the next sprint backlog. Because we don't want to have any even inkling of deprioritizing something that comes out of a retrospective. It's that Kaizen portion. So we want to make sure that comes first. So yeah, it absolutely is going to go into the next sprint. Whatever we decide is the most important thing, we're going to make an impact on it in the next sprint. So that's why I think that it's the most important thing for us is it's the engine that really drives continual improvement. And without it, I think teams stagnate. I think they just get kind of stuck in a rut. problems that we have, we just continually repeat. if we don't have the time to stop an exam. Cort Sharp (06:00) Yeah. All right. So I kind of got one bigger idea from there. And for whatever reason, when you were like, we gave everyone the red button to stop the assembly line. And that's kind of, we're stopping, we're pausing, we're inspecting, and then we're going to come up with a plan to adapt. Whatever reason, this phrase stuck in my head, it just popped out to me. But it sounds like we're giving power to the people. Brian Milner (06:06) Okay. Cort Sharp (06:26) where we're, you know, the team has the power, the people have the power to say, whoa, let's stop here. Let's hang on a second. Let's take some time and let's figure out a better way to move forward. And from that, I just think of sports. I think of sports teams. We're in the middle of March Madness as we're recording this right now. And I can pretty much guarantee you that every single one of those teams who's advancing on past, I think round one is going on right now, so passing on through round one, they're probably watching some film on their opponents. They're trying to see, what are they gonna do? What are some plays? How can we kind of counteract it? But more often than not, I would wager, I'm not a gambling man, but I'd wager, that they're looking at their own film and they're trying to see what did we do well in this game that got us the win? What can we improve? so that we could maybe have a little bit more of a bigger margin of victory. And what is it that we should probably stop doing? What is there that wasn't working out? Maybe our pick and rolls were not good, maybe we weren't executing well on those, or not to get too into basketball terms there, but maybe we should stop shooting so many threes or something like that. I don't know, right? But yeah, that's, yeah. Brian Milner (07:42)

Ever left a meeting feeling more drained than before it started? That’s the dreaded meeting hangover. Brian Milner and Julie Chickering dive into why bad meetings have lasting effects—and what facilitators AND participants can do to make them better. Overview Bad meetings don’t just waste time, they drain energy, morale, and engagement long after they’re over. In this episode of the Agile Mentors Podcast, Brian and Julie Chickering unpack the concept of "meeting hangovers"—the lingering negative effects of ineffective meetings. They explore why bad meetings happen, the shared responsibility of facilitators and participants, and practical strategies for turning the tide. From fostering accountability to knowing when to walk it off, this conversation will help you rethink how meetings impact team dynamics and productivity. References and resources mentioned in the show: Julie Chickering #137 Stop Wasting Time with Guests Kate Megaw HBR The Hidden Toll of Meeting Hangovers by Brent N. Reed, et al. When: The Scientific Secrets of Perfect Timing by Daniel H. Pink Remotely Productive by Alex Pukinskis Working on a Scrum Team Class 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. 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). Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're here for another episode of Agile Mentors podcast. I'm with you as always Brian Milner and haven't got to say this for a while. So I'm happy to say again, welcome back to the show, the fabulous Julie Chickering. Welcome back, Julie. Julie (00:15) Thanks, Brian. Glad to be here. Brian Milner (00:17) Yeah, very excited to have Julie back. Julie is a friend of the show. We've had her on multiple times and it's been too long. We just need to have you on more often again. So thank you for making the time and coming back. We wanted to have Julie on sort of as a little bit of a continuation from our last episode that we had with Kate McGaw. You we talked a little bit about facilitation there and there was a lot that we talked about initially to set that up to talk about Julie (00:30) Sure. Brian Milner (00:44) just the fact that there's an epidemic of bad meetings. There's kind of a harmful thing happening where it's extremely prevalent that meetings are going poorly. There's not a lot of attention that's given to this. There's not a lot of focus in a lot of organizations because it's such a prevalent issue. of our meetings being so bad. And Julie pointed out to me this Harvard Business Review article that sort of became a touchstone, I think, for what we wanted to talk about. It's called the hidden toll of meeting hangovers. And we'll link to this in the show notes. But the idea behind the article was just to say, they quoted a stat early on saying that they did a study and found that more than a quarter, 28 % of meetings left employees with lingering negative effects, such as impaired engagement and productivity. And so that's what they were referring to this sort of this meeting hangover, that bad meetings take a toll beyond just the lost time in the meeting. And that's kind of what we were talking about more with Kate is, you know, yeah, we want to make our meetings better, but there is sort of this ongoing lingering that, you know, from my reading of this and what I've experienced, kind of compounds, you know? One bad meeting then can lead to another bad meeting and another one and that feeling of anxiety and disconnectedness and like I said here, impaired engagement and productivity, those kind of grow and get worse and worse the longer that you have these bad meetings. So Julie, I'll just start with you and say, you know, when you read this article, what was it? What was it that really stood out to you, that jumped out to you, that made you think this was an important kind of area of focus? Julie (02:27) First of all, I love the title because I can relate to it. So when you're having a hangover, you just feel terrible, right? And this person that they talk about first, Jacob, about like, he was so frustrated when he left the meeting. So the introductory story when he was so frustrated when he left the meeting, he canceled his one-on-one right after because he knew he couldn't concentrate. And then he was just like so upset. for the rest of the day and talking about how he just didn't even want to work on the project anymore. So just this, I just got this physical sensation reading this around how it feels when you're in a meeting that's ineffective. And we've all been there and I could just like feel it in my body when I read this story. And I also feel like once you know what I, what an ineffective meeting feels like, the ineffective one is more noticeable and draining. yeah, so and then this this lingering effect of morale and just wasted, just wasted opportunity. And it feels like Brian Milner (03:32) Yeah. Yeah. Julie (03:47) in the corporate world, this is the norm. That we just have meeting after meeting after meeting that's just sucking the life force out of everyone. And then we wonder why nothing gets done. Brian Milner (04:00) Yeah, I mean, this article is packed with statistics and it's tempting for me to just kind of read them all off to you. I'm not going to do that. But there's a couple of things that kind of jump out to me. they talk about how around half of people have this feeling of that as a result of the hangover from the meeting, that they have negative or harmful impacts on their interactions with coworkers. They feel more disconnected from their team. and they want to spend more time alone based on the fact that, I went through this really kind of, there's no other way to say it, traumatic experience of having this really harmful, bad meeting. they connect the dots by saying, people will leave these meetings and oftentimes they will then go commiserate with coworkers and say, share their frustrations, which is helpful, it's good. But it also, you know, they noted here, this can kind of spread some feeling of negativity or hopelessness, you know, that it's always going to be this way. You know, yeah, I had a meeting like that as well. Boy, I guess this place is doomed. It's always going to feel like this. And so they have this kind of ongoing, as I said, compounding almost nature of it that one bad thing leads to another leads to another leads to another. And pretty soon you've got this really harmful, negative work environment and it's not necessarily something that's just happened. It's just the repetition of going through those things lead to this ongoing negative psychological impact in the organization. Julie (05:28) Yeah, I'm just smiling because I can just think of some meetings that I used to have a leader that would always show up late. Always show up late. We'd be halfway through the topic and then he would show up and we'd have to stop what we were doing and go circle back and just speed and you could just feel. the whole mood of the meeting change. We were actually making progress and we have to stop and we have to go all the way over. And this is constant. So what we would do afterwards is then have meetings after the meetings to complain about the leader doing that. The more adult thing would have been of course to say to the leader, when you do this, Brian Milner (06:15) Yeah. Julie (06:22) This is the outcome. Brian Milner (06:25) Yeah. So, so that's kind of, you know, what we want to talk about a little bit in here as well is, in the last episode, we, focused a lot on facilitation and the idea that, Hey, there's a lot of responsibility to the meeting organizer, whoever's facilitating this to not have it be this negative kind of environment. And I don't disagree with any of that, that we talked about in the last episode. I think there is a lot of that, that is true, but I think it's, it's. important for participants to not look at that as, it's all the facilitator then, right? I'm just a participant, I'm showing up and it's your job to get all this stuff out of me. And if the meeting goes poorly, that's entirely your fault. And I think it's important for us to recognize, no, if I'm a participant, if I accept that meeting invite and I'm here, I have a role to play. I have a contribution to be made and I can have, you Julie (07:14) Right. Brian Milner (07:19) as kind of Pollyanna-ish as it sounds, I can have a negative impact or a positive impact on this meeting. And I think that's an important kind of responsibility to take a hold of. Julie (07:25) you Yeah, I agree. And I think about that in a couple of ways. So actually, in both Scrum Master and Product Owner class, I remind them at the end of every meeting to ask two questions. The next time we have this kind of meeting, what would you want to do differently? But you gotta ask the question. And if you ask the question and nobody says anything, then they can't fee

In this episode, Kate Megaw joins Brian Milner to share simple but powerful techniques that can turn those soul-sucking meetings into dynamic, action-driven conversations. If you're ready to make meetings worth attending, this one’s for you! Overview Brian Milner and Kate Megaw uncover the secrets to running highly effective and engaging meetings. They tackle common facilitation pitfalls, the staggering amount of time wasted in ineffective meetings, and how simple tweaks can transform team collaboration. Kate shares practical strategies for keeping participants engaged, fostering psychological safety, and ensuring meetings lead to real action—because no one has time for another pointless meeting. References and resources mentioned in the show: Kate Megaw ARCLight Agile Katanu Katanu’s Facilitator Certification Course Katanu Resources #44: Transformations Take People with Anu Smalley Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule 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. Kate Megaw is the Founder and CEO of ARCLight Agile, specializing in helping organizations create empowered, high-performing teams through agility and collaboration. A dynamic Certified Scrum Trainer (CST), Certified Team Coach (CTC), and Project Management Professional (PMP), Kate is a sought-after speaker known for sparking ‘aha’ moments that drive real transformation. 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 here as I always am, Brian Milner. I'm with you as your host. But today I have the one and only, amazing Kate McGaw is with us. Kate, thank you for coming on. Kate Megaw (00:17) Thank you for having me. Brian Milner (00:19) Absolutely. If there's some of you out there that aren't familiar with Kate, she is a CST, a Scrum trainer like myself. She's also a certified team coach. And she also has the other side of things, the dark side. She's a PMP. So she has that project management kind of background that she brings to the table as well, which I think is awesome. She's a CEO of a company called Arclight Agile. And she's a co-founder of one of our favorites here that's come on the show, Anu. But they team up together. So it's Kate and Anu. And so their company is Katanu. I love it. love it. So why we decided to have Kate on is because Kate and Anu both have done a lot of work around facilitation. And we did have a user request. Kate Megaw (00:57) That's it. Brian Milner (01:09) to have an episode where we focused on facilitation. And listeners of the show know there's nothing I love more than being able to fulfill listener requests here and try to do those as soon as possible. So let's dive in. Let's talk about facilitation. It's a funny word. There's lots of different misconceptions and things about it, I'm sure. What do you find people misunderstand most about facilitation? Kate Megaw (01:34) think one of the key misunderstandings around facilitation is that you're part of the meeting, you're part of the event, you're actively involved. And when you're facilitating, you're actually, taking a step back because you are accountable for making sure that everyone is speaking and that we're keeping an eye on the agenda and things like that. And if you are actively involved in the discussion, You can't be doing that because you're missing body language. You're missing people who need to talk and who aren't talking. So I think one of the main misconceptions is, or that people forget is a facilitator is neutral. So if, for example, you have a scrum master facilitating a retrospective and they need to be actively involved in the retrospective, they should be inviting somebody else in to facilitate it. and I think We're beginning to see a lot more interest in it now because it's one of these key things. If it's done badly, people generally will notice. If it's done well, hopefully you don't notice that much other than, you know what, that meeting was very efficient. We achieved the goal and I feel as though it was worth my time. One of the things I like to say to people at the end of a meeting is the fist of five, how worth your time was this meeting? And I'm looking for fives or fours. If we're getting threes, twos and ones, we've not facilitated it well, or the meeting didn't achieve its agenda and things like that. think a lot of the statistics around facilitation that have come out recently, and you and I were talking about these briefly before we started that the average at the Microsoft trend index shows us that average time spent in meetings by employees at the moment is 21 and a half hours a week, which is an increase, I know, an increase of 252 % since the pre-pandemic. So. Brian Milner (03:36) That's incredible. Yeah, I mean, that's more than half of a work week, right? I mean, we're spending more than half our work week in just locked in meetings. So you're right. We had this conversation beforehand and you were telling me that stat and it just kind of floored me that we're spending that much time in meetings. But it was the next one you told me that really floored me. And it's a combination of these two, I think, that people need to really grasp onto. So tell them what you told me next. Kate Megaw (03:49) Mm hmm. Yep. Yep. Yeah. So the next one is that the Harvard Business Review indicates their research, 67 % of meetings are considered by executives to be failures. So if we look at the financial impact of that, and this is something I didn't share with you, but the financial impact of that is for a company, imagine you have a company with 100 employees, unproductive meetings are wasting upward of $1.7 million a year. If you have a thousand employees, increase that number. it's one of these things that it is not difficult to do. It is just understanding why we need someone in the facilitator role. And the basics around the basic facilitation, the basic getting ready for the meeting, facilitating during the meeting and properly closing the meeting. takes those unsuccessful numbers up to successful numbers where you're getting those fives and people are sort of, yep, that meeting totally achieved the purpose and the outcome and it finished early. So I've got 20 minutes back before my next meeting. Brian Milner (05:24) Yeah, it's so incredible that combination of those two stats. I thinking that we're spending over half our time in meetings and that 67 % of them are failures, we're having a lot of them and we're not doing them well, clearly. Kate Megaw (05:36) Absolutely. I think with, I don't know with Zoom, well, I think with Zoom, it's got easier to have meetings. So we're probably having meetings where we don't need to have meetings. That's one of my favorite things to ask is, does this need to be a meeting? Or are you just going to talk at me and roll data out? In which case, send it to me in email. Don't tie me up for a meeting. Brian Milner (05:44) Yep. Kate Megaw (06:02) Because so many meetings are a waste of time that a lot of people are spending meetings multitasking. So we're taking an hour for a meeting that we could do in 25 minutes if people were 100 % engaged and following the agenda and things like that. Brian Milner (06:22) Yeah, yeah, that's so fascinating. it seems like such a, it's hard to believe that there's not more of that skill in just basic business training, right? Because if we're having all those meetings, then it would seem natural that there would be more segments that would say, you know, a little facilitation skill for, you know, a, you know, bachelor's in business, you know, like that might be a little helpful, right? Kate Megaw (06:41) Yep. Mm-hmm. Yeah, absolutely. And it's a small investment for something that will make a huge difference. I mean, one of the things Anu and I have been working on is the mnemonic of ready, reach, and wrap in order to make sure we have effective meetings. And the ready part of it is setting the foundation. So before you even get to your meeting, this is ahead of time. You're understanding, okay, what are the Rs? What are the roles and responsibilities? So if I'm facilitating, then who are the decision makers? Who is mandatory? Who's required to be there? Who are the, you can come if you want. Let's stop doing meetings to 30 people and expecting 30 people to show up. So we've got to understand the roles and responsibilities. The other, the E for the ready is expectations and engagement. Brian Milner (07:29) Ha ha ha. Kate Megaw (07:41) So if the expectations are that this is an interactive meeting, we're using Lucid or Mural or Mira, whatever tool we're using, it's going to be collaborative, webcams are going to be on, multitasking is going to be at a minimum, everyone knows going into that meeting what the expectations are. And then the A again is the agenda and the alignment. The agenda should be very clearly saying these are the items that the D is making sure where we have defined the purpose and the outcome. So every meeting, we need to know what the purpose of the meeting is, what the outcome of the meeting is, and they should be included in the agenda. We shouldn't be accepting meetings. Imagine the power