TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Technology

    Agile Mentors Podcast from Mountain Goat Software

    Mountain Goat Software’s Agile Mentors Podcast is for agilists of all levels. Whether you’re new to agile and Scrum or have years of experience, listen in to find answers to your questions and new ways to succeed with agile.

    Advertise

    Copyright: © 2023 Mountain Goat Software

    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    #167: Running Better Remote Meetings with Evan Unger Nov 19, 2025
    Show notes

    Consultant and collaboration expert Evan Unger joins Brian to share practical tactics for leading more engaging, effective meetings that actually get results (and don’t drain everyone’s will to live).

    Overview

    In this episode of the Agile Mentors Podcast, Brian Milner welcomes longtime consultant and facilitation expert Evan Unger to dig into one of the most persistent workplace headaches: remote meetings.

    With decades of experience helping leaders shift from “presenting at” to true collaboration, Evan shares how a simple POPRA framework can change the game, why simultaneous chat might be your new secret weapon, and what leaders get wrong when they step into the (virtual) room. From deprogramming the HIPPO effect to humanizing remote collaboration, this conversation is packed with real talk, useful tools, and just enough snark to make you want to fire up your next Zoom meeting with purpose.

    References and resources mentioned in the show:

    Evan Unger
    Collaborative Leadership: A Virtual Immersion™ Program
    #138: The Bad Meeting Hangover with Julie Chickering
    #142: Communication Patterns Keeping Your Team Stuck with Marsha Acker
    Agile Skills Video Library Use code PODCASTSKILLS for $10 off
    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.

    Evan Unger is a collaboration expert and consultant who’s spent over three decades helping leaders turn messy meetings into meaningful progress—even in a post-pandemic, Zoom-fatigued world. As managing partner at Schwartz + Associates, he now trains leaders in the art of virtual facilitation and high-stakes collaboration, so teams can stop surviving meetings and start making decisions that actually stick.


    #166: AI Isn’t Coming for Your Job, But It Is Joining Your Team with Dr. Michael Housman Nov 12, 2025
    Show notes

    AI is already changing how we work—and how we work together. In this episode, Dr. Michael Housman joins Brian Milner to explore how AI is reshaping team collaboration, decision-making, and the very structure of Agile teams.

    Overview

    We keep talking about AI like it’s something that’s coming. But as Dr. Michael Housman points out, it’s already here—embedded in our tools, shaping how we collaborate, and quietly shifting the makeup of our teams.

    In this episode, Brian sits down with Dr. Housman, CTO, keynote speaker, and author of the upcoming Future Proof: Transform Your Business with AI or Get Left Behind, to talk about what AI is already doing in Agile environments. From how it’s helping Scrum Masters level up decision-making to how it might literally join your org chart, they dig into what’s helpful, what’s hype, and what leaders need to pay attention to right now.

    References and resources mentioned in the show:

    Dr. Michael Housman
    #82: The Intersection of AI and Agile with Emilia Breton
    #99: AI & Agile Learning with Hunter Hillegas
    #151: What AI Is Really Delivering (and What It’s Not) with Evan Leybourn & Christopher Morales
    #165: Can Your Product Process Keep Up With AI with Cort Sharp
    Agile Skills Library use code PODCASTSKILLS for $10 off
    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.

    Dr. Michael Housman is the author of Future Proof: Transform Your Business with AI (or Get Left Behind) and the founder and CEO of AI-ccelerator where he helps organizations leverage advances in artificial intelligence. He is a seasoned technologist with over 15 years of experience architecting AI platforms in sectors ranging from hiring and fraud detection to customer communication and real estate lending. His research has been published in a variety of peer-reviewed journals and profiled by such media outlets as The New York Times, Wall Street Journal, The Economist, and The Atlantic. Dr. Housman received his A.M. and Ph.D. in Applied Economics and Managerial Science from The Wharton School of the University of Pennsylvania and his A.B. from Harvard University.


    #165: Can Your Product Process Keep Up With AI with Cort Sharp Nov 05, 2025
    Show notes

    If AI is speeding up how fast we can ship, what’s slowing teams down now? Brian and returning guest Cort Sharp dig into the emerging friction between AI-assisted development and the still-slow art of product decision-making. Overview With AI accelerating software delivery, it’s no longer the developers dragging their feet. It’s the backlog that’s backing everything up. In this episode, Brian and Cort tackle the big shift: as coding becomes faster and easier, the real challenge becomes knowing what to build, why, and whether it’s worth it. They talk about feature bloat, the myth of productivity, the “good enough” curve, and why product owners are quietly becoming the most critical role on agile teams. Plus: short sprints, fake one-day sprints, and a healthy dose of “what even is a Sprint, anyway?” If you're feeling the tension between building faster and deciding smarter, this convo’s got your name on it. References and resources mentioned in the show: Cort Sharp#104: Mastering Product Ownership with Mike Cohn#3: What Makes a Great Product Owner? With Lance Dacy#164: Why Innovation Efforts Fall Flat with Tendayi VikiGet the Agile Skills Video Library Use code PODCASTSKILLS for $10 offSubscribe 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. 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 back Agile Mentors. We're here for another episode of the Agile Mentors Podcast. I'm with you here as always, Brian Milner. And today I have back the one and only Cort Sharp with us. Welcome back Cort. Cort Sharp (00:11)Hey Brian, thanks for having me. Brian Milner (00:13)Yeah. Cort and I were chatting just in between engagements and things we were talking about going on. Cort's coaching a lot recently, and I've been coaching a lot recently as well. And so we've been kind of sharing stories and talking about kind of some of the things we've been experiencing. And you came across something really interesting recently that I thought we talked about might make a good topic. help us out. What was that that you came across? Cort Sharp (00:42)Yeah, so I've seen this idea pop up a few times actually on LinkedIn specifically, but I've seen it trickle out into other areas within the coaching that I've been doing recently, but also just in other pieces or parts of the internet as well. And it's this idea of like with AI being brought into organizations, brought into companies, helping out developers so much that AI has actually lowered that barrier. for the programming side of stuff, programming side of the development side of things, that the new blocker that is currently emerging, so the new piece that's been slowing everyone down now is actually the product management side of stuff itself, which I thought was just so fascinating because I've done a little programming, definitely more in the product management side of things now, but I kept seeing this pop up and I was like, man. I would love to just hear, you know, Brian's thoughts about this and the community as a whole, everyone's thoughts about this a little bit here too, but I have my own thoughts, but just quick little immediate reaction to that idea there, Brian. How does that make you feel? What do you think of that? Brian Milner (01:51)Yeah, I actually have been thinking this was coming for a while. I don't have this prepared, so please don't get me wrong in this. I know I always say data didn't happen. But there are three studies that I found at one point that were trying to determine the number of features in just your average software project that were rarely or never used. And it was three separate studies spread out over years. And one of them was like 48%. That was the low one, was like 48%. Then there was a middle one that was 64. And then there was another one that was more recent that said like 80%. And I mean, think about that, know, like I, even if you take the low end, And so, you know, 48, let's just round it up to 50 just to make it easier to have the conversation. But let's just say out of those three studies, we say it's 50 % of features that people are building are things that people rarely or never use. Now I get it that there are some rarely used features that are essential, right? Like admin functions and things. You may not use those all the time or it may not be a huge swath of users. that uses that, but you have to have them. So set those aside because that's not 50 % of what's being developed, right? And I think if that's true, if we even like go on the low end of that and say that it's closer to 50%, then that's an awful lot of productivity that's being lost. Not to mention just money and energy and effort. of developers to build stuff that no one cares about. Those studies were all prior to AI. So let that sink in, right? If those are prior to AI and we were seeing at the low end, 50%, you know, across those surveys of things that no one was using. Well, that's where I've been kind of forecasting this to say, if, if AI is speeding up our process to build things. the actual development of things, then what's going to become painfully obvious very quickly is that the bottleneck isn't developers. And it, you know, my point from saying that in classes is to say it's never been right. It's not been developers that have been the bottleneck to us being more successful. That's where the focus has been. But I don't think that was correct. And I think that the correct area to put it on is the product side. And if that's true, right, I know I'm doing a lot of leaps here, but if that's true, if it is the product side, well, I think that what that really translates to is the discipline of product management, of being able to recognize what's valuable. Cort Sharp (04:50)Mm-hmm. Brian Milner (04:54)to your customers to deliver that, to close the loop and verify that that's actually what was needed and to measure the impact of those things, that discipline, I think, becomes just all the more essential because that stat tells me there's a lot of bad product management going on. So that's my initial thought. That's a lot of thoughts, but that's my initial thought when you said that. What about you? What do you think about that? Cort Sharp (05:19)right there. I'll share my thoughts, but I do want to harp on or just go back to your first initial one of the callback to those studies there. When you first threw out those, because I've seen similar studies where it was about 50 % was kind of it. I haven't seen those studies that say like, know, what was the last one you threw out there on the high end, like 80 something percent. ⁓ Brian Milner (05:39)Yeah, actually I remember, so I remember two of them. The 64 % one was from a group called the Standish group. There's been some question about their methodology in that one. I haven't seen the methodology of the 80 % one, but it was a group called Pindo that did that one. And I don't remember the 48 % one. that's just off top of my head. Cort Sharp (06:01)Sure. But that 80 % one though, that one sticks out to me because as you were going through it, I was like, okay, well, I have Google Docs open right here just for some show notes or something. Just make sure I ask the questions that I'm supposed to ask or I want to ask. And I thought, wow, I'm looking at the menu bar right here. I use maybe, two or three of these consistently. And there's like 15 options up here. yeah, I could absolutely see a large majority of features that a product has that go widely unused by the vast majority of its users. And I think that poses the question then is, do we wanna go down the path of having one product be really good for, or like, really good at one thing and then kind of OK at everything else. The thing that always comes to my mind in this, and I've been going down this rabbit hole of kind of digital minimalism, is like the cell phone, right? Where it's a really great communication device. OK camera, kind of OK video, kind of OK speaker if you want to use it once in a while. It's kind of OK at browsing the web or doing some other things on there. Brian Milner (07:05)Yeah. Cort Sharp (07:21)Is it worth making those products that have an okay aspect to it on these other things that, you know, some people like to use, but not everyone will use all the time type deal thing, which is a totally different discussion here. But that's kind of where my memory went of like, okay, that 80 % plus isn't actually all that surprising to me. I would, I would probably throw out there, you know, for the vast majority of programs that I use, baby, aside from my banking. Brian Milner (07:35)Right. Cort Sharp (07:48)my banking apps, you know, I don't use, I probably only use 10 to 15%, maybe 20 % of the total features in there. and I, it is such a interesting point to the productivity side of stuff of, okay, are we just being productive for the sake of being productive? is it actually being productive? Are we just working for the sake of working? so yeah, just harping on that a little bit. Brian Milner (07:50)right. Yeah, yeah, I mean, I agree. And I kind of have a similar response. And I think that there's, you know, the good enough argument, right? ⁓ Sometimes people take exception to that and say, well, why would we be okay with only doing something good enough? Well, it's not about quality, right? It's not saying that the quality of what you do is good enough, but it's saying that the... Cort Sharp (08:22)Mm-hmm. Brian Milner (08:41)the amount of functionality is good enough. And I think your example of the cell phone is a great one because, know, I'm old enough that I remember before, you know, that was the main way that people took pictures. You know, when you had the little flip phones and stuff, the quality in those were not very good. And so you would have other digital cameras that would took higher quality photos. But the reason that it won out in you started to just see more and more pictures taken from a phone, even though they were lower quality, was because you always had your phone with you. And so there's sort of an extent to which you would say, how badly do I want to carry around an extra device that's just for taking pictures, even though it takes better quality pictures, is the quality that I'm getting with the phone good enough and there was a tipping point there, right? There was a certain point where it went out and the quality of what was on the phone was high enough that people said, yeah, I don't need a separate digital camera anymore. This is good enough for what I need and that one. And I think that that value curve is very similar across any product. There's a certain level. that when you add features, it's a steep value curve. But after you've added those key core things, then it starts to tail off. It starts to flatten. that flatten, it may still be going up, right? But the effort that it takes to deliver something is not the same return on that investment of effort, right? Early on, it's a huge, you that effort creates a spike in value. Later on, that effort creates a small little spike in value. At a certain point, that's where they talk about trimming the tail. At a certain point, that's what they mean by it is that value curve has gone past that point where now it's flattened and we're incrementally adding small little things, but they're not valuable enough to justify the effort that it's taking to build them. Now, will AI change that? I don't know, right? Because if we have a bank of AI programmers, I don't know that it actually changes it because we still could have that bank of AI programmers doing something else instead, you know? ⁓ Cort Sharp (10:48)Hmm. Right? Right? So it's figuring out that value proposition side of stuff. Yeah. Yeah. Brian Milner (11:05)Right, right. The impact, actual, you know, how much do people care about this being there? And, and at a certain point, you know, we had a podcast recently where we talked about this, just at a certain point, there's a, an end of life, right? At a certain point, you have to deliberately say no to something and say, you know what? This product has done all it's going to do and we'll support people that still use it up to a certain point. But at a certain point you say, no, it's better to have a new product now, where that value curve now starts to get really big again. So yeah, I mean, from an AI standpoint, I think it does make an impact because it kind of just makes it more apparent where that problem is. ⁓ And that's why I think I tell all the product owners that come through classes, I think product owners are poised to become highly impactful. Cort Sharp (11:46)Mm-hmm. Mm-hmm. Brian Milner (12:00)in their organizations in this AI era. Because if you can refine your craft to a level to where the things that you are producing are all a lot of value, right? All creating a lot of value, then now we have the productivity to spit out more and more of that stuff. And if your side of it's taken care of as well, then everything that we're producing is now producing a lot of value. Cort Sharp (12:29)Right. Right. I think it opens the door for programmers, developers. I'm not just going to say programmers because I know AI can help out in every aspect of the development process. But I think it opens the door to developers, not only just being more productive, but also just being able to experiment with new things more, more readily, more easily. Right. And we can, we can kind of simulate some of what our customers might want. Right. If we can build a really great persona. I know you've done this in a class recently, Brian. I'm doing a similar thing and just saying, look, let's build out this persona using an AI tool that we can use and create basically an AI agent and say, here you go. This is my ideal customer. Here's my product. What pieces or new features of my products can I focus on in order to deliver higher value to this customer? which is exactly what a product owner does. So I totally agree with you there, Brian of saying, yeah, the role of the product owner is about to become one of the most valuable roles, in an organization, in, in understanding. How do we deliver value to our customers? What do our customers even want? Right. Starting there. If you can build all the cool things you want, if your customers don't use it, who cares? Right. So many examples of that, what I called out earlier, but so many examples of that of like, if you build stuff just for the sake of building stuff, is it wort…

    Full show notes at the publisher

    #164: Why Innovation Efforts Fall Flat with Tendayi Viki Oct 29, 2025
    Show notes

    Tendayi Viki joins Brian to unpack the difference between doing innovation and delivering value, with practical takeaways for product folks, innovation teams, and anyone who wants to stop spinning their wheels. Overview Innovation theater. Experimentation theater. Value that never quite materializes. In this episode, Brian Milner sits down with Tendayi Viki—author, strategist, and partner at Strategyzer—to talk about why so many organizations look like they’re innovating… but aren’t. Together, they dig into what real innovation looks like (and how to measure it), how to escape the trap of cool ideas with no customer value, and why experiments only matter if they lead to decisions. You’ll also learn how to spot the difference between a small bet and a large leap, and what it actually means to “be a pirate in the navy.” References and resources mentioned in the show: Tendayi VikiTendayi’s BooksGet the Agile Skills Video Library Use code PODCASTSKILLS for $10 offSubscribe 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. Tendayi Viki is a globally recognized innovation strategist, author, and partner at Strategyzer, where he helps large organizations build real value—not just innovation theater. With a PhD in Psychology and a client list that spans Unilever to The British Museum, Tendayi brings deep insight into the human side of transformation, backed by frameworks that actually work. Auto-generated Transcript: Brian Milner (00:00)Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner. And today I'm very, very excited. I have Mr. Tendayi Vicki with us. Tendayi, welcome in. Tendayi Viki (00:13)Thank you. It's a pleasure to be here. Brian Milner (00:15)Very, very excited to have him here. Just to give you some background, if you're not familiar with his work, very prolific and very deep thinker here. He's a partner at a company called Strategizer, where he helps large companies innovate like startups. He's a regular contributor on Forbes, so you may have read some of his articles on Forbes. He's the author of three books, The Corporate Startup, Pirates in the Navy and the Lean Product Lifecycle. Pirates in the Navy is his latest one. Pirates in the Navy, correct me if I'm wrong, it's kind of about how to infiltrate via innovative presence in a large corporation. Is that correct? Tendayi Viki (00:55)Yeah, exactly. Yeah, how to be a pirate in the Navy. Brian Milner (00:58)I love it. I love the title. ⁓ But his books are really practical. They're on building innovation ecosystems that actually work. He's advised some big companies like Unilever, Amex, and Lutanza. He's been named to Thinker's 50 radar list for his influence and innovation and strategy. But his passion is really helping teams avoid Tendayi Viki (00:59)that. Brian Milner (01:22)what do you terms as innovation theater and focus on creating real sustainable value. So I thought maybe that's a good place to just start to kick off a conversation and say, Tendayi, talk to us about innovation theater. What does that look like to you? How would you define that? What does that mean? Tendayi Viki (01:41)Yeah, it's fascinating. It's a term that's kind of simultaneously coined by Rita McGrath. Steve Blank has used it a few times, and so has Alex Osterwalder. And it's really about... So the thing about the startup world is that the startup world is kind of a coolness factor. So everybody wants to be cool. And then the toolbox that startups use in that cool design thinking, deep school vibe of like sticky notes and... design and prototyping and all that. So everybody wants to do all of those things. I've even watched teams actually engage in agile rituals. Like they do the daily stand up, they do the demo day, they do the retro, right? But when you really look at the, when you dive deep into the focus, it doesn't seem to be a lot of value creation. So you're like, you're doing a... a retrospective as an agile team and you're not talking about what you learned from customers. You didn't do that during that week's sprint. yeah, you can do all the rituals, but if you don't understand the reason the rituals exist, then it's easy for you to kind of just spin and not create any value. And that's innovation theory. Brian Milner (02:42)Yeah. Yeah. man, I am with you a million percent on that and completely agree. These structures are there to help kind of be a pathway to that, but not the end result. If you don't understand, just like you said, if you don't understand the reason behind it, the why, then yeah, you could go through all the motions. And I completely get that term, It's kind of theater. It looks like it's actually happening, but it's not really happening. The culture underneath it is not really there. ⁓ So that brings the million dollar question then, right? If these structures like we do, like standups and everything else, aren't going to automatically generate that kind of innovation and it's more of a culture thing, Tendayi Viki (03:28)Exactly. Mm-hmm. Brian Milner (03:44)How do you then build a culture that is placing innovation as a priority? Tendayi Viki (03:53)So yeah, so just to answer your question, think one of the things that's really interesting about the way to create value is you have to authentically care about value creation first. You really have to understand this notion that innovation is this combination of really, really cool ideas, right? Together with a deep understanding of customers and their needs, and then a deep understanding of how to... use a business model that works to deliver that value to customers so you can get value back. Once you complete the entirety of that cycle, we say you're a successful innovator. If you complete the ideas or tech portion of that cycle, you're just an inventor or the ideas guy or whatever people call themselves, right? And so I find that companies excessively focus on ideas too much. And so too much focus on ideation and not enough focus on putting ideas on a journey towards value creation and actually value realization for the organization. So if you're going to build a culture for innovation, you have to understand what you're building it for. You to go, all right, we have to deliberately design our workflows and the way we interact with each other to discover what customers we need. Then we have to design the workflows to bring those customer needs into life through products. Then we have to test whether those products are really delivering that value. And then we have to figure out a way to scale that value and give value back to the moment of vision. you go, okay, that's the job. Now let's design the process, the culture, the toolbox, the artifacts, the rituals that allow us to actually do that. And I think that kind of understanding is probably more fundamental than anything else. Brian Milner (05:32)Yeah, absolutely agree. It's the structure for discovery, right? I mean, it's not the discovery. It's the structure that led you to the discovery that has to be repeatable that then can generate future discoveries. It's not how you found the island in the middle of the ocean. Or it's not the island you found in the middle of the ocean. It's how you found it. ⁓ that would lead you to find another one you know. ⁓ Tendayi Viki (05:55)Exactly. And that's the fundamental question is, can you find another island? Because again, innovation teams stumble a lot on good ideas. And so you can bumble into something good and then fail to do it again because you don't have a repeatable process. Brian Milner (06:01)Yeah. Yeah. So let's dive into that a little bit. mean, whether you're a startup or whether you're a bigger organization and you're working on a product in a bigger organization, I know that you can often feel like you're kind of, I was talking to someone this week about this, you kind of feel like you're drowning in a sea of opportunity. There's all these things that we could do and it's sometimes hard to find, well, which ones do we really Tendayi Viki (06:32)Mmm. Brian Milner (06:42)double down on which ones we invest in and really pour our time and energy and efforts into. So how do you talk about that in your book? How do you find the things that are worth really investing in? Tendayi Viki (06:54)Yeah. So I mean, mean, there's two ways, right? The one is the first one is a kind of like an art thing. It can be fed by data, but it's art and that's finding the direction of travel. So that's a strategy choice. We go, we think that an AI is big thing these days. We think that AI is going to do these various things to our business model. And that's really important, by the way, like when you think about AI. And Sharjee, Alex also has got one of my favorite all-time phrases, is AI changes everything and AI changes nothing. The fundamentals for business are still the same, even though the stuff that you can do is exponentially different. So you have to think which elements of the business model do we want to play with around here strategically. Brian Milner (07:26)Yeah. Yeah. Tendayi Viki (07:41)And then once you pick a direction of travel, now you've got multiple options of different product ideas, services, business model, value propositions, offerings, technology, stacks, et cetera, et cetera. Once you get to that point, you then cannot pick the winning idea on day one yourself. You have to stop building a systematic process of discovery. so you may be, and we, so we often say when you're at that stage, make multiple small bets, right? OK, and I like the way you phrased the question, by the way, because you said, how do you choose what to double down on? That's what you said. You said double down, right? Well, you don't double down on something unless you've made an initial small bet. You double down after an initial bet. Doubling down is I've made a bet, now I'm doubling down. But what companies do is they just make a large bet, and they call it doubling down. But it's not really doubling down. You've just made a large bet. Brian Milner (08:18)Yeah. Yeah. Hmm. Tendayi Viki (08:38)Right? Doubling down is a follow on bet after an initial bet. And so it means that the first bet is a punt. It's a, see what happens bet. And then the question is, what do you want to see? So somebody just wants to see size of market. Somebody who's wanting to see a real customer with a real need. Somebody who just wants to see a real customer with a real need plus an internal capability to create value. So they'll say, if I give you my 50K, you have to answer both these questions before I double down. And some of these will say you have to answer only one of these questions before I double down. And then so I'll give you less, I'll give you 20K. So that's how you start building these frameworks, right? You start going like the one we built at Pearson, right? You go, ideas, it's ideation, it's strategic thinking. We don't invest any money. That's free. But when you start going into discovery, we might give you 25,000 pounds and you earn the next level of bet by the data you bring using that 25,000. And we have a list of questions that we need positive answers to before we actually make the doubling down. And so that's a way of curating ideas based on evidence and some kind of action and activity. Brian Milner (09:48)Yeah, it's amazing to me, like in some of the companies I work with, it's amazing to me to see how many times people will choose bets that they're going to make, but not really even be able to articulate what it is they hope that bet will actually do. Right? Not just, you know, like we have this feature that we're betting on and we think if we add this feature that it's going to, you know, be cool. It's gonna, you know, people will love it that will add this feature, but they don't go the extra step of being able to articulate, yeah, but what does that mean? Does it mean that you're gonna increase your return on investment? it gonna increase your customer satisfaction? So that kind of gets to the heart of how do you measure whether it's actually a successful bet or not? Tendayi Viki (10:39)Yeah, exactly. mean, to go way back in the days, to Dave McClure and the pirate metrics. I'm sure you were like, R, right? It's like if we do acquisition, activation, revenue retention, referral, whatever those R's are, you could add a few others that you want. So those are metrics. Why would we ever build a feature that's not connected to any one of those goals? Like, what's the point? Brian Milner (10:58)Yeah. Yeah. Tendayi Viki (11:07)Right. A measure of satisfaction is referrals, maybe. A measure of customer satisfaction is retention, maybe. You could measure customer satisfaction with your NPS scoring or whatever, right? Like, if you have all those things laid out, then you go, right now we're working on this thing because we believe that it's going to increase our ability to acquire customers. by how much? Possibly by 5%. OK, now we have a benchmark. Then we have a way to start testing whether the things we're building are actually Brian Milner (11:17)Yeah. Tendayi Viki (11:33)actually creating value. I don't think that there should ever be a wouldn't it be cool if conversation. Maybe at the beginning, but later. Brian Milner (11:39)⁓ Yeah, businesses don't... Right. That's not really a great model to build a business on, right? It's just, I think it would be cool. Tendayi Viki (11:48)Yeah, it was crazy. I was once working in the large organization and they had disparate products on different platforms. So they had this thing where they were going to put it all as like one on one website, one platform, one product layout. And for them, it was in the backstage of the business, was value creation because it lowers costs and puts everything in an easy to manage place. But then I was like, have you guys ever considered that you could potentially destroy value by putting everything, like you could essentially like make it worth for customers. Like it's not automatic, but just because you've now put everything on this one thing, they even called it the one strategy, whatever. But then because you put it all in this one thing, that is automatically value for customers. So who's in charge of checking for that? Because it's distinctly possible that you've just made things worse. You're going to see a drop off in customers and you're to see a drop in revenue. So that's really something to always be thinking about, right? Brian Milner (12:21)Yeah. Yeah. Yeah. Yeah, or kind of parallel to that would be if we wanted to add s…

    Full show notes at the publisher

    #163: Should We Go Back to the Office? It Depends. with Lance Dacy Oct 22, 2025
    Show notes

    Five years post-COVID, are we any closer to knowing what kind of work environment actually works best? Brian and Lance dig into the real drivers behind return-to-office mandates, remote productivity myths, and why "context beats location" every time. Overview The return-to-office debate isn’t over—it’s evolving. In this episode, Brian Milner welcomes back frequent guest and fellow Agile coach Lance Dacy for a wide-ranging conversation about remote work, in-office mandates, and the big question: what actually boosts team performance? Together, they explore what we’ve learned (and what we haven’t) in the five years since COVID reshaped the way we work. With studies offering conflicting conclusions and executives often leading with personal preference, Brian and Lance unpack how leaders can navigate decisions that impact morale, productivity, and long-term value delivery. From context-driven collaboration to psychological safety, this is a nuanced take on one of Agile’s most pressing modern challenges. References and resources mentioned in the show: Lance DacyExcerpt from A Leader's Guide to Agile eBookScrum, Remote Teams, & Success: Five Ways to Have All Three by Brian Milner#61: The Complex Factors in The Office Vs. Remote Debate with Scott DunnUsing a Task Board with One Remote Team MemberSubscribe 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. 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. Auto-generated Transcript: Brian Milner (00:00)Welcome in Agile Mentors. We are back. Thank you for bearing with us for a little bit of a break there. If you notice, we have not been releasing episodes the past few weeks because we've been practicing sustainable pace, but we are back and we are ready to dive into some really, really gritty topics, some things that we think will be really beneficial. Who better to kick us back off to bring us back around than a friend of the show, Lance Dacey, who is with us today. Welcome in, Lance. Lance Dacy (00:25)Right now. Thank you, Brian. How was Hawaii, that big sabbatical y'all took in July? Brian Milner (00:34)Yeah, Hawaii is always great, right? Hawaii is awesome. Absolutely. Isn't that what everyone did in July? ⁓ Well, we're glad to be back and we're excited about what we're going to talk about today because we figured why start with something that was not controversial? Why not find something very controversial? Lance Dacy (00:36)My tie's on the beach. That's where you over. I mean, I didn't see y'all there, but yeah. Brian Milner (00:58)and just set ourselves up to receive lots of disgruntled emails that we're probably going to get this wrong. We're probably going to get awesome feedback too. But I'll just go ahead and start by saying, hey, we hope you give us a little grace on this topic. We're just talking from our experience, our opinions. And I know there's lots of opinions on this, but we wanted to focus on the fact that Lance Dacy (01:06)No, awesome feedback, Brian. Awesome feedback. We're going to get awesome feedback. Brian Milner (01:25)Hey, we're five years removed from the COVID outbreak. And when COVID happened, that was a massive disruption in work. We all had to learn how to do work in a different way, but five years in, what have we learned? What's changed? And now we're seeing lots of things like return to office mandates and hybrid working agreements. You must be here for this many days a week or other things. Lance Dacy (01:44)and Brian Milner (01:50)or companies that say, no, we're now fully remote and we're doing things this way. But I saw this kind really interesting question that made me think about this. If you were designing the workplace from scratch today, would anyone build cubicles? And I thought, well, that's a really interesting question. So Lance, what do you think we've learned in the last five years? Where do think we are today with this whole work from home versus return to office? Lance Dacy (02:16)I tell you what, Brian, I sit there and think, man, five years is a long time to have empirical data. And I don't believe we have data. Let me say it this way. We got the data. What does it mean? You know, so and I'm a data guy. You all know that. And I'm sitting there trying to look at it going, I don't know how much we've learned. think what we've learned is there's no right answer. Brian Milner (02:22)Yeah. Yeah. Lance Dacy (02:39)And everybody's, especially organizations, we're looking for the right answer. Just give me the answer and let's go for it. You and I, coach and consult and people hire us to tell them sometimes what they need to do. And sometimes we're like, no, we're not going to tell you what to do. We're going to learn what the issues are. And then based on that, what should we go from? And I find, you know, if I had to sum up what we've learned, remote can be great, right? Office can be great. neither is a silver bullet. That's what I want. So I'm going to go back to my coaching stance and say, well, let's define the outcome, measure with a multi-focus, multi-factor, multi-dimensional metrics of what we're trying to actually accomplish with our people, experiment, and then keep an eye on the team health. I still feel like that's what we're doing. Five years sounds ridiculous that we haven't figured that out. But I think it was so disruptive that five years isn't enough. And I think the work on top of that is changing so radically. have too many variables up in the air. So for now, if I had to make a decision, I lean toward co-location. When the work is ambiguous, when relationships are important or new, that's another one. If we've got a lot of new people together, working remote is going to be a very difficult thing for a while. So, you know, I'd say, hey, if I'm starting a company and the work is ambiguous, you know, kind like a software product company, the work we're not quite sure what we're doing and needs a lot of collaboration and and a lot of hands on, you know, trust with each other, then I'm probably going to say, let's let's be in the same area sometime. You know, I'm not saying every single day, but. That's how I'm gonna lean towards. And then I'm gonna say if your work is predictable, repeatable, doesn't require a lot of that, and you need intense focus, well then maybe remote is fine for you. So how's that for an answer? I don't know. Brian Milner (04:32)No, think that's a look. I don't think there's ever I don't think you're ever worse off by by being able to admit that right to just say, you know what? I don't know. And I think sometimes that's part of the problem with the way that we approach certain issues is that people are reluctant to say that right. They're reluctant to just admit, you know what? I don't really know. I don't really have the answer on this yet. And I think you're hitting on something that's really important is that there is Lance Dacy (04:39)Right. Brian Milner (04:59)You said no silver bullet. I also think there's no one right answer. I don't think that there is a right answer to this question of should you be in the office or should you be remote? think, right. Lance Dacy (05:12)confidence interval, right? I mean, it's like, there's no, it's not it's not binary. So I agree with you. Brian Milner (05:16)Right. Yeah, there are certain industries, certain products, certain job types that I think are better in the office. And there are others that I think are better remote. And I think what you got to do, and I think I love your return to kind of a coaching stance and looking at this. What's the goal? And I think that's what you have to try to distill it down to is what's the purpose? What's the goal we're trying to reach here? If it's productivity, then let's talk about productivity. If it's morale, if it's enhancing communication, it starts from there. Define what it is that we want as our end goal, and then we can start to find data. We can start to find empirical evidence that either supports or detracts from whatever hypothesis we think we have about this. And that should be what leads us. Lance Dacy (06:10)And it could change, you know, that's the other problem. One quarter, it may be better the stuff we're working on. We're in the office more often. The next quarter, maybe we agree too much. Now, the problem is you go survey people. Let's talk about productivity. You ask, let's say a programmer. Okay, I'm just going to say garden variety programmer, highly skilled. You ask them where they are most productive and most of them, I'm not going to indict everybody, most of them will say, Brian Milner (06:22)Yep. Yes, let's do it. Lance Dacy (06:39)I want to be left alone, no meanings, in silence, coding on my keyboard. They may be going a direction completely opposite of where we need to go, and we won't know that until they come together. And so the other problem with this is we're asking sometimes the wrong question with the wrong people. You ask a single programmer where they're more productive. It's sitting in my office being able to go get a coffee when I want, not sitting in traffic. Hey, I'm all for that. Who's productive in traffic other than, I'm listening to books, you know, so I am growing myself. But nobody, I'd be hard pressed to find anybody saying I love sitting in traffic. So let's put that to the side. Nobody wants to drive two hours a day to their office and back home. That's terrible. But if you ask a programmer that, would you concur that most of them would say, I'm most productive, just leave me alone. Let me write all the code I want. Brian Milner (07:16)You Lance Dacy (07:30)What do you think of that? So now that's the wrong question then, because now we're working in an agile type, let's say in an agile context, where we're working in an empirical nature, which says we don't know what we're doing. So the more iterative and incremental feedback, the better we understand, are we on the right path or not? Brian Milner (07:33)I think that's probably true. I think most developers would say that, yeah. Lance Dacy (07:52)And so if I was to say, it more productive to let the individuals be efficient at what they're doing and then come together later to learn that we got a big gap where we were from? Or do we sacrifice individual productivity with a lot of collaboration, which they may term as meetings? I don't like to call them meetings, they're working sessions, right? We had a backlog discussion about this, I believe, you not long ago. Backlog refinement is not a meeting. It's a working session to say, hey, customer needs this. How are we going to do it? You know, and What is it that they need? So I find, I'm debating with people on LinkedIn a lot, I love this, so this is why it's top of mind, is even if the customer knows 100 % of what they want, which let's just say they won't, but if they did, you do not know how to build it. One programmer may, but when you got four programmers, some testers, some database people, architect, all these cross-functional skills, how can you sit in a vacuum and do that? So if your work... requires multiple skills to come together and you're trying to build a done increment by the end of one, two, three or four weeks, having an individual productivity to me could be harmful. you look, I told this guy on LinkedIn that I don't believe productivity is one dimensional. So he referenced a Stanford, let's see, this was in 2023, that he was saying that, you know, the Stanford study showed that people were more productive working at home. Well, it was actually a 10 % decline for call center staff, by the way. So that work is not as collaborative, I would say, maybe. That same study, though, found 35 % lower attrition, higher employee satisfaction, which raised the long run throughput. So while they declined in productivity at home 10%, most executives would go, no, I got to come to the office. We can't have that. But what if I told you, you say 35 % on whatever the number is, attrition and employee satisfaction in the long run, would you rather take that gamble or not? know, Gallup did the same thing. He was referencing a state of workplace and they find, you know, customer loyalty and margin was better for people that were in the office. They may be less productive individually, but the customers saw a better outcome. So what are we measuring, right? So Brian, that's what I look at. with these productivity debates, I'm like, my gosh, what does productivity mean? Are we optimizing for delivery to the customer flow, or are we optimizing for the individual utilization of the people on the teams? And I think executives have to make a choice. And I say executives, because they're the ones who influence heavily, whether we, I'll talk about culture in a second. But I find that, If people steer towards individual productivity, we might be sub-optimizing, right? We know this. mean, we know flow and systems thinking and, you know, all the things that we read in books with lean and inefficiency and cross-functional teams. But what is productivity? I don't know. You have to define that. So that's where I go back. What are you trying to achieve? Individual utilization, work from home. Let's go. You want delivery to your customer? Maybe not. Right. Brian Milner (10:54)So. Right. No, you're making an excellent point. so I'll throw maybe a massive curve ball into this discussion because I would propose that we may not, if we're looking at productivity as whether in an agile organization, we should return to office or not, we may be looking at the complete wrong thing because Productivity, I would propose, and I say this all the time in classes, productivity isn't the answer. What do we hear all the time now about AI and developers is that AI is enhancing productivity. It's allowing them to do more in less time. Well, that's great. Individual, right. But that's a volume. Lance Dacy (11:42)Individual productivity, individual productivity. Brian Milner (11:48)calculation, right? When we talk about productivity, that's usually we're referring to a volume type calculation. But that's, you and I both know very well that the missing gap there is actually the value gap. And so the question i…

    Full show notes at the publisher

    #162: Focus, Flow, Cold Coffee, and the ADHD Developer with Paige Watson Oct 15, 2025
    Show notes

    What happens when your brain loves puzzles… but struggles with where to start? Paige Watson shares how ADHD shapes his work as a developer—and how practices like TDD, mob programming, and discovery trees help him stay focused, move forward, and actually enjoy the ride. Overview In this episode of the Agile Mentors Podcast, Brian Milner is joined by Paige Watson, a technical coach, seasoned XP practitioner, and self-proclaimed “code crafter.” Paige shares his firsthand experience navigating ADHD as a software developer, and how practices like Test-Driven Development (TDD), ensemble programming, and visual planning (like Discovery Trees) have helped him find sustainable focus and flow. Together, Brian and Paige unpack how small, iterative steps and collaborative team dynamics can support not just neurodivergent developers, but everyone on the team. Whether you're navigating ADHD yourself, leading a diverse team, or just want to write better, more maintainable code—this episode is packed with thoughtful insights and practical takeaways. References and resources mentioned in the show: Paige WatsonPaige Watson’s ADHD Blog Posts#76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell#123: Unlocking Team Intelligence with Linda RisingScrum FoundationsSubscribe 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. Paige Watson is a passionate advocate for “Quality Software as Craft,” known for transforming developers into high-performing, cohesive teams. With deep experience guiding software teams and leading workshops for global companies, he helps build elegant, scalable systems designed for longevity and real-world impact. Auto-generated Transcript: Brian Milner (00:00)Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. I'm with you always Brian Milner. And today I have Mr. Paige Watson with us. Welcome in Paige. Really excited to have Paige here. We kind of crossed paths with Paige because of some posts that he had done. Paige Watson (00:11)Thank you. Brian Milner (00:19)He is a technical coach and has been in the development community for a long time and is an XP practitioner, right? Did I hear you correctly say that? Paige Watson (00:27)Yes, I like to use the term code crafter, but yes, a lot of the things I do are XP centric. Yes. Brian Milner (00:31)Nice. I love that, Codecrafter. Then the post that kind of got our attention was a series of posts, actually, that Paige had done about really ADHD and software development. And as people who have listened to this show for a while know, we've done a couple episodes around neurodiversity and neurodiverse traits. and how that bleeds into our work in the software industry. There's plenty of stats showing that there's an unusually large percentage of people in this profession that have some form of neurodiversity. The topics were how he manages ADHD and works. The first one I thought was an interesting title, talked about it being a bug or a feature. So tell us a little bit about what kind of got you started in exploring this. Paige Watson (01:21)Yeah. So I go to a three-day open space that we have in the Northwest. I'm in the Seattle area. And one of the sessions that we had was something, I forget the exact title, but it was around neuro-spiciness in the workplace. And the whole idea was let's get a bunch of people who are neuro-spicy. for lack of a better term, and find out what works for you at work. What are things you need? How do you make sure that what you need is being said out loud? how do you make your work better? So this was a great discussion that we had. And I came out of it going, a lot of the things that I do, a lot of the practices and processes that I use, are actually really helpful for me in my ADHD. So then I sat down and thought, well, first I thought this would be a great conference talk. So I wrote that. And then I was like, I bet this would be a great series of blog posts as well. So I wrote those. Brian Milner (02:24)Ha ha. Yeah. Paige Watson (02:32)It turns out it is a pretty good conference talk, if I say so myself. I get a lot of really good feedback. And honestly, the discussion after I do the presentation is almost better a lot of the time, because you're right. There is a lot of people that, whether they've been diagnosed or they self-identify, whether it's ADHD or autism or anything, there's a lot of that that Brian Milner (02:37)Hahaha. Paige Watson (02:56)that I think we see existing in our software. you know, area that we don't, I don't want to say it's more, I don't have like a definitive study or anything like that that says it's more people in software, but it seems like it. And I sometimes wonder whether that's just me, you know, seeing people because I'm in the software industry or whether there's a draw towards it. Brian Milner (03:22)Yeah, there was a study that I, because I did a conference talk on neurodiversity and software development a while back too, and there was a study that I found out at the University of Texas that basically the only correlation I could find was saying that young people who were entering college and choosing majors were choosing actually it was people on the autism spectrum of some kind were choosing careers in computer science at a rate that was three times essentially that of the general public. So it's not all the neurodivergent traits, but it is one flavor of that. I just don't, maybe there's just not a study on the others, but I... I agree with you. think just from my experience, working in software and managing people in software and developing myself, the people I've kind of been around and worked around, now that I'm more aware of neurodiverse traits, it seems like, yeah, that seems very much like this is going on. That seems like that's going on. And it just starts to make sense a little bit more. Yeah. Paige Watson (04:24)Yeah, yeah. And I wonder, you know, I kind of look back and like, I like to play board games a lot. you know, I like, I have a model railroad and I like the aspect of not just watching the trains go around, although there's probably a maim in there somewhere, but I like sort of operating it like a model railroad. How do I get these cars over there to the green elevator in the fewest moves? There's a puzzle solving aspect. And one day I was like, I like to do that in my work too. You know, and is that part of the the neuro spiciness? I don't know. But you know, it's definitely a draw as to why I like development. Brian Milner (04:56)Yeah. Yeah. Well, I want to dive into some of the things that you uncover in your talk and in the blog post that you wrote. What were some of the discoveries that you realized as you were looking into this? Paige Watson (05:17)So, like, first off, let me preface by saying I'm not a doctor, you know, and if you have, if you think you're, you know, if you think you have ADHD or want to know more about it, please talk to your medical provider. That's really important. Brian Milner (05:21)Yeah. Yes. Paige Watson (05:34)And I can only really talk for my ADHD because ADHD comes in so many varieties. Yes, there are certain things that happen together, but there's so many sort comorbid aspects to it that I only really want to talk about mine and touch on some other things I've seen maybe, but just that caveat. What was really interesting is that I used to think that I ADHD was about not being able to focus. But it's about not being able to control the focus. Because sometimes I can't focus at all. There's lots of things going on. That whole, squirrel, that sort of thing. And then there are other times when I can hyper-focus. And this is where my talk comes. My talk I call Focus Flow on Co-Coffee. Brian Milner (06:13)Yeah. Paige Watson (06:21)And the whole idea is that I go and sit down at my desk with a cup of coffee, and I'm ready to go. And I start typing, and I go to take a sip, and the coffee's cold. And I forgot to go to lunch again. So it's not really about not having focus. It's about not being able to fully control where that focus goes. In terms of the way I Brian Milner (06:32)You Yeah. Paige Watson (06:47)the way I work, there's a lot of things that I found I can get really overwhelmed by big tasks. I can get overwhelmed if I'm not sure where to start. I'll do that thing where I'm like, I have my work. I know my story. I've got all the requirements. I sit down at the IDE, and I start to think about how am I going to write a test. I don't know where to start. I know what I need to do. It's not that. It's picking a place to start. And that's really a tough one for me. And then I can get overwhelmed by that. Or I can get overwhelmed by a large task and not fully understanding all of it. And when I do, I sort of freeze and shut down. And so there's a lot of learning around this that I've found about myself, which has been really nice. Also, having to talk about it to people has been sort of forced me to be a little more circumspect. But there are some really great practices that I found that work really well as well. For me, especially, mainly collaborative programming, mobbing or ensemble work. Pairing works as well, but I find collaborative, like full team programming to be much more effective. Brian Milner (08:00)Yeah. Paige Watson (08:06)Test driven development. I really like that in because I think about the the Requirements as code so I write one little requirement and then I make that requirement happen and then you know that the test fails because it I haven't written the code and then it passes when I write the code, know, and hooray little dopamine hit when it passes but also I don't have to go back afterwards and remember the code that I wrote and and try and write tests around it. That's a really tough one. I was going to remember to test this one thing, but I forget what it was. Now, if I think of my tests as requirements in code format, even the name, the name isn't should get user. It's that when I pass user ID1 should return user. for ID one type of thing, you it's a very clear or when I pass null should throw exception, you know, like, and they're very small. So again, I don't have to be overwhelmed thinking about this grand architecture and holding on to all the information. Brian Milner (09:19)Yeah. What I think is really vital here is to, because I love how you explain the kind of symptom, right? The symptom that we experience and then kind of matching that up to say, but here's a practice that really kind of counteracts that a little bit. I think you're absolutely right. You know, I experienced the same thing with hyper-focus and not being able to focus and There is something about having small little chunks of work that makes that so much easier to digest because it's a constant flow of things. It's not, oh my gosh, now I've got to stay with this for three days straight before I get out of it. No, I'm going to do a little bit and then check it and a little bit and check it. And I agree. That's a big problem, I think, as well for people with ADHD that we kind of... can't always remember what happened yesterday, because so much has kind of come our way. And it's not that we weren't invested in it when it was there. It's just that, our brains are trying to keep up with all the things that are going on. And it just kind of overwhelms our memory processes a little bit. Paige Watson (10:15)Yeah. Yeah. Yeah, I talk about it like I have my short term, which is my memory buffer. And then I have my long term, which is my hard drive. And the problem is that the buffer gets flushed really easily. something new, interesting, something that sparks my interest immediately flushes the buffer. And so a lot of things that are important don't get written to the hard drive and save for later. And another issue that I've run into is Brian Milner (10:35)Yeah. Right. Paige Watson (10:55)there are times I don't really understand what's important. What's important to me is not always what's really important to the team, the work, right, to my wife, you know, all that sort of thing. And so, you know, I'll think like, gosh, I have this chunk of work where I have to add this logging, but if I refactored this into a need-based eventing system, it would be so much better in the long run. Brian Milner (11:00)Yeah. Yeah. ⁓ Paige Watson (11:21)Well, the important thing is that the logging get in there. But I don't think about that. think like, the need-based eventing system is the important that in four years, that's really where we need to be, you know? And so I'll like, I'll get excited about that and I won't focus on that. And I'll, you know, I'll forget about the buffer will flush. And, and so being able to, to do little tiny chunks of work and in, and use use whatever I'm a story or whatever I have in terms of my requirements to drive my tests is super helpful because I can look and say, okay, this happened here because I have a test that says this happened. And I have a test that says it didn't happen to what it should happen, what the response should be or the outcome should be if it doesn't happen. That's really... like TDD is fabulous for that. Collaborative work is fabulous for this because when I'm driving, I don't get overwhelmed if I'm at the keyboard because all I have to do is listen to what other people are telling me and type on the smart input. When I'm navigating or I'm helping write the software, I can get stuck, I can get lost and it's really... It's good because my teammates will say, hey, let's just add this little part. I know you want to refactor this into a need-based eventing system, but let's just add this. In fact, I can hear my buddy's voice in my head saying, can we just write this little part? And the answer is, yeah. OK, great. So there's guardrails on both sides when you work as a collaborative team, which is really excellent. Brian Milner (12:46)Ha ha. Yeah, I agree. part of that hyper-focused kind of side effect sometimes is that our brain turns its attention to something. And it's hard to come back from that edge once you've gone over it. And if you're thinking, oh, it's this needs-based event system that we need to move to, my brain is now in that mode. if I don't have that help to say, whoa, hold on, let me pull you back over that cliff edge here. Let's go this direction. I agree that partnering up with someone, pairing with someone, that can be such a vital thing there to kind of help control that a little bit. Paige Watson (13:31)Yes. Yeah, yeah, it really and I mean, there's so many other things that the sort of myopic view versus the 10,000 foot vie…

    Full show notes at the publisher

    #161: Test-Driven Development in the Age of AI with Clare Sudbery Oct 08, 2025
    Show notes

    AI might write your code, but can you trust it to do it well? Clare Sudbery says: not without a safety net. In this episode, she explains how test-driven development is evolving in the age of AI, and why developers need to slow down, not speed up. Overview In this episode, Brian sits down with Clare Sudbery, experienced developer, TDD advocate, and all-around brilliant explainer, to unpack the evolving relationship between test-driven development and AI-generated code. From skeptical beginnings to cautiously optimistic experimentation, Clare shares how testing isn’t just still relevant, it might be more essential than ever. They explore how TDD offers a safety net when using GenAI tools, the risks of blindly trusting AI output, and why treating AI like a helpful human is where many developers go wrong. Whether you’re an AI early adopter or still on the fence, this conversation will sharpen your thinking about quality, ethics, and the role of human judgment in modern software development. References and resources mentioned in the show: Clare SudberyClare’s upcoming Software Architecture Gathering 2025 workshop Clare at GOTOAI Practice Prompts For Scrum Masters#99: AI & Agile Learning with Hunter Hillegas#117: How AI and Automation Are Redefining Success for Developers with Lance DacySubscribe 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. Clare Sudbery is an independent technical coach, conference speaker, and published novelist who helps teams rediscover their “geek joy” through better software practices. She writes and speaks widely on test‑driven development, ethical AI, and women in tech, bringing clarity, humor, and decades of hands‑on experience to every talk and workshop. Auto-generated Transcript: Brian Milner (00:00)Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here, as always, Brian Milner. But today, I have Miss Claire Sudbury with me. Welcome in, Claire. Clare Sudbery (00:13)Hello. Brian Milner (00:14)I'm so happy to have you here. is here with us because we wanted to talk about a topic that I think is going to be interesting to lot of people, and that is test-driven development, but not just test-driven development in light of AI and kind of the changes that AI has made to test-driven development. So why don't we start with just the base level test-driven development for people who have only heard kind of buzzwords around it and aren't as familiar with it, how would you explain test-driven development in sort of plain English? Clare Sudbery (00:47)Okay, so the idea of test-driven development is that you want to be certain that your code works. And I'm sure most people will be familiar with the idea of writing tests around your code to prove that it works. But that principle is considered so important in test-driven development that we write the test before we write the code. And that's why we say that the development is driven by the tests. So the very starting point for any coding exercise is a test. Another really important part of this is that that test is tiny. So what we're not doing, and people might have heard of behavior-driven development, which is where you start with quite a big test where you say, I'm going to write a test that says that my thing should do this and the user should see a particular thing happen in a particular circumstance. In test driven development, the test is testing not what the user sees, but just what the code does in the tiniest, most granular way possible. So if you have a piece of your software that does some mathematical operations and you expect certain numbers to pop out the end, then you might say, just in this tiny bit of this calculation, this number should be multiplied by four. So you're not even necessarily saying that given these inputs, you should get these outputs. I mean, you may have tests that say that, but you're just testing that something gets multiplied by four. And that's just an example. But what you're doing is you're thinking, what is the tiniest possible thing that I can test? And you write a test that tests that tiny thing. And you do that before you've written the code. So obviously, the test fails initially, because you haven't even written the code yet. And that's another important part of the process. You want to see it fail because you want to know that when you then make it pass, the reason it's passing is because of something you did. And that means that every tiny little bit of code you write is proven because it makes a test pass. And when you get into the rhythm of it, it means you're constantly looking for green tests. And there are lots of other things I could talk about. Like for instance, you never want those tests to fail. So if at any point any of them start to fail, you know that that's because something you just did made them fail, which also means that you want to run them consistently every time you make any changes. So you're getting that fast feedback. You're finding out not only whether what you've just written works because it makes its test pass, but also that it's not making any other tests fail. So not only does it work within its own terms, but it hasn't broken anything else. And that's actually really common when you're coding is that some new thing that you add breaks some existing thing. So you're constantly paying attention to those tests and you're making sure that they pass. And it drives the development in a very interesting way because you're always talking about what should work. You always think about what should work. You always think about how it should work. You're moving in tiny, tiny steps. So you're gradually, gradually, gradually increasing the functionality and whether it works or not and how it works is being determined by the fact that you're making tests passed. And the really interesting thing is that it actually helps you to design software as well as to make sure that software works. So hopefully that explained it. Brian Milner (04:10)That's an awesome explanation. really appreciate that. That was a great kind of practical, plain English explanation of it. I love it. So for the people who weren't familiar, now you have kind of a good idea of what we mean by test-driven development. I know with the advent of AI, there's been lots of changes that have taken place, lots of changes in the way that developers create their code. We now have these sort of co-pilots, assistants that help in doing our coding. But on the other hand, one of the things you hear quite often is that there's lots and lots of quality issues, that it takes a lot of effort to try to maintain that quality and make sure that it's still at a high level. So how does AI enter the picture of test-driven development? How is that helping? How is it changing the way that we do test-driven development? Clare Sudbery (04:59)It's a very good question and there are lots of different strands to how I can answer it. And I think it's probably important that I start by saying, I came to this from a position of deep skepticism. So I have been sitting on the sidelines for a long time, watching the AI explosion happen and not actually getting very involved. But what I did find was that It was becoming like a tennis match. I was like just going, okay. And they say that and they say that. And it actually became very interesting to me just how polarizing it could be. You know, that there were people within my networks, people who had a lot of respect for, who were very anti or who are very anti and who also are very pro. People who've been experimenting with it and having a lot of fun with it. But one of the big issues that I didn't even have to be told I could guess would occur and has occurred is exactly what you said that the code that is generated by GenAI coding tools is often not reliable. And it's not reliable for the same reason that when you ask ChatGPT a question, the answer you get is often not reliable. And that's because these things are not deterministic. They the way that they're constructed. mean, people might remember a long time ago, people used to talk about fuzzy logic. It's all a bit wibbly wobbly. It's not you can't you'll get this a different answer if you ask the same question. And the way that it's constructing those answers is not in the way that we're used to as software engineers. It's not a strict series of logic. It's not all nuts and ones. And hallucination is a real problem. And so it and then you also have to think about the fact so part of the problem is that AI is synthesizing new answers to questions that it's not answering on in a logical deterministic way. But also the place that it's getting his answers from is the results of years and years and billions of files and lines of human output, but with no way of discerning. which bits of that output are good and which bits are bad. And also whether this particular bit that it happens to have plucked from some random code base somewhere is really right for this context. So you're gonna get, when you ask GEN.AI to write code for you, you are gonna get weird results that don't necessarily do what you want them to. But one of the things that we're being told is it's gonna speed you up. And the big attraction of asking AI to write code for you if you're a software engineer is, well, you know, sometimes I'm not quite sure how a particular library works or how a particular framework works. And I have to spend ages on Stack Overflow and Google trying to work out or, you know, trying to work out an annoying bit of CSS or an annoying bit of an annoying regular expression or, you know, all of these things that I've been kind of bashing my head and can spend ages on. Oh, here's a machine that could just do it for me. Yay. And that's, that's, that's very tempting to pretty much anybody who's ever written code, I'm sure. Brian Milner (08:13)Yeah. Clare Sudbery (08:14)And also the idea that it will speed you up and the idea that it will work out tedious task force that you don't want to have to work out is very attractive. But if you don't then look at in detail exactly what it gives you, and particularly if you're not actually able to understand in detail exactly what it gives you, then how the hell are you going to know if what it's given you is the right thing? Brian Milner (08:42)Yeah. Clare Sudbery (08:42)And because we're all impatient and I, you know, I certainly am. And I think most people are to some degree or other. It's hard. It's hard to persuade yourself to check the results. And the more impatient you are and the less experienced you are, the more likely it is that you won't pay proper attention to the results. You won't really rigorously check. whether it's doing what you want it to do. Now that's fine if it's a little hobby project, particularly as sometimes the speed with which you can generate things is such that you can just throw it away and create another one. But if you're building production software, if you're building software that really has to result for a very high number of users, particularly if you're building software that actually has real life implications where bad things can happen, people can lose money. You know, not many of us work on software that endangers life, but some of us do. But at the very least, we do work on software that has privacy implications, that has financial implications. So if you're working within the industry and not just having a bit of fun, then you need some way of knowing whether what AI has presented you with. is actually fit for purpose. And that's where tests come in. Obviously, that's always where tests come in. That's how we know that things are working. And if you're used to working with test-driven development, which I am, it becomes addictive. Now, most people who learn how to do test-driven development will go through a period, and that period will be longer or shorter depending on who you are and depending on like a million different circumstances. But you'll go through a period where it's like, it's just a bit. do I really have to write all of these tests? Can I not just, you know, take a bit of a shortcut? But when you get through that period of thinking, isn't it just slowing me down? And isn't it just a bit tedious really? Then most of us get to a point where we actually become kind of addictive. We become very reliant on test-driven development specifically, because what we realize is it gives us safety and security and really strong belief in what we're building. in a way that we didn't have previously. Now, given that that's where I am, that I've been doing TDD, I mean, I'm going to stop saying test-driven development. I like to not jump straight to TDD in case people doesn't know what it means or they think I'm saying DDD because they sound very similar. I'm going to say TDD now because it's slightly quicker than saying test-driven development. But I've been doing it for long enough now that I miss it when I don't have it. And one of the things that... I really love is that a good, a well designed test suite, which is another thing that another skill that you pick up as you get good at TDD can be run quickly and can give me very fast feedback and, and, security and also a belief that something I've built is robust and that it works. So obviously that's the first thing I think of when I think of how. If I'm going to leap in and make a pact with the devil and start playing with with Gen.ai, how am I going to be happy with with what it builds? How am I not going to be endlessly suspicious? And tests for me are the answer. But then what's really interesting is that when I started paying attention to people who were using Gen.ai in real world applications. So not just having a bit of fun with it, but actually using it to build real important systems. What I started to notice, and I wasn't surprised, was that they were saying is that it's reinforced to us how important the belt and braces are, how important tests are, and how we absolutely really need to put tests around it. And so that's when I started really looking into how can I use AI in a way that's effective and useful and fun, but also ethical, which is a whole other subject, and also robust and trustworthy. And for me, tests were really the obvious answer to that. Brian Milner (12:49)Yeah. Yeah. Yeah. I really appreciate the way you went about explaining this because it's, I think you're absolutely right. First, you have to understand what it is that AI, like large language models are doing and that they are based on kind of more probabil…

    Full show notes at the publisher

    #160: The Real Work of a Scrum Master with Brian Campbell Oct 01, 2025
    Show notes

    What separates a solid Scrum Master from a great one? In this episode, Brian Milner sits down with veteran Scrum Master Brian Campbell to talk about the balance between being empathetic, staying grounded, and knowing when it’s time to move on. Overview In this episode of the Agile Mentors Podcast, Brian Milner is joined by longtime Agile Mentors Community member and enterprise-level Scrum Master Brian Campbell to explore the core skills every Scrum Master needs, beyond the textbook answers. Drawing from 13+ years of experience, Brian Campbell shares how flexibility, empathy, and situational awareness help Scrum Masters navigate real-world team dynamics, conflicting priorities, and tough leadership environments. Together, the Brians discuss how to support product owners without overstepping, when to gently push back with leadership, and how to foster effective teamwork even under pressure. They also dive into what it means to advocate for your team—especially during crunch time—and how to know when it’s time to walk away from an unhealthy engagement. Whether you’re just starting out or deep into your Scrum career, this episode is packed with practical insight from someone who's been there. References and resources mentioned in the show: Brian CampbellRescue Your Daily Scrum videos#113: Influence Without Authority with Christopher DiBella#126: Mastering the Scrum Master Role with Gary K. EvansThe Daily Scrum Meeting - a detailed breakdownSubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Brian Campbell is a seasoned Senior Scrum Master with over 13 years of experience helping enterprise teams in healthcare, insurance, and tech deliver real results with agile. He’s known for his calm leadership, strong facilitation skills, and a flexible, coaching-first approach that meets teams where they are. Auto-generated Transcript: Brian Milner (00:00)Welcome back Agile Mentors. We are here for the Agile Mentors podcast. I'm here, Brian Milner, and I also have with me another Brian. I have Mr. Brian Campbell with me. Welcome in, Brian. Brian Campbell (00:12)Hi. Nice to be on the podcast. Brian Milner (00:13)⁓ I was, yeah, we're really happy to have you here. I always kind of joke with, with other Brian's and, and, Brian is one of the other ones I can joke with here about this and say, thank you very much for spelling your name correctly. Brian is, is, someone who's a member of our agile mentors community and he's, he's shared a lot of really great, advice and he's mentored people through there. Brian Campbell (00:27)I do know people too. Brian Milner (00:39)So we wanted to highlight that, but he's an enterprise level scrum master. He's been doing this for a while. He's got over 13 years experience as a scrum master and has had some really insightful comments in our and post in the Agile Mentors discussion forums. We're going to link to one in particular that's really interesting that hopefully everyone here will find interesting in the show notes. But we talked about what we would. kind of dive into here and seeing as Brian has all this experience as a scrum master, we wanted to focus on some scrum master issues. in particular, one particular quality that Brian brought up that he felt was really, really essential, and I agree with him, for a successful scrum master, and that's flexibility. So maybe we start there and just define that for everyone. When you talk about how important it is for a scrum master to be flexible, What does that mean to you, Brian? Brian Campbell (01:33)Well, there's three things. You've got to work with a product owner at their level. So you may have a brand new product owner who doesn't understand how to construct a story with acceptance criteria or a bug with steps to reproduce. Other times you have a product owner who's really, really on their game and very established. And then you're going to be more hands off and just providing a little bit of guardrails according to the way the company works. You're going to be flexible with the daily standup. I've had teams rebel against the idea that standup has to be run cookie cutter scrum. So you may find that they prefer to go person by person. And that's fine. You may find they prefer to go issue by issue. You may find that you do it a whole section at a time. Dev, QA. going down a column on a board just to try and work with the team the way they want to be worked with. But my goal as a Scrum Master is to make it efficient and effective. I'm not trying to keep them sitting on a call for the sake of being a Scrum Master. But get familiar with how each company does things. Don't try to radically improve things. Suggest incremental improvements where merited. So don't come in guns a-blazing trying to change everything in the environment. Come in, observe for a while, make a little course correction here and there. Suggest things if they're above your station that might allow you to allow the teams to work more effectively. So those are three ideas. Brian Milner (03:02)Yeah, that's awesome. I agree with you on those. think those are really important. There's kind of this, starting with the last thing that you brought up there. There's kind of an idea that I've heard people say before. I've always subscribed to this as well. Kind of the evolution versus revolution kind of approach to doing things that you're going to be served better by trying to incrementally in small little doses change things rather than big bang. let's all of a sudden, Monday morning, everyone's going to be doing Scrum. It doesn't really work very well if you try to drastically change things. I know that's one thing with Kanban I've always appreciated is Kanban talks about start with where you are. And I think that's a good approach for us as Scrum Masters as well, is kind of start with where the team is, Brian Campbell (03:31)Yeah. Well, I've also done Kanban implementations and where people are doing scrim and they want to do Kanban and developers think there isn't a lot of, you know, I'm just going to be wild, wild west and do what I want. But Kanban has its own structure and way of doing things that you need to get the team, its own set of ceremonies, et cetera, that you need to get the team familiar with. Brian Milner (04:06)Yeah. Yeah. And you mentioned earlier as well, like trying to be flexible as you work with your product owners. I agree there as well. Product owners, you know, come in all shapes and sizes as far and all kind of levels of experience. maybe you'll get lucky and you'll have one that's really experienced and doesn't really need a lot of help. But maybe you'll get one that's brand new, that's never done this before. In which case you have to have a lot of patience and a lot of time to coach and help them get up to speed with what's really going to be valuable. Brian Campbell (04:38) Yeah, they need different kinds of support. I think the new scrum master may, new scrum master, new product owner may require, let's read, let's start that one over again. I think they will require different levels of support. The. Brian Milner (04:48)Yeah. ⁓ Brian Campbell (04:51)the new product owner needs to have have stronger agile guard rails in place. The biggest problem I have sometimes is there's a product owner that's very set in their waste. I had one product owner who decided that he was going to map out all the work for this quarter and tell a sign by developer and even story point the items. And I had to go to management and say, Hey, this guy's bad. We'll get into that later. You have a time to move on thing. This was one of my times to move on because management was not supportive and changing his viewpoint. ⁓ Brian Milner (05:30)Yeah. Yeah, I mean, that's part of just being agile that you expect the kind of same attitude towards being flexible from the product owner that, hey, you know, I'm going to grow and learn. And maybe that starts with kind of a humility of just saying, I may not be right. Brian Campbell (05:49)Yeah. I like to form a trika between, well, actually four people. I like to get the product owner, the dev lead and the BA all coordinating at the same time. So the product owner is not writing these stories blind. They're getting feedback from the dev lead and the BA. is learning how to support the product owner. It's kind of like that whole idea with Three Amigos where you get the product owner, developer and QA together and you just try and get them to work on an individual story. This is more like at the team level. Brian Milner (06:24)Yeah, if you do that, just have to make sure you don't kill the invisible swordsman, right? ⁓ Little three amigos reference for the listeners. Yeah, I agree. And I'm kind of curious there because you mentioned business analysts, mentioned dev leads, and that's always a hot button issue as well as we think about working with our teams because there's not really strong guidance from Scrum on Brian Campbell (06:29)That's it. Brian Milner (06:50)those roles and how they might interact or play with the Scrum team, what have you seen work well with those kind of roles? Brian Campbell (06:59)Just like I am an advocate for proper Scrum, know, agile guardrails, dev leads are people who have an ear towards the product owner and an ear towards the team. And if they had three ears, their third ear would be towards best practices in the company. So they have a very difficult job to wear where they're wearing, to do where they're wearing multiple hats. In terms of a BA, I think they just need to learn how the product owner thinks. Brian Milner (07:31)Yeah, that's good point. mean, they're assisting, they're alongside the product owner. it's back kind of like your three amigos reference, right? mean, it's somebody who should anticipate and assist and yeah, that's what I've seen work well also. Well, I want to talk a little bit more about the developer side of things as well, because they're the majority of our team. And if they're not working well, then our Scrum team is not going to work well. And that's always a fine line, I think, too. So I'm curious what your thoughts are here. It's always a fine line with how technical do I need to be? And how do I help my developers become the best version of a team possible without crossing over into getting into their realm and trying to tell them how to do everything? Brian Campbell (08:20)Yeah, I had an interesting lesson with the latter. think one of my first gigs as a scrum master, I was in a room full of people and there was a systems architect with all the developers doing something on a whiteboard. And I said something and they went, you're here to observe. And it taught me that there were boundaries. And on the other hand, there is something you can and should do, which is Try to have enough familiarity with what the team's working on and the other teams involved in the project to where you can anticipate what's coming down the line. try to, if you're trying to anticipate that you're forming good connections with the other teams and their product owners, you're forming maybe even with their BAs, and you're trying to make sure that the dependencies are addressed before the team comes to the work would be a really good example of that. So what else did I, I wrote some notes here because we went over the questions. ⁓ Brian Milner (09:22)Sure. Yeah, you brought dependencies. I agree, the dependencies are kind of a huge area for teams and they can be a team killer, they can be a productivity killer. I know there are people who are focused really, really huge amounts of attention on how do we reduce our dependencies and how can we make our team more independent. So I think you're right, that's a huge key to unlocking the team's speed and productivity is just, you know, how can we have as few dependencies outside our team as possible? Brian Campbell (09:58)Well, that's true, but at the same token, you're going to have, for instance, if you've got a systems team, you're going to have dependencies with them. Right now I'm working at a company where there's a team that does, they're moving off a legacy system, they're moving on to a new system. So they have to sync the data with the old system coming out of the system, going back into the system. And there's a team that specializes in that. There are teams that specialize in different aspects of the system. They all come back to the team that synchronizes stuff in and out of the system. So there going to be dependencies from time to time, but you have to have a good working relationship with both, with any of those teams. you know, the idea is you get ahead of when the need is so you don't disrupt that other team and their work. Brian Milner (10:49)Yeah, I agree. I don't think you can ever really truly get rid of every dependency that you have. I think that's kind of a fantasy, but you you can you can try to limit them. You can certainly try to eliminate the ones that you can and then then try to just realistically handle the ones that are remaining. Right. Yeah. That's a great point. So the other area I was kind of curious to talk to you about is is the area of working with with leaders, because that's always a huge Brian Campbell (11:06)Right. Right. Brian Milner (11:17)hot button issue for us as Scrum Masters. I know there's been lots of surveys and things that have been published in the past saying that that's one of the kind of determining factors of whether it's going to be a successful adoption of these agile values and principles or not is whether the leaders are behind it, on board, supportive. But you know. I'm sure you've had the same experience I have. There's degrees. I've never had 100%, but there's been times it's been more than others. What do think the Scrum Master's role is in then working with leadership? Brian Campbell (11:54)they're going to set a tone and you need to work within the tone and realize that especially if you're in a contract job, you're not going to effectively facilitate change at a VP level, for instance. You're going to have to understand their paradigm and work within it. think you can advocate for your team, but often you'll be advocating across multiple teams. see a pattern, again, goes back to understanding more than just your team. You may be advocating for a pattern you see across multiple teams. And then you come at it from a suggestion that would be in their best interests or in the interest, usually in the interest of getting the project done on time. But I've had good leaders, I've had bad leaders. I think about three…

    Full show notes at the publisher

    #159: Is Scrum Really Too Many Meetings? with Lance Dacy Sep 24, 2025
    Show notes

    “Too many meetings” is one of the most common complaints in Scrum teams, but is it really the meetings, or what’s (not) happening in them? In this episode, Brian and Lance Dacy dig into the events of Scrum to uncover what works, what doesn’t, and how to make each one actually add value. Overview In this episode of the Agile Mentors Podcast, Brian Milner welcomes Certified Scrum Trainer and Mountain Goat colleague Lance Dacy for a breakdown of the four main Scrum events, and why so many teams struggle with them. They tackle one of the most persistent frustrations teams face: the sense that Scrum has “too many meetings.” Together, they explore how to reframe these as working sessions, clarify their purpose, and avoid the common traps that drain time without moving the work forward. From sprint planning that skips the plan to daily scrums that lose their rhythm, this episode is full of specific guidance for getting more value out of each event. Plus, hear why retrospectives and backlog refinement are two of the most underrated (and powerful) drivers of team improvement. Whether you're new to Scrum or looking to reset a struggling team, this conversation will help you re-center on what the framework is really designed to do, and how to help your team do it well. References and resources mentioned in the show: Lance Dacy#138: The Bad Meeting Hangover with Julie Chickering#156: Making Product Ownership Work in Shared Services with Kert PetersonDoes Scrum Have Too Many Meetings? By Mike CohnWhat Happens When During a Sprint By Mike CohnScrum Activities: An OverviewWorking on a Scrum Team CourseSubscribe 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. 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. Auto-generated Transcript: Brian Milner (00:00)Welcome back Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and I have with us friend of the show, once again, Lance Dacy with us. Welcome back, Lance. Lance Dacy (00:12)Thank you, Brian. Glad to be here. Brian Milner (00:14)Always happy to have Lance on. we thought we'd have Lance on. We were kind of doing this thing at Mountain Goat. We're getting ready for the launch of a new course here that's called Working on a Scrum Team. And Lance and I are going to be two of the people that teach that course. And it's going to deal with a lot of like basic stuff that the teams deal with, common problems, common issues, and really how to work together well on a Scrum Team. And one of the things that we always hear questions about is about the meetings themselves. There's kind of three core components there for the Scrum framework. There's the roles, the events, and the artifacts. And so the events, the meetings are one of the biggest kind of focal points. And there's lots of questions about it. So I guess let's kick it off that way, Lance, and just say, what do you most hear? people complain about when they talk about scrum meetings. Lance Dacy (01:06)Well, that's the big thing, right? It's like we call them meetings. And the first thing I like to do is try to explain to them that there really aren't meetings, right? So when you hear the idea that you're going to go to a meeting, that's not very exciting, right? You're like, I'm to sit there and not get a lot out of this. So what I would like to say about the, working on a scrum team, I'm going to say it's probably the first course I ever taught as a scrum trainer. And we've been actually teaching it for a very long time. It's mainly just a private. you know, that we go into organizations and help them learn this. So I'm super excited that we're making this available publicly because so often people say, well, I'm a, you know, I'm not a product owner and I'm not a Scrum Master and I want to learn more about Scrum and I don't want to kind of bend to one role. So I am just shouting for joy that we have this one now. And I really hope that a lot of people will benefit if you're a stakeholder or if you're a manager or leader or things like that. A lot of times you have to pick and choose, you know, which class you're going to go to. So Brian Milner (01:49)you Lance Dacy (02:00) "That's one thing, but it helps us address this idea. We kind of talk about it in Scrum Masterclass where people are like, well, we're practicing Scrum now, and now I feel like I got to go to all these meetings. Okay, well, first of all, they're not meetings. Let's get that out of the way. Let's quit calling them meetings. You called them events. I think that's an appropriate term, but I like to call them working sessions. No matter what process we use, you are going to have to get together with your team and collaborate on how we're going to approach building this thing. You have to collaborate on Brian Milner (02:11)Mmm. Hmm. Lance Dacy (02:29)understanding the needs of the users. Like that doesn't go away. Regardless of the process you use, Scrum just tries to focus us and allow us to get together in specific checkpoints throughout the process. And so if you boil it down, the Scrum framework itself has the four events of sprint planning, daily Scrum, review, retrospective. And then we have this activity, product backlog refinement, which if I had to choose... One of the top two problems with Scrum teams is we don't spend enough time doing product backlog refinement. So a lot of teams even misunderstand what that is. Is that a meaning? Well, not always. It's an activity as well. So I think probably some of the biggest complaints we hear about Scrum as we go to all these meetings. And so I typically like to advise people, you know, if you're going to implement Scrum, get rid of all the other meetings first. Okay. So you're going to do Scrum and Brian Milner (03:16)You Lance Dacy (03:19)We're gonna do sprint planning at the beginning of a sprint. Every day we're gonna check in on how we're doing against the work that we've collectively decided we could do. We're gonna show our stakeholders at the end and then we're gonna meet at the end and try to figure out how we can get better. There's nothing inherently wrong with that if you don't call it a meeting. Like plan the work we're gonna do for the next, let's say two weeks. Every day check in on it. Show our stakeholders at the end, is this what you wanted? And then what's wrong with getting together and saying how could we do better next sprint? Okay, so get rid of all the other meetings and try to build it into that cadence, if you will. Now, the other side to that is you're going to also have to get together and do backlog refinement, which is estimating, breaking large items down into smaller items. You're going to have to do some level of design on these items. And then, of course, adding clarity and detail to the work items is another big aspect of that. So those aren't meetings. Those are working sessions. So. When I hear most people complain about the scrum meetings, get rid of everything else, only do these. You're going to have to spend that time anywhere, anytime, know, whatever process you use. And if you want to get into the numbers, you know, I hear managers all the time or project managers going, I've got 12 people on a team and they're going to spend, you know, let's say a two week sprint maximum time box for sprint planning is four hours. And that's multiplied by 12 people. That's a terrible amount of time. It's like, yeah, but if you start doing all the math, And you spent the maximum amount of time, which we always would want to lead and coach and train them to spend half of that eventually. But you may have to spend all that time at the beginning, but you don't spend more than that. So, sprint planning kind of just boils down to about 5 % of a 40 hour work week for two weeks, daily scrums, about 3 % sprint reviews, about two and a half percent retrospective 2%. And so that's a total of about 12 % of your collective time going to these scrum events. Now. I would pay that any day if it's going to save us some mismatch, you know, further down the road. So that's really what I like to boil it down to is these are not meetings, first of all, they're working sessions, and it's not as much as you really think it is. So what do you think? Brian Milner (05:17)Yeah. Yeah. No, I agree. mean, I hear people say that all the time that there's, why are there so many meetings? And I mean, I think when people say that it's usually one of two kind of core reasons why. One is maybe they're doing it for like four or five teams. And if that's case, yeah, that's a lot of meetings because you're not meant to be on four or five teams. You know, that's kind of the your problem isn't the meetings, right? Your problem is something else. But the other thing I think is, I think it really can feel like there are more meetings than there are when the meetings don't really accomplish the purpose or the people don't really understand the purpose of why they're there. ⁓ Right, they're ticking a box. Lance Dacy (06:16)They're ticking a box, right? They're saying, well, we went through this meeting. Brian Milner (06:19)Yeah. I mean, and when you do that, just feels like it does feel like a drag. feels like just a, you know, a beat down, you know, that happens over and over again. It's funny that you put that about 12%. I was trying to do the math in my head and I just, I roughly kind of thought, well, what did I do last time I was a scrum master? Yeah. We would, we would have like half a day of the first, if I have a two week sprint, we'd have half the day, the first day in sprint planning about, or maybe not even half of it, right? Lance Dacy (06:48)Right. When you get better, it's less time, right? Brian Milner (06:50)Yeah, right. We would have a portion of the morning of the last day being a sprint and review and a portion of the afternoon being retrospective. But even if you made that just the whole time, mean, the maximum that you could even add that up to if you had tried to squeeze in those daily scrums as well would be 20%. But even at that, would say, you know, compare if you're not doing scrum. Compare what percentage of your times in meetings now. And I guarantee you it's more than 20 % of your work time over two weeks that you're in a meeting. ⁓ Lance Dacy (07:15)Right? Well, you also have the context switching, right? If you're not doing it in a more focused event like Scrum, you kind of have more probably interrupt. I, you know, I think that's such a great point to make when we're teaching people this, which we kind of talk about this in our class as well. But we try to encourage people to not think of it that way as a meeting. It's a working session. It's a collaboration session. Cause I hear all the time, you know, developers will say, I don't want to go to sprint planning. I just want to get in there and start coding. I'm like, code what? Brian Milner (07:47)Yeah. Lance Dacy (07:49)What are you going to code? I mean, what if you went in there and coded a thousand lines? It's all incorrect. Is that helpful? No, it's not helpful. So I find let's help the teams learn how to translate time because they're always sensitive to it, to ROI, not a cost. So every event that we typically have in Scrum is what we would call a scheduled inspect and adapt loop, right? That's really what the three pillars of Scrum, inspection, adaptation, and visibility or transparency. So those loops are what tries to help us, you know, slash up the rework that might happen later or missed requirements or delay costs. So the real hidden meanings that devour our calendars, Scrum is going to give us a little bit more thoughtful way to do that. And, you know, there was a study out there, actually, Jeff Sutherland did a study, I think it was back in 2024, and he found that teams who hit each time box saw about 32 % fewer unplanned meetings and a 27 % drop in defect work. Now with numbers, you never know, you I'd have to go read, where did he get these numbers at? But I just think it's curious, an argument to make with that. And so you can invite leaders who are saying this is too many meetings to do a, you know, like a cost of delay experience to say if a 15 minute daily scrum saves even one developer from being blocked for half the day. we're already net positive on meeting time. So how often does that happen in the world? And that kind of turns it around from time to flow and ROI and all that. So I think making those metrics visible is important to especially leaders and managers who kind of balk at, my gosh, my people are in these, all these meetings and they feel like the only way to be productive is hands on a keyboard. So. In our working on a Scrum Team class, we get to kind of broach that not from any particular role and just say, celebrate that. Don't be mindful of that as we go. know, obviously the CSM course, we would try to talk about techniques on how to mitigate it. But that to me is one of the biggest issues is this notion that meetings are not a good thing to be in. Brian Milner (09:36)Yeah. Yeah, yeah, I agree. Well, let's step through the four main meetings. This is always a trick question too. I tell people in class, if you are answering a test, there's actually five events in Scrum, but the fifth one is the sprint itself. So we're not gonna focus on the sprint, but we'll talk about the four here. Just at least hit them. and talk about some of the bigger issues that we've seen in them. So let's start with the one that sets it up, sprint planning. Like you said, I think one of the kind of chief things to think about here is if you don't do this, how are you solving that purpose of knowing what it is we're gonna do? But what do you think some of the biggest mistakes people make are in trying to do a sprint planning session? Lance Dacy (10:30)Get in and out of it very quickly. That's the biggest mistake. I typically like to teach, know, sprint planning is really, we could use all the scrum terminology, but we are trying to co-create and forecast work that the team believes will accomplish the sprint goal set forward by the product owner. Brian Milner (10:32)Yeah. Yeah. Lance Dacy (10:48)and then devise a plan on how to get there. So we typically think of sprint planning in three parts. And I think that's the big mistake is they just want to ge…

    Full show notes at the publisher

    #158: Should You Skip the Sprint Retrospective? with Mike Cohn Sep 17, 2025
    Show notes

    Is your team dreading retrospectives, or skipping them altogether? Mike Cohn joins Brian Milner to unpack what’s really going wrong (and how to fix it) so retros don’t just take up time… they actually make your team better. Overview In this candid conversation, Brian Milner welcomes back Mountain Goat Software co-founder Mike Cohn to talk about one of the most misunderstood parts of Scrum: the sprint retrospective. Too many teams treat retros as boring, repetitive, or even pointless—and end up skipping them entirely. But retros are where the magic of continuous improvement actually happens… when they’re done right. Brian and Mike dig into the common reasons teams dread retros, how to spot the signs a retro isn’t working, and the practical ways to bring them back to life. They also share their own lessons learned (including how Mike once argued retros shouldn’t be part of Scrum!) and walk through the real reason retros matter: giving teams space to inspect, adapt, and improve together. References and resources mentioned in the show: Mike CohnYour Fast Tract to a Fresher Retrospective Webinar#141: Cooking Up a Killer Retrospective with Brian MilnerOvercoming Four Common Problems with Retrospectives by Mike CohnRetrospectives Broken? Fix Them for Good by Mike CohnSubscribe 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. 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)Hey everyone, welcome back to the Agile Mentors Podcast. I'm here with you always, Brian Milner. But before we dive in today, I wanted to let you know that we're gonna have a free webinar that I'm gonna be running here for you. It's gonna be on September 24th at 9 a.m. Pacific. So do your adjustments wherever you are. It's called Your Fast Track to a Fresher Retrospective. It's just gonna be a little short 20 to 25 minute presentation. And then there's gonna be some open question and answer that we're gonna have after that. it's perfect if your team's retros are feeling a little stale, or if you're looking for practical ways to shake things up. We're gonna put a link to it our show notes, but wanted to make sure right up top that you guys knew about that. It's completely free, September 24th, 9 a.m. Pacific. We're gonna have that webinar on retrospectives. And joining me here today, also is the one and only Mike Cohn. Welcome in, Mike. Mike (00:55)Hey, Brian's good to be back. Brian Milner (00:57)Glad you're here. We wanted to have a conversation because I think we can probably all agree that not all retrospectives, we might even say are worth having. When you look back on them and you look back on the content of it, maybe we'd say it wasn't worth having. If your team isn't getting value from the meeting and skipping it might feel rational. But skipping the point of retrospective, continuous improvement, isn't something high performing teams really can afford. It's a main part of what we do. So we're going to talk a little bit more. We're going explore that about why some teams end up dropping retros. Because I hear that all the time. People ask that in classes. Is it OK to? Should we? Should we do it less often? So we're going to talk about why some teams might drop retros. What that really says about the team health itself. and how you can bring retros back in a way that reconnects to their purpose so that it's not just a ritual. And with that then, I'm going to pull Mike back in. So again, Mike, thanks for being here. I really appreciate you giving us your time for the episode today. Mike (02:05)Yeah, I appreciate it. I'm glad to be here. Before you jump in, I do want to point out that we've been on for about 15 minutes before we got ready to record. Just kind of haven't talked to each other for a bit. And I just want to point out for everybody listening that Brian did a mini retro on his podcast before we got started, talked about how we can change some editing on that, maybe get episodes out more quickly and also to get them out in video. So I guess I'm saying that to. make us commit to the video part of it, but to also point out that Brian did a retro on his podcast, right before we got started. So Brian is walking the walk. Brian Milner (02:40)Yeah, mean, it's always good to inspect and adapt, right? I mean, if you don't do that, then you're not questioning why things are happening the way they are and things get stale and eventually fall off. So yeah, I'm a big proponent in that, stopping down to inspect and adapt for sure. Mike (02:56)Brian, one of the things that does come up with retros is teams feel like skipping them when they're not getting anything out of it. Do you think it's okay to skip a retrospective? Brian Milner (03:08)Well, I'm probably not going to shock anyone here in my answer, but I'm not going to be someone who would support that. I'm not a proponent of that. I think that's a mistake. I try to be very careful about saying, hey, this is always this way. I do think that that's the Agile Manifesto talks about periodically, routinely. kind of having this kind of inspecting and adapting moments where we retrospect on how things went. And Scrum has this meeting built into it to happen every single sprint. The thing that kind of jumps out at me when I first thought about this is we kind of take this attitude sometimes that, this thing isn't working great. And so maybe we should skip it. Or least that's, I guess, the mentality behind skipping the retrospective. Mike (03:55)When you say skip it, I think about the guy skipping leg day, right? Brian Milner (03:59)Right, right. Well, that's exactly where I was going to go. It's like, where else in life do we say, that's not working, so I just won't do it. You know, like, I'm having a hard time getting my passport renewed, so I guess I just won't get my passport. You know, like we don't do that with other things. There are things that are hard. There are things that take more effort. And it doesn't mean that if it's harder or it's not working right now that we just don't do it. We got to figure out why and... you know, fix it and, you know, get better at it. Mike (04:27)Yeah, there's a I'm a big fan of the Lego Batman movie. And in there, there's a song where this says Batman never skips leg day. Right. And, you know, skip something if it's truly useless, but don't skip something because it's hard. Right. I would agree that. Brian, I'm curious what you think about this situation. What suppose you have a team doing one week, one week sprints and one week is. Brian Milner (04:31)Ha ha. Right. Mike (04:51)Awesome. It's the right length for the team. It's a right length for the business. Everybody agrees. It rocks. One week sprints rock. But the team hates retrospectives. Like literally, they'd rather go to the dentist and have a root canal instead of having a retro. And at some point, somebody on the team goes, huh, if we switched to four week sprints, we wouldn't have to do these darn retros as often. That's a tough one. What do you think about that? Brian Milner (05:18)Well, there's some truth in that. You know, they're not wrong, as they say. You know, if you do longer sprints, then you have meetings less often and included in that is a retrospective. So yeah, that's not wrong. You would do it less often. But on the other hand, your retro is gonna be a lot longer. If you're retrospecting over the past month versus over the past week, Mike (05:28)Mm-hmm. Brian Milner (05:42)A weekly retrospective is going to be very short. A monthly retrospective is going to be very long and no one likes longer meetings. So that's the trade-off is, yeah, we can do it less often, but do you really want to have those meetings double and triple and link? Mike (05:46)Okay. in double and triple perhaps, but I I gave it the example where it'd be one fourth as often. So it'd have to be four times as long. And I doubt that it would truly be four times as long. See, this is a case where we probably disagree on this a little bit, because I have had teams that have made that argument. Hey, if we went to longer sprints, we wouldn't have to do this as often. And I don't want them to go to longer sprints. I doubt you do either. But what I've told them is like, look, the rule is do a retrospective often at least once a month. Brian Milner (06:20)Yeah. Mike (06:27)If you're going to do it every four weeks and you want to do two weeks sprints, for example, do your two weeks sprints. But I'd rather have you do the retro every other sprint, but take it seriously. Because what they do is they just go through the motions. They're going to go through the motions for 10 minutes. They're going to go through the motions in 10 minutes in a four week sprint too. Just show up. Can we get better or anything? No, we're good. Done. Brian Milner (06:37)Right. Mike (06:49)I'll let them trade off if they want. If they will make the commitment to me, they'll take it seriously and really come with ideas and try to improve. Brian Milner (06:56)Yeah, well, I think this is a prime example as well why inspecting and adapting is so important because, all right, what's our issue? No one likes going to the retrospectives. We're jumping from that to, then let's just not do them as often. When what you need to do is stop and inspect and say, why don't any of us like coming to the retrospectives? What's the problem about our retrospectives? And that's really the core issue there is to say, Hey, are we doing the same thing every single retrospective? Are we saying, Hey, what went well? What didn't go well? Right. I mean, are we being asked the same questions every time? we never varying it up? Are we always doing kind of navel gazing kind of thing? Or sometimes are we doing team building stuff? Sometimes are we even just celebrating some things that happen from time to time? The root cause is the important part because otherwise, you know, it's like cutting off your leg because you you got to a little infection or something in your big toe. That's not the cure for it. The cure is find out what the disease is and treat the disease. Mike (07:57)'m back to it's leg day at the gym and I'm going to cut my legs off because I hate leg day that much. Right. It's like, no, no more leg day. Right. So you'd have to really hate leg day for that, for that to be the solution. What, what are some of the signs that you've seen that indicate a retro is not working and that the team needs to kind of rethink things? What are some of those signs? Brian Milner (08:00)All right. No more leg day. Thanks. Yeah, no, that's really good. Common things, people checking out, people just giving surface level answers. Here's a big one. There's obvious things that didn't go well in your sprint, and no one brings them up. You just kind of get there and it's like, for example, hey, we didn't finish everything in this sprint. Mike (08:39)Yeah. Brian Milner (08:44)But then we get into our retrospective and no one puts on the board. What's something that didn't go well this front? We didn't complete all our work, right? Sometimes people get to that point where they just feel like, it's so obvious. Why would I need to bring it up? Well, if it's so obvious, then we need to address it, right? We need to do something about it. So yeah, I think that's part of it is that sometimes people will just check out and you might be able to tell it that way. You might be a tell it because they're not really contributing things. People try to rush through it. You know, it's like you only get a team where only a couple of things are in each one. And it's almost like it feels like the team's colluding to sort of, well, you put these two things up there and that'll be enough. And then they'll leave us alone. We can go on. You know, so, you know, they're, they may not literally be doing that, but it's almost, you get that feel that it's almost like there's an implied, I guess we have to have this number of things up there. Yeah. I mean, it's just, Mike (09:13)Good. Brian Milner (09:37)In general, there's no investment. When people show up, they're not really engaging. They're marking the time. And when that's going on, yeah, that's usually a precursor to someone eventually saying, hey, let's just not do this then. Mike (09:54)One of the problems that I'd add or one of the symptoms that I'd add would be when the team is talking about things again and again, the same item again and again, right? And it's not gonna get fixed. You we might be in there talking about, you know, I hate the new building, right? The new building's farther from my home. This is a real team I worked with where they all moved. They were downtown and the company moved everybody out. near the airport in their city. And it wasn't better for anybody. I mean, it was probably better for the CFO writing the check for the landlord or to the landlord. But it was a bigger commute for everybody. The facility wasn't as nice. It wasn't your restaurants. I mean, it just kind of sucked. And they would grumble about it every week. It's like, we can't fix this, right? We can't fix this. Right. You know, and so sometimes talking about things that are out of a team's hands are are they're just frustrating. Right. Brian Milner (10:34)Ha ha ha ha. Yeah. Mike (10:42)It's like mention it one time. I hate the new building. It sucks. There's no good restaurants here. And you know, you're probably not going to fix that problem. Maybe you can agree that you're going to, know, on, you know, the last Friday of a sprint, everybody on the team is driving back downtown and we're all going to lunch together, right? Fix it that way a little bit. But, you know, don't grumble about things that are out of your hand, right? You know, I'm worried about climate change. It's like, yeah, but I don't hear about that. It seems retrospective, right? Brian Milner (11:02)Yeah. Yeah, that's completely outside our circle to do anything about, right? So yeah, I agree that there is that scope sometimes that happens. But on the other side of it too, I would say one of the other killers that can contri…

    Full show notes at the publisher

    Previous 1 2 3 4 5 19 Next

    Related Podcasts

    Reply All

    1

    Reply All Games & Hobbies
    Inside VR & AR

    2

    Inside VR & AR Gadgets
    Note to Self

    3

    Note to Self News
    BrainStuff

    4

    BrainStuff Natural Sciences
    This Week in Tech (Audio)

    5

    This Week in Tech (Audio) News
    Hands-On Tech (Audio)

    6

    Hands-On Tech (Audio) Technology
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights