Podcasts about Agile

Salum Abdul-Rahman: The SECI Model of Knowledge Management Applied to Team Retrospectives Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum explains how the key role for Scrum Masters is to help teams develop themselves to the point where they can learn and grow without constant guidance. Success means building team resilience and operational capability while knowing when to step back. He emphasizes the importance of recalibration workshops to maintain shared understanding and the balance between supporting teams and challenging them to become self-sufficient. When teams reach this level of maturity, Scrum Masters can focus their efforts elsewhere, knowing the team has developed the capability to continue evolving independently. Featured Retrospective Format for the Week: The 5-Stage Retro Format From the book "Agile Retrospectives," this format captures the complete learning process and aligns beautifully with knowledge management principles. Salum connects the three central phases of this format to the SECI model of knowledge management, particularly referencing Nonaka and Takeuchi's work in "The Knowledge Creating Company." This retrospective structure helps teams create new knowledge and behavioral change by following a systematic approach that transforms individual insights into collective team learning and action. In this segment, we also refer to the seminal article by Takeuchi and Nonaka: “The New New Product Development Game”, which originated the work on Scrum as a framework.  Self-reflection Question: How do you recognize when your team has developed enough self-sufficiency that your role as facilitator can evolve or step back? [The Scrum Master Toolbox Podcast Recommends]

Nigel Thurlow previously served as the first-ever Chief of Agile at Toyota, where he created the World Agility Forum award-winning “Scrum the Toyota Way” and co-created The Flow System™, a holistic FLOW-based approach to delivering customer-first value built on a foundation of The Toyota Production System.Throughout his career, Thurlow has gained an enviable recognition as a leading expert in Lean and Agile methods, tools, techniques, and approaches. He specializes in developing effective organizational designs and operating models for organizations to embrace both Lean and Agile concepts. By leveraging knowledge from various sources, Thurlow helps optimize organizations to enact successful, long-lasting transformational strategies in applying Lean thinking, Agile techniques, and Scrum – while combining complexity thinking, distributive leadership, and team science, represented by a triple helix structure known as the DNA of Organizations™.As of 2024, he has trained over 8,500 people worldwide in Scrum, Agile, Lean, Flow, Complexity, and organizational design. Thurlow is a Professional Scrum Trainer (PST).An instinctive problem solver, Nigel Thurlow takes a method-agnostic, cross-industry approach in helping organizations find the right tools, methods, and approaches to overcome challenges within their contextual situation. He advocates for the fact that there is not a one-size-fits-all prescriptive approach to agility; all tools have utility, but they also have contextual limitations. From this vantage point, Thurlow equips an organization's people to become an army of problem solvers, expanding their perception of what they do so they can better understand and prepare for potential challenges along the way.Thurlow is currently the Chief Executive Officer at The Flow Consortium, a collection of highly regarded companies in the Lean and Agile world — as well as the scientific and academic communities at large. The Flow Consortium strives to expand the boundaries of current Lean and Agile thinking through the understanding of complexity thinking, distributed leadership, and team science by tapping into the minds of top thought leaders from these concentrations.While at Toyota, Thurlow worked to frame Scrum as more than just a standardized behavioral process by applying and advancing fundamental methodologies to spur innovative, forward-thinking solutions to Toyota's most complex challenges. He also founded the Toyota Agile Academy in 2018. These efforts signaled a transformative phase for Toyota, leading the company towards organizational agility and helping its team members better understand this concept in an automotive production context.Additionally, Thurlow has been a board presence at the University of North Texas since 2019, serving as an advisor to the Department of Information Science Board and a member of the College of Information Leadership Board. He has also served as the President of CDQ LLC since 2012. Prior to that, Thurlow held executive coaching and training roles for companies including Vodafone, Lumen Technologies, Scrum, Inc., GE Power & Water, 3M Healthcare Information Systems, Bose Corporation, The TJX Companies, Inc. – as well as the Commonwealth of Massachusetts. He has also taught Scrum at the Massachusetts Institute of Technology (MIT).As an author, Thurlow was named a Forbes top 10 author for co-authoring the book “The Flow System™” in 2020. He has recently co-authored “The Flow System Playbook” published in 2023 which presents a practical study guide and reference book to all the concepts covered in the first book.His other notable publications include “Introducing the Flow System (2019)” and “TPS and the Age of Destruction (2019).” He is also the co-author of The Flow Guide and The Flow System Principles and Key Attributes Guidebook. Recently, Thurlow co-authored “The...

When operations break down, growth stalls — and for most companies, the warning signs creep in long before anyone notices. Tammara Carr, founder of Audacity Management, has seen it all: from Fortune 50 boardrooms to fast-moving SaaS startups. With a Master's in Project Management, top-tier Agile and Six Sigma certifications, and experience leading multimillion-dollar initiatives, she's the go-to expert for turning operational chaos into a well-oiled growth engine. In this episode, she shares: The early red flags that your operations are holding you back The most common scaling mistakes mid-sized companies make — and how to avoid them How to prioritize business shifts without grinding everything to a halt One system or mindset shift that works just as well for scrappy teams as it does for corporate giants If you're a founder, COO, or team leader feeling buried under moving parts, this conversation will show you how to build systems that not only sustain your business, but help it scale with clarity and confidence. Connect with Tammara: www.audacitymgmt.com www.carrandcompass.com/ IG: @carrandcompass www.pinterest.com/carrandcompass/ www.linkedin.com/company/audacity-management/ Audacity Management Initiative Strategizer | Prioritize what will drive the most value and change for your business: https://audacitymgmt.com/value_disruption Audacity Management Operational Health Check | Pinpoint your biggest areas for operational improvement: https://audacitymgmt.com/operational_check Audacity Management Composite Case Study | See proven approaches for tackling business challenges: https://audacitymgmt.com/case_study-293872 Iconic business leaders all have their own unique genius. Take this quick 10 question quiz to uncover your specific CEO style advantage: ⁠⁠⁠⁠⁠⁠⁠⁠⁠https://cubicletoceo.co/quiz⁠⁠⁠⁠⁠⁠⁠⁠⁠ If you enjoyed today's episode, please: Post a screenshot & key takeaway on your IG story and tag me ⁠⁠⁠⁠⁠⁠⁠⁠⁠@missellenyin⁠⁠⁠⁠⁠⁠⁠⁠⁠ & ⁠⁠⁠⁠⁠⁠⁠⁠⁠@cubicletoceo⁠⁠⁠⁠⁠⁠⁠⁠⁠ so we can repost you. Leave a positive review or rating at ⁠⁠⁠⁠⁠⁠⁠⁠⁠www.ratethispodcast.com/cubicletoceo⁠⁠⁠⁠⁠⁠ ⁠⁠⁠Subscribe for new episodes every Monday. Learn more about your ad choices. Visit megaphone.fm/adchoices

Casey Handmer, Founder of Terraform Industries, joins me to talk about the state of NASA in 2025, talent acquisition and retention, productivity, and so much more.This episode of Main Engine Cut Off is brought to you by 34 executive producers—Kris, Joakim (Jo-Kim), Creative Taxi, Heiko, Joel, Frank, Josh from Impulse, The Astrogators at SEE, David, Jan, Tim Dodd (the Everyday Astronaut!), Theo and Violet, Joonas, Stealth Julian, Donald, Warren, Matt, Pat, Steve, Fred, Bob, Lee, Natasha Tsakos (pronounced Tszakos), Will and Lars from Agile, Russell, Better Every Day Studios, Ryan, and four anonymous—and hundreds of supporters.TopicsCasey Handmer (@CJHandmer) / XCasey HandmerTerraform IndustriesNASA Is Worth Saving – Casey Handmer's blogEpisode 170 - Luckily, We Did All the Math (with Casey Handmer) - Off-NominalThe science behind clean hydrocarbons | The Freethink Interview - YouTubeThe ShowLike the show? Support the show on Patreon or Substack!Email your thoughts, comments, and questions to anthony@mainenginecutoff.comFollow @WeHaveMECOFollow @meco@spacey.space on MastodonListen to MECO HeadlinesListen to Off-NominalJoin the Off-Nominal DiscordSubscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhereSubscribe to the Main Engine Cut Off NewsletterArtwork photo by NASAWork with me and my design and development agency: Pine Works

Salum Abdul-Rahman: From Lunch Conversations to Company-Wide Change—The Power of Creating Communities of Practice Within Organizations Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum shares how he organically built an Agile community within his company by recognizing a shared need for discussion and learning. Starting as a software developer who took on Scrum Master tasks, he felt isolated in his Agile journey. Rather than waiting for formal training or external events, he sent out a simple invite on the company Slack for a lunch discussion during a work day. People showed up, and what began as informal conversations about different approaches to Scrum and Kanban evolved into monthly gatherings. Over time, this grassroots community grew to organize company-wide events and even found new leadership when Salum moved on, demonstrating the power of identifying shared needs and taking initiative to address them. Self-reflection Question: What shared learning needs exist in your organization that you could address by simply reaching out and organizing informal discussions? [The Scrum Master Toolbox Podcast Recommends]

In this episode of the Agilists: Aspire and Achieve podcast, host Renae Craven chats to Vinnie Gill about her experience of living in different countries and how her agile career has grown because of that.    About the Featured Guest Vinnie Gill puts people and culture first. She enjoys connecting with people and companies to find their purpose, walking alongside them in their organisational growth journey. Her passion is influencing change at the Enterprise level.   She is deeply involved in the Agile community, speaks at international conferences and has a special interest in educating and education being the tool that empowers people. Follow Vinnie on LinkedIn (https://www.linkedin.com/in/vinniegill/) Her website: https://outcomeoveroutput.com   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).

Even the most capable professionals can struggle in interviews. In this episode, Brian and job interview coach Tali Shlafer break down why, and what to do instead. Overview In this episode of the Agile Mentors Podcast, Brian welcomes interview coach Tali Shlafer for a practical, clear-eyed conversation about how to approach job interviews as a skill, not a personality trait. Tali shares why being great at your job doesn’t automatically translate to interview success, especially in collaborative fields like product development, Agile coaching, and project management. She outlines a straightforward way to prepare for interviews by identifying the real challenges behind a role and building stories that speak directly to them, without sounding rehearsed or robotic. From reframing “bragging” as problem-solving to handling tough questions with clarity and self-awareness, this episode is full of grounded advice for professionals navigating their next move. References and resources mentioned in the show: Tali Shlafer Free Job Interview Tip Vault Tali's LinkedIn Tali's Instagram #93: The Rise of Human Skills and Agile Acumen with Evan Leybourn #111: Adapting to the Future of Work with Heather McGowan Blog: Entry-Level Scrum Masters: Seven Tips on How to Get Your First Scrum Master Job by Mike Cohn AI Prompt Pack for Product Owners & Scrum Masters Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Tali Shlafer is a certified interview coach who helps high performers turn nerves into clarity and confidence so they can land roles they’re truly excited about. Her practical frameworks—rooted in psychology, communication, and performance—ditch the gimmicks and empower candidates to show up as their best, most authentic selves. Auto-generated Transcript: Brian Milner (00:00) Welcome in everyone. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have Miss Tali Schläufer with us. Welcome in Tali. Tali Shlafer (00:11) Thanks, Brian. I'm excited to be here. Brian Milner (00:13) Very excited to have Tali with us. She is a job interview coach so you can kind of See the direction we're going in here one of her tagline is that she she helps you know professionals get offers they're really excited about and She's got some really interesting insights here because I know in today's world in today's environment There is a lot of shifting going on. There's a lot of transitioning between different places of work. And that interview is always kind of the forgotten portion of it, right? You get past all the other stuff, you get to the point where you're in the interview. So Tali, from your perspective, I know you see and help a lot of people with that portion of it. What are some of the biggest mistakes that people make that you see routinely as you help people prepare for their interviews? Tali Shlafer (01:01) Yeah, absolutely. I think one of the things that you just mentioned where, you know, people really struggling with the interview piece, you do all this work in your job search to update your resume, update your LinkedIn network, all this stuff, and then you get to the interview and it's like, okay, we're close. It's actually the interview is actually a completely different stage than anything else. And one mistake that I often see people making is just the mindset around interviews. A lot of people think, if I'm great at my job, I'll just interview really well. Like I'm a top performer. I'm good to go. But interviewing is actually a skill that's completely separate from anything else we do in the workplace. It requires you to be able to articulate what you've done in the workplace and the results and the impact that you brought in a way that most of us don't have to do in our day-to-day jobs. And you have to do it better than everybody else. So just because you are a top performer doesn't necessarily mean that that translates into your ability. to talk about yourself and talk about your career, especially in a way that resonates with the specific job culture and the specific job that you're applying for. So I think that's kind of the top mistake that I would just from a mindset level, is seeing interviews as something that you're naturally good at rather than as a skill that you can really develop and build in order to set yourself up for success. Brian Milner (02:12) Yeah. Yeah, that's a great point because, know, just because, as you said, just because I'm a top performer in something that I do, have a huge skill set or knowledge area that I'm really good at, doesn't mean that I'm necessarily good at an interview process because it is kind of a whole set of other communication skills that you have to have in that kind of environment. I know when I've talked to people about it sometimes, they feel sort of this, I don't know, dichotomy a little bit back and forth about... I know I'm supposed to plug myself here. I know I'm supposed to kind of brag a little bit, but I also don't want to sound cocky. I don't want to sound, you know, I don't know, just brash or anything. How do you help people or what do you advise people about in that area? Tali Shlafer (03:06) Yeah, and I think this is really common for people who are top performers and people who are very team oriented and collaboration oriented. It's really difficult for those folks to go, hey, I did all this stuff by myself and to kind of put themselves in that spotlight. So it's a very common challenge. It's also very common for folks who are really good at their job and have been doing this for a long time to actually be able to articulate. what that secret sauce is, like why they're actually good at their job, which is part of the challenge. Remind me the question that you just asked. Brian Milner (03:38) No, I'm just, in talking about kind of like how people prepare for these kind of things, the way they communicate this stuff, sometimes it's kind of more this worry about am I being a little too overbearing or brash in how I'm bragging about myself? Will I come off seeming cocky? or overconfident, how do they walk that fine line? Tali Shlafer (04:03) Yeah, I think this is a really big mindset piece where a lot of people who are those top performers and are very collaborative in nature are afraid to talk about themselves and be in the spotlight and kind of take credit where, especially in something like in the agile world or project management, product management, it's a very collaborative space. people are afraid to like, people are afraid to say, here's what I did. And Part of the mindset shift that I really encourage clients and job seekers to have is rather than to see it as, hey, the interview is all about you and the spotlight's on you and you're a used car salesman trying to promo yourself and it feels really icky so we don't want to do it. We end up not doing it at all. Think of it rather as you're trying to help this employer solve a problem. You're on the same side of the table with them. You're essentially a consultant for them. Their problem is... Hey, I've got this role. I have this challenge in my company. I have this opportunity. I have this thing that I need help with and I need to find who's going to be able to help me do that. And so you're essentially being an advisor for them and sharing here's how my previous experiences and what I've done in the past might be able to help you with your challenges. So it's really, it's really a partnership type of conversation where you're exploring, well, what are you struggling with? and how, let me share ways that I think I might be able to help. I think having that mindset is a lot more helpful for people who are more collaborative in nature. I think there's also a part of it that is getting really clear on how your work has actually delivered results. Being really confident, a lot of folks who are more collaborative in nature, which is a lot of people that I work with. tend to really get stuck in the we. So they say, we deliver this, we manage this, we strategize in this way. And then the interviewer ends up losing the thread of, well, what did this person sitting across from me do? What did they lead? What did they manage versus what did they do collaboratively? so getting really clear and even getting some language around how to talk about your contributions with respect to the team. So saying, I led this strategy session or I facilitated the collaboration of this, or I made the suggestion to people who then made a decision. Those kind of nuanced pieces of communication can help us feel more comfortable with actually owning our story in a way that doesn't feel gross. Brian Milner (06:39) Yeah, I think you make a great point there about the partnership aspect of it because having been on both sides of the table there, I know when I was hiring people as a software manager of some kind, the thought is always when the person comes in, you want to hire them. When they've reached that stage, when you finally bring them in, you're excited about the people that you decided to bring in and you're pulling for them. You want them to actually be successful. So I think it's important to keep that in mind too, that they want you to be successful. They want that role filled or they wouldn't have put out the job wreck and all the other things. If you, so let's just kind of talk through on a practical level. If you, you've done the work, you've put out the resume, you've got the call, maybe you've even gone through, well, I guess we should talk about that as well. Kind of the difference between a virtual or phone interview and an in-person interview. Is there a difference in level of prep or in how you, you know. tricks to being more successful if it's virtual versus in person. Tali Shlafer (07:50) I think the preparation itself should be the same. At the end of the day, your preparation should be about what are the challenges that this company, that this organization is facing and how does this role help solve those challenges? What are the skills? What are the top five skills that I need to demonstrate? Hard and soft skills. And in order to show them that I can be the top performer for this role and what are stories that I can share for each one of those skills. to prove that, I have what it takes, I can actually walk the walk as well. I've gotten results in this area before. So the prep work itself in the days leading up to the interview should be more or less the same. I would say the difference between a virtual interview versus an in-person interview is just people's comfort level. I think a lot of people are really comfortable in in-person interviews because it feels like you're actually talking to a human, right? You have a full-size person sitting across from the table from you. So it's a lot more comfortable. And I think even though through COVID, we had a lot more virtual conversations, there's still a very performative feeling element to it when it comes to virtual interviews. So one of my top tips for virtual interviews is please turn off your self view. So if you're in the Zoom call and if you're in a meeting, because it makes people so nervous and self-conscious. So when you get on that Zoom call, that Teams call, whatever platform you're using, make sure you're in the frame, right? Make sure that your lighting is good, all that stuff, and then turn off that camera so that you're not just watching yourself and being super self-conscious the entire time. Because think about it, in what other context in your life, when you're having a conversation with someone, do you have a mirror that you're looking at? Brian Milner (09:36) Right, right, I mean, if you're in their interview room, unless there's a mirror all the way around, you're not really getting that view. And even if you did, you probably wouldn't watch yourself in the mirror the entire time. So yeah, that's a great tip. And I think you're absolutely right. It can lead to being very, very self-conscious then. I think it's, I want to go back a little bit to the prep because I think your tip there is a really important thing is to try to understand the challenges, understand what it is they're looking for. And it just struck me as you were saying that it seems very similar to, in my kind of line of work, I do a lot of consulting work with people. And when I have a client that's a prospective client, it's almost the same thing. where you have to research a little bit about the company ahead of time. If you're doing kind of a sales call prior to the engagement, it's very similar. And I just thought about that. There is an overlap there between that and job interviews because you are selling yourself. You are selling your services to that company. Tali Shlafer (10:36) And a lot of people, here's another mistake that a lot of people, a lot of well-meaning people make is as part of their prep work, going online and finding a bunch of questions that they can then prepare for. So it's a very, I kind of call it whack-a-mole where, hey, let me try to figure out all the possible questions I might get asked and write out answers for those. Brian Milner (10:51) Ha ha. Tali Shlafer (10:59) That might get some people results. And if it's getting you results, that's great. But what I really encourage people to do is really reverse engineer your talking points from the job description, from what you know, even, you know, once you've had the conversation with the recruiter, you know, a little bit more about the position than maybe is even listed on the job description. So compile everything that you know about this opportunity and figure out, okay, what are the most important things for me to be able to articulate rather than just guessing at. random questions that the internet says you might get asked. Brian Milner (11:32) Yeah, that's a great point. I know we all want to get past that and get to the job, but I think there's also an element there of, let's say you do memorize these questions and they just happen to ask you the exact questions you had prepared for. If you don't really have that knowledge, then you're not going to really do well in that job even if you get it. So it's almost a blessing to not get that job, you know, if you didn't know that information, because they're going to be counting on you to do that. And you're not going to be a you're not going to do your job well then. Yeah. Tali Shlafer (12:06) Yeah, and the memorizing piece that you just mentioned is really, really easy for people to fall into the trap of trying to memorize their answers, especially with chat GPT and AI. Everybody's thinking, well, let's use these AI tools to help us come up with interview answers. so we plug in, job seekers will plug in, here's a bunch of questions that I might get. Look at my resume, tell me how can I answer these questions? And it feels safe. It feels like, this very smart robot or technology is gonna say this in a better way than I can. Brian Milner (12:36) you Tali Shlafer (12:40) But it really sets people up for failure most of the time because number one, most people aren't good at memorizing things, right? Most of us don't have to do that as our job. So most of us are really bad at memorizing. Number two, it makes you sound like a robot. It doesn't sound human. You lose the attention of the person who you're talking with. And number three, doesn't when you just memorize answers rather than thinking about it as what are talking points that I can riff off, riff on and kind of reuse and recycle and tell stories with. When you memorize, it puts you in the position of, well, yeah, it's great if they ask you that exact question. And some questions you will get asked, like tell me about yourself, you're going to get 99 % of the time. But for the most part, if you memorize a set of 10 questions and one of those questions gets a slight variation, or they ask a question that's not on there, you end up panicking. You don't know how to think on your feet because you're reliant on your tool. You've used AI or you've used your script as a strategy rather than a tool. Brian Milner (13:42) Yeah, that's a great point. I'm kind of wanting to get your take on this because this is a big thing that I know often comes up in these kinds of interviews is those questions that we all hate to get that you just know, no one ever knows how to answer these things. So I'm just curious how you advise people, you know, the awful question like, you know, give me some of your weaknesses or give me some of the things that you're not good at. How do you advise people to handle those kind of questions when they get asked in interviews? Tali Shlafer (14:14) Yeah, so there are definitely some questions that we tend to hear more often than others, especially when it comes to those recruiter interviews. The tell me about yourself, what are your strengths? What are your weaknesses? Tell me about a time you had to deal with a conflict. Tell me about a time you had to deal with a mistake. Those are pretty common, I would say, in that initial recruiter conversation. It's always an interview in my book. The weakness question I know is one of the that and the tell me about yourself is what really stresses people out. Brian Milner (14:40) Ha Tali Shlafer (14:43) My general advice for the weakness is actually something that I heard Adam Grant, who's an organizational psychology at Wharton share, which is pick something that is real but not disqualifying. So if you're an Agilist, your weakness should probably not be scrum or not be, you know, understanding business requirements. But it could be something like public speaking. Brian Milner (15:00) Ha Tali Shlafer (15:08) Or it could be something like delegating, where, you know, it's something real and it's not... It's something authentic. Authenticity is really, really important, especially nowadays in interviews. But it doesn't stop you from being able to perform well. So what I typically advise is pick a weakness, like Adam Grant says, that's real but not disqualifying. And this is important, and where a lot of people miss out, share what are you doing to actually address it? Because what we want to do, the point of that question isn't tell us what's wrong with you so we can judge you and disqualify you from the job. It's the subcontext of it is do you have self-awareness? Are you somebody who is aware enough and humble enough to know your shortcomings? And are you someone who's proactive about fixing them? and about becoming a better person. So the second part of that answer should be, well, what have you done to try to improve? What are specific steps that you've taken in order to improve? Brian Milner (16:09) Yeah, that's a great response. I know I've heard the traditional, you try to say one of your strengths as, I guess my weakness is I work too hard, like that kind of thing. Which I agree, it's not sincere. If I'm hearing that and I'm interviewing someone, that could disqualify him in my book, because I could think, this person is not going be honest with me. ⁓ Tali Shlafer (16:20) Yeah. or the I'm a perfectionist piece? The most common answer to that question. Brian Milner (16:33) Alright, I'm a perfectionist, right? Yeah, exactly. Well, you hit on the other big one too, the tell me about yourself. How do you advise people to handle that? Do you have a script in mind? you kind of detail out a couple of things? What's important to hit when someone asks you to just tell me about yourself? Tali Shlafer (16:54) Yeah, I'm a big fan of formulas over scripts. So I'll share my formula, but let me share a couple things that derail people. Let's kind of establish what's not helpful. And then we can kind of talk about this formula, which by the way, lots of different career coaches have different formulas. There's not necessarily one that works. It's just pick something and learn to do it really well. A lot of people will go in and start well. I graduated from the University of Washington in 1995, and they give kind of their entire history. And we lose the interviewer right away when we do that. So rather than giving them a chronological history of everything that's happened in your career and asking them, when we do that, we are essentially asking them, hey, here's all this information and data. You make sense of it. You figure out how it's relevant to you. I think it's actually really kind to use a formula to help them understand. Here's everything you need to know about me as it pertains to this role. So taking everything, taking your history and your career through the filter of what is important to demonstrate for this role. So the formula that I teach is sharing a super quick background. Hey, I'm Tali, I've been a project manager for the last 10 years. That's not true, that's not, let me reset that. So I think starting with a very brief. Brian Milner (18:12) You Tali Shlafer (18:16) sentence about yourself, your relevant role, how long you've had experience. Hey, I'm John. I've been project manager for the last 10 years, sharing the three key skills that you need to have in order to succeed at this job. And for each of those three skills, can you list an accomplishment or a metric or a success story? And we're not telling a whole story. We're just giving them here's the highlight reel, here's the headline, and then you'll click into all of those stories later. So quick little background about yourself, three main skills that you've developed that are relevant for this role, and super high level accomplishment to demonstrate those skills. So that's a little bit, that kind of is the first half, and that talks more about your previous experiences. And then in the second half of this answer, we want to pivot it to the future. So the first half is really about the past, it's about yourself. And then in the second half, we want to pivot to the future. what are you looking for in your next role? And hopefully that thing is also in that, that whatever you're looking for in your next role should dovetail really nicely into what they're offering as a company and as, as a, as an organization. What are you looking for specifically in your next role? And why are you so excited about interviewing with this company? And we want to share something really specific that We want to share something specific that feels personal. Where a lot of people go wrong is they'll share something like, I really want growth in my next role. And I'm excited about this team because I know you guys really value innovation. That doesn't really tell us anything. So we want one level of detail lower. So I'm really excited. What I really want in my next role is more leadership opportunities, so opportunities to mentor. And I'm really excited about this particular opportunities because I looked on your website, I looked at your blog posts, I looked at your, you know, CEO's posts that they share on LinkedIn. And I can tell that this is a really important part of your culture is being able to mentor people up into higher positions, right? Getting that specific, and there's not a right answer. I remember when I was interviewing for... out of college, I was interviewing for T-Mobile for an internship. And my answer was, I've talked to a lot of people, I've networked with a lot of people at T-Mobile. And one thing that really strikes me is the fact that a lot of people will leave for local companies like Microsoft, Amazon, and then they come back. There's a lot of people who spend a lot of time here. really does. There's a lot of loyalty and the culture, like I shared things that are specific to the culture and there's not a right answer here. It just needs to be. specific and it needs to be something that when you talk about it you kind of start getting butterflies because that's contagious. Brian Milner (21:07) That's awesome. Well, I want to ask about kind of the other half of the interview or the other portion of the interview as well. They, you know, I often hear people say, you know, you should walk into the interview understanding that it's a two way interview. They're interviewing you, but you're interviewing them as well because you want to know, is this the right place for me? So I can make the right decision about where I'm going to end up. What kind of things do you advise people to ask about or to focus on? What are some things that might expose some hidden things about the organization, warning signs or anything like that that might pop up in an interview to ask about? Tali Shlafer (21:45) That's a really good question. think one thing, it really depends on the opportunity and what you're looking for. So I don't think that there's one magic question that if you ask it, oh, the person's gonna be super impressed. Let me back up. What I really like about what you just said, is the framing of the questions that you ask at the end as a two-way conversation and as a way for you to understand more about the company so you can see if it's a good fit. I think a lot of people, especially in tough job markets, tend to kind of close their eyes and hope they get something and they almost blind themselves to the fact that they need to also do the work to make sure that it's a good fit. Or I see a lot of people who go, well, what can I ask that's impressive? What questions can I ask that's going to really wow them at the end, rather than seeing it as an opportunity to really understand what they offer more? So I would sit down and prioritize what is really important for you in a culture. if getting feedback, if growth is important for you, making sure to ask about, can you tell me about recently on your team, somebody who was promoted or how you helped somebody grow in the company? The best way that we can learn about something is through examples. The best proof that somebody values something is through the examples that they share. So we want to ask, kind of like you hear behavioral questions, you get asked, like, tell me about a time when. You can also use that, figure out what's important for you, and then create. Ask questions specifically about those things. One question that I think can be really helpful to get you to get a sense of what kind of person succeeds on this team and what the team really values is kind of the inverse of that. can you tell me about, can you tell me about what type of person doesn't do well here? Because then if they say, you know, The type of person who doesn't do well here isn't committed to working 60 hours a week. They expect to take their vacations and not be able to unplug. That kind of being able to hear who isn't successful gives you some context around some of their values as well. Brian Milner (24:01) Yeah, that's an excellent question because I agree. Presumably, this is someone you're going to be working with if you get the job. That immediate relationship, think, is going to really be impactful on the expectations, that sort of thing. Yeah, if I'm interviewing and I ask that kind of question, and they do come back and say, yeah, the person who doesn't work 60 hours or anything. Yeah, that's a good sign that maybe this is, I don't know, unless I enjoy working 60 hours a week, that maybe this is not the right cultural fit for me. So that's an excellent question, because I think that would expose some of that behind the scenes stuff, cultural things. ⁓ Tali Shlafer (24:42) And you really want to ask about questions about your dynamic with the manager. So what kind of people succeed under them? Because that's the number one people. I believe I'd have to fact check this, but you always hear that the number one people reason people don't like their jobs or people leave their jobs is because of their boss. So you want to understand you're essentially going on a date with them and you want to understand what is it like to hang out with you for 40 hours a week? Brian Milner (25:05) you Tali Shlafer (25:09) So asking specific questions to really understand what's their working style, what are their expectations, what are their positive experiences, what does feedback look like? Is it a once a year thing? Is it a every time we touch base during our one-on-ones you get feedback? That is really important. The other thing that's important to think about is do you understand the role itself? Like what questions do you have? What gaps in your understanding do you have about the role? Really clarifying to make sure that you know what you're signing up for. Brian Milner (25:40) Yeah, that's a great response as well. I know I remember from back in the day getting told that it's a good kind of question to ask what would success look like? If you really got someone to nail this and you were really happy with the hire and it was perfect, what would be the biggest thing that would contribute to that? And I've always liked that approach as well because it kind of gives you the expectation from the start to know here's what's most important in that manager's mind of what they're looking for. Yeah, just in my memory of interviewing people, would say I've never, I don't think I've ever not hired someone because of a question that they asked at the end, but... I have felt sometimes like when they don't ask questions that they're a little unprepared. Tali Shlafer (26:30) Yeah, and I think it, I think part of the not asking questions, one is being not prepared, not thinking thoroughly about the job. But it's also a little bit of a sense of desperation, like, I've been applying for four months, I don't care, I'm willing to take anything. So I don't have questions, because let me just take any first job that comes available. There's kind of that mindset. And I think it manifests as, I don't have any questions. And I think Brian Milner (26:48) You Tali Shlafer (26:58) People can kind of feel that when you're not critical, when you're not trying to figure out, am I really going to be able to succeed here? People kind of pick up on that and it either looks like desperation or it looks like disengagement and disinterest. We want people not, we don't want to hire the first person off the street who can do the job. We want to hire somebody who's excited to be there and who we know isn't going to leave six months later when they find something better. Brian Milner (27:23) Yeah, that's really good. Well, this has been really enlightening. I think there's a lot of gems in here that I think people can apply. we all find ourselves in that position from time to time of having to interview for things. As I said, even as a consultant, it's an interview when you talk to a potential new client. So I think these are all really great tips for that. We're going to make sure that there's contact information for Tali at the show notes of this so you can get a hold of her. Anything you want to shout out about, any places you want to point people to to get in contact with you? Tali Shlafer (27:56) So for the last few years, I've been posting usually about two short form videos a day to LinkedIn, all the social medias. Over the last couple of years, I've posted over 700 short form videos on social media. I've actually had over a hundred million views on LinkedIn, which is really crazy. Somebody recognized me at the dog park the other day, which was wild. But I created an interview tip-ball that took the best... The most helpful videos the ones that have gone viral received the best feedback gotten people the biggest results in their interviews And I compiled them all in one Interview tip bolt so that's my little thing that I like to share with people You'll see everything in there from how to tell me about yourself To answering why do people ramble and what other mistakes are people making? and also special tips for senior leaders and executives. So that's my little freebie that I like to share out for folks who are interested in the stuff that I'm talking about. Brian Milner (28:56) Awesome, awesome. we will definitely make that available to people in the show notes and links to your socials as well so people can follow you and stay on top of your tips as they come out. So thank you so much for coming on, Tali, and I appreciate you spending some time with us and sharing your knowledge with us. Tali Shlafer (29:13) Thanks so much, Brian. It was a pleasure.

Strong teams and transformed product practices drive growth. In order to drive outcomes using software and build great product teams, you need to drive speed to value and adapt quickly. The problem is, technology teams and business teams are often disjointed and lack clarity around each other's “why.” Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. In this first part of a continuing series on the Convergence podcast, Ashok Sivanand and Bailey O'Shea, Head of Product at Integral, explore 9 conversations essential for the success of product teams that are too often forgotten. These conversations are cultivated from the years of experience Ashok and the team at Integral have consulting with some of the best product makers in the world. This discussion is vital for product managers and team leaders, offering an in-depth look at the nuanced dialogues that shape a product's journey from ideation to market execution. Learn about the often-overlooked discussions that can significantly enhance agility, speed up market delivery, and maintain team alignment as your operations scale. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Access Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Inside the episode... Understanding Communication Impact: Ashok and Bailey discuss how insufficient communication can severely affect team dynamics, decelerate processes, and impede agility. Critical Conversations for Product Teams: They highlight the crucial but frequently missed discussions necessary within product teams to prevent bottlenecks and foster a culture of transparency. Methods for Effective Dialogue: They share detailed strategies on facilitating these conversations to ensure comprehensive alignment across roles from engineers to product managers. Practical and Theoretical Insights: The episode offers practical examples and theoretical insights to help listeners understand the application of these conversations in real teams, along with the foundational theories behind their significance. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

Today's episode of the Punk CX podcast is with Greg Kihlström from The Agile Brand. Greg is a best-selling author, speaker, and entrepreneur, and serves as an advisor and consultant to top companies on marketing technology, marketing operations, and digital transformation initiatives. A couple of months ago, Greg invited me to be a guest on his show, and we took the opportunity to meet up and record the episode while he was in Scotland recently on vacation. We covered a lot of ground, including the state of customer experience, what brands get right and what they don't and hyper-personalisation. It went so well I thought I'd release it as an episode on the Punk CX podcast too. This interview follows on from my recent interview – Envisioning a personal AI agent for every customer – Interview with Malte Kosub of Parloa – and is number 552 in the series of interviews with authors and business leaders who are doing great things, providing valuable insights, helping businesses innovate and delivering great service and experience to both their customers and their employees.

The agile brand may have become toxic, but your skills haven't lost value. If you're struggling - listen or watch as we discuss the valuable skills you have and how you might apply them in future roles. Founder & CEO Alex Polyakov returns to the podcast, joining Product Manager Brian Orlando and Enterprise Business Agility Consultant Om Patel for a discussion about the market shift that has taken place and how people avoid being held back by outdated terminology!One immediately actionable piece of advice?Reframe your experience in business terms, such as:What impact did your presence bring?How did you save money or drive revenue? How did you improve speed to market or decision-making? What deep organizational problems did you solve? These are executive-level skills that could translate to Director and VP roles. This work hasn't disappeared - it's evolved and so should your career positioning. #BusinessConsulting #Leadership #AgileIsDeadLINKSWatch it on YouTubeYouTube https://www.youtube.com/@arguingagileSpotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Website: http://arguingagile.comINTRO MUSICToronto Is My BeatBy Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

In this episode of the Mob Mentality Show, we explore Agile Manifesto Principle #11: “The best architectures, requirements, and designs emerge from self-organizing teams.” This principle often sparks debate. Can teams really create great architecture and design without top-down control? Can autonomy be granted when the team isn't ready for it? Does self-organization only work when the right skills, trust, and shared values are already in place? Can control without competence cause chaos? We dig into what it really means for modern teams and why it's still controversial today. Topics covered in this episode include: Why is Agile Manifesto Principle #11 frequently misunderstood in organizations? What dangers arise when control is handed over without building XP competence first? How can mob programming and collective learning raise a team's ability to self-organize effectively? What role do psychological safety, trust, and leadership support play in enabling autonomy? Why must Agile principles be applied together rather than in isolation? How does Principle #11 connect to Lean thinking and the reduction of common wastes in software development? What real-world lessons show how solid architectures can emerge naturally through collaboration? What practical advice can leaders and agile coaches use to balance empowerment with readiness? The conversation highlights both the promise and the potential pitfalls of applying Agile Principle #11.  This episode is useful for anyone who works in software development, engineering leadership, product management, or Agile coaching and wants to understand how to create conditions where self-organizing teams thrive instead of flounder. Video and Show Notes: https://youtu.be/lTPtr8t3yaM  

Salum Abdul-Rahman: From Isolation to Integration—Rebuilding Agile Team Connection For Remote Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum describes working with a grocery ecommerce team during COVID that fell into the trap of prioritizing individual convenience over team collaboration. Remote work led team members to design their work around personal preferences, with the lead developer becoming increasingly isolated and unresponsive to team communication. This anti-pattern of "what works for me" over "what works for the whole team" created significant dysfunction. Despite management intervention, the situation required creative solutions like organizing face-to-face sessions and shared working sessions with digital whiteboards to rebuild team cohesion. Featured Book of the Week: Agile Retrospectives One of the most important roles of Scrum Masters is to help teams develop themselves. Salum emphasizes that you can't tell the team what to do - you have to help them discover it themselves. "Agile Retrospectives" provides the foundation for running meaningful retrospectives that become the key tool for team self-development. The book's emphasis on variation and building retrospectives to match your team's needs and maturity level makes it essential for empowering teams to grow and evolve continuously. Self-reflection Question: How might your team's current work arrangements prioritize individual convenience over collective effectiveness, and what steps could you take to shift this balance? [The Scrum Master Toolbox Podcast Recommends]

Are You Chasing ScrummerFalls?You can be pure Agile, you can be pure Waterfall, but have you ever been Waterfalling Agile? I have seen Waterfalling Agile, and it's not a good scene. Essentially, when you are doing the worst of both worlds, thinking you are on top by taking the best of both, but you are wrong.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Mark Condon, founder of QuantumWork Advisory (QWA), joins us on this episode of The New Talent Code to explore how HR can evolve in the age of AI. We discuss why agility — not skills — should be the starting point for workforce transformation. AI agents are moving the conversation from the theoretical to the tangible applications of what HR can achieve with this growing technology. Condon also shares QWA's “5B model” (build, buy, borrow, bot, bundle) as a framework for shaping the workforce of the future. He highlights the critical need for HR leaders to step into a more strategic role — one that impacts every employee, not just the HR function. Additional takeaways: - Why HR should lead the charge on AI governance and partner with IT to manage emerging risks. - The role of work design — breaking down tasks and redesigning roles — in making organizations more agile. - How storytelling and transparency help overcome leadership hesitation and employee fears around AI. - Why ROI from AI and workforce transformation can be far greater than cost savings alone, creating lasting value for both businesses and employees.

Salum Abdul-Rahman: The Expert Who Couldn't Connect: An Agile Team Integration Challenge Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum shares a challenging situation where a software architect with deep expertise struggled to integrate with the team. Despite the architect's technical knowledge, his expert-based communication style and inability to justify reasoning created friction with other developers. The conflict escalated when the architect disengaged from teamwork and ultimately left the company. This experience highlights the importance of understanding organizational dynamics in large corporations and recognizing when separation might be the best solution for everyone involved. In this episode, we refer to Nonviolent Communication, a topic we've discussed often here on the podcast.  Self-reflection Question: How do you balance respecting expertise while ensuring all team members communicate in ways that foster collaboration rather than create hierarchies? [The Scrum Master Toolbox Podcast Recommends]

Irene Castagnotto: Building Bridges—How Great Product Owners Create Team Alignment Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Building Trust Through Transparency and Purpose Irene emphasizes that exceptional Product Owners excel at building trust with their teams by consistently sharing the "why" behind decisions and features. They trust their teams completely and ensure that team members understand the purpose and reasoning behind every request. This transparency creates a foundation of mutual trust where teams feel confident in the Product Owner's direction. Great Product Owners use moments when features don't work as expected as opportunities to explore and reinforce the underlying purpose, turning potential setbacks into learning experiences that strengthen team understanding and alignment. The Bad Product Owner: When Stories Replace Truth Irene witnessed a Product Owner who, when facing difficult client conversations without positive information to share, chose to "make up stories" rather than being transparent about challenges. This lack of honesty led to delivering something the client couldn't accept, resulting in an angry client during the demo. This anti-pattern of using "good words" instead of honest communication ultimately damages client relationships and team credibility. The lesson learned: Product Owners must be transparent with clients about what is and isn't possible, even when the news is difficult to deliver. Self-reflection Question: How do you balance protecting your team from client frustration while maintaining the transparency necessary for successful product development? [The Scrum Master Toolbox Podcast Recommends]

For most of us, workplace engagement isn't a solo sport—it's a team one. The ADP (yes, the payroll people) Research Institute's study across 19 countries found that most of us, regardless of company size, are immersed in team life. In companies of 150 or more employees, 82% of employees work on teams, and nearly 3/4ths juggle more than one team. Even if your employer has fewer than 20 people, 2/3rds of us are teaming up on one, two or even three teams. This matters: team membership doubles our odds of scoring high on Gallup's engagement metrics, with this research concluding that the sweet spot belonging is being on five distinct teams. It is not just the number of teams, but whether we trust the team leader that can make us 12 times more likely to be fully engaged. Let's go back to the holy grail of Google's Project Aristotle, which took team-obsession to a new level.  Google spent twp years studying 180 teams to crack the high-performing team code. They discovered that talent and resources aren't the magic ingredients—they're just the gravy. The meat and potatoes or tofu and rice for the team? Psychological safety—the freedom to speak up, take risks, and make mistakes without fear of public humiliation. It turns out, when people feel safe to contribute, they get bold, creative, and collaborative.  Leaders create psychological safety with dependability, structure and clarity, meaning, and impact.  McKinsey's research builds on this, showing that effective teams come in different “archetypes.” A cycling team is like a NASCAR pit crew—specialized, coordinated, but with independent metrics. Agile software teams are more like relay squads—high interdependence and shared outcomes, where dropped balls ripple through the race. Surgical teams? Think rowing crew—total synchronicity, clearly defined roles, and an unshakable sense of belonging.   To truly hum, teams need to tend to their “health drivers,” grouped into four areas. Configuration means having the right roles and perspectives. Alignment is clarity on purpose and shared commitment. Execution covers collaboration, communication, decision making, and feedback. Renewal—the often-overlooked one—ensures long-term sustainability through belonging, psychological safety, recognition, and trust. Not every team needs to nail all of the team health drivers - of the 17 identified health drivers even top performing teams are only “very good” at about 11, which is like a C-! Four health drivers stand out as the performance heavyweights: trust, communication, innovative thinking, and decision making.  Much of this is what we know - what is surprising is that just getting some of the elements that create healthy and effective teams right is a game-changer in the workplace.

Summary Have you ever wrapped up your workday thinking, “I've been busy all day, but I'm not sure I actually made anything better”? If so, you're not alone, and today's guests are here to help you break that cycle. In this episode, Andy talks with Don Kieffer and Nelson Repenning, co-authors of the new book There's Got to Be a Better Way. Don is a former Harley-Davidson executive who led during some of the company's most challenging years. Nelson is a professor at MIT Sloan who studies why well-intended management tools often fail in practice. Together, they're helping leaders rethink how work actually gets done. In the conversation, you'll learn why so many teams get stuck in firefighting mode, and why that's often not a people issue but a systems issue. You'll hear how to spot the “firefighter-arsonist” pattern, why problem-solving starts with problem-finding, and what it means to “design for discovery.” We also talk about Agile, Lean, invisible handoffs, and even how these ideas apply to family life. If you're looking for insights on how to make your team's work more effective, sustainable, and human-centered, this episode is for you! Sound Bites “Most performance problems are not people problems. They're design problems.” “You get what you design for. And most work isn't designed at all. It just kind of happens.” “Firefighting is not a character flaw. It's a predictable output of a broken system.” “If you don't make the work visible, you can't improve it.” “When no one owns the handoff, it's not really a handoff. It's a drop.” “Success should be easy. That doesn't mean the work isn't hard, but the path to doing it well should be clear.” “Discovery isn't luck. It's a design choice.” Chapters 00:00 Introduction 01:49 Start of Interview 01:59 The Origin Story: How Don and Nelson Collaborated 07:36 Challenges in Implementing Business Tools 13:19 Dynamic Work Design vs. Traditional Methods 25:16 A Lesson from the Factory Floor 26:53 Identifying and Solving Problems in Teams 31:23 The Importance of Connecting the Human Chain 35:46 Making Work Visible: Strategies and Tools 40:34 Applying Work Strategies at Home 42:46 End of Interview 43:12 Andy Comments After the Interview 47:35 Outtakes Learn More You can learn more about the book and their work at shiftgear.work/theres-got-to-be-a-better-way-book. For more learning on this topic, check out: Episode 249 with Aaron Dignan about Brave New Work Episode 252 with Marcus Buckingham about Nine Lies About Work Episode 162 with Jonathan Raymond on culture and leadership mindset Thank you for joining me for this episode of The People and Projects Podcast! Talent Triangle: Business Acumen Topics: Leadership, Project Management, System Design, Agile, Lean, Problem Solving, Collaboration, Organizational Effectiveness, Continuous Improvement, Work Design, Team Performance The following music was used for this episode: Music: Quantum Sparks Full Version by MusicLFiles License (CC BY 4.0): https://filmmusic.io/standard-license Music: Synthiemania by Frank Schroeter License (CC BY 4.0): https://filmmusic.io/standard-license

Irene Castagnotto: The Risk-Aware Scrum Master: Preventing Problems Before They Happen Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene defines success for Scrum Masters as helping teams anticipate and manage risks before they become unexpected problems. She focuses on ensuring teams don't face surprise risks during sprints and don't start work with missing requirements. Her approach includes using user story mapping with Product Owners to visualize potential risks and maintaining team happiness as a key success indicator. For Irene, creating a positive team environment is a crucial deliverable that Scrum Masters must actively work on. She emphasizes the importance of listening to team feedback and regularly assessing whether the team feels supported and engaged. In this segment, we refer to W. Edwards Deming, and his famous quote “a bad system will beat a good person, every time!” Featured Retrospective Format for the Week: The Good/Bad/Risk Retrospective This retrospective format works particularly well with younger teams and uses humor to help teams discuss emotionally challenging topics. The format focuses on three key areas: what went well (Good), what didn't work (Bad), and what potential risks the team sees ahead (Risk). Irene recommends this approach because it helps teams surface risks that aren't visible to anyone else, creating opportunities to address potential problems proactively. By incorporating the language of risk into everyday conversations, teams become more aware of potential challenges and can plan accordingly. The humor element helps reduce the emotional intensity that often accompanies difficult discussions about team performance and challenges. In this segment, we refer to the book “How to Make Good Things Happen: Know Your Brain, Enhance Your Life” by Marian Rojas Estape. Self-reflection Question: How comfortable is your team with discussing risks openly, and what techniques could you use to make these conversations more approachable? [The Scrum Master Toolbox Podcast Recommends]

Nigel Thurlow previously served as the first-ever Chief of Agile at Toyota, where he created the World Agility Forum award-winning “Scrum the Toyota Way” and co-created The Flow System™, a holistic FLOW-based approach to delivering customer-first value built on a foundation of The Toyota Production System.Throughout his career, Thurlow has gained an enviable recognition as a leading expert in Lean and Agile methods, tools, techniques, and approaches. He specializes in developing effective organizational designs and operating models for organizations to embrace both Lean and Agile concepts. By leveraging knowledge from various sources, Thurlow helps optimize organizations to enact successful, long-lasting transformational strategies in applying Lean thinking, Agile techniques, and Scrum – while combining complexity thinking, distributive leadership, and team science, represented by a triple helix structure known as the DNA of Organizations™.As of 2024, he has trained over 8,500 people worldwide in Scrum, Agile, Lean, Flow, Complexity, and organizational design. Thurlow is a Professional Scrum Trainer (PST).An instinctive problem solver, Nigel Thurlow takes a method-agnostic, cross-industry approach in helping organizations find the right tools, methods, and approaches to overcome challenges within their contextual situation. He advocates for the fact that there is not a one-size-fits-all prescriptive approach to agility; all tools have utility, but they also have contextual limitations. From this vantage point, Thurlow equips an organization's people to become an army of problem solvers, expanding their perception of what they do so they can better understand and prepare for potential challenges along the way.Thurlow is currently the Chief Executive Officer at The Flow Consortium, a collection of highly regarded companies in the Lean and Agile world — as well as the scientific and academic communities at large. The Flow Consortium strives to expand the boundaries of current Lean and Agile thinking through the understanding of complexity thinking, distributed leadership, and team science by tapping into the minds of top thought leaders from these concentrations.While at Toyota, Thurlow worked to frame Scrum as more than just a standardized behavioral process by applying and advancing fundamental methodologies to spur innovative, forward-thinking solutions to Toyota's most complex challenges. He also founded the Toyota Agile Academy in 2018. These efforts signaled a transformative phase for Toyota, leading the company towards organizational agility and helping its team members better understand this concept in an automotive production context.Additionally, Thurlow has been a board presence at the University of North Texas since 2019, serving as an advisor to the Department of Information Science Board and a member of the College of Information Leadership Board. He has also served as the President of CDQ LLC since 2012. Prior to that, Thurlow held executive coaching and training roles for companies including Vodafone, Lumen Technologies, Scrum, Inc., GE Power & Water, 3M Healthcare Information Systems, Bose Corporation, The TJX Companies, Inc. – as well as the Commonwealth of Massachusetts. He has also taught Scrum at the Massachusetts Institute of Technology (MIT).As an author, Thurlow was named a Forbes top 10 author for co-authoring the book “The Flow System™” in 2020. He has recently co-authored “The Flow System Playbook” published in 2023 which presents a practical study guide and reference book to all the concepts covered in the first book.His other notable publications include “Introducing the Flow System (2019)” and “TPS and the Age of Destruction (2019).” He is also the co-author of The Flow Guide and The Flow System Principles and Key Attributes Guidebook. Recently, Thurlow co-authored “The Substrate Independence Theory,” a peer-reviewed scientific article

In this episode, Ashok sits down with Josh Seiden, author and product management expert, to explore key insights from Josh's latest book, "Who Does What by How Much." The conversation centers around using OKRs (Objectives and Key Results) to align teams and improve organizational outcomes. They examine the challenges many teams face when implementing frameworks like OKRs or Agile and emphasize the importance of understanding the "why" behind these systems. Josh also reflects on his early work, such as developing the Kensington Turbo Mouse and collaborating with Alan Cooper, widely known as the "Father of Visual Basic." Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Get key strategies for fostering a customer-centric culture, building effective product teams, and aligning leadership with team goals. Whether you're new to OKRs or looking to refine your process, this episode provides actionable advice for team leaders, product managers, and executives alike. Inside the Episode... The role of OKRs in driving business alignment and outcomes The importance of clarifying the "why" behind processes like OKRs or Agile Josh Seiden's background and his early design work with the Kensington Turbo Mouse Strategies for using frameworks to empower teams and avoid over-focusing on the process How to implement OKRs successfully and avoid common pitfalls The evolution of design thinking in product development Understanding the customer's role at every level of an organization Key lessons from "Who Does What by How Much" and Josh's other books Mentioned in this Episode: "Who Does What by How Much" by Josh Seiden and Jeff Gothelf "Lean UX" by Josh Seiden and Jeff Gothelf "Sense and Respond" by Josh Seiden and Jeff Gothelf The Goal by Eliyahu M. Goldratt "Outcomes Over Outputs" The Kensington Turbo Mouse Alan Cooper - The father of visual basic, author of About Face Book that every software designer should now - About Face by Alan Cooper Vitsoe Shelving Subscribe to the Convergence podcast wherever you get podcasts, including video episodes on YouTube at youtube.com/@convergencefmpodcast. Learn something? Give us a 5-star review and like the podcast on YouTube. It's how we grow. Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

In aviation, the most transformative breakthroughs often take place far above the commercial flight lanes, and far below the public radar.  But in today's defense and aerospace economy, those breakthroughs are harder than ever for small companies to bring to life.  Government budgets overwhelmingly favor the largest primes. Smaller, more agile innovators are forced to bankroll their own R&D while competing against firms with deeper pockets, stronger political clout, and guaranteed contracts.  Venture-style “build-to-flip” incentives tempt some to chase quick exits over long-term quality. Even when technology works, commercial adoption can stall as customers demand bespoke designs for each use case. Swift Engineering's record-breaking high-altitude glider is one such breakthrough fighting its way through that gauntlet.  Designed to fly at 67,000 feet for days at a time, this ultra-light, solar-powered aircraft can do what satellites can't: hold a fixed position, deliver real-time intelligence, and land on a runway. At just 1% of the cost. For Hamed Khalkhali, Swift's president, the innovation story isn't just about engineering excellence. It's about surviving and thriving in a system that often seems built for incumbents.  In this conversation, he unpacks the strategic, funding, and talent challenges that determine which companies survive in the next wave of aerospace innovation.   You'll also learn: High-altitude, solar UAV that outperforms satellites at 1% of the cost. Why system integration is aerospace's next frontier. The funding squeeze forcing small firms to self-finance R&D. The “moral accuracy” gap shaping U.S. drone strategy. How fresh grads can drive bigger breakthroughs than veterans. Keeping start-up creativity alive in bigger organizations. Guest Bio Hamed Khalkhali is the President of Swift Engineering and an adjunct professor at Cal Poly Pomona, with more than 25 years of experience spanning technical innovation, leadership, and cross-disciplinary communication. He brings over a decade of expertise in system-level design for Fly-by-Wire flight control systems with the highest safety standards (FDAL-A), along with deep knowledge of ARP-4752, DO-160, and DO-178 certification processes. Throughout his career, Hamed has led high-performance engineering organizations, managing teams across mechanical, electrical, verification and validation, manufacturing, AI, machine learning, quality control, supply chain, and R&D. He is known for integrating manufacturing engineering into the earliest stages of design, optimizing products through rigorous processes such as Six Sigma, Lean, Kaizen, and design-for-manufacturability. His leadership approach blends technical precision with a focus on systems integration, efficiency, and innovation in both aerospace and defense. Connect with Hamed on LinkedIn.    About Your Host Craig Picken is an Executive Recruiter, writer, speaker and ICF Trained Executive Coach. He is focused on recruiting senior-level leadership, sales, and operations executives in the aviation and aerospace industry. His clients include premier OEMs, aircraft operators, leasing/financial organizations, and Maintenance/Repair/Overhaul (MRO) providers and since 2008, he has personally concluded more than 400 executive-level searches in a variety of disciplines. Craig is the ONLY industry executive recruiter who has professionally flown airplanes, sold airplanes, and successfully run a P&L in the aviation industry. His professional career started with a passion for airplanes. After eight years' experience as a decorated Naval Flight Officer – with more than 100 combat missions, 2,000 hours of flight time, and 325 aircraft carrier landings – Craig sought challenges in business aviation, where he spent more than 7 years in sales with both Gulfstream Aircraft and Bombardier Business Aircraft. Craig is also a sought-after industry speaker who has presented at Corporate Jet Investor, International Aviation Women's Association, and SOCAL Aviation Association.    Check out this episode on our website, Apple Podcasts, or Spotify, and don't forget to leave a review if you like what you heard. Your review feeds the algorithm so our show reaches more people. Thank you! 

Irene Castagnotto: Timing Is Everything - Learning When Agile Teams Are Ready for Change Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene shares a powerful story about discovering team dependencies and proposing solutions that management initially rejected. When her team identified that Epics weren't organized to avoid dependencies between teams, they proposed using a single unified backlog to manage these challenges. Despite the logical solution, management wasn't ready to accept it. A month later, the same management team returned with the identical proposal. This experience taught Irene that timing is crucial in change management—you don't decide when the right time is; the people involved determine their own readiness. She emphasizes the importance of socializing changes early and often, collecting feedback before proposing major transformations, especially when those changes affect management structures. Self-reflection Question: How do you balance persistence with patience when you know a change is needed but the organization isn't ready to embrace it? [The Scrum Master Toolbox Podcast Recommends]

On this episode of Data Driven, we venture into the ever-shifting landscape of software engineering, AI-assisted coding, and the sometimes chaotic future of development teams with special guest Thanos Diacakis—no, not the Marvel villain, but a powerhouse in software leadership whose career spans scrappy startups to tech giants like Uber.Hosts Frank La Vigne, Andy Leonard, and resident AI BAILeY welcome Thanos for an insightful, witty, and sometimes philosophical conversation about the promise and perils of AI in software engineering. From the rise (and risks) of “vibe coding” to the changing definition of good engineering, Thanos shares firsthand experiences, pitfalls to avoid, and why solid fundamentals matter now more than ever—even with AI churning out code at lightning speed.We also explore how AI is reshaping workflows for both solo developers and large teams, the difference between local and global efficiency, and how bottlenecks are shifting in this new era. Thanos breaks down his “seven mental models” for effective engineering, demystifies the right way to work with AI tools (instead of letting them run wild), and explains why junior devs still deserve a seat at the table.If you're curious about the real impact of AI-assisted coding, worried about the next wave of software “apocalypse,” or just eager for practical strategies to keep your teams productive and sane, this episode is packed with the wisdom, humor, and actionable takeaways you'll want to hear. Buckle up as we dive deep into the code base—this is Data Driven, where the only thing disappearing is inefficiency.LinksCosmic Teacups: https://www.cosmicteacups.com/The Goal 40th Anniversary Edition: https://amzn.to/4lGhZbI (Amazon affilliate link)The Goal Graphic Novel (Yes, really) https://amzn.to/47ohIXx (Amazon affilliate link)Time Stamps00:00 "Exploring AI Coding with Thanos"05:20 Revolutionizing Productivity with Code08:18 Cross-Platform Utility Development12:14 Database Costs Drop, Demand Surges14:43 Unauthorized Copying of Software Manuals17:54 "Chunked Narratives Enhance LLM Performance"19:43 Grox Impressive Despite Incompletion24:40 Reviving a Startup with AI28:53 Bottleneck Identification and Resolution Strategy29:37 Incremental Improvements Drive Success34:40 Agile's Evolution: Remembering Its Roots38:41 Balancing Features and Tech Debt42:50 Software Estimations: A Management Trap45:55 Managing Project Time Expectations47:47 Trust Building Through Incremental Delivery51:23 Language Models: Human Cognition Parallel?56:04 "Exploring Intelligence: Brains vs. AI"58:06 "Data Driven Episode Conclusion"

Join Brian and Barnaby Golden as they dig into a surprisingly common roadblock in Agile teams, the underpowered product owner, and how it quietly derails decision-making, flow, and team momentum. Overview In this episode of the Agile Mentors Podcast, Brian welcomes Agile coach and community contributor Barnaby Golden to explore the risks and ripple effects of placing a product owner in the role without the authority to own it. They discuss the stark difference between empowered and underpowered product owners, why availability without authority is a setup for frustration, and how misalignment at the leadership level creates more theater than agility. From trust gaps to political decision-making, Barnaby and Brian unpack the hidden reasons teams get stuck and what it takes to create real, empowered ownership that delivers actual value. References and resources mentioned in the show: Barnaby Golden #104: Mastering Product Ownership with Mike Cohn #3: What Makes a Great Product Owner? With Lance Dacy How to Engage and Help Busy Product Owners by Mike Cohn What Happens When For Product Owners Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Barnaby Golden is an experienced Scrum Master and Agile Coach with a knack for helping teams truly live Agile, not just adopt it. Lately, he’s been diving into the real-world use of AI—helping organizations, including nonprofits, turn tech hype into practical, high-impact tools with smart governance Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors Podcast. I'm here with you as always, Brian Milner, and we have a very special guest with us today. We have Mr. Barnaby Golden with us. Barnaby, welcome in. Barnaby Golden (00:14) Thank you, it's good to be here. Brian Milner (00:16) Very excited to have Barnaby here. Barnaby is an Agile coach, also a Scrum Master. He is known to us because he is part of our Agile Mentors community. And he is an active member there and has weighed in on several issues and helped people and mentored people through things there. So we wanted to share some of the wisdom of the crowd that we have there at Agile Mentors. Just a few select people that have really contributed. and giving us some really good advice there with the podcast audience as well. So you guys can kind of hear what kind of stuff is there on the Agile Mentors discussion forums. But we were talking about topics here with Barnaby about what we were going to talk about and he proposed one that I really found intriguing. It was focusing around the underpowered product owner, the underpowered PO. And I think that's probably a good place for us to start then, Barnaby. Why don't you kind of just explain to everyone what that idea is, what you mean by the underpowered PO. Barnaby Golden (01:12) Sure, of course. So in fact, what I'll do is I'll explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like? And I was working for an organization a few years back, it was a publishing organization. And we had the head of the editorial team was the product owner for a particular Scrum team. Brian Milner (01:16) Okay. Barnaby Golden (01:38) And this head of editorial had a lot of power and influence in the organization. They were pretty much a decision maker in terms of the products that the team was building. And I remember a particular conversation where the team was talking to this product owner and the team said, look, we know you want to get this, this release out this week, but we've got some technical debt. really need to fix it. And I remember the, this guy saying, look, okay. I'm going to let me think about this for a second. Okay. I can make the decision on this, which is, yep, you can have your time. I'll communicate with others within the organization. The release will be delayed. And that was such a powerful moment because in that second, the decision was made. The product owner trusted the team, the team completely trusted the product owner. And it felt slick and efficient and worked really well. Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role. So I've seen the situation where you have a whole hierarchy of product people and the most junior role in the product organization is the product owner. And what happens in that scenario is the product owner is powerless to make a lot of decisions. So they have to push them up the tree. And in that situation, the conversation between the team and the product owner is the team says, yeah, we need to do this thing. And the product owner says, okay, give me some time. Might be a day and I'll get back to you. Hopefully I can get in contact with other people within my hierarchy and the flows broken. What's the team going to do now? They're going to maybe find something alternative to work on. It's very frustrating. And you sometimes get the situation as well where the the underpowered product owner will sympathize with something the team is saying, but will not be able to make a change because they haven't got the authority to do the change. So they'll say, yeah, I agree with you. I know what you're saying. This is a really bad idea what's being suggested, but I have no choice. We have a roadmap. We've got to meet the roadmap. Brian Milner (03:45) Yeah, that's a clear picture. I agree with you that those are two stark contrasts. And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other, right? It's just, it's such a dramatic difference when that person is able to make the decisions on the spot. go forward, and the team is just free to move as quickly as possible. Whereas the other one, it's just holdups. It's just delays and obstacles, roadblocks in the team's way. So yeah, a really clear picture there. Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking about this. is trying to understand a little bit about the why behind it. ⁓ Because I think there's, just in thinking about it, I think there's maybe several causes for this or several things that might lead to having an underpowered PO. What's been your experience? What kind of things have you seen that might contribute to an underpowered PO? Barnaby Golden (04:36) Hmm. I think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend with the team. So you've got your head of product or the real decision makers in the organization. They are saying, I can't spend two, three hours a week with a team. I can't go to a planning meeting. got, you know, I'm a busy person. I've got things on my schedule. So they see the product owner role as a stand-in for themselves with the team. And this stand-in has lots of time to spend with the team, which is good. And that's a powerful thing. But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent. Brian Milner (05:41) Yeah, it's almost as if they just want a warm body there. It's a placeholder. You're here as a placeholder for me because I can't be two places at once. I've heard a couple of things that people will frequently point to that a product owner needs to be successful. And there's sort of this dichotomy of these two things that are part of that. And that's the kind of empowered Barnaby Golden (05:44) Yeah. Brian Milner (06:05) product owner that is empowered to make decisions versus having the availability to actually be present with the team. it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, hey, I need to make all the decisions, but I don't have the availability. and the people that they know have the availability, they don't want to empower to make the decisions. So they're kind of setting up their product owners to fail. Barnaby Golden (06:35) I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility. You can't just have a scrum team and say, well, that's where we'll be agile in this scrum team. The entire organization as a whole has to think in the agile mindset. And if you want to be able to adapt to change, then one of the ways you're to have to do that is you're going to have to have the decision makers close to the teams that are implementing the decisions. and so you can't have your, your cake and not eat it. If you see what I mean in terms of, you, you can't pick and choose the aspects of agile that you want. need to, as an organization, adopt the whole thing. Brian Milner (07:17) Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when you're trying to decide who's the right person to be the product owner for this team, those are two of the things you have to really consider strongly is does this person have the availability to be here with the team and is this person empowered to make decisions? I've run up against leaders before that don't want to empower someone and Kind of the counterpoint I give them a lot of times is, I don't know, I think maybe in their head they're thinking this is giving someone free reign to make really long-term decisions on their own when that's not really the case. The product owner can be fully empowered, but the decisions that they're making on the spot are just a couple of week decisions. It's not a six month decision. there's gonna be sprint reviews, we're gonna display stuff and get feedback and we can course correct and all those things. So once you can kind of put it in that frame that it's really just a couple of weeks that you're empowering them to make decisions, I've had more success framing it that way. I don't know, what about you? Barnaby Golden (08:23) Yeah, I think that makes a huge amount of sense. The fear is loss of control. So the fear is that by empowering the product owner, they might do something which they would regard as a mistake. And they will often see themselves, because they're in a senior position, they see themselves as being responsible. So if they're responsible and the product owner makes a decision they don't like, perhaps that will reflect poorly on them. So there's a trust issue here. A good product owner is going to be consulting their stakeholders anyway. And I would think the, the senior product leadership team is part of their stakeholders. So you would hope that they were keeping them very, very up to date on their thinking that there would be no great surprises that they wouldn't do something, you know, suddenly switch from one product to a completely different product. They would always be keeping their stakeholders in the loop. And in which case. they would be building up the trust of the people around them and then you would hope that over time that they would become more empowered. Brian Milner (09:23) Yeah. Yeah. I just, I kind of wonder if that's maybe part of it, that the, they have a misunderstanding of kind of how the role works. You know, cause maybe they, maybe they see it as completely independent. This person is just making decisions on their own without consulting anyone. Maybe that's because that's how they do their job. Barnaby Golden (09:35) Yeah. Yeah. Brian Milner (09:49) So they may look at that as, know, this is how I would do it, so why wouldn't this person do it the same way? Well, that's not how it's designed. It's designed to be done in concert. Barnaby Golden (09:59) Yeah, absolutely. Yeah, it's a misunderstanding of the product owner role. And it's also a misunderstanding of why the product owner role came about, which is the reason it was there was to solve the problem of too many chefs, of too many people trying to make decisions. So there's huge value in the role. But the value in the role only comes about if that person can actually take ownership of the product. I mean, the clue's in the name, isn't it? They are the owner of the product, so therefore they can make the critical on the ground decisions, but all the time talking to their stakeholders. So, I mean, as with many things in Scrum, it's about a misunderstanding, a general misunderstanding of what the roles are within the Scrum team. Brian Milner (10:41) Yeah, I think they also have the fear of the wrong decision that somehow that's going to lock them in or this person's not equipped to make the right decisions that they are the knowledge expert for the product. so they should be the one making all the decisions. They have the authority. I have had a couple of cases where I've had to have difficult conversations with leaders to say, well, let's examine the decision. because you're looking at them as making the wrong decision, but is it the wrong decision? You're disconnected from the day-to-day of the team. This person is fully connected to the day-to-day, and they're more likely to have more current knowledge. And it's not always the case that just because you assume it's the wrong decision that it actually is, they may actually be right and you could be wrong. Barnaby Golden (11:30) And funny enough, this brings on to another topic I'm greatly interested in, which is the definition of value. And that is if there is no clear understanding within the organization of value, then decisions become arbitrary. You know, we decide to do X rather than Y in the product. Well, why did you decide to do that? Well, because it was my decision to do that. Yeah, but is there a rationale behind it? Do you have a definition of the value of X and the value of Y? and why you chose one over the other. And I think that's part of the problem as well. The kinds of organizations that don't have empowered product owners also typically don't have a definition of value. Brian Milner (12:08) Yeah, I completely agree. I know I've had conversations in classes where I've talked to people about how when you're prioritizing, when you're looking at things in your backlog, and we always say you prioritize according to value. Well, what's the value? What's the value of doing that thing? And so many times, I think there are organizations that can't really identify what it is. Why are we doing this thing? because it sounded cool, because it seemed like the right thing to do, it just felt right? No, we're doing it so that it does something, it creates some outcome for us. And if you can't even really define what that outcome is that you're hoping it achieves, well, isn't that the start of the problem? Barnaby Golden (12:55) And I think part of the root cause of that as well is the tendency for these types of organizations to do long-term planning. So what they'll often do is they'll have a roadmap for the year and they'll say in this roadmap for the year, we will achieve all these things. And then it becomes less about delivering value and more about delivering the roadmap. And I've had conversations with product owners where I've said to them, you do realize what we're doing doesn't make sense. And they say, yeah, of course they do, but I'm not being measured. on sense or the delivery of value, I'm being measured on whether or not I meet the roadmap. And that was what's important to me. You can see how all these elements are tied together within the organization. Brian Milner (13:28) Right. Right? Yeah. No, that's an excellent point. And you're absolutely right. So much of our metrics and some of the things that we judge teams on or performance by is basically just a volume kind of metric. And it's how much stuff is being produced. that's not value. Volume does not equal value. Value can be achieved with much less a lot of the times. And if we're This is why sometimes I'll advise product owners in classes to say, look, start up your sprint review. Maybe go back and look at some things that you've done recently and show the metric that you're using for that thing to see if it's successful. Because if the team's done something in the past three or four sprints and it's actually moved the value needle some way, it's increased customer satisfaction. added new members to our site, whatever the thing is, right? If you can show that kind of business value to it, my experience is that people stop focusing as much on volume, because that's volumes of means to the end, which is the value. Barnaby Golden (14:40) Yeah. Yeah, absolutely. And the other thing I've noticed as well in these types of organizations is that the value they're focused on is the incremental, is not the incremental delivery. It's usually a new feature or something like that competing. And what you often find is that the teams are not end value creators. They're often parts of... the creation of value. rather than the whole creation of value, there may be a component of it. And because of that, people will say, well, there's no direct link between you and value creation in the organization. And I find that is very problematic. And it really flies against the rationale of Scrum, which is that you want within each sprint, you want to deliver some incremental value. And if you can't measure it, if you can't... clearly define what that value is. And as you were saying, if the product owner can't stand in the sprint review and say, well, this is the value we've delivered. How does the team keep motivated? How do they keep passionate about what they're doing? Brian Milner (15:50) Yeah. Yeah. I think part of that is just trying to put yourselves in the shoes of your customers and try to look about what they would find as being really valuable. I don't know about you. know, well, I'm sure this applies to you as well. But we all are consumers of different software products, whether that's a business software product or even games or other things that we would use. And when they come out with new releases of those things, they come out with release notes. Now, when they come out with the release notes, are you looking at the release notes and going, wow, I'm satisfied. There's a ton of things that's in this release. Or are you looking through the individual items and going, well, I don't care about that. I don't care about that. I don't care about this. That thing, oh yeah, that's important to me. Right? That's what we do. And that's a clear picture of value over volume. Barnaby Golden (16:49) Yeah, I mean, I think the thing that gets in the way here is a lot of it is the pride of the management team. So they often have strong self belief. They believe they make, they believe by definition, the decisions they're making are powerful decisions. So, I, it's also, think one of the reasons why a lot of organizations don't aren't data driven. You would hope they would. produce a feature and then measure whether or not that feature was a success. But that's not as common as it should be. There's very rarely business metrics tracked against deliveries. I mean, I'm generalizing here. There are many organizations do this very well. But I found there's quite a few organizations that don't really do that. And it leads to a disconnect with the customers. I mean, I can think of an example that we're... an organization I was working at where they worked on a feature delivery for six months that was on the roadmap and they got it done and they shipped it. And I think the expected users were tens of thousands and they got 16 users for this feature. And at that point there wasn't even a post-mortem. They didn't even look back and say, well, what are the lessons learned here? It was like, that's shame. Let's move on to the next item on the roadmap and hope that works instead. And it's very frustrating, especially because the feel of a good Scrum team is the connection with the customers and the feeling that you can see the passion in the engineers and in the team's eyes because they're delivering things that people want and they feel connected to it. And it means they work better and they work more effectively. Brian Milner (18:22) Yeah, there's no worse feeling than building something no one uses. I used to joke with the team, it's kind of like that old joke about if a tree falls in the woods and no one's around us, makes, if we build software that nobody uses, did we build it? It's not going to be used for anything. So it didn't serve any purpose. Barnaby Golden (18:31) You Yeah. Yeah, the way I like to think of it is that an organization should not view people's time spent in the job as important. What they should view is the value that that person has delivered as important. So sometimes people will say, know, yeah, okay, we delivered a feature that nobody really used, but you you did your job, you came in for eight hours a day during that time. And that's hard for people, I think, because they feel like this is my life. I'm investing time and energy into this. Yeah, the money is important, of course. I'm doing it as a career. But at the same time, I also want to feel reward. I want to feel like I'm achieving something. And I think with that element, you get so much better performance from the team if they feel that. Brian Milner (19:26) I agree. There's another thing I was thinking of here too, when we were talking about underpowered POs. Another cause I think that maybe you've encountered or seen as well, but screwy things that people do with kind of personnel. Like for example, having multiple product owners for a team, that leads to underpowered product owner or the opposite even putting a product owner on too many teams. That's going lead to underpowered POs as well. What's been your experience with that? Have you seen that? Okay. Barnaby Golden (19:54) I have one extreme example where there was an engineering team and the organization was an international organization. And politically within the organization, it was unacceptable to have one backlog. They had to have a backlog for the UK, a backlog for the US, a backlog for Australia, backlog for other areas of the world. And the team then had to... prioritize them kind of in this wild order. So they would say, right, we'll take number one from UK, number one from US. And so there was no coherence to what they were building at all. It was really just about satisfying people within the organization. And it kind of brings you back to that key point about why do we have product owners? Because product owners, they narrow down all the ambiguity, they narrow down all the possibilities to the thing that's most effective for the team to do next. Brian Milner (20:47) Yeah, I like your example because it highlights kind of what I think about those scenarios a lot of times is that they're theater. They're an act. They're not really serving the purpose, but they're making someone or helping someone to feel a sense of security about something that really they shouldn't feel. It's not there, but it has the appearance of it. It has the stage set. Barnaby Golden (20:55) Hmm. Yeah. Brian Milner (21:11) of something that looks secure, you know? Barnaby Golden (21:13) Yeah. mean, whenever somebody mentioned that to me, the first thing I always think about is the length of the backlog. I've worked in organizations where they could not achieve the backlog in 10 years if the team kept at it. And yet people within the organization say, yeah, I'm not worried. My feature request is on the backlog. And I'm thinking, yeah, but we're adding 10 new items a week and we're only completing eight. So in fact, you're moving further down the backlog. You're not actually getting closer to. being done. And it's, it's, it's a disconnect to gain. And this is what it's all about. Good agility, good scrum is when there's a strong connection. And if you start having that, that just doing things for appearances sake, then you lose that connection. Brian Milner (21:55) Yeah, and it really is kind of that fundamental flaw that we try to address throughout Scrum of transparency. When you do those kind of theater-ish things to give the appearance of something, it's the opposite of being transparent. You're trying to make it more difficult to see the reality. Yeah, it's on the backlog, so you have this false sense of security. It's on the backlog. It's never gonna get done, but... that's not transparent that it's never going to get done because it's on the backlog. Yeah, mean, part of that I put on the product owner a little bit, but that could also be that the organization demands it. Like your example with it having different backlogs across different geographies, does it serve a purpose? Well, maybe the purpose is to make someone feel better. That, hey, my thing's number one on our list, but... Barnaby Golden (22:39) Yeah. Brian Milner (22:43) That doesn't mean it's number one, that's the next thing that's going get done. It's theater. Barnaby Golden (22:47) And it was done exactly for that reason. I mean, it was done because they didn't want to alienate the heads of the individual countries. So they wanted to make them feel like they were going to get something even though they weren't going to get it. Which is really frustrating. Brian Milner (22:59) I've seen that as well with the multiple product owners. When there's a team that has multiple product owners, a lot of times that's a theater kind of thing as well, because there's a, I don't know if there's a fear that someone's gonna feel undervalued if they're not called the product owner. But it just seems like, yeah, we want all these voices to be involved with it, which again, maybe it's a misunderstanding of the product owner role. That's okay, you can have multiple voices involved, but you gotta define who's the decision maker. And if a team doesn't know that, that's gonna cause a whole host of problems. Barnaby Golden (23:34) Absolutely. I mean, I've been in scenarios where you would have multiple product owners. The team has been instructed by a product owner to go in a direction and then midway through a sprint, the other product owner will come along and say, yeah, that's not really what I had in mind for this sprint. Can you please switch onto this other thing? And as a, you know, I was a scrum master at the time and what I ended up doing in my sprint report was I would say, and the team lost 20 to 30 % of their capacity in switching. between what one product owner wanted and what the other product owner wanted. And that at least got a reaction because people said, well, OK, maybe that's not a good thing if we're losing output from the team. But it's a failure of the organization to make value judgments and make genuine decisions. Instead, it becomes political decisions. Brian Milner (24:19) Yeah. Well, I'll give you my trick for when I've encountered it as a consultant a couple of times, I usually just ask one question and it'll clear it up. I'll just go to them and whoever the leader is that's insisting that there's multiple product owners on the team, I'll just go and say, all right, what happens when, let's say it's two, what happens when those two people disagree? And usually the immediate thing I hear back is, oh, no, no, no, they get along. They usually understand. Barnaby Golden (24:45) You Brian Milner (24:47) And I always just counteract it really quickly and say, yeah, but what happens when they don't? What happens when the day comes when one of the product owners wants something that's number one and the other one wants an entirely different thing as the number one priority, who makes the call? And usually they'll point to one of them and say, push comes to shove that one. right. I mean, at that point, I just say, well, you just told me that's your product owner, right? Barnaby Golden (25:08) got a little bit more authority so they make the decision here. Brian Milner (25:15) That's the product on the other person's a stakeholder, which is fine. There's nothing devaluing about someone who's a stakeholder. They can work all day every day with that product owner. Barnaby Golden (25:24) Yeah, absolutely. I think that people feel if they're not in the product owner role, then they will just be another stakeholder and maybe they won't have as loud a voice. But what's so frustrating about the situation is when you see it done well, when you see it done effectively with a really good empowered product owner, a very motivated team, it's such a powerful thing. And I mean, it's why I stayed in Agile for so long is because I know how good it can be and It's very frustrating and I guess I have sympathy for organizations because maybe if they've never seen it done well, it's difficult for them to understand how just how effective it is. Brian Milner (26:00) Yeah, I agree. Well, this has been a great discussion. I really like this topic. It's great to focus on product owners a little bit. And hopefully, maybe there is a leader out there or somebody listening who heard some of these things and thought, you know what? Maybe it is time to give our product owner a little more power. We talk about testing things all the time, inspecting and adapting as we go. Well, leaders, try that. Barnaby Golden (26:25) Yeah, maybe just try it as an experiment. You know, if you're concerned, give it a go. Brian Milner (26:27) Yeah. Yeah. Give it a shot and see what happens. You may like it, and you may decide this is the best way to go. So yeah, I think that's a great suggestion. Well, Barnaby, this has been great. I really appreciate you making time for this. thanks for not only being on the show, but for the contributions you made in the Agile Mentors community as well. Barnaby Golden (26:47) Well thanks a lot Brian, I really enjoyed that, it was a great conversation.

Bret discusses exciting news about Swarm being maintained until 2030.

Irene Castagnotto: Three Toxic Conditions That Destroy Agile Team Effectiveness Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene encountered a team where everything appeared perfect on the surface, but underneath lay a complete lack of transparency. The team displayed negativity while their manager prevented them from taking responsibility, asking them to complete tasks without explaining the reasoning. These three toxic conditions—negativity, lack of transparency, and micromanagement—combined to destroy the team's effectiveness. Initially hesitant to speak up, Irene ultimately chose to leave. Reflecting on this experience, she emphasizes the importance of addressing problems directly with leadership rather than simply escaping the situation. In this segment, we refer to the 5 monkeys experiment, as comment on conditioning that happens in groups. Featured Book of the Week: Switch by the Heath Brothers Switch: How to Change Things When Change Is Hard by the Heath Brothers focuses on understanding change and why it's challenging for people. According to Irene, change isn't difficult because people resist it, but because it creates internal conflict within us. The Heath Brothers explain the three essential elements needed for successful change: the rational rider (logical thinking), the emotional elephant (feelings and motivation), and the path (the environment and systems). The book provides practical guidance on how to facilitate change and help people navigate transitions effectively, emphasizing the importance of celebrating achievements throughout the change process. Self-reflection Question: What internal conflicts might be preventing positive changes in your team, and how can you address both the rational and emotional aspects of resistance? [The Scrum Master Toolbox Podcast Recommends]

Agile Is Not Dead, Whether You Like It Or NotRecently, there has been a flood of articles and videos claiming that agile is dead. The Agile Manifesto was created during my university years, so I witnessed firsthand how this topic gained traction in software development. As a result, I have a pretty strong opinion on the matter that I'd like to put out there.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

In this insightful episode of the SaaS Fuel podcast, host Jeff Mains welcomes Nik Froehlich, founder and CEO of Saritasa. The conversation dives deep into the perennial pain points of custom software development, especially the ongoing challenge of translating business needs into effective technical solutions. Nick reflects on nearly two decades of helping businesses overcome tech hesitation, scale SaaS operations, and avoid major pitfalls in product development and maintenance.Together, they discuss the misconceptions SaaS founders have—like thinking software is “done” after launch, underestimating ongoing maintenance, and not accounting for technical debt. Nick shares lessons from working with a wide range of clients, managing feature requests versus product vision, and how to build a resilient tech culture. The episode also zeroes in on the evolving role of AI and low-code tools in the dev landscape, and Nik's predictions for custom dev firms in the SaaS ecosystem over the next five years.Key Takeaways00:00 Translators' Role in SaaS Scaling04:58 Bridging Business-Developer Communication09:25 "Emphasizing MVP in Software Development"12:21 Customer-Driven SaaS Feature Challenges13:44 SaaS Customers Push Boundaries17:26 Maintaining Client Confidence Strategies22:56 SaaS Product Optimization Service25:33 Business-Tech Partnership Origin28:48 "The Captain's Keys: Leadership Relationships"30:20 Underpriced Software Projects Issues34:55 "Middle-Market Focused Business Services"38:10 Interpreting Specifications: Key Differences40:27 Refactoring Delays in Technical Debt44:06 "AI Bots Need Supervision"50:22 Thermal Paper Alert System52:56 AI Transformation Insights with Industry LeadersTweetable QuotesThe Truth About SaaS Growth: "Why do so many SaaS founders think the hardest part is launching, when that's really just the warmup?"— Jeff Mains Viral Topic: The Power of Translators in Tech "There's also a hot take on the often missing role of translators, those rare people who can speak both business and geek or tech, turning those abstract goals into real world roadmaps without getting lost in all the jargon." — Jeff Mains Timeless Challenges in Technology: "And I think it's interesting in technology there aren't a lot of problems that last 20 plus years. And this will be a problem, I don't know, maybe 50 more years, 100 more years, I don't know. But from it has been from the very beginning and will continue to be absolutely timeless." — Jeff Mains "Some of the biggest value in the spec. You're not going to get everything in the spec. And I think one of the biggest things is, is the things that aren't said and the choices that are made and just the experience level." — Jeff Mains Bridging the Tech-Business Communication Gap: "The pain point really comes down to the communication between the stakeholders, in this case business people trying to run their business, whatever it is, and knowing that or hearing that they can use technology in a way, but delivering that request and communicating in a way to developers so they understand what they want because developers speak a different language." — Nik FroehlichViral Topic: The Challenge of Customer-Driven Product Decisions in SaaS "I've seen them put their foot down on multi-million dollar customers and just say, we're not doing it until the customer said...

Irene Castagnotto: When Proactive Help Backfires - A Gen Z Scrum Master's Learning Journey Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene shares a valuable lesson about the pitfalls of being overly proactive without proper communication. As a new Scrum Master, she observed Product Owners struggling with role changes and took initiative to help them understand and implement changes. However, she discovered that her well-intentioned proposals weren't aligned with what the POs actually wanted. The key insight: when people don't speak up during your proposals, it often means they're not on board but are avoiding conflict. Irene learned that asking questions and letting others express what changes they're ready for is far more effective than assuming what help is needed. Self-reflection Question: How can you better gauge whether your team is genuinely on board with your suggestions, especially when they remain silent during discussions? [The Scrum Master Toolbox Podcast Recommends]

The Future of Scrum: What Will Agile Look Like in 2030?Agile methodologies, particularly Scrum, have dominated the software development and product management landscape for decades. However, as technology advances and workplace dynamics shift, Agile is evolving rapidly. By 2030, Scrum will be unrecognizable from its early iterations. Here's how it will transform...How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

In this episode, Josh and Bob challenge the growing obsession with artificial intelligence and mechanical leadership “frameworks” by reminding us what matters: leading humans like a human. They unpack what authentic high-performance leadership looks like and how showing genuine care for people is still the most powerful management tool you have. Instead of passing leadership responsibilities on to checklists or algorithms, the hosts lay out a bold reminder — real leadership comes from connection, courage, and empathy. Stay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Micah Martin is a co-founder, CEO, and Studio Director for Clean Coders. He's a 2nd-generation coder, serial entrepreneur, family man, pilot, airplane builder, engineer, author, and just a normal guy trying to enjoy life to the fullest.   He is also a co-author of Agile Principles, Patterns, and Practices in C#, along with his father, Robert C. Martin, also known as Uncle Bob, and a contributor to the popular testing framework FitNesse, among other things.   Topics of Discussion: [1:52] Micah talks about early influences from his father, Uncle Bob, including childhood “robot” games and learning to code on a Commodore 64 and the first Macintosh. [3:47] First job working alongside industry legends like Kent Beck and Ward Cunningham, and the humbling realization that college hadn't prepared him to build real software. [5:00] Founding Clean Coders to distribute training videos and later expanding into custom software development with Clean Coders Studio. [6:54] Why apprenticeship is key to developing strong software engineers and how Pete McBreen's Software Craftsmanship influenced his approach. [8:20] Parallels between martial arts training under a sensei and learning software from a master craftsman. [11:23] How Clean Coders apprentices learn new languages like Clojure through Project Euler challenges and Koans, and why maintaining and extending code is essential training. [15:13] The origins and purpose of FitNesse, acceptance testing, and the need for a modern replacement. [18:43] The gap in tooling for non-programmers to write executable tests, and AI's potential role in bridging it. [20:35] The role of bullet-point test scenarios in developer/customer collaboration. [21:07] The decline of Agile's technical focus and the creation of the Software Craftsmanship Manifesto at a summit in Libertyville, IL. [25:29] Carrying forward the Clean Code discipline in both training and client projects. [27:11] Plans to offer a digital apprenticeship experience through CleanCoders.com. [28:17] How Micah uses AI for algorithms, test data generation, and client projects, plus its current limitations. [36:37] Lessons from aviation autopilot systems and why humans remain essential in software development.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Agile Principals, Patterns, and Practices in C# Clean Coders   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.  

Tom Marotta of The Spaceport Company joins me to talk about the executive order this week focused on commercial space regulatory reform, what problems it seeks to solve, his experience on both sides of those issues, and how we should understand the positioning of the order.This episode of Main Engine Cut Off is brought to you by 34 executive producers—Frank, David, Jan, Josh from Impulse, Steve, Ryan, Joakim (Jo-Kim), Lee, Creative Taxi, Theo and Violet, Fred, Pat, Donald, Better Every Day Studios, Stealth Julian, Bob, The Astrogators at SEE, Russell, Joel, Tim Dodd (the Everyday Astronaut!), Matt, Natasha Tsakos (pronounced Tszakos), Kris, Warren, Heiko, Will and Lars from Agile, Joonas, and four anonymous—and hundreds of supporters.TopicsTom Marotta | LinkedInThe Spaceport CompanyPrevious appearance: T+259: Tom Marotta, The Spaceport Company - Main Engine Cut OffEnabling Competition in the Commercial Space Industry – The White HouseTrump Issues Executive Order on Commercial Space – SpacePolicyOnline.comThe ShowLike the show? Support the show on Patreon or Substack!Email your thoughts, comments, and questions to anthony@mainenginecutoff.comFollow @WeHaveMECOFollow @meco@spacey.space on MastodonListen to MECO HeadlinesListen to Off-NominalJoin the Off-Nominal DiscordSubscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhereSubscribe to the Main Engine Cut Off NewsletterArtwork photo by NASAWork with me and my design and development agency: Pine Works

Somya Mehra: When Technical Expertise Becomes Product Owner Micro-Management Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Clear Communicator and Dependency Master Somya worked with an exceptional Product Owner on a project with multiple team dependencies. This PO excelled at clear, direct communication with both stakeholders and the team. They were proactive in stakeholder communication and maintained strong focus on what was needed and why. Their backlog management was exemplary, creating proper epics with comprehensive information including dependencies, enabling the team to easily know who to contact. This approach led to a much more motivated team. The Bad Product Owner: The Technical Micro-Manager Somya encountered a technically strong Product Owner whose knowledge became a liability. While technical strength can be beneficial, this PO used their expertise to control the team, telling developers exactly what solutions to implement. Initially, developers accepted this direction, but it escalated to every feature and task. The developers became uncomfortable voicing their perspectives, creating an unhealthy dynamic where the PO's technical knowledge stifled team autonomy and creativity. Self-reflection Question: How do you help Product Owners leverage their technical knowledge without falling into micro-management patterns? [The Scrum Master Toolbox Podcast Recommends]

“Agile isn't about following the rules. It's about delivering real value together.” In this episode, host Rebecca Kalogeris speaks with Jenny Martin, seasoned facilitator, coach, and creator of the OOPSI framework. While Agile has transformed software development over the past two decades, many organizations struggle to scale it effectively or to see the benefits they were promised. Jenny explains why so many teams fall into the trap of focusing on ceremonies and tools instead of the principles that actually drive results, like collaboration, value delivery, and rapid feedback. She introduces OOPSI—short for Outcomes, Outputs, Process, Scenarios, Inputs—a lightweight, non-prescriptive framework that helps teams break down complex problems, align on value, and accelerate delivery. Jenny shares how OOPSI can resolve common Agile pitfalls like “water-scrum-fall,” where work still flows through waterfall-style handoffs despite sprint-based development. If your teams don't understand user stories, are unclear on priorities, or struggle to collaborate across functions, this conversation offers a practical path to restoring focus, alignment, and energy in Agile. For show notes and more resources, visit: pragmaticinstitute.com/resources/podcasts Pragmatic Institute is the global leader in Product, Data, and Design training and certification programs for working professionals. Learn more at pragmaticinstitute.com.

Somya Mehra: Why Collaboration Should Be Your Team's Primary Goal Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Unlike technical roles where success is tangible, Scrum Master success can be harder to measure, especially for those transitioning from tech roles. Somya defines successful Scrum Master performance through team behaviors: when teams trust and respect each other, and when collaboration becomes their goal. She emphasizes the importance of observing behaviors and discussing them with team members early enough to foster the right behaviors within the team. Featured Retrospective Format for the Week: The 2 Pillars Retrospective Somya recommends the 2 Pillars retrospective format, which she intentionally varies to keep teams engaged and curious. Her core structure focuses on two essential questions: "What went well?" and "How can we improve?" She notices that using the same retrospective format repeatedly leads to team boredom, so she adds variety while maintaining these fundamental pillars. In specific cases, she includes a gratitude section to ensure team members feel appreciated. Self-reflection Question: How do you measure your success as a Scrum Master when the results aren't as tangible as in technical roles? [The Scrum Master Toolbox Podcast Recommends]

In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit their earlier discussion on defining ‘done' in Agile – how to stay on Track and Avoid Scope Creep. They explain why “done” must mean more than “I finished coding,” and they show how a shared Definition of Done (DoD) keeps teams aligned and projects on schedule. What Does “Done” Really Mean? In Agile, “Done” extends beyond writing code. It often includes: Passing unit and integration tests Receiving QA approval Deploying to staging or production Updating documentation Securing acceptance sign-off Without a clear, documented DoD, each team member may interpret “done” differently. As a result, projects risk rework, delays, and frustration. “If we ask, ‘Is it done?' we should get a clear yes or no—no ‘sort of' or ‘almost.'” – Rob Broadhead Why Ambiguity Leads to Trouble Michael points out a common problem: a developer finishes their code, marks the ticket as done, and passes it to QA—only for testers to find gaps in the requirements. A login screen ticket might say “Allow users to log in with username and password.” But does that mean: Username is case-insensitive? Special characters are allowed? Do error messages display on failure? If these details aren't defined, both the developer and tester may interpret “done” differently, leading to frustration on all sides. The Link Between “Done” and Scope Creep Rob and Michael agree: unclear definitions open the door to scope creep. Without a firm DoD, features get stuck in an endless loop of revisions: Developers feel QA keeps moving the goalposts. QA feels developers aren't meeting the requirements. Clients think the delivered feature isn't what they expected. Over time, this erodes trust and pushes delivery dates further into the future. Lessons from the Field Michael contrasts two scenarios from his career that highlight the power of a strong Definition of Done. Before an acquisition, his team worked with a crystal-clear DoD. Every ticket had precise requirements, clear acceptance criteria, and well-defined testing steps. As a result, tasks finished on time, testing followed a predictable pattern, and rework was rare. The team knew exactly when work met the agreed standards, and stakeholders trusted that “done” truly meant done. After the acquisition, the situation changed dramatically. Tickets became vague and massive in scope, often resembling open-ended “make it work” directives. Multiple teams modified the same code simultaneously, resulting in merge conflicts, inconsistent results, and unpredictable delivery schedules. Without a clear DoD, developers, testers, and stakeholders all had different ideas of what completion looked like, and work frequently circled back for revisions. The difference between the two environments came down to one factor: a clear and enforceable Definition of done. In the first scenario, it acted as a shared contract for quality and completion. In the second, the lack of it created confusion, wasted effort, and missed deadlines. Building a Strong Definition of Done The hosts outline key components every DoD should include: Code complete and reviewed – Ensures quality and shared understanding. Automated tests passing – Reduces regressions. Documentation updated – Prevents future confusion. Deployment verified – Proves it works in the target environment. Acceptance criteria signed off – Confirms alignment with the original requirements. Pro Tip: Keep your tests fresh—don't just update them to pass without meeting the real requirement. Who Owns the DoD? One person doesn't own the DoD—it's a team responsibility. Product owners, Scrum Masters, and developers should collaborate to create and update it, reviewing it regularly to adapt to evolving project needs. Making “Done” Part of the Process Once defined, your DoD should be visible and integrated into your workflow: Add it to user stories during sprint planning. Track it in tools like Jira, Trello, or GitHub. Use workflow stages that match your DoD steps—coding, testing, review, deployment, and sign-off. Michael emphasizes that personal accountability matters just as much as team accountability. Great developers hold themselves to the DoD without needing reminders. Your Challenge: Define “Done” This Week If your team doesn't have a documented Definition of Done—or if it's been more than three months since you reviewed it—set aside time this week to: Write down your current DoD. Identify where ambiguity still exists. Get agreement from the entire team. Update your workflow so that every ticket must meet the DoD before it is closed. This single step can prevent months of wasted effort and ensure your work delivers exactly what's intended. The Bigger Picture A well-defined DoD is more than a checklist—it's your guardrail against wasted effort and shifting goals. It ensures the final product matches what the client truly needs, not just what was coded. Your Definition of Done is your “why” for each task—it keeps your work focused, aligned, and valuable. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects The Importance of Properly Defining Requirements Changing Requirements – Welcome Them For Competitive Advantage Creating Use Cases and Gathering Requirements The Developer Journey Videos – With Bonus Content Building Better Developers With AI Podcast Videos – With Bonus Content

At 9:23 p.m. on April 14, 1953, the crew aboard a U.S. Navy patrol plane conducting a classified ELINT (Electronic Intelligence) operation during Korean War had an unsettling encounter with the unexplained. Moving silently through the air at nine thousand feet, the aircraft initially noticed a light in the distance that appeared to be signaling to them using Morse Code. Over the hour that followed, the crew found themselves in the middle of a strange series of engagements that could only be interpreted as an aggressive display toward their aircraft by objects of unknown origin.  This week on The Micah Hanks Program, we explore this little-known Cold War-era incident involving a U.S. Navy spy plane's classified mission that led to an aggressive encounter with unidentified aerial phenomena, as well as its implications to the history of the subject and similar military encounters then and now.  Have you had a UFO/UAP sighting? Please consider reporting your sighting to the UAP Sightings Reporting System, a public resource for information about sightings of aerial phenomena. The story doesn't end here... become an X Subscriber and get access to even more weekly content and monthly specials. Want to advertise/sponsor The Micah Hanks Program? We have partnered with the AdvertiseCast to handle our advertising/sponsorship requests. If you would like to advertise with The Micah Hanks Program, all you have to do is click the link below to get started: AdvertiseCast: Advertise with The Micah Hanks Program Show Notes Below are links to stories and other content featured in this episode: ANNOUNCEMENT: Physics of Exotic Propulsion with Dr. Matthew Szydagis - Society for UAP Studies  NEWS: Google Search Ranking Volatility Shakes Up This Weekend  OpenAI will not disclose GPT-5's energy use. It could be higher than past models  1953 UAP REPORTS: UFO Reports and Documents from 1953 - Project 1947  UFO HISTORY: The UFO Encyclopedia - By Jerome Clark, et al  PROJECT BLUE BOOK: US, Project Blue Book - UFO Investigations, 1947-1969 BECOME AN X SUBSCRIBER AND GET EVEN MORE GREAT PODCASTS AND MONTHLY SPECIALS FROM MICAH HANKS. Sign up today and get access to the entire back catalog of The Micah Hanks Program, as well as “classic” episodes, weekly “additional editions” of the subscriber-only X Podcast, the monthly Enigmas specials, and much more. Like us on Facebook Follow @MicahHanks on X. Keep up with Micah and his work at micahhanks.com.

Somya Mehra: From Top-Down to Collaborative—Reimagining Organizational Restructuring Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. During a business unit split and reorganization focused on creating smaller teams, Somya and her fellow Scrum Masters were invited to create the new structure process. After hearing feedback that teams felt excluded from previous changes, they decided to include teams in the reorganization process to give them a sense of control. They started by asking top management for constraints, then applied them to see what was possible. They facilitated workshops with Product Owners to divide the product portfolio and determine team assignments, ensuring people felt involved in the change process. Self-reflection Question: When leading organizational change, how do you balance the need for structure with giving teams meaningful input into decisions that affect them? [The Scrum Master Toolbox Podcast Recommends]

In this episode of the Agilists: Aspire and Achieve podcast, host Emily Lint chats with Alena Keck about the realities of leading international teams across the U.S., Europe, and beyond.   About the Featured Guest: Alena Keck is an experienced Transformation Leader who has led complex, enterprise-wide change initiatives across Europe and the U.S.—from building an omnichannel Digital Solution Center at Mercedes-Benz Financial Services USA, driving engineering transformation at Aptiv, and aligning digital strategy and ways of working at Porsche, to heading the Lean-Agile Center of Excellence at Vodafone/VOIS. Her passion: driving purposeful transformation that delivers sustainable value—with people always at the core. Follow her on linked in at https://www.linkedin.com/in/alena-keck/   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg   Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile. About our Host: Emily Lint is a budding industry leader in the realm of business agility. Energetic and empathetic she leverages her knowledge of psychology, business, technology, and mindfulness to create a cocktail for success for her clients and peers. Her agile journey officially started in 2018 with a big move from Montana to New Mexico going from traditional ITSM and project management methodologies to becoming an agile to project management translator for a big government research laboratory. From then on she was hooked on this new way of working. The constant innovation, change, and retrospection cured her ever present craving to enable organizations to be better, do better, and provide an environment where her co-workers could thrive. Since then she has started her own company and in partnership with ICON Agility Services serves, coaches, and trains clients of all industries in agile practices, methodologies, and most importantly, mindset. Please check out her website (www.lintagility.com) to learn more. You can also follow Emily on LinkedIn (https://www.linkedin.com/in/emilylint/).

Join Brian and Scott Dunn as they unpack what “buy-in” actually means and what it takes to move from surface-level support to genuine commitment in this episode of the Agile Mentors Podcast. Overview In this episode of the Agile Mentors Podcast, Brian is joined once again by Scott Dunn to tackle a listener-chosen topic: how to get real buy-in for Agile initiatives, especially when shifting from a non-Scrum environment. They explore why buy-in isn’t about enthusiastic cheerleading or deep Agile knowledge, but about leaders and teams aligning on desired outcomes. From the cost of performative support to the emotional side of change, Brian and Scott share practical strategies for securing support at all levels of the organization. Along the way, they dive into influence tactics, the importance of shared purpose, and how co-creation—not compliance—drives lasting change. Whether you're guiding a large transformation or simply trying to influence up, this episode will help you rethink how to earn trust, build alignment, and inspire meaningful momentum. References and resources mentioned in the show: Scott Dunn Elements of Agile Assessment Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Auto-generated Transcript: Brian Milner (00:01) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And I also have with me today someone that you probably know pretty well because he took over this podcast for about a month there. Mr. Scott Dunn is with us. Welcome in, Scott. Scott Dunn (00:19) Hey, thanks Brian. Yes, that podcast takeover was a lot of fun. So thank you for that opportunity. That was a hoot. Had a great time. Brian Milner (00:25) Absolutely. Well, I don't think I publicly thanked you for that. just ⁓ a public thanks. Scott Dunn (00:28) No, you didn't. No, not even an email. Not even a Slack message. Brian Milner (00:33) Well, very public thanks to you for doing that. Those episodes were great. I enjoyed them and it was fun to be a listener. It was fun to listen to it and just kind of hear the conversations and be a fly on the wall for those. So thanks again for doing that. Scott Dunn (00:47) Yeah. Yeah. It's a real treat. Brian Milner (00:48) We're having Scott on we kind of ran an experiment on this one because we were Scott was teaching a class for mountain goat and We thought maybe we'll just see what the class thinks so we pulled the class to see what topic do you want us to talk about and We thought we'd just go with the winner the winner that came out of that class was how to get buy-in How do you get buy-in in a? move from a non-scrum place to a Scrum kind of way of working. How do you get buy-in in the organization and buy-in from others? So when I was thinking about this as a topic, I think the first thing that popped in my head Scott about this was What do we mean by buy-in? So what does that mean to you? Scott Dunn (01:33) Right. So sometimes what I'm hearing is people saying like, buy in, you know, they, I would hear a common complaint, like they don't get it. They don't understand. don't, for me, buy in isn't that they need to understand agile or scrum and these types of things and how it works. Buy in is they get, they give their support kind of regardless. So my favorite example of that is walking into, this is a multi vendor effort we're doing on a Salesforce implementation. And we'd asked for the VP of the whole thing to come down and say some words before we had our first retrospective. You can imagine it's going to be kind of heated with different vendors trying to make each other look bad or whatever. And he'd said, yes. So we're coming down into this, you know, big high stakes meeting. And I just remember him saying, you know, I'm so excited to be doing this for you all. It's great. And he kind of falls in and looks at me says, what am I doing again? Cause he didn't, he didn't know, he didn't know what a retrospective was. He just knew he was asked to come and do something around that. And to me, Brian, Brian Milner (02:21) Ha Scott Dunn (02:28) That's fine. He's showing up. He's letting everyone know this way of working is important. It's important to me. It's important to success. And he probably couldn't tell you any of the meetings or artifacts or anything in scrum, right? But that's still what we need. Brian Milner (02:39) So. Yeah, I think that's a good way to think about it because I think a lot of people sometimes think of buy-in, like everyone's clapping and waving scrum flags around and all that stuff. And I don't think that's really buy-in. I think it's just the willingness to honestly try it, to give it a shot and be open about what would work and what doesn't work. The opposite of that is the resistance, know, of just being resistant to it and saying, I'm gonna put up hurdles and walls in the way of this being successful. That's, think, what needs to be avoided. Scott Dunn (03:18) Right, right. think that some of what was helped is to give them the, for me, the mindset of their buy-in isn't about doing things right. They're not saying, we're really wanted. We really want a new process. We were getting asked to come in because they're not getting the results they want. So buy-in for me from their perspective is how to help get the results that they're looking for. And they'll support us to get those results. So I don't talk to them about some of the aspects of an empirical process or any of that. I sort of say, you in order to get things faster or in order to improve quality, right? And that's how they get behind that. I think sometimes people are preaching some of the process part, even if they could understand that's not really what they're about. But I think they even struggle to understand what we're talking about. So yeah, it's hard for them to get behind and support us when they're not tracking. They simply know there's a pain point we're having. Can we talk about that and how to get what we need and what do you need from me to get that? Great. But I think we We can do ourselves a favor by helping point to the same target, make sure we're aligned with the same target they want. And maybe they'll give us more support if they feel like, yeah, you're tracking with me. I want to come in talk about, you know, more collaboration. Like we already have enough meetings. That's what, that's what I heard. Right. But I'll come and talk about faster time to market. Well, yeah, now they're interested in talking about what they need to do, you know, that I'm asking them to get behind that. I think that's fair. Brian Milner (04:28) Right. Yeah, I think there's also an element there, because I know we're both kind of fans of and users of kind of the path to agility framework from our friend David Hawks. And I love the part of that that's trying to establish the motivation, the purpose from the outset to try to say, What's the thing we hope to get out of this? And I think that's really crucial in getting buy-in that you can't just tell people, hey, we're gonna be a Scrum organization now. Why? Because I tell you that's what we're gonna do, because we're gonna check off the box and say that we're now Scrum. That's not motivating to anyone. if I can say, no, we're gonna... go through this change because here's the end result. Here's what we're trying to get to. Here's what we think will be better. If I can lay that out, then I've got a purpose behind it. And now I have motivation to go forward with this difficult change and learning what's expected of me and all that stuff. But if that's not done, I feel like that's a crucial misstep in that. Scott Dunn (05:44) Yeah, I wanted to add to that, that that point about the clarity of the goals is really something that has sticking power. And we had a client, I came and was working with him this year that he had remembered from the last year as the CTO. He's remembering from last year that we had done that same exercise or what are the goals that leadership has. And he remembered it was quality and customer satisfaction. That had been over a year since we had done that, but that not only stuck with him, but we came back to the group and kind of had a fun poll. Like, everyone remember? They remembered. And so every time we're having a decision we're trying to make about should it be this way or that way on the process, the different, were doing the race, the matrix work, et cetera, people kept coming back to, well, is that going to help us in terms of quality? Is that going to help us in terms of customer staff? We're not going into the nuts and bolts of Scrum or these other approaches. It's simply what's the business goal. will that help us hit the goal? And when the leader hears you using their language that they get, like that's my goal, they're feeling like, okay, whatever you need to do, sounds like you understand what I'm after, right? It's really powerful. But I like that you mentioned that, because when we go through that exercise, always super clear, we don't get confused. Times when we lead with, especially on the executives trying to lead with explaining Scrum, you can tell sometimes they're not really tracking or they're following along, okay, so what's the point? Brian Milner (06:59) Yeah. Scott Dunn (06:59) Yeah, you start off with what's their goals. They're like, great, this is exactly what I want to talk about. And then, Hey, you're not doing the things you need to do to hit those goals. Oh, okay. What are they? I mean, I remember one time a couple of years back, literally when the coach was presenting the results of that assessment towards their goals, they cut them off in the middle of his presentation. Just says, well, why, why is it, you why is that red? Why are we not hitting the goal? What do need to do? And they just started solving the problem right then he couldn't even finish his presentation. Talk about getting support. And he had been there six years saying, Brian Milner (07:23) Wow. Scott Dunn (07:27) Scott, they're not gonna buy into doing this transformation team and the scrum work. He couldn't even finish, I think, a couple of slides and they gave him everything he wanted, right? Powerful, powerful. Brian Milner (07:36) Yeah. Yeah. I think that's a good point. I also think one of the reasons that there's, you know, and that kind of parallels it. One of the reasons there's a lack of buy-in in general is that it's sort of targeted to just one area. You know, like this is a team thing. The teams are going to get trained, but the leaders have no idea really what's going on. They're kind of separated off from this. And I think that's a big part of the problem as well is you get buy-in when they see the leaders have bought in. So are the leaders bought in? Are the leaders on board with this? If they're not, then the rest of the group isn't going to be bought in either. Scott Dunn (08:18) People are smart. They're watching which way the wind's blowing. to be honest, Brian, I'd love to hear your thoughts. I tell people, I don't even care if they genuinely believe in that or not. If they're getting behind it because that's the way the politics are going, hey, they're getting out of the way. We're getting things done. Fine by me. Right. So partly when we're getting that by now, so make sure leaders, are you communicating this clearly? Because some of your people are either not on board or they're kind of waiting to see, this a fad or is this going to blow over? I need you to really communicate that clearly, et cetera, to see if people are get on board with that or not. Or, and on the other side, if I feel like some of these folks are not on board and I do feel like I have leadership support, I need to escalate that pretty quickly and make sure you understand, know, because they might get mad at you or me for talking about scrum and changing things. I'm like, I didn't knock down the door and come in myself. I was asked to come in here by someone who has authority. So maybe you need to clarify that with them, whether we're doing this or not. But don't get mad at me. Brian Milner (09:04) Right. Scott Dunn (09:11) So I will check them on that and clarify with the leadership to say, let's make sure your people are in alignment as well. If we do have that buy-in for sure. Brian Milner (09:20) Yeah. I saw another kind of quote about this that really got my brain working a little bit. Cause it was talking about the cost of fake buy-in and it was, it was kind of saying, you know, performative buy-in might actually, you know, it was asking the question, is performative buy-in worse than just outright resistance? And I don't know. Let me ask you that. What do you think? Do you think performative buy-in is worse than just someone who's resistant? Scott Dunn (09:28) Interesting. Yeah. As someone that just gave an example of performative buy-in. So if you would ask me a week ago, I might have gave a different answer, but someone was talking about this is a wildly different aspect of this, but you did ask me to join. So you get what you get. ⁓ They're talking about the difference of discrimination in the US versus South Africa. And they said, what's the difference? And they said in South Africa, it was blatant. no, you're a person of color. You cannot buy property here. That's how it is. Here, it's more like Brian Milner (09:59) You Scott Dunn (10:14) Yeah, we're looking at your loan application and I don't know if you can buy in this way. So it's subtle. And this person actually said, I'll take the outright blatant discrimination of South Africa, where at least you know what the issue is versus the subtle one. So maybe to that point with what you're saying, maybe it is better to have outright resistance and then say, well, at least I know who's on board or not. Rather than the person says they're on board, but every time they're in a meeting, they come out meeting and we don't get the decisions made we need. That's funny. Brian Milner (10:39) Yeah. Yeah. When I read this and started to think about it, I kind of had that same conclusion that like when someone's being outright resistant, yeah, it's an obstacle, but it's honest. And, you know, I'd rather have the honesty because they're trying to, they're still acting their way because they have a belief that their way is the right way to do it. And so they're throwing up a resistance because they're honestly resistant to it. Whereas someone who just sort of nods in meetings and claps along and, know, oh yeah, sure, great. But then they're kind of in the quiet, you know, behind the scenes and the hallway conversations. That's insidious. That's something that I can't really deal with. And it's like, you know, let's have the discussion. Let's talk about it. And, you know, if you win, then great. Why not have the courage to just have the conversation and see which idea wins? Scott Dunn (11:39) Right. on that note, think for everyone's sake, Brian, if we could be honest for a moment, not that we haven't been honest in these other podcasts, but in this, in this moment, we're really going to be honest. Would you, would, do you feel at times that our culture, our company cultures actually teach people to do just what you said to not be honest, but then like be like, you know, politically savvy, don't say what you really think, but then you're going to kind of be subversive and undermine that thing. And I've dealt with that so many times, I'll show up to a meeting like, I would have swore we were on board. had that one-on-one and now you're not saying in the meeting that you go on board with that. So people might've gotten coached. It's actually not safe to be honest and have good clear spirited debate because there's a price to pay if they do that. And they maybe 10 years in corporate can kind of teach you don't be honest or they're trying to read the tea leaves about what you think it's going to be. And so, yeah, I definitely would rather take it. Maybe it's part of the mindset of trying to really check, you know, where people are at. If I go back to my early days of coaching, those one-on-ones of having the level of honesty to really know where people are at. That was, think, some of the power. And I think some of that came from genuinely caring about the people, wanting them to succeed, wanting them win, even if it wasn't going to be at this company because of all the change or whatever. I did feel people felt like I really was open and honest with them and transparent and had their back. I would hear some real things about how they really felt because they didn't feel like there was a payback for that. And that allowed me to actually say, well, you know what, if you're really not on board, let's see what we can do as far as another opportunity. Maybe it's a positional switch we can do or whatever that was. Because I mean, this did affect people's jobs in some ways. And I think maybe if I don't have those one-on-ones, they're probably just going to give lip service because they don't know if anyone there really has their back in a turbulent time of change. AI is a great example of that, right? Hey, we want to move forward with AI. Well, what's the impact of my job if we do? But no one's really talking about that, right? It's all positive and all that. So I think people are trying to read that too. But you bring up a good point. I think I would take the direct as long as they feel like they can safely be open and honest. Brian Milner (13:31) Yeah. Yeah, well, even that question, right? What effect is AI gonna have on my job? And the honest answer I think that someone has to give right now is, don't know. I feel like I understand what it is today, but I don't know that that's gonna be the same way tomorrow because this technology changes so fast, so I can't promise anything. But here's what it is today and this is the paradigm we're trying to live in. So I think that there's an honesty component there that you've got a mirror to say, hey, I'm going to be honest with you. You be honest with me about this. And we'll be upfront with each other as we make our way through this. yeah, so yeah, think that kind of being honest and taking that approach, I think, is the right way to go. I also think that being kind of a reverting back before you get into things like, here's what a Scrum Master is, here's what a product owner is. You've got to start with the basics and mindset kind of culture things. You have to start with transparency, inspection, adaptation. That's really the way to go. And if we buy into those sorts of things initially, then we can start to say, well, here's a practice that supports that. Now you understand why we're doing this practice because it does this thing. Without it, it's just sort of one of those things of do as I tell you, you know, and that doesn't get buy-in. We've got to see the why behind it. Scott Dunn (14:48) Yes. Yeah, I think so. That's a great point. I was just making a note because sometimes we come in about agile. Some of the folks when I'm sharing this, it's maybe is new to them that I try to really present it. I want what you want. So even down to the words and then I kind of map back to that. So for example, if if we have quality problems now, I might believe in say an agile practice like mob programming, but I don't want to bring up like, hey, we should try mobbing. because it's cool or because you know, whatever, they don't care about that. But oh, they have a quality concern. Hey, boss, I've been thinking about, you know, these quality issues. I got an idea that I think it really could help with quality. But if I was to ask you, Brian, is is Bobby gonna, does Bobby help with quality? Does Bobby help me with, you know, cross training and tearing down knowledge silos and sharing learning? And I think, well, it does a lot of things, I pitch it towards what management wants. So agile as a means to an end. So I want what you want. And if I can't get that clarity that I want what you want, I need to be listening more because if I feel like I come to them talking, I've seen from my own experience, I come talking about better collaboration. That's not what's on their mind. I'm literally losing credit with them because they're like, why are you bringing this up? Like this isn't even our concern right now. Right. So I'm losing trust. I'm losing political capital. So I listen intently what their concerns are, the things I think that are important or that can get that. Then I'm going to pitch it. I'm going to pitch it in that language even like, you know, that what these are the things that would help on. I want what you want. Brian Milner (16:00) Yeah. Scott Dunn (16:18) the sport, I'll even research stuff to find out. So maybe I gave an example recently, when I was a manager for a web development, team that they wanted bigger monitors, of course, and I couldn't get approval for the bigger monitors. so I went and researched, I knew that always we had pressure to deliver more. I researched until I found somewhere someone had to study the show that larger monitors help productivity. And then I brought that to him and like, Hey, I'm looking for ways to improve the team productivity. I think I found something. What is it Scott? Brian Milner (16:30) Mm-hmm. Scott Dunn (16:46) Well, larger monitors, you can tell us, Smollick, really? You've been asking for this for months. I said, no, there's a study that proves it. Now he approved it right then. But partly I wonder, Brian, is I was also giving him air cover for when he gets flack from the other departments. Why does Scott's team get the special monitors? Well, it improves productivity. And right. He's got a reason now. Otherwise, it looks like maybe he's just playing favorites or something else. Right. We're all watching costs. So I will do the research to say, hey, I want what you want. I'll go and I'll go and dig it up. Brian Milner (17:04) Yeah. Scott Dunn (17:13) Someone somewhere must've said it's gonna help. So I'll bring that to them. It ⁓ worked. Brian Milner (17:17) Yeah. Yeah, I think you're right. you're giving him the why behind it. You're telling him, hey, here's something that's in. It's the old outcome argument that the outcome from having larger monitors is this, that we have this productivity. I know you want greater productivity, so here's a means to do that. And I think that's kind of the way that this, you in a nutshell, what we're trying to say here is, you know, I can't go into a company, your boss comes into your company tomorrow and says, hey everyone, we're switching to pens that write in green ink, because we're a green ink company. We just, we want to be known as the green ink company from now on, because it's better. So everyone, make sure you switch to green ink. I mean, they do it. But there's a difference between compliance and real commitment. ⁓ And that's the difference, I think, is, all right, you wanted to switch to green ink, but why? What's the point behind it? I'll do it, but I'll be committed to it if you tell me, well, studies show that when people read in green ink. I mean, that kind of thing can make an impact. But otherwise, it's like you're Scott Dunn (18:08) Yes. ⁓ Absolutely. Brian Milner (18:31) It's almost like an insult to the intelligence of someone, you know, to say, we're going to do this crazy new thing called a standup, you know, or daily scrum or whatever. And well, why are we doing that? I don't know. Cause right. That they tell us that's what we're supposed to do. Well, we have to stand up for a meeting. Why are we standing up? Why aren't we just sitting down? It's more comfortable. I don't know, but that's what you do in a daily scrum is you stand up. Right. I mean, it's, it's, it's that kind of a thing that I think. Scott Dunn (18:34) yeah. Yeah. I don't know. Brian Milner (18:58) if you don't lay the groundwork of here's why, then they're gonna just react with the way that you would switch to green ink. ⁓ Scott Dunn (19:05) I love that example. love that. And we've all been there, right? When someone says, why would we do this? I'm like, I actually don't know. It's a terrible feeling. I don't know. We go through all this effort to do just that. And you mentioned that compliance, compliance will never have their heart and soul and energy into this. So think that that's a big deal for them as well. When leaders are, we had something happen where it's a large financial institution and their data engineering group. Brian Milner (19:11) You're right. Yeah. Scott Dunn (19:33) You're like, yeah, AI is not really, you know, for us, not important to us. Which is interesting, right? Then the next week, like that, the head of that group, their boss's boss says, we need to be using, AI. Well, guess who makes it announced at the very next week. We need to get going with AI, So some of this is like, look, if they're pushing those things, we also want to make sure that they're in a position to look good for their bosses, those types of things. Right? So one, you know, giving them air cover, but two, listen to the winds of those things. If we make them successful, I mean, this is old school, right? Make your boss look good. My goodness. If they feel like that's happening, then you're going to get a lot more support. And this is a good example of a radical change for a whole data engineering team, just because the boss's boss says so. So now we're going to do it. I think looking for even those opportunities and following through on what that might be bringing them ideas that make them look good and generating that as well. I love the green ink one. just now it makes me want to be that we're the green ink company. You're we're going to be known for this. Brian Milner (20:23) Yeah. Scott Dunn (20:29) ⁓ But why? Brian Milner (20:30) Yeah. I think it's also kind of important that you acknowledge that there is an emotional impact here. And this gets into kind of the idea of the whole Satir model of change and that kind of thing. And so I think maybe part of the equation of getting buy-in is really comprehending and understanding that you're not going to get buy-in right away. ⁓ Scott Dunn (20:56) Hmm. Brian Milner (20:57) you know, there's going to be chaos and resistance. There's going to be a point where people are going to be resistant to it. And if you do the rest of it well, then that they'll turn that corner. But what makes them turn that corner is, is that they're connected to the purpose behind it. And so if you're, if you're going to try to implement this, if you're to try to do a change, and just expect it's gonna be, know, hunky dory from day one, you're fooling yourself. Humans don't take to change well. It's got an emotional aspect to it. I love the way David Hawks used to always say this. You know, I knew how to be a hero the old way, and I have no idea how to be a hero in this new thing. So I don't feel comfortable with this change because I don't know how to win. Scott Dunn (21:41) So true. Brian Milner (21:47) And I think that is a really accurate reflection of that emotional kind of impact of it. Everyone wants to do their job well and be seen as a smart person at work and everything else. And I knew how to do that before, but now I don't know how. And so I'm afraid I'm gonna look bad. Scott Dunn (22:02) Right? And I think that lack of awareness or knowledge is some of the things that we're asking them to do. Like you said, uncomfortable or new doesn't feel good. And we kind of think that, oh, if I don't feel good, this must be bad. It's just uncomfortable. But I think I love what you're saying. We can map it out and say, by the way, it's going to look like this as we go through that. And that hero part, a lot of our management, like 90 % of the management is going to be in that, you what we call expert or achiever. Like they're the smartest ones in the room, or they're ones that coordinate everything and they know who to talk to. you're trying to introduce something to someone who thinks they already know all the things. So how we're presenting that to them, including the fact that they're human too, right? They're gonna feel some things and maybe uncomfortable. It wouldn't hurt to explain a bit more, even if they're not gonna necessarily admit it, but like, hey, it's gonna feel different. The people might push back on this. So even when you're first beginning that, it reminded me of how I just knew I'd need to ask my boss like five times. Look, lots of people are asking him for stuff. They're partly just going by the simplest way of Who keeps coming to my office the most? And maybe on time five, like, wow, Scott, this sounds like a problem. Well, yeah, I've been here five times. Because they're kind of waiting, like, is it really a problem or do you just come in once or twice? So repeating that and then maybe framing it to say, and doing the change looks like this and that, giving them information so they don't have to admit that they don't know if they're priding themselves on knowing all the things. I really think that's a great addition to that. The Satir change model, knowing that it's going to get uncomfortable. I've seen execs jettison this just because people are bothered or upset or they're uncomfortable. So therefore this must be a bad idea. So I think we can do ourselves a favor by explaining a little bit like it's going to look like this moving forward as far as their support. Some people may not like it and here's why, but here's how I would answer those people. Like you're literally feeding them the responses. And I'll also do the get behind the expert and say, well, this is, this is what Harvard business review says, or this is what this expert says. You might be surprised because Again, back to them being experts, if you ask them what they think they know about Agile, I might have mentioned before, they score themselves on average about 8.5 out of 10. But their people would score them about 4.5 out of 10, right? It was what I've seen when I did the study, the surveys. So they think they know, so they're not gonna admit they don't know, but go ahead and give them the information they wish. If you know they don't know, I like what you're saying, kind of shrink the chain so they can understand, it's gonna look like this and feel like this. People might ask this way. But here's how I'd respond to them. know, remember this is where, you know, 90 % of the companies are doing X, Y, and Z. So they have backing. They can answer to the people. We kind of set them up for success. Otherwise that satiric change curve is going to hit them. They won't have answers. That feels really awkward. This must be a bad idea. And they're going to undo what you just asked for. Right. I've seen that happen. You just got approval and then a week or two later it got put on hold or undone. Brian Milner (24:44) Yeah, no, I agree. one of the areas, one of the other kind of things that I found in thinking about this in advance was a quote that was from the five dysfunctions of a team book that we all talk about quite a bit. But there's a quote from that that says, people don't weigh in, they won't buy in. And I love that. And I thought, you know, that really is a good point that there, it's not about Scott Dunn (25:00) Woo! Brian Milner (25:08) people need to feel like they're co-creating with you. And to do that, you need to be able to listen to them. If they don't feel like they have a voice, mean, put yourself in their shoes. If you felt like there was a big change happening and you had no say in it, that would feel pretty oppressive. But if they felt like they're building the change with you, then I think then that's what kind of can turn people around and say, no, I have a say in this, I'm a part of this. and I get to shape a little bit about what this is going to look like. They're going to shape it a lot. I mean, that's part of just the Azure way of working is that, hey, we're going to individualize this for this company, for this team. It has to fit here. And the more we can help people see, no, you're a co-creator in this. You're not just being told, but you're going to shape this with us. Scott Dunn (25:54) Right? Even with the leadership, I mean, it's easy. think everyone listening would agree. If you look at the common leaders, that's, even the, let's say director level and above personality types, right? For, for disc, it's going to be a high D for a strange pattern would be like command, um, computing values framework. They're going to be blue, get results, make it happen. But we need it to be, we need to be their decision for some of these folks. So when I would come to one of my bosses and say, I think we should do X every time he'd say like, yeah, let me think about. I'll get back to you. I kept thinking like, I don't understand because these are my people. I thought you trusted me. I realized, it has to be his decision. So part of what you're saying is invite him into the solution. So then I'd say, hey, we've got three options, good, better, best. What do you think we should do? Or I'd say, hey, I've done all the research, option A looks great, option B looks terrible. What do you think we should do? I mean, I try to simplify it. I tried to make it obvious, but I couldn't tell him I need to do X or we need this from you. It needed to be his input and to decide. Brian Milner (26:44) Right. Scott Dunn (26:51) once I framed it that way, he agreed every single time. I simply frame it, put it right in front of him so it's kind of an obvious decision, but I had to let him have that voice to decide. I'm really glad you brought that up. That one literally went from zero to 100 % if I changed my approach of how I had addressed it to let him be the one to decide and weigh in on that. Or even pitch it as a sales. Hey, I think it'd be great to move forward. What would that look like to you? Well, now he's talking about moving that change forward. without even realizing it, because you said to move forward, what would we need to do? And now he is co-creating, but it's already a yes, right? But by default, a little bit of sales, a little bit of sales effort there. Brian Milner (27:24) Yeah. Yeah, no, that's a, that's a good example. And that's a good example, I think for like the scrum masters listening and other people out here that are, feel like, you know, I'm not the leader in the organization. I'm not way up here and I can't, you know, have my decisions trickle down to other people, but, you know, kind of the, influencing up kind of mentality there. Yeah. It might sound like a little bit of a trick, but you know, if you can help. the boss co-create with you, right? Here's the problem. I've done some research. Here's some solutions. How would this look for you? Or what do you think of these options? Which one do you think sounds best? If I'm a boss and someone comes to me and says that I've researched this, here's the solutions that are possible. Which one do you think sounds best? That's really a service to me because you've just done a lot of work for me and I know that I'm doing my job by making the decision, but you've presented it and now I don't have to do anything but make the call. Yeah. Scott Dunn (28:24) Yeah, yeah. Simplify the decision-making or frame the decision-making is, think we might actually be kind of, I don't want to say teasing. I just hear some feedback from people at times like, leadership's was like, bright, shiny squirrel, right? And they get frustrated. But in some ways I'm thinking, well, at least someone in the org is decisive. I'll take that. But we can help them leverage that decisive trait they have. Brian Milner (28:43) Yeah. Scott Dunn (28:48) But for the good, instead of these random crazy things, you know, when the leader's like, I love Agile, I can change my mind all the time. We can, we can, we can guide them to better decision-making too. I love the influence both up and down what you're saying the Scrum Master can do. I think we miss, that we all have that ability to try to influence decision-making and shape some of this. Maybe there's more agency than we realized, I think for some of these folks, Scrum Masters, product owners, cetera, that you might be surprised. Like run an experiment, try some of these things out that we're talking about and see for yourself. I mean, all these personality types are different and your orgs are different. I totally understand that. Do something, inspect and adapt and see what you get. might, cause once you strike gold, you're like, you know, you're set on getting influence and buy-in from folks. It's really powerful network. Cause we don't need to give you a title or change the org chart in order to have results happen with you involved if you're that kind of a person. And I think you can really write your ticket in your career if you're able to do that soft skill of influence and buy-in up and down. It's great. Brian Milner (29:43) Yeah, yeah, that's awesome. Well, I hope that for at least the people that were in your class, this is is hit it right on the nail on the head for what it is they were they were thinking this would be about. But I think this is good. I think this is a good conversation and it's important, I think at all levels, because there's you know, this this affects us whether we're doing a massive transformation in an organization or Scott Dunn (29:51) Yeah. Brian Milner (30:06) We're just trying to influence up a tiny bit, you know, the food chain. Scott Dunn (30:10) Yeah, absolutely. Yeah, I hope that for the folks who were in that class, you better let us know if that was it. If anyone else is interested in other things, absolutely. We love hearing what your what those topics would be and bring on the right people. I will say that Brian, you brought in so many different voices. It's really, really great. So again, influence us. You can practice what we're talking about by putting those ideas up there. Other folks that we'd love to hear, because I love the the slated speakers you brought in. Brian's been really awesome. Thanks for this opportunity. Brian Milner (30:34) Thank you. Yeah, absolutely. Thanks for coming on again, Scott.

Somya Mehra: How Upper Management Can Destroy a High-Performing Team in Minutes Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. While working as a business analyst at a startup building an exam evaluation product for universities, Somya witnessed a well-functioning team with good collaboration and timely delivery. However, upper management began challenging the team lead and Scrum Master, accusing the team of padding story points. When leadership confronted the team, the tech lead threw the entire team under the bus, breaking all trust. The CEO's declaration that he could detect padding in estimates shattered the relationship between developers and leadership, leading team members to want to leave. Featured Book of the Week: Agile Retrospectives by Larsen and Derby Somya recommends "Agile Retrospectives" by Larsen and Derby because doing Scrum right means doing retrospectives right. As someone who wanted to excel as a retro facilitator, she found this book invaluable due to its excellent reviews and practical examples. The book provides several examples of how to facilitate retrospectives effectively, making it her go-to recommendation for Scrum Masters wanting to improve their retrospective facilitation skills. Self-reflection Question: How do you maintain trust between your team and leadership when management questions the team's estimates or performance? [The Scrum Master Toolbox Podcast Recommends]

In this episode of Grow a Small Business, host Troy Trewin interviews Robyn Djelassi, founder of Impact People Solutions. After a 25-year corporate HR career and a top role at Vinomofo, Robyn launched Impact People Solutions in 2022 to give growing Australian businesses access to top-tier people leadership without the full-time cost. Their flagship service, CPO Connect, embeds a fractional Chief People Officer into your business. Bootstrapped from day one, Robyn has grown the business from a solo consultancy into a cash-positive team of eight. This is a story of building a business on clarity, commerciality, and treating adults like adults. Why would you wait any longer to start living the lifestyle you signed up for? Balance your health, wealth, relationships and business growth. And focus your time and energy and make the most of this year. Let's get into it by clicking here. Troy delves into our guest's startup journey, their perception of success, industry reconsideration, and the pivotal stress point during business expansion. They discuss the joys of small business growth, vital entrepreneurial habits, and strategies for team building, encompassing wins, blunders, and invaluable advice. And a snapshot of the final five Grow A Small Business Questions: What do you think is the hardest thing in growing a small business? According to Robyn, the hardest thing in growing a small business is time. Finding enough of it to get everything done, especially when you're wearing multiple hats as a founder. What's your favorite business book that has helped you the most? Robyn's favourite business book is Who Moved My Cheese by Spencer Johnson. Despite being an oldie, she finds it incredibly relevant and continues to refer to it even today. Are there any great podcasts or online learning resources you'd recommend to help grow a small business? One of Robyn's go-to podcasts for professional development is How I Work by Amantha Imber. She appreciates Amantha's insights on productivity and building habits that stick. What tool or resource would you recommend to grow a small business? Robyn recommends using Microsoft To Do List as a simple yet powerful tool to manage daily tasks. Despite using more advanced tools like HubSpot, she finds this one still does the best job of helping her stay on track and productive. What advice would you give yourself on day one of starting out in business? If she could go back to day one of starting her business, Robyn would tell herself: “Be patient.” Success doesn't happen overnight, and learning to breathe and enjoy the journey is key. Book a 20-minute Growth Chat with Troy Trewin to see if you qualify for our upcoming course. Don't miss out on this opportunity to take your small business to new heights! Enjoyed the podcast? Please leave a review on iTunes or your preferred platform. Your feedback helps more small business owners discover our podcast and embark on their business growth journey.     Quotable quotes from our special Grow A Small Business podcast guest: Good people help good people. Kindness in business always comes back around – Robyn Djelassi You don't need funding to succeed. You need grit, trust, and a hell of a work ethic! – Robyn Djelassi Success is doing the work you love with people you respect, not just chasing numbers. – Robyn Djelassi      

In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit one of the most persistent challenges in software projects: scope creep. Using AI prompts, we revisit a past episode on “Mastering Scope Creep: Navigating the Hidden Challenges in Software Development.” In that discussion, we explored what scope creep is, why it happens, and how to prevent it from stalling projects, draining teams, and eroding trust. Today, we're building on that conversation with fresh insights and practical strategies. Listen to the full episode for more real-world stories and practical strategies to keep your projects on track. What Is Scope Creep? Scope creep occurs when requirements change after development begins—often without proper planning or agreement. Rob describes it as “moving the goalposts” for what “done” means. This differs from: Iteration – Evolving requirements after review and delivery. Agile flexibility – Adjusting before a sprint starts, not mid-execution. Uncontrolled changes shift the destination while you're already driving toward it. Scope Creep vs. Feature Creep Michael introduces feature creep—adding extra features—as a related but distinct problem. Feature creep bloats the product, while midstream requirement changes alter agreed-upon work. Both can waste time and resources, but shifting requirements often cause rework and missed deadlines. Why It Happens The hosts highlight common causes: Poorly defined requirements Lack of regular checkpoints Stakeholder indecision or shifting priorities Underestimating the impact of “small” changes Without a process to control evolving requirements, teams risk chasing ever-changing goals. The Impact of Unmanaged Scope Creep Burnout from Endless Adjustments When requirements keep shifting, tasks drag on for weeks instead of days, creating “death march” projects that drain morale. If the definition of done changes mid-task, close the ticket and open a new one. Damaged Trust in Estimates Developers see moving targets, clients see missed deadlines, and both lose faith in estimates and planning. Growing Technical Debt Repeated changes often necessitate quick fixes, making the system more challenging to maintain. Stories from the Trenches Rob recalls a four-week integration project that stretched to nine months due to unclear ownership of data mappings. Michael shares a modular app that was copied into six separate projects instead of being built for reuse. One small change multiplied into six updates—an expensive lesson in poor change control. How to Prevent Scope Creep Expansion Define “Done” Clearly – Every task needs explicit completion criteria. Set Regular Checkpoints – Confirm that requirements remain relevant throughout the project. Separate New Work – Treat changes as new tickets with new estimates. Clarify Ownership – Assign responsibility for every requirement and integration. Challenge “Quick” Changes – Always Assess the Real Impact. Key Takeaways Unmanaged scope creep—or any uncontrolled change—can sink a project. By defining requirements early, revisiting them often, and isolating new work from current work, teams can adapt without losing control. Managing changes well is the difference between a project that adapts and one that never ends. Your Scope Creep Challenge Think about the last project you worked on. Did requirements change midstream? Were there regular checkpoints to confirm priorities? How did those changes impact the timeline, quality, or team morale? This week, choose one active project and: Review its requirements with the team. Confirm whether they are still valid. If anything has changed, document it as a new item rather than altering the current work in progress. By doing this, you'll practice catching and managing evolving requirements before they cause unnecessary rework. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Sprint Planning – Setting The Scope A Positive Look At Scope Creep The Importance of Properly Defining Requirements Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects The Developer Journey Videos – With Bonus Content Building Better Developers With AI Podcast Videos – With Bonus Content

Bret and Nirmal are joined by Michael Irwin to discuss Docker's comprehensive AI toolkit, covering everything from local model deployment to cloud-based container orchestration across multiple interconnected tools and services.

Somya Mehra: Learning to Spot Team Performance Warning Signs Early Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. At the start of Somya's Scrum Master journey, she joined a well-organized and balanced team. However, after two senior developers left the company, the team faced unexpected challenges. Despite hiring new people, velocity didn't improve. Somya discovered that a remaining senior developer had been stepping back and wasn't contributing actively to the team. Through conversations and giving specific tickets to the senior developer, Somya learned valuable lessons about early intervention and communication. Self-reflection Question: How quickly do you address performance concerns with team members, and what signals do you watch for to identify when someone might be disengaging? [The Scrum Master Toolbox Podcast Recommends]

Sarah Elk, Senior Partner at Bain & Company and global leader of its operating model work, brings a clear, pragmatic lens to why so many large-scale change efforts fail to stick. Drawing on decades of advising multinational organizations, she diagnoses the structural and behavioral traps that cause transformations to stall, and shares the disciplines that make change durable.   Elk emphasizes that transformation is not a one-off program but an enduring capability that must be “led from the top and embedded in the culture.” She cautions against outsourcing responsibility to a program office: “If the CEO is not leading it and the leadership team isn't engaged in the change, you might get something done, but it will erode quickly.”   Key Insights from the Conversation: Clarity on Non-Negotiables Many failed transformations lack a shared definition of the “non-negotiables” in the new operating model. Without them, execution becomes fragmented. “You have to be crystal clear on what's standard and what's flexible.”   Outcomes Over Activity Successful change efforts anchor to measurable business results, not just activity metrics or generic benchmarks. “It's not about hitting 80 percent of a checklist. It's about whether you've moved the needle on the outcomes you care about.”   Leadership Alignment Is a Continuous Process Alignment isn't built in a single offsite; it requires ongoing dialogue, joint problem-solving, and confronting decisions that challenge entrenched interests. “You need the leadership team acting as one—every week, every month—not just at the kickoff.”   Manage Change Fatigue Overloading the organization erodes momentum. Sequencing initiatives and celebrating visible early wins tied to strategy helps sustain energy. “People get tired. You have to show progress and give them space to breathe.”   Governance, Incentives, and Talent Must Evolve Together Elk warns that without parallel changes to systems and structures, “behavior will revert to what it was before.”   The discussion reframes transformation from a high-profile event into a muscle organizations must build and maintain. For executives seeking change that endures beyond the initial push, Elk offers a blueprint grounded in operational rigor, leadership accountability, and cultural realism.   Get Sarah's book here: https://shorturl.at/Tyotz Doing Agile Right: Transformation Without Chaos   Here are some free gifts for you: Overall Approach Used in Well-Managed Strategy Studies free download: www.firmsconsulting.com/OverallApproach   McKinsey & BCG winning resume free download: www.firmsconsulting.com/resumepdf   Enjoying this episode? Get access to sample advanced training episodes here: www.firmsconsulting.com/promo

Florian Georgescu: How Decision Journals Can Transform Product Owner Behavior Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Humble Learner Florian describes a Product Owner who started from scratch with business knowledge but no PO experience. This exemplary PO demonstrated transparency and engagement in their communication style, showed humility in recognizing knowledge gaps, and actively built strong relationships with the team. They used practical tools like a Product Canvas shared with the team, implemented "Story Time Tuesdays" for informal refinement sessions, and introduced feature learning cards to assess impact and learn from completed work. This PO's success came from embracing the learning journey openly and creating collaborative environments where both they and the team could grow together. The Bad Product Owner: The Command-and-Control Controller Florian encountered a Product Owner who transitioned from 20 years in project management, bringing a command-and-control style that frustrated the development team. Despite having good business and technical knowledge, this PO made technical decisions for the team without allowing input, particularly challenging since they were in a different location. Florian addressed this through a "decision journal" experiment over three sprints, documenting every product decision and analyzing their impact during retrospectives. This approach served as a powerful mirror, clearly showing that technical decisions made without team input produced poor results, ultimately helping both the PO and team recognize the importance of collaborative decision-making. Self-reflection Question: How does your Product Owner balance their expertise with the team's input, and what tools could help improve this collaboration? [The Scrum Master Toolbox Podcast Recommends]

Michael Moreno, VP of Strategy at Lunar Outpost, joins me to talk about what they've been up to at the company, the NASA Lunar Terrain Vehicle Services contract, the idea of services as a business on the Moon, and more.This episode of Main Engine Cut Off is brought to you by 35 executive producers—Lee, Russell, Fred, The Astrogators at SEE, David, Matt, Theo and Violet, Warren, Josh from Impulse, Frank, Pat from KC, Steve, Pat, Creative Taxi, Jan, Stealth Julian, Better Every Day Studios, Kris, Heiko, Donald, Natasha Tsakos (pronounced Tszakos), Joel, Joakim (Jo-Kim), Will and Lars from Agile, Harrison, Joonas, Ryan, Tim Dodd (the Everyday Astronaut!), Bob, and four anonymous—and hundreds of supporters.TopicsHome | Lunar OutpostLunar Voyage 1 Update Lunar Outpost Becomes First Company to Receive Payment for Space ResourcesNASA selects three companies to advance Artemis lunar rover designs - SpaceNewsLunar Dawn Team Awarded NASA Lunar Terrain Vehicle ContractLunar Outpost Signs with SpaceX for Starship Moon MissionThe ShowLike the show? Support the show on Patreon or Substack!Email your thoughts, comments, and questions to anthony@mainenginecutoff.comFollow @WeHaveMECOFollow @meco@spacey.space on MastodonListen to MECO HeadlinesListen to Off-NominalJoin the Off-Nominal DiscordSubscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhereSubscribe to the Main Engine Cut Off NewsletterArtwork photo by NASAWork with me and my design and development agency: Pine Works