Podcasts about product owners

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 Small Business PR Podcast, I sit down with Kim Behzadi, founder of Read It & Eat—a purpose-driven food and book subscription box that fights hunger with every purchase.Launched from her bedroom after losing her job during the pandemic, Kim bootstrapped her business with no investors, no PR background, and no big-name endorsements. Today, she's been featured in Women's Day, local magazines, and podcasts—without spending thousands on PR retainers or flooding the media with free samples.If you're a product-based founder who wants consistent, cost-free press, this episode is your blueprint.How Kim Built a PR System That Delivers Year-Round FeaturesAfter joining the PR Starter Pack, Kim learned to:Pitch with purpose, not desperationBuild relationships with journalists through LinkedIn, Instagram, and even TwitterAdapt pitches for national vs. local media to maximize relevancePlant PR “seeds” months in advance to secure Q4 gift guide placementsHer Women's Day feature led to:A 40% increase in website trafficLocal partnerships like a Buffalo book club and tea shop collaborationInvitations to vend at book fairs and community eventsA direct connection with a Harlequin author for a special edition boxWhy Serving (Not Selling) Gets You FeaturedKim stopped leading with “Here's my product” and started pitching with “Here's a story your audience will love.” This value-first approach helped her:Land coverage without sending dozens of samplesGet invited to collaborate with brands and authors she once thought were “out of reach”Build a press system she can run in just two dedicated nights per weekKim's PR Tools & StrategiesLinkedIn & Instagram to find and connect with journalistsEmail + social media follow-ups to stay top-of-mind without spammingSeasonal pitching calendar to target: Valentine's Day, Mother's Day, Back-to-School, Holidays, and themed brand roundupsThe CPR Method (Credibility, Point of View, Relevance) to craft irresistible pitchesCommon PR Mistakes Kim AvoidedOverspending on product samples before confirming interestWaiting for the “perfect” moment to start pitchingRelying solely on social media for visibilityFinal TakeawayYou don't need an expensive PR firm—or a massive marketing budget—to land in national gift guides. What you do need is: ✅ A clear, value-driven message ✅ A repeatable system ✅ The courage to hit “send”If Kim can build Read It & Eat from her bedroom and land Women's Day, so can you.

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]

Wie baut man eine der umfangreichsten Datenplattformen im Fußball auf? Welche Herausforderungen gibt es bei der Transformation einer IT-Struktur und warum ist der DFB international Vorreiter im Umgang mit Daten? Diese spannenden Fragen diskutiert Jonas Rashedi in der ersten Folge dieser neuen Podcast-Reihe von MY DATA IS BETTER THAN YOURS mit Kevin Telke vom DFB. Kevin ist als Product Owner maßgeblich für die strategische Weiterentwicklung der Datenplattform verantwortlich und erzählt, wie der DFB Daten nutzt, um sowohl im Profi- als auch im Amateurbereich wichtige Erkenntnisse zu gewinnen. Gemeinsam gehen sie darauf ein, wie der DFB datengetrieben Nachwuchstalente identifiziert, warum die Integration und Qualität von Daten entscheidend sind und wie sich die IT im Verband von einer klassischen hin zu einer agilen, dezentralen Organisation verändert hat. Ein besonderes Highlight: Kevin teilt Einblicke, wie Live-Daten den Fußball in Zukunft weiter prägen könnten und welche visionären Projekte bereits heute umgesetzt werden. MY DATA IS BETTER THAN YOURS ist ein Projekt von BETTER THAN YOURS, der Marke für richtig gute Podcasts. Zum LinkedIn-Profil von Kevin: https://www.linkedin.com/in/kevinhochmuth/?originalSubdomain=de Zur Webseite des DFB: https://www.dfb.de/ Zu allen wichtigen Links rund um Jonas und den Podcast: https://linktr.ee/jonas.rashedi 00:00:00 Intro: Daten beim DFB 00:01:50 Vorstellung Kevin 00:03:27 Use Cases und Datenplattform beim DFB 00:05:53 Internationaler Vergleich 00:08:08 Transformation der IT-Struktur 00:13:25 Dezentrale IT und Zusammenarbeit 00:20:15 Warum beim DFB arbeiten attraktiv ist 00:22:24 Die umfassendste Fußball-Datenplattform Deutschlands 00:27:05 Datenpunkte und Datenmenge 00:34:52 Live-Daten vs. Batch-Verarbeitung 00:37:32 Herausforderungen Datenqualität 00:40:28 Das Datenmodell beim DFB 00:47:51 Blick in die Zukunft des Fußballs 00:49:28 Persönliche Datennutzung

“You can build software with Excel. You can finish an Ironman on a cheap bike. But will it be enjoyable? That's another question.”In this inspiring and energetic episode, Sander and Jim sit down with Dana—Scrum Master, team lead, and passionate triathlete—just ahead of her session at the Online Scrum Master Summit. Together, they unpack:Dana's journey into agile and what drew her to the Scrum Master Summit.How her dual passions—agile coaching and triathlon—intersect in powerful and unexpected ways.The surprising overlap between triathlon training and software delivery: focus, iteration, adaptation, and complexity.The value and limitations of tools—whether it's JIRA or a $6,000 triathlon bike—and why mindset still trumps everything.The importance of coaching: in sports and in software. Do you really need to know how to code to be an effective coach?Connect with Dana: (31) Dana Mykytiuk | LinkedInCheck out our sponsor:www.xebia.comwww.wiserbees.comwww.masteringagility.orgHosted by Ausha. See ausha.co/privacy-policy for more information.

Join Brian and Mike Cohn as they unpack the five essential pillars that take Agile from “just the motions” to meaningful, measurable impact. Plus, get a behind-the-scenes look at their revamped course built for real team transformation. Overview In this episode of the Agile Mentors Podcast, Brian is joined by longtime collaborator and Agile thought leader Mike Cohn for a deep dive into what really makes Agile stick. They explore the five foundational pillars—mindset, practices, roles, teamwork, and support beyond the team—and share stories of what happens when teams get them wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles. Whether you're new to Agile or knee-deep in transformation, this episode will help you rethink how to build an Agile approach that actually works. References and resources mentioned in the show: Mike Cohn #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn Scrum Team Roles and Responsibilities Working on a Scrum Team Course Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian Milner (00:00) Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors podcast. Thanks for joining us. I'm with you, as always, Brian Milner. And today, I have the one and only Mike Cohn back with us. Welcome in, Mike. Mike (00:12) Thanks, Brian. Good to be here. Brian Milner (00:14) Always happy to have Mike on the show and really appreciate Mike making time to come on. Wanted to have Mike on because there's some things Mike's been talking about recently that are really interesting and people have been asking a little bit about this and I thought maybe it'd be just a good opportunity to talk through some of the stuff that Mike's been writing about. I know you spent, Mike, a lot of time helping teams to not just do Agile but to really get solid results from it. to see impact from it. And I know the topic you've been talking about recently is sort of these five pillars of supporting real agile improvements, the mindset, practices, roles, teamwork, and support beyond the team. So I thought maybe we could just dig in and drive through those and maybe learn a little bit about those as we go. Obviously also to talk a little bit about the exciting new course that's being launched here, the working on a Scrum team course, because I know that was originally just for private classes, right? And now it's being open to the public. Mike (01:23) Yeah, we've done working on a Scrum team as a private class for probably 20 plus years. It's been kind of our main offering to private clients. But we're hearing from a lot of people that they have one team and they can't really get a private class approved with the budget and such. So what we're doing is going ahead and making that course available as a public course. So two people from your company, five people from another company all in the same class the way we've done our certified courses for decades. And so we're going to start offering this as a public course. And the exciting thing there is that it's really meant to be a team-based class, where things like Scrum Master training, great class, but it's really meant for the Scrum Master, right? And working on a Scrum team is really designed, and you and I helped you and I design this course together, but it's designed to be something that is a whole team training, right? So good for anybody on a team. Brian Milner (02:16) Yeah, yeah, it's been really great teaching those in the private classes and I'm excited to think about the public being able to come in and take that now. Let's talk a little bit about these pillars and, I think people are gonna be really intrigued by the concept here. The first one is mindset, I think, and just wanna start there and say, what does it actually mean to... think Agile and what is the found, why is that kind of the foundation for successful transformations? Mike (02:43) Remember the kind of the early days of agile and there was a lot of conversation about could you be agile without understanding the principles, right? If you just did the practices, were you agile? Other people were saying, no, you have to start with the principles, right? And so do you start with principles? Do you start with practices? And I remember these early debates and they often devolved into a discussion of the karate kid movie, right? Remember that one, right? And, you know, can you just wax on? Brian Milner (03:12) Ha Mike (03:12) for long enough, just do the practices. And then all of a sudden, your karate instructor or your agile coach is, OK, you're agile. And it's like, wait, all I know how to do is wax a car, right? And so there were these discussions about practices versus principles. And I was kind of always on the side where you better understand the principles to do this. Just knowing the practices, waxing on all day, is kind of just going through the motions. And so you have to understand the principles. And the idea that I wanted was that if a team truly understood all of the principles underneath Agile, I don't just mean just the manifesto, but all the principles that are there from Lean, from Kanban, from everything, that if you really understood those, you'd kind of invent the practices, right? You do those and you go eventually to go, hey, we should probably meet every day. Or hey, if we tested first, that might be a really good thing. Brian Milner (03:57) Yeah. Mike (04:05) So you'd invent the practices if you really had that type of agile mindset. And so for me, when we're working with organizations to get them truly agile, and I don't mean like more agile than less agile, but agile in a way that's going to stick, you got to change mindsets, right? You've got to do more than just the wax on. So people have to get the mindset. Brian Milner (04:27) Yeah, I love that. I know that I've experienced some things in the course of working with people that's it's sort of like you, if you're not on the same page with the principles, then you start to talk through the practices and you run up against a problem. And really what you find out the core of it was, well, we weren't aligned on really the principle behind this. So why would I want the practices then, right? ⁓ Mike (04:49) Yeah. Well, that's where you also end up then with a lot of team debates about things, right? Because you're arguing about the practice. if you'll say you and I are arguing about the benefit of some practice, if we agree on the principle, we might just have different views on it. But deep down, we'll probably agree on some practice, or we might find an alternative one. But if you don't agree on the principles, you end up with a lot more of these kind of annoying. mean, team debates are great. I mean, I love. Brian Milner (04:54) Yeah. Mike (05:12) you know, having a team debate, arguing stuff like that, but not about pointless things, right? And not without some sort of foundation. They just kind of get in the way. It's just frustrating for everybody. Brian Milner (05:21) Yeah. Well, I'm kind of curious, what kind of signs or signals do you think teams should look out for to kind of clue in and let them know that what might actually be going on here is more of a mindset issue? Mike (05:36) think sometimes it's when you hear the appeal to authority, right? Somebody says, you know, well, we got to do it this way because the scrum guide says, right? Or the one that annoys me is we have to do it this way because Mike Cohn says, ⁓ you know, that was like, no, I, somewhere else also said, think, right? Don't just, you know, don't just, you know, blindly do story points or something. Cause I say they're a good thing. I want you to think too. Brian Milner (05:50) You You Mike (06:01) And so I think that kind of appeal to authority when teams are debating things. It's where we also see teams who think they're agile because they do a set of practices. We use a particular agile tool, so we must be agile. We do daily meetings. We must be agile. And those are not the things that make you agile. Those are artifacts of being agile. If you're agile, you're going to meet a lot. You're not going meet a lot, but you're going to talk a lot. Um, and so those are the artifacts of behaving in an agile way. And so I want to understand why we're doing those things. So I look for those kind of appeals to authority. Um, you know, emphasis on that type of stuff in an argument talking about how this is the right way saying there's only one right way to do something. Brian Milner (06:49) Yeah, yeah, that's great. How does working on the Scrum team deal with this? How does that address it? Mike (06:55) Well, one of the things we do, it was actually one of my favorite exercises. We do this exercise at the start of the class where we ask people to kind of map out how the organization talks about certain adsel principles and then how does the organization behave. And so for example, if a company says, people are our greatest asset, and then they treat people like dirt, we've got this kind of problem between what we say and what we do. And so I like to kind of map this out. And so we do this with the principles in the Agile Manifesto. And once we map those out and we start to see things that we say we value, but we don't behave that way, really helps us understand if we've really embraced that mindset. Or are we just doing things because an Agile coach told us to, or a boss told us to, or we did it that way in our prior company. Those are all bad reasons to do something. Brian Milner (07:48) Y eah. So this is great. So I agree. The mindset's really foundational. And there is this symbiotic relationship between mindset and practices, which came first and which comes first, as we talked about. I know a lot of teams get stuck doing Agile, though, in really only name only. So when we talk about practices, what makes the difference between going through the motions? Mike (08:00) Mm-hmm. Brian Milner (08:11) and actually doing things that work. Mike (08:13) Well, practices is kind of our second pillar, right? You have to have the mindset, right? But you also have to have the practices that come from having that mindset. so, again, I try to think of that team on a desert island, right? And they're isolated from the world. They've never talked to anybody, but they have an agile mindset. What practices are they going to invent, right? And I think those are kind of the core practices. We see a lot of problems with as an example, teams that misunderstand sprint planning. And I know when I first started teaching about sprint planning, I'd have a slide up there to have a picture of a sprint backlog. And the sprint backlog listed tasks like code this, design this, test this. And then there were estimates next to code this. It's going to take four hours testing. It's going to take three. And so we were able see all these numbers and think the point of a sprint planning was these numbers. And Even in the early days of this, I was always saying, no, it's not about those numbers. It's about deciding what product backlog items you can pick. if taking a, I don't even want to call it an estimate, but taking a wild guess about, it probably can take four hours to code. If that helps you decide how many backlog items you can commit to, great, put those numbers up there. But it was never about the numbers. And it's one of the most common problems that I see with teams in sprint planning is they get obsessed with How many hours did we bring in? How many points did we bring in? And I remember one team I worked with where we did sprint planning. Having those estimates were helpful for them on their sprint back. They were helping. And we finished the meeting. And we're using Google Sheets in a meeting to do this. We've got a row with the estimates in there. And as we start to wind down the meeting, I deleted that column that they'd spent so much time talking about. They're all kind of pissed off at me. Why'd you delete that? We spent all this time talking about it. I said, because we got the benefit, right? You got the benefit of those numbers. The benefit isn't a week from now remembering that you said five hours, because it's going to take what it takes. The benefit was the discussion that it led to of can we take more or are we already full? So I see teams get obsessed with that. This is one example, but that's one of the problems with sprint planning as a practice. Brian Milner (10:25) Yeah. Yeah. I think you're absolutely right. And that's one of the things I know I've talked about with people going through the course is sort of understanding the purpose behind the things. Just going back to, know, harkening back to what you said about, don't just do it because someone told you, you know, understand why the purpose behind it. And, know, otherwise we, I'm sure we've all had that experience before where someone just tells you to do something and says, you know, why? Cause I told you so, you know, that, that doesn't, that's not very convincing. Mike (10:52) Thanks, Mom. Brian Milner (10:53) Right, right, thanks mom. Yeah, not very convincing, but it's much more convincing when they can tell you, well, no, you do this because this is what we're trying to do. And I think you're right, that makes all the difference there. ⁓ Mike (11:05) It just, don't know anybody that responds well to being told what to do, right? My instant reaction is no, right? mean, you it could be, you know, a really, you it could be a really good thing. Eat more vegetables, you spend more time outside. No, right? Don't tell me what to do. So. Brian Milner (11:09) Right. Right. Yeah. It's almost like our default response is no until you convince me. Are there other common practices? We talked about sprint planning. Are there other kind of practices you see teams struggle with? Mike (11:28) Yeah, yeah, for a lot of people. think a huge one is product backlog refinement. I don't know what a better word would be than refinement. refinement is about making the backlog better. It's not about making it perfect. And I see teams that get stuck on backlog refinement and feel like they have to resolve every open issue, that everything has to be tiny and answered and buttoned up before we can start a sprint. And that's not the case. For me, the goal in refinement is to make sure things are small enough and sufficiently well understood. I don't want to bring in a backlog that's bigger than my velocity. If our velocity is 25, I don't want bring in a 50-point story. how about the problems of a 50-point story anyway? But I don't want to bring in some massive epic like that into a sprint. And so refinement is about making it small, making sure it's sufficiently well understood. Sufficiently well understood, not perfectly. And so Brian Milner (12:18) Yeah. Mike (12:28) The problem is these teams, and I know you've seen this, but teams who get in there, want to resolve every open issue. It's like, no, we can resolve that during the sprint. If we think about the goal and planning to make sure we know what to bring into the sprint, not too much, not too little, we're fine just enough that you're at that point. Is the button blue or red? Who cares? If it's a log in story, we're going to lock people out after some number of failed attempts. Who cares how many? Figure that out during the sprint. If it's five or three or eight, who cares? Figure that out later. So I think refinements won. Another big one would be reviews, ⁓ where sometimes teams demo too much in a sprint review. And they feel like they have to justify their existence, show everything you did during the sprint. And the most egregious example of that was this was a handful of years ago. But I literally remember a team showing Brian Milner (12:58) Yeah. Yeah. Mike (13:18) how they had updated the copyright notice on the footer of the web page, know, copyright, you know, whatever year our company, right? And it's like, my God, you didn't need to show that to stakeholders, right? We all either know there's a copyright notice on the bottom of the web page or we've seen one before. I don't need you to bring it up and scroll down to it. Now only took 15 seconds of the meeting, but that was 15 seconds of people's lives. They were never going to get back. you know, show stuff that you need feedback on, right? If you'd... Brian Milner (13:41) Right. Mike (13:45) You fixed a bug and you fixed it only way it could be fixed. Mention it perhaps, but you don't need to show it, right? Brian Milner (13:51) Yeah, yeah, know teams I've been on often it's just it's suffice it to have a list sometimes and just say here's a list of things if you want to know more about these come talk to us but we're move on to the stuff you care about. Mike (14:02) Yeah, I always have like a will show, will not show list. you know, I often, if I'm writing the meetup present, that'll put that up on Zoom or, you know, show it on a screen if we're in person. And often somebody wants to see something that's on the will not show list. Or they just want me to describe what bug was that again? What was that? You know, and I'll explain it really quickly. But if nobody wants to see it, don't bother showing it. So. Brian Milner (14:26) Yeah, I know we talk about these scrum practices quite a bit in the working on the scrum team class, but if someone signed up to take this class, what can they expect to hear or what can they expect to learn about these practices in the course? Mike (14:39) Well, I think one of the things that you and I did together in creating the newest version of the course was to look at what do you actually need to practice doing, and it's feasible to practice doing in a classroom setting, versus what should you just kind of talk through. And not everything needs to be practiced to get the hang of it, right? Everybody in the world has taken something big and split it up into smaller things before, right? I need to make. spaghetti dinner tonight. What do need to buy? Right? OK. Well, that's that's that's test decomposition by noodles, by sauce, by tomatoes. Let's make it from scratch. Right. By some garlic. Right. So everybody in the world has done decomposition. We've broken a big thing into small things. And I remember, you know, iterating over I'm still on sprint planning, I guess. But I remember iterating over exercises in sprint planning and in courses over the decades by now. And I would have one where you're planning a party for your kid, break it down into tasks. It's like, nobody learns anything from this. And so that's one where I'd rather say, OK, this problem occurs in sprint planning. How could you solve it? Other things like, let's say, splitting user stories or splitting job stories, that's a skill worth practicing together, getting feedback on. And so those type of things we try to practice in the course. other things we just talk about. mean, I'm curious on your thoughts on that. What do you think about some things being worth practicing, some things worth being better talked about? Brian Milner (16:01) Yeah, I agree. I agree fully. it's, it's, you know, there's some things, it's kind of like what you said before, there's some things that's not worth spending the time on, and it's better to just have a discussion and move on. Mike (16:13) Yeah. Yeah. I guess that's one of the things we always talked about. We always talked about return on investment of the exercise. What's the return on the exercise? And if you're going to have a one hour exercise, cool. One hour exercise. But it better have a pretty healthy return because that's a lot of time in class. And so what's the return on exercise? Is this worth a practice? Is it worth just a discussion? And if we can discuss two hard problems and give people advice on two common problems, they're probably going to face. Brian Milner (16:21) Yeah. Mike (16:41) Might be better than spending 20 minutes practicing something that they've probably done before. Brian Milner (16:45) Yeah, I completely agree. Let's move to the third pillar then, because I know this is a big one, just thinking and talking about the roles. And just as far as communication issues are concerned, even outside of Scrum, I know that's part of the big problem with teams and organizations just not being clearly defined about who does what and who's responsible for each thing. So those misunderstandings are really common failure points. ⁓ Mike (17:09) Mm-hmm. Brian Milner (17:10) How do you see teams getting that wrong and how's that derailing a Scrum team? Mike (17:15) Well, think we see it all the time on Scrum teams between Scrum Master and Product Owner and even the development team, right? Who does what? I was responding to some comments on LinkedIn this morning on some post I'd made last week and somebody had some comments. And it had to do with whether the Scrum Master or Product Owner does something. And it was interesting because in the comments on that post, I... I don't remember which one it was, but I shared a certain perspective. I feel pretty strongly that I have it right. I mean, I this is how we do it. But there were other people saying the opposite, right? And so, you know, these are people that are probably fairly experienced with Scrum, if they're following me on LinkedIn and feel comfortable commenting on a post, probably feel comfortable with it. And so there's a lot of confusion about what role does what thing. And I don't think this is something where the Scrum guy is going to have the answers for you. I think it's, I mean, you can look at the Scrum guy, oh, this. Here's my starting point answer, but we always want to play to people's strengths, right? And if you've got a scrum master who's got a lot of skill in one area, maybe they shift a little work from the PO to themselves, right? With the PO's permission, right? And the opposite, right? Between maybe PO and team. So it's fine to have default starting positions on who does what, but you always want to play to people's strengths. So I think PO scrum master, I think we see it with project managers and scrum masters, roll confusion on those type of roles as well. Brian Milner (18:38) Yeah, completely agree. A lot of those roles that are not named Scrum team roles and how they interact with the team, that's often a source of confusion as well. What are maybe some signs or symptoms that teams might be having confusion or problems in this area that maybe they don't even recognize or realize they're having an issue with roles? Mike (18:59) Any sort of conflicts, right? You know, you and I arguing over which one of us should do something. The other one would be kind of the opposite, which would be like a dropped ball. I was watching some YouTube video. I love baseball. I was watching some YouTube video the other day of like missed catches or something like that. And some team hit a baseball way up in the air and it was landing near three players, right? Three players are all looking at it. Brian Milner (19:12) You Mike (19:23) One guy waves the other two off, he's going to catch the ball and he must have been blinded by the sun because he's like six feet from the ball when it lands on the ground, right? And, you know, if we have a responsibility to catch the ball, run this meeting, right, right the backlog, the kids dropped, right? And so I think either arguing over who does something, two of us trying to do the same thing or neither of us doing it. I don't mean trying to get out of the work, right? All three players have been happy to catch the ball, but I think you've got it. You think I've got it, right? Those type of things are pretty good signs. think getting clarity around these roles can really optimize how a team works. And I think a really key thing here is that it changes over time. So I'll go back to my example of maybe the Scrubmaster has some skills that can help the product owner early on. Because maybe the product owner is new to the company. The product owner doesn't know the product as well. So they might rely on the Scrubmaster for guidance on things. Well, a year from now, we might shift responsibilities a little bit because now the PO is the expert on all things related to the product. So it's not like we want to establish clarity on roles one time and leave it forever. It's going to change. We get a new tester on the team, things might change. Product owner moves. It's going to change again. So we need to realize these responsibilities are dynamic. Brian Milner (20:39) Yeah, that's a great point. Your point about baseball just made me think about how, when you watch any youth sport in the world, when you go watch your kids play a sport, what's the one thing you always hear people scream from the sideline? Talk to each other. Call the ball. Well, that too. That too. Ump your blind. Those kinds of things. Well, let's talk a little bit about Mike (20:52) I thought you were going say, put my kid in. Brian Milner (21:00) I know this course addresses the roles and how would you say this course really helps address that issue of role confusion? Mike (21:07) think a big part of it is that we designed it to be for everybody on the team, right? Suppose you send a scrum master to a class, and it's a great class. Scrum master is going to back to the certain set of impressions about their role. Product owner goes to an equally good class about the product. They might have different impressions. Even if they took the course from the same instructor, they're hearing it a little differently. They're hearing it through their filters, right? And so when they're in a course together, there's more opportunities to clarify their understanding about those things, especially in the classes designed as we did with this one to bring out some of those differences. So I think the course helps with that. we've also designed it to mention the rules we haven't talked about, like managers and things like that. Brian Milner (21:53) Yeah, yeah, I think those are so important. And there's a lot of great discussions that come out when we have those topics. ⁓ Let's talk about the fourth pillar then, teamwork, because this, I think, builds really well on what we just talked about. And the idea that there's actually, Scrum is a team sport. ⁓ So beyond just normal human personality conflict type issues, what do you see that gets in the way of teams actually Mike (21:58) Mm-hmm. Mm-hmm. Brian Milner (22:18) working as a team. Mike (22:19) think ego is probably one, right? I can do everything better, just leave me alone. There's an old book that says basically, beware of a lone developer in a room, right? You know, it was referring to the developer who wants to close their door and say, I'll it done in a month, trust me, right? And one of the companies I worked with, and this one's going back like 15 years ago, but it was a really good story. Brian Milner (22:36) Yeah. Mike (22:43) is they would literally grab one unit of work. Each person on the team would grab a unit of work and take anywhere from three to 12 months to do the thing. So they were big things, but the person would do everything on it. They'd coded, tested everything. And the organization was putting out very little because of this. When they moved to Scrum in the first year, by their estimate, they said they delivered 540 % more work. over five times the amount of new features delivered. And that was through the collaboration, through the short iterations, those type of things. But it was about getting people to collaborate more. So I think there's huge opportunities to do that. One of the problems I see is when we don't overlap work. If we think about that organization I just described, you grab your thing, you're done in six months. I grab mine, I'm done in seven months. If we'd work together on those things, what's not make us any faster? No faster. But you and I could have worked on your one thing and been done in three months. OK, we're delivering value in three months, right? And so one of the things I look for a lot is how much teams are overlapping work, right? And if we're not overlapping work, there's huge opportunities to improve at that. I'll a little example of this. One of my favorite restaurants is, I don't know, barely call it a restaurant. It's a fast food deli. It's called Jimmy John's. Have you been to Jimmy John's, Yeah. Yeah, there's one near my house where I can go there and the wine will be out the door. Right. And you know, normally you see a wine out the door and it's like, crap, I'm going somewhere else. Right. These guys are so fast. They're so fast. When I get to the front, I place my order. I play this little game of can I fill up my cup? You know, I get an iced tea and they give me an empty cup and can I go fill up ice and put the tea in before they hand me my sandwich? And it's about 50-50. Right. It doesn't take long to fill up your iced tea. But the way they do that is the overlap work. As soon as I order my Italian club sandwich, somebody's already got the bread open, somebody's got a slab of meat they're ready to drop on there, somebody else has their hands over the vegetables and they're dropping the vegetables on there, and then a fourth person wraps it up. And so like four or five people touch my sandwich. Hopefully their hands are clean, but four or five people touch my sandwich as opposed to like most delis where I go and it's like you watch one person plod along making the sandwich, right? Overlap work is huge. Brian Milner (25:07) Yeah. Yeah, this episode sponsored by, no, just kidding. Use code Mike Cohn when you go to, no, just kidding. Yeah, I agree. And yeah, yeah, I'm familiar with Jimmy John's. Probably too familiar. ⁓ Yes, yeah, no, that's, I think that's part of their shtick is that they're, you know, they're known for being fast. So yeah. Mike (25:10) You Is yours just as fast? Yeah. Yeah. They call it Freaky Fast. They actually have a competition. I've seen YouTube videos of this where they get like the best teams at various restaurants race, right? And so they have like the Jimmy John sandwich making Olympics or something, but it's a skill. Brian Milner (25:36) wow, wow, yeah. You should pair that up with the hot dog eating challenge in some way and see if we could have a team sport going there. ⁓ Mike (25:48) Well, that's a good point because think about the hot dog eating. That's one guy, right? That's Joey Chesnett shoving hot dogs down. The Jimmy Johns is a team. They get the best crew at a restaurant and it's a team, right? How fast can the team go? Not how fast can one guy make a sandwich, right? Brian Milner (25:51) Yeah. Yeah, yeah. That's awesome. So what are some tips? What are some ways that you can really unite a team, especially those new teams? Because that's the fascination point for me is, how do you take this group of humans that really don't know each other and haven't worked together in the past and unite them together and have them gel as a team? How do you do that? Mike (26:21) I'll give you a couple. One, I think having really crisp sprint goals helps. So we all know exactly what we're trying to get done in the sprint. We don't lose sight of that because sometimes in the middle of a sprint, you lose sight of it. And you get myopic and you just focus on a list of tasks. And I'm going to say that it's probably similar to the team doing sprint planning and just getting them assessed with the numbers. It's not about the numbers. It's not about the tasks. It's about the backlog items that lead to some goal. So crisp sprint goals help. That's a hard phrase. Crisp Sprinkles helps. The other one I'd say is having a shared vision about where you're headed over a little bit longer term. Probably the biggest change to the Scrum Guide ever that I've liked is the inclusion of a product goal. And that was something I'd been talking about forever. mean, literally since I started doing Scrum was that sprinkles are great, but they're pretty short, right? You want to have something bigger. Brian Milner (26:52) It is. Mike (27:14) And so I like having product goals that are a few months out there. And one of the things I like doing for product goals is have teams do something like write a press release that describes their goal or create a vision in some way, write a review that you want to see come out on the App Store, Play Store, and a magazine. And one of my clients made software and they were reviewed by a major magazine and they were given an editor's choice runner up award. And they actually estimated that being runners up for that was probably worth about $10 million. First place, first time was worth about $10 million a year to them. And so they decided to get serious about this and they wrote a review. Their scrum master, she was actually combo scrum master product owner, Erin. She had the team write a review and she said, let's go earn this review. And I literally remember the email I got from her three months later. It was because it was Halloween night. I just like, you know, brought in the candy from outdoors. We're done trick or treating. And I checked my email. I a three word email from her from Erin. said we did it. And the magazine had let her know, hey, we're reviewing you. be out on, you know, like Tuesday's edition. And the review had quotes in there that were from their vision review, right? The things that they had wanted to achieve. Brian Milner (28:22) Ha ha. Mike (28:35) And that team had just really jelled around that and just became so much more productive and collaborated so much better because of that shared vision. Brian Milner (28:43) Yeah, that's amazing. getting back to the course then, I know in the course we're trying to kind of some of those collaboration muscles. What are some of the ways that the course helps to build that? Mike (28:56) think one of the key things that we're doing, and I'm excited about this, is that we're, you know, we of course use Zoom breakout rooms, right? You you go talk about this, we'll see you in eight minutes or something like that. And for this course, we're doing something where a group of three or more, when they register, can have a private breakout room. And this to me is exciting because people get the benefit of having a private breakout room. They can have sensitive discussions if they want. They can talk very specifically about. you know, what do we do about our jerk product owner? mean, whatever it is, right? You know, they can talk about their specific issues, yet have the context of a broader class. Because I think in one of the benefits of any public class is hearing how other teams are doing things. And sometimes that's because you get a good advice, you know, how did you solve that problem? We have that problem. Other times, it's just feeling that you're not alone in the world. they've got that problem too, right? And they don't have any solution for me, but I know I'm not alone in the world with this. And so I like these private breakout rooms for three or more. I think it's a novel thing we're doing with this class. And it's with the intent of combining the best of both worlds of private and public training for this. I'd the other thing is probably consistency, having everybody on the team hear the same message, having those discussions with an experienced instructor like you or me in the room to provide guidance when they have questions. know, go back to the role clarity, right? You know, they can talk about it and they're there. Then they're back in the main room with you or me and we can kind of answer questions. So I think that consistency will be huge as well. Brian Milner (30:25) Yeah, yeah, I love that idea of the private private breakout rooms that that's that's gonna be huge for a lot of people I know. ⁓ Mike (30:31) I'm excited to try it with this. This will be the first classes we do that for. I'm excited about it. Brian Milner (30:36) Yeah, yeah. Well, let's bring it home then and talk about the fifth pillar because the fifth pillar is really interesting as well. It talks about support beyond the team and teams can only do so much. Every team struggles when they're not supported well. And there's lots of studies that show leadership support is one of the biggest hurdles or obstacles to the adoption. Mike (30:46) Mm-hmm. Brian Milner (30:59) What does that support look like from outside the team and how can a team influence that? Mike (31:06) Yeah, if you're trying to be agile and your HR group has quarterly reviews of personnel that are all based on individual performance and has nothing to do about teamwork in there, it's going to be hard to focus on collaboration. So we have to kind of fix these issues. I think what we have to do here is to have team members educate those outside the organization. And we have information that we share about, you here's how to talk to a boss that's maybe mandating deadlines, things like that. And so we try to coach people through having some of those challenging conversations. And one of things I want teams to do is kind of become an example of what good agile looks like. And if you have a team that's excelling with agile and they're doing it from a kind of principles first, that mindset first approach. You're going to see other groups look at that and let's say the marketing group. They're going to look at that go, hey, that's an interesting way to work. I wonder how we could do that, right? And it's going look different for a marketing group than a tech team. the mindset is going to be the same. Principles will still be the same. And so when we get teams to do really well with this, other parts of the organization start to get interested. And then they stop being as much in our way. Brian Milner (32:20) Yeah. I know one of the most important aspects here and that we talk about is, is that you don't need to, to wait, right? If you're the team level, you don't have to just sit around and wait for the organization to make changes. you, you have opportunities to make changes as well. So how does that happen? How's the team change, you know, bring about those changes that, improve the agile process, the results. Mike (32:42) I think that's by being the example so that people see it. I think it's by having those conversations. You know, one of the things that we'll get is, you know, it's so common is the product owner that wants to change their mind all the time. I was reading something, I guess this is in our Agile mentors community, I think is where it was, but it was about the, you know, the product owner who said his favorite thing about Agile is that he can reprioritize every week. ⁓ And it's like, you can, you know. Brian Milner (33:05) Hmm. Yeah Mike (33:10) I'm not sure it's good. And I think about that, a team gets momentum, right? And you're working on a certain feature. Next sprint, it would be nice to work in that same area of this system, right? Your head's there. Just kind of keep going a little bit. And I've often described this as like, let's say you're working on three backlog items that are in a certain area of this system. Let's make it concrete. Let's say it's the spell checker in Microsoft Office, right? And you do three backlog items related to the spell checker this sprint. Next sprint, maybe your top priority is not more spell checker stuff, but maybe items, I don't know, 25, 26, and 27 on the backlog are still in the spell checker. You know what? It might be better to do those. There are probably two or three sprints away. Let's bring them into this sprint. Just get them done while my head's into spell checking. And so getting product owners or stakeholders to stop doing that, one of the ways that I like to talk about doing that is using an example of ordering a meal at a restaurant. I can order, let's say, the chicken entree. And then as the waiter is taking the orders around the table, I change from chicken, no, bring me the fish. Not a big deal. The waiter is going to cross off chicken and write down fish. If the waiter goes away, brings me back my salad, and I change my mind then, I say, hey, bring me the fish. Might not be a big deal. It's going to be a big deal if I've already taken three bites of the chicken. right? Or if he brings me the chicken. So yeah, we can change our mind, but there's a cost, right? And we want to educate stakeholders about that cost. They don't overdo it. Brian Milner (34:31) Yeah. Yeah. Well, speaking of the leaders and the organization, managers, leaders, do you think this course is appropriate for managers and leaders to attend as well? you feel like they might need to in order to really have this be an impact? Mike (34:55) Yeah, that's a good question. Is it appropriate? Yeah, I think it's appropriate. When we do this privately, we've had plenty of leaders and managers attend. I think it's great. I don't think that's required because they're not on the Scrum team. You said the name of the course is working on a Scrum team. And so they're not on the Scrum team. They benefit by knowing more how their Scrum team works. But I think what we found is that having just a key subset of people who hear the same message work through the training together, and then go back to the organization. That's enough to bring the passion, conviction, and skills that we want. So we don't truly need leaders. They're great. I would never talk a leader out of going, but I wouldn't. If I were a team and I could take the class this month or with my leader next month, I would just get the class done, right? And educate the leader afterwards. Brian Milner (35:41) Yeah. Yeah, yeah, I think that's a good plan. All right, well then we've made our way through the five pillars and for people who have come this far with us and are at this point, if they're listening and they're recognizing some of these problems we've been talking about, what would you recommend to them as next steps here? Mike (35:49) if Well, take a look at our website. If you go to mountaingoatsoftware.com. And then I think there's a courses link on the top. You can go up there and find the link to this course. It's an exciting one that we're doing. I've literally been teaching this, I think the first time I taught a class called Working on a Scrum Team was 2003 or 2004. it's a time tested course. You and I kind of redesigned it a couple of months ago to make it appropriate for public. or little better just in general and more appropriate for public. But it's a time-tested course that's now designed to be available for public settings instead of, you know, have to have 25 people or something. Brian Milner (36:36) Yeah, yeah, that's really exciting. I can't wait to see kind of how people are in, you know, react and interact in the course to some of these concepts and ideas. And we'll, we'll of course link to all these things that we've talked about in our show notes and make it easy for everyone to find the course listing and, and, you know, where the dates and everything that we're going to offer them. So make sure to check that out. Mike, thanks so much for coming on. This has been really enlightening and I appreciate you making time for it. Mike (37:01) Of course, thanks for having me, Brian. Always a pleasure.

Hoe zet Polarsteps AI-features in om jouw volgende reis te planen? In deze aflevering spreekt Ruud met Floris, Senior Product Manager bij Polarsteps, over een slimme AI-feature die automatisch nieuwe reizen plant op basis van je eerdere trips, voorkeuren en het gedrag van andere reizigers. Geen gimmick, maar een functionele toevoeging waar gebruikers écht iets aan hebben. Samen duiken ze in het ontwikkelproces: van idee tot lancering, de rol van data, tools, en het team. Een praktische aflevering over hoe je als productteam AI inzet om waarde toe te voegen aan je product. In deze aflevering hebben we het over: Polarsteps, AI in productontwikkeling, gepersonaliseerde reisplanning, slimme AI-feature, productmanagement, MVP (Minimum Viable Product), data als input voor AI, AI en klantwaarde Over deze podcast: Deze aflevering is onderdeel van de speciale reeks ‘AI in Product Development', onderdeel van de Product Owner podcast. In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van productowner.nl

Product Backlog Management – von der Pflichtaufgabe zum strategischen Hebel Viele Product Owner sehen Product Backlog Management als lästige Pflicht. Dabei ist es laut Scrum Guide eine Kernaufgabe des Product Owners – und entscheidend für Klarheit, Wirksamkeit und Fokus. In dieser Folge sprechen Tim und Oliver darüber, - warum viele Product Backlogs ausser Kontrolle geraten - wie ein klares Product Goal Priorisierung und Stakeholder-Gespräche erleichtert, - weshalb Kommunikation mehr ist als über Jira-Tickets sprechen und - wie Mut zum Ausmisten den Weg zu mehr Fokus ebnet. Oliver teilt frische Erkenntnisse aus seiner Product Backlog Management Masterclass mit Product Ownern aus unterschiedlichen Branchen und zeigt, wie das Product Backlog vom Verwaltungstool zur strategischen Steuerungszentrale wird.

Anamaria Ungureanu: Building Self-Awareness in Overly-Technical Product Owners 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 Master Storyteller Anamaria highlights a Product Owner who excelled at storytelling and vision communication, making every team member feel aligned with project goals. This exceptional PO consistently explained the "why" behind requirements and painted compelling pictures of how the team's current work would create future value. Their storytelling ability kept the team engaged and motivated, demonstrating how great Product Owners apply agile mindset principles to create shared understanding and purpose. The Bad Product Owner: The Monologue Specialist Anamaria describes a technically-skilled Product Owner who transitioned from a tech lead role but fell into the anti-pattern of excessive monologuing during sprint planning sessions. This PO, despite good intentions, overwhelmed the team with lengthy technical details, causing developers to withdraw from interactions and leaving them confused about project purposes. Through one-on-one coaching focused on building self-awareness and establishing working agreements, Anamaria helped this PO learn to communicate more effectively and engage collaboratively with the team. Self-reflection Question: How do you help Product Owners transition from technical expertise to effective team communication, and what signs indicate when detailed explanations become counterproductive monologues? [The Scrum Master Toolbox Podcast Recommends]

How do you prove your value as a Scrum Master? What steps can you take as Scrum Master to coach your Product Owner? What are some ways to make Scrum Events more engaging? There is a lot to navigate within the Scrum Master Accountability. PST Bart Versteegen recently answered some burning listener questions about the Scrum Master Accountability. Tune in for great insights!

38% van de product owners loopt achter op hun roadmap. Deadlines schuiven op, prioriteiten stapelen zich op en teams raken overbelast. In deze aflevering van de Product Owner podcast spreekt Ruud met Martijn over wat je dan doet. Herplannen? Team aanpassen? Of toch eens over de grens kijken, bijvoorbeeld naar nearshoring? We horen hoe Martijn al jarenlang succesvol samenwerkt met nearshore teams, en hoe Giancarlo als IT-leider vaak de afweging maakte: fixen we het intern, of met een partner? We bespreken wanneer nearshoring wel of niet werkt, hoe je de juiste partner kiest én hoe je als product owner grip houdt op kwaliteit en communicatie. Ook hoor je hoe je kunt inschatten of nearshoring geschikt is voor jouw situatie. Een aflevering vol inzichten, praktijkvoorbeelden en concrete tips. Wil je inzicht krijgen en inlopen op je roadmap? Ga naar productowner.nl/uitbesteden. In deze aflevering hebben we het over: roadmap achterstand, product owners, deadlines, prioriteren, nearshoring, teamcapaciteit, uitbesteden, NetRom, partnerkeuze, grip houden. Over deze podcast: In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van Productowner.nl

Anamaria Ungureanu: Goal Clarity—The Missing Piece in Agile Team Performance 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. Anamaria shares her experience working with a platform implementation team that appeared engaged but was actually struggling in silence. Despite initial assumptions that everything was fine, the team's quiet demeanor masked their lack of understanding about project goals and deliverables.  Through strategic intervention including goal clarification with the Product Owner, confidence level assessments, and story mapping sessions, Anamaria helped transform a disengaged team into one capable of successful delivery. Her approach emphasized the importance of fostering constructive conflict, asking open questions during sprint planning about demo expectations, and facilitating better PO-team interactions to create transparency and shared understanding. In this episode, we refer to User Story Mapping and the concept of Gemba, or Gemba Walk Self-reflection Question: How might your teams be silently struggling, and what signs should you watch for to identify when apparent engagement actually masks confusion or disengagement? [The Scrum Master Toolbox Podcast Recommends]

Tanja Heyken ist zu Gast bei Dominique, um gemeinsam auf das Thema „Designprinzipien“ zu schauen und was diese im Alltag von Produktteams tatsächlich bewirken können. Tanja bringt ihre doppelte Perspektive als UX-Professional und Product Owner mit, die sie bei Checkmk täglich lebt. Ihr Ziel ist es Entscheidungsprozesse zu vereinfachen, Konsistenz schaffen und die User Experience verbessern, ohne dafür jedes Mal von vorne zu diskutieren. Designprinzipien versteht sie dabei als konkrete, nutzerzentrierte Leitplanken. Sie helfen Teams, bessere Entscheidungen zu treffen – auch dann, wenn gerade niemand aus UX oder Product dabei ist. Die wichtige Grundlage dafür sind Daten: Wer mit Designprinzipien arbeiten möchte, sollte die Perspektive der Nutzer:innen ernst nehmen. Tanja empfiehlt den UEQ+ als kompaktes Instrument, um herauszufinden, welche Eigenschaften den Nutzenden wichtig sind und wie das Produkt aktuell wahrgenommen wird. Daraus lassen sich Designprinzipien ableiten, die zur Realität der Nutzer:innen passen, nicht nur zu den Annahmen im Team. Doch wie kommt man von ersten Erkenntnissen zu Prinzipien, die im Alltag wirklich nützlich sind? Für Tanja beginnt alles mit einem interdisziplinären Workshop. Entscheidend sind UX, Product, Entwicklung, Support, Sales; also möglichst viele Sichtweisen an einen Tisch holen, um gemeinsames Verständnis zu schaffen. Ziel ist nicht die perfekte Formulierung im ersten Anlauf, sondern die Entwicklung von sogenannten Proto-Prinzipien, die sich dann im Team schrittweise verfeinern und gegen reale Entscheidungen testen lassen. Dieser iterative Prozess sichert nicht nur Qualität, sondern stärkt auch die Akzeptanz im Unternehmen. Designprinzipien müssen einfach und greifbar sein. Drei bis fünf gut formulierte Prinzipien lassen sich besser merken und leben als zwölf ambitionierte. Spotify zeigt, wie es geht: Relevant, Human, Unified. Auch bei Figma sieht man, wie Eigenschaften wie „Thoughtful“ oder „Approachable“ Orientierung bieten können. Entscheidend ist aber nicht nur die Kürze, sondern das gemeinsame Verständnis dahinter: Was bedeutet z. B. „Human“ konkret im Produkt? Welche Sprache, welche Gestaltung, welche Entscheidungen zahlen darauf ein? Damit Designprinzipien im Alltag wirken, braucht es mehr als ein PDF oder einen Eintrag im Wiki. Prinzipien müssen kontinuierlich sichtbar gemacht werden, etwa durch Beispiele in Reviews, durch Argumentation im Daily oder durch Verankerung im Onboarding neuer Teammitglieder. Designprinzipien sind keine Regeln, sondern Orientierung. Sie ersetzen kein User Research, kein Testing, keine Interviews, aber sie geben Teams Sicherheit in Entscheidungen, die jeden Tag getroffen werden müssen. Die große Stärke von Designprinzipien liegt darin, dass sie helfen, auch in wachsenden Teams mit immer mehr Beteiligten eine konsistente UX sicherzustellen. Die Verknüpfung zu anderen Artefakten in der Produktentwicklung, etwa der Produktvision, dem Product Goal oder Sprintziel ist auch sehr spannend. Selbst wenn Designprinzipien keine direkten Bestandteile von Scrum sind, lassen sie sich gut als tägliche Entscheidungshilfe für alle, die das Produkt gestalten, in diese Strukturen einbetten. Wer Designprinzipien im Team etablieren möchte, sollte aber auch nicht zu perfektionistisch starten, sondern lieber loslegen, lernen und iterieren. Denn die besten Prinzipien entstehen nicht auf dem Papier, sondern in der echten Zusammenarbeit. Referenzen: - Unter https://ueqplus.ueq-research.org/ gibt es mehr Infromationen zum UEQ+ - Ein ähnliche sKonzept ist die UX Vision. Unter https://produktwerker.de/ux-vision/ findet ihr eine dazu passende Folge.  Tanja steht euch natürlich für weitere Fragen zur Verfügung. Ihr erreicht si am besten unter https://www.linkedin.com/in/tanja-heyken-7a9406124/.

Anh Vu: The Hidden Cost of Decision-Making Delays in Product Development 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 Strategic Connector Anh describes an exceptional Product Owner who went far beyond managing the backlog to become a strategic connector between customer needs, business requirements, technical constraints, and overall strategy. What made this PO remarkable was their background - they came from a developer background rather than business, yet quickly mastered the Product Owner role through dedicated learning. Despite being new to the PO role, they rapidly developed the ability to connect backlog items directly to customer pain points, often using techniques like user story mapping. This PO brought both clarity and purpose to the team, significantly boosting team motivation by helping developers understand how their work directly impacted customers and business outcomes. The Bad Product Owner: The Proxy Problem The worst Product Owner situation Anh encountered involved a Proxy PO who lacked the authority to make decisions independently. This created significant challenges for both the team and the PO, as every new problem or decision required seeking permission from external stakeholders. This pattern lengthened feedback cycles and demotivated both the PO and the development team, who couldn't move forward efficiently when blocked by decisions. Anh's approach to addressing this involved coaching the PO on engaging with external stakeholders, setting up regular touchpoints (2-3 times per week) to shorten feedback cycles, and focusing on improving the decision-making process to unblock the team. He also emphasized creating a strong network of connections for the PO to navigate the organization effectively and always having a Plan B when certain decisions couldn't be made quickly. Self-reflection Question: Does your Product Owner have true decision-making authority, or are they frequently forced to seek permission from others, and how is this affecting your team's velocity and motivation? [The Scrum Master Toolbox Podcast Recommends]

En este episodio de Hack Tu Vida hablamos con Vladimir Guzmán Mendoza, experto en innovación y mentor de emprendedores en Reino Unido, sobre lo que realmente significa vivir, aprender y trabajar en tiempos de inteligencia artificial. Conversamos sobre cómo la IA está transformando el mundo profesional, las oportunidades que representa para los latinos y por qué es urgente aprender a usarla sin miedo, sin importar tu edad o experiencia previa. Este episodio es una invitación a reemplazar el miedo por curiosidad, y la curiosidad por acción. TEMAS DESTACADOS: Qué es la inteligencia artificial (explicado para nuestras mamás). Por qué la IA no viene a quitarnos el trabajo, sino a liberarnos. Cómo los latinos pueden aprovechar esta tecnología para crear, aprender y crecer. El poder de los prompts: aprende a comunicarte con la IA para obtener resultados reales. Reinvención profesional: cambiar de carrera o aprender algo nuevo con IA. Automatización sin saber programar: ¡tú también puedes! El valor del coraje, la acción y el pensamiento crítico en la era digital. En esta conversación, Vladimir también comparte herramientas de inteligencia artificial que recomienda para empezar a automatizar tareas, crear contenido y resolver problemas reales sin necesidad de programar. Entre ellas están ChatGPT y Gemini para conversaciones inteligentes, Make y n8n para flujos de automatización, y Canva o Bo3 para diseño y creación de videos con IA. Además, menciona cuentas en español como @construyeconIA y @welcomemineiro, así como su propio proyecto @gingga.ai, enfocados en compartir conocimientos y aplicaciones prácticas de esta tecnología. "La inteligencia artificial no es el enemigo. Es el atajo. Y estamos justo a tiempo para aprender a usarlo." – Vladimir Guzmán Mendoza Comparte este episodio con alguien que aún cree que la IA es solo para expertos. ¿Tienes miedo de sonar tonto al usar estas herramientas? Este episodio te va a cambiar la perspectiva. Dale like si aprendiste algo nuevo y SUSCRÍBETE para seguir recibiendo conversaciones reales sobre tecnología, conciencia y crecimiento. Suscríbete a nuestro Newsletter www.hacktuvida.com

"Origin stories create die-hard fans. Once your story and your product are inseparable, you win."In this powerful episode of Mastering Agility, Jim and Sander sit down with storytelling strategist Osita Ifezue to explore how strategic storytelling can reshape the way agile teams operate, connect with customers, and innovate beyond the status quo. Recorded at ScanAgile 2025, Osita shares how organizations like LEGO, Apple, Nike, and IKEA use storytelling to drive customer loyalty, enhance internal alignment, and navigate change.Connect with Osita: (31) Osita Ifezue | LinkedInCheck out Think About It! With Osita Ifezue Podcast: https://open.spotify.com/show/2idqtZvGCMswcqIPvQMDCa?si=oQhfzXDkRFCYRDtW16PkUgCheck out our sponsor:www.xebia.comwww.wiserbees.comwww.masteringagility.orgHosted by Ausha. See ausha.co/privacy-policy for more information.

Industrial Talk is onsite at Xcelerate 2025 and talking to Austin Anderson, Product Owner, Condition Monitoring at Fluke Reliability about "Azima's Powerful AI Vibration Platform". Scott MacKenzie hosts the Industrial Talk podcast, highlighting industry innovations and trends. He introduces Austin Anderson, who discusses Azima's diagnostic system and its integration with Fluke Reliability. Anderson explains the standardization of data collection over 15 years, emphasizing the importance of accurate data for reliability. He details the integration of Azima's AI with human analysts for 85% accuracy and the development of a user-friendly interface. The conversation also covers the future of Azima, including expansion into oil analysis and thermography, and the importance of efficient data storage and management. Anderson can be contacted via LinkedIn for more information. Action Items [ ] Rebuild the Azima user interface to make it more user-friendly and easily accessible. [ ] Integrate Azima's data and insights with Fluke's other reliability solutions, such as alignment and balancing, to provide an end-to-end connected reliability offering. [ ] Enhance the Azima platform to include additional reliability data sources beyond just vibration, such as oil analysis and thermography. [ ] Develop a solution that can automatically translate Azima's problem identifications into work orders in the customer's CMMS (e.g., eMaint). Outline Introduction and Overview of Industrial Talk Podcast Scott MacKenzie introduces the Industrial Talk podcast, emphasizing its focus on industrial innovations and trends. Scott highlights the free ebook and workbook available on Industrial Talk, which expands on five elements of successful companies: educate, collaborate, innovate, invest in culture, and communicate effectively. Scott MacKenzie thanks listeners for their support and celebrates industrial professionals for their boldness, bravery, and problem-solving skills. Introduction of Austin Anderson and Azima Scott MacKenzie introduces Austin Anderson, who will discuss the product Azima. Austin Anderson shares his background, mentioning his three-year tenure with Azima and his role in developing the diagnostic system. Scott MacKenzie inquires about the accuracy of the data stored in Azima, to which Austin explains the standardized method of data collection and its relevance over the years. Austin discusses his background in vibration analysis and his previous work with the Navy, highlighting his expertise in the field. Strategic Path and User Experience of Azima Austin outlines the strategic path for Azima, focusing on making reliability engineers superstars and providing useful insights for top-level executives. Scott MacKenzie asks about the integration of Azima with Fluke Reliability, and Austin explains the goal of making the platform user-friendly and value-added. Austin describes the end-to-end connected reliability solution offered by Fluke Reliability, including hardware, software, and alignment and balancing services. Scott and Austin discuss the importance of user experience and the redesign of the user interface to make it more accessible and user-friendly. Data Accuracy and Integration with Fluke Reliability Scott MacKenzie inquires about the accuracy of the diagnostic system, and Austin explains that AI can achieve 85% accuracy, with the remaining 15% covered by human analysts. Austin discusses the integration of Azima with Fluke Reliability's x5...

Hoe zit het eigenlijk met strategisch denken, eigenaarschap en het gebruik van data in ons vak? Ruud bespreekt met Stephan van Expandior de resultaten van de GO Product Navigator: een assessment dat door meer dan 1000 Product Owners en Product Managers is ingevuld. Wat blijkt: we zijn sterk in delivery en samenwerking, maar strategie, data en business blijven achter. Veel PO's voelen zich niet verantwoordelijk voor omzet of richting, en dat roept natuurlijk vragen op. Ook komt het fenomeen ‘title inflation' aan bod: hoe komt het dat steeds meer mensen zich PO noemen, terwijl ze die rol inhoudelijk niet vervullen? In deze aflevering hebben we het over: strategie, verantwoordelijkheid, data, samenwerking, delivery, title inflation, GO Product Navigator, product owners. Over deze podcast: Deze aflevering is onderdeel van de speciale reeks ‘AI in Product Development', onderdeel van de Product Owner podcast. In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van productowner.nl

User Stories sind aus der agilen Produktentwicklung kaum wegzudenken, dennoch verursachen sie regelmäßig Reibung, Missverständnisse oder sogar echten Schaden im Entwicklungsprozess. In dieser Folge schauen sich Oliver und Tim die größten Fehler bei der Arbeit mit User Stories an und sprechen offen darüber, wie sie selbst immer wieder in diese Fallen getappt sind. Ein häufiger Fehler beginnt schon beim Schreiben: Statt sich gemeinsam ein Bild vom Nutzerproblem zu machen, werden Storys im stillen Kämmerlein formuliert und (nur) in Schriftform ins Sprint Planning gebracht. Dabei soll die Story eher ein Erinnerungspunkt für ein Gespräch sein, nicht das Gespräch ersetzen. Die Diskussion über das zugrundeliegende Problem, also das gemeinsame Verstehen der Nutzerbedürfnisse – ist der Schlüssel. Storytelling und entwickeln von Problemempathie mit dem Team führen zu besseren Lösungen. Und genau dafür braucht es ein Gespräch, kein perfekt ausgefülltes Template oder "Ticket". Der nächste Trugschluss: User Stories müssten irgendwie "abgenommen" werden. Diese Idee stammt noch aus einer Projektlogik und widerspricht dem agilen Grundgedanken. Akzeptanzkriterien dienen nicht als Vertrag, sondern als Einladung zur gemeinsamen Einschätzung: Haben wir das gemeinsam verstandende Problem gut genug gelöst? Abnahme-Rituale im Sprint Review mit "Daumen hoch oder runter" führen hier meist in die Irre. Vielmehr geht es um Reflexion ob die gefundene Lösung zum Nutzerproblem passt – im besten Fall sogar mit Feedback der eigentlichen Nutzer:innen. Besonders schädlich wird es, wenn Product Owner anfangen, in User Stories ihre Lösungen dertailliert vorzugeben. Dann bleibt wenig Raum für Kreativität oder bessere Ideen aus dem Team. Eine gute User Story wird im Problemraum formuliert und darf dabei auch gerne eine LösungsIDEE mitbringen. Sie macht Wirkung und Ziel verständlich – nicht den genauen Umsetzungspfad. Wenn alles schon vorgegeben ist, gibt es keine echte Zusammenarbeit mehr. Auch beim Schneiden von User Stories wird viel Potenzial verschenkt. Zu große Storys, die sich über mehrere Sprints ziehen, nehmen uns die Chance für kurzfristiges Feedback und verlangsamen damit die Lernkurve. Und wenn denn geschnitten wird sorgen horizontale Schnitte entlang technischer Komponenten eher für Abhängigkeiten statt echten Mehrwert. Der Weg zu kleinen, vertikal geschnittenen Storys ist nicht immer leicht, aber entscheidend für schnelles Feedback bzgl. der erwünschten Wirkung (Outcome). Und dann wäre da noch das "Connextra"-Template. Es kann helfen, den Einstieg zu finden. Aber wer alles in das Format "Als (Nutzer) möchte ich…, damit …" zwängt, läuft Gefahr, das Denken zu verengen. Nicht jede Aufgabe ist eine User Story und nicht jede User Story braucht eine feste Form in diesem Template. Es braucht ein Gefühl für das Problem, nicht nur eine korrekt ausgefüllte Schablone. Der größte Fehler ist oft der Versuch, mit der falschen Haltung an User Stories heranzugehen. Wenn das Format über das Verständnis gestellt wird, wenn Gespräche durch Jira-Tickets ersetzt werden, wenn Stories zu Mikro-Aufträgen oder Fachfeinspezifikationen verkommen, geht der Sinn für die Arbeit mit User Stories verloren. User Stories sind ein Mittel zur Zusammenarbeit, kein bürokratischer Selbstzweck. Wer das versteht, nutzt sie, um gemeinsam zu denken, nicht nur um Aufgaben ans Team zu dokumentieren. In dieser Folge wurde auf eine ganze Reihe früherer Episoden verwiesen: - Erfolgreich mit User Stories arbeiten - Wer nimmt User Stories ab? - User Story Splitting: Wie geht das "richtig"? - Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? - Akzeptanzkriterien richtig einsetzen - Mit Storytelling andere von Deinen Produktideen überzeugen Welche Fehler bei der Arbeit mit User Stories beobachtest du in deinem Team bzw. hast sie überwunden? Was funktioniert bei euch gut – und was weniger? Wir sind gespannt auf deine Erfahrungen, Perspektiven und Fragen.

Joelle Tegwen: Business Analyst to Product Owner—More Than a Title 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. The Great Product Owner: The Collaborative Visionary Joelle worked with an exceptional Product Owner at a medical company who was leading their team into a new way of working. This PO understood both the vision piece of the work and the importance of experimentation, recognizing that the team was responsible for figuring out how to solve the problems they were trying to tackle. Working within a Large Scale Scrum framework, they demonstrated patience while collaborating with skilled team members to improve how they worked together. Rather than complaining to the team about performance issues, this PO collaborated directly with the Scrum Master to address challenges. Most importantly, they maintained crystal clear focus on customer value, ensuring every decision and direction connected back to what would truly benefit the end user. The Bad Product Owner: The JIRA Manager Joelle describes the problematic pattern of Business Analysts who receive a title change to Product Owner without understanding the fundamental shift in role and responsibilities. These individuals continue to see themselves as scribes rather than visionaries, treating their primary job as managing JIRA instead of setting a vision for where the product should go. They typically lack understanding of meaningful metrics and rely on gut-feel prioritization rather than data-driven decisions. Most critically, they fail to communicate about problems to solve or establish a clear North Star for the team. Joelle recommends providing these POs with structured formats for Epics and features that start with hypothesis, problem, and measures, helping them think at higher levels than just user story management. Self-reflection Question: Whether you're a Product Owner or work closely with one, how might you help elevate the conversation from task management to vision and problem-solving? [The Scrum Master Toolbox Podcast Recommends]

Deze aflevering duiken we in de wereld van AI met een duidelijke focus: maatschappelijke meerwaarde. Want hoe kun je AI nou écht goed inzetten for the greater good? Daar is Marlies, werkzaam bij Norday, actief mee aan de slag. Zij lanceerde de AI for Good Studio en werkt daarmee aan features en oplossingen die er écht toe doen. En dat werk blijft niet onopgemerkt. Zo wonnen ze een Webby Award voor de Wondercast, en bespreken we een van de nieuwe AI-projecten in de ouderenzorg. Want juist daar kunnen échte problemen worden opgelost met de inzet van AI. Een interessante aflevering die laat zien wat de toegevoegde waarde van AI kan zijn – en nog belangrijker: hoe je de juiste AI-oplossing vindt voor jouw probleem. In deze aflevering hebben we het over: AI for Good, design sprint, solution space, prototyping, AI-adoptie, impact, problem definition Over deze podcast: Deze aflevering is onderdeel van de speciale reeks ‘AI in Product Development', onderdeel van de Product Owner podcast. In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van productowner.nl

Pascal Papathemelis: The Mobile Product Owner—Why Great POs Move Around and Talk to People 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 Visionary Communicator Pascal describes great Product Owners as excellent communicators who possess the courage to confront stakeholders when necessary. These exceptional POs thrive as decision makers and understand the importance of being mobile - they have "legs and walk around to meet stakeholders" rather than remaining isolated in their offices. Great Product Owners maintain a clear vision and excel at breaking down products into granular items that teams can easily pull from the backlog. They demonstrate superior backlog management skills and understand how to focus on creating systems that collect valuable feedback. Pascal emphasizes that it's critical to help Product Owners develop these capabilities so they can flourish in their role as the primary decision makers for their products. The Bad Product Owner: The Dominating Manager Pascal encountered a challenging Product Owner who exhibited several destructive anti-patterns. This PO dominated meetings by talking most of the time while the team remained silent, creating an environment where team members felt unsafe to contribute. The situation was complicated by the fact that this Product Owner also served as the line manager for the team members, blurring the boundaries between product decisions and personnel management. This dual role created a power dynamic that inhibited healthy team collaboration. The PO went so far as to stop retrospectives, even when Pascal explained how these sessions could benefit the entire team. Pascal identifies a critical anti-pattern: when a Product Owner has no channel of communication or coaching support, and they resist help, it becomes impossible to improve the situation. Self-reflection Question: What steps could you take to help Product Owners in your organization develop better communication skills and create safer environments for team collaboration? [The Scrum Master Toolbox Podcast Recommends]

Pascal Papathemelis: From Waterfall to Agile—A Multi-Level Change Strategy 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. Pascal describes a successful agile transformation where he collaborated with a fellow coach in the IT department of a large organization with a waterfall history and heavy documentation-driven processes. The two coaches worked together effectively, sharing information and scouting for opportunities to take action. They began with an assessment and discussions across IT, business, and management levels to understand the current state. Using the Cynefin framework to understand complexity, they conducted a two-day workshop to introduce Agile vocabulary, covering concepts like Push/Pull and process waste.  The coaches operated at multiple levels simultaneously - working strategically with leadership who typically pushed excessive work to the organization, while also helping teams visualize their processes and clarify priorities. At the team level, they acted as Scrum Masters to demonstrate the role while mentoring the actual Scrum Master through one-on-one sessions. They also supported the Product Owner in understanding their role and used story maps to help visualize and organize work effectively. Self-reflection Question: How might collaborating with another coach or change agent amplify your effectiveness in leading organizational transformation? [The Scrum Master Toolbox Podcast Recommends]

Pascal Papathemelis: The Hidden Cost of Removing Scrum Masters from High-Performing 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. Pascal shares a cautionary experience with mature Scrum teams that appeared to function flawlessly. These teams demonstrated excellent Scrum practices with minimal impediments, leading management to conclude that Scrum Masters were unnecessary. When management removed all Scrum Masters from the department, the previously high-performing teams began to struggle significantly.  Team members had to absorb the responsibilities previously handled by their Scrum Masters, causing them to lose focus on their core value-creating work. Different teams adopted various approaches to fill the Scrum Master void, but none proved effective. Pascal reflects that the Scrum Masters could have made their value more visible by supporting Product Owners more actively and becoming more involved in team tasks. This experience taught him the importance of demonstrating the ongoing value that Scrum Masters provide, even when teams appear to be self-sufficient. Featured Book of the Week: Learning Out Loud—Community Learning and Networking Pascal draws his greatest inspiration not from a single book, but from active participation in the Agile community. He finds tremendous value in discussions within local communities, networking events, and sparring sessions with colleagues. Pascal particularly benefits from Agile Coaching circles in Helsinki, which provide practical knowledge and insights. He also gains inspiration from Agile conferences, but credits Agile Coaching Camps as having the biggest impact - these 2.5-day open space format events are intense and packed with valuable insights. Pascal recommends that Scrum Masters actively engage with their local Agile communities and attend coaching camps to accelerate their professional development and gain diverse perspectives. Self-reflection Question: How visible is the value you provide as a Scrum Master, and what steps could you take to make your contributions more apparent to your organization? [The Scrum Master Toolbox Podcast Recommends]

Bernard Agrest: Millions of Users, Multiple Stakeholders—The Art of Product Owner Navigation 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 Stakeholder Navigator Bernard describes an exceptional Product Owner who managed a product impacting millions of people while navigating constantly evolving requirements from multiple stakeholders. This Product Owner excelled at understanding each stakeholder's unique needs and communicating effectively with all of them. What made this person truly great was their ability to come to the development team with a clear understanding of both the business case and user needs, having done the hard work of stakeholder management upfront. This Product Owner understood that their role was to be the bridge between complex stakeholder requirements and clear team direction. The Bad Product Owner: The Collaborative Hoarder Bernard identifies a dangerous anti-pattern: the Product Owner who adds everything to the backlog under the guise of being "collaborative." While this behavior appears inclusive and team-friendly on the surface, it actually demonstrates that the Product Owner isn't following through on delivering real value. These Product Owners become almost exclusively focused on authority rather than outcomes, making them particularly difficult to coach since they resist guidance. Bernard recommends using Cost of Delay as both a prioritization technique and a tool to help Product Owners understand why certain items shouldn't be added to the backlog at all. Self-reflection Question: Is your Product Owner truly collaborating by providing clear direction, or are they avoiding difficult prioritization decisions by adding everything to the backlog? In this segment we refer to the Coach Your Product Owner e-course that we created for everyone who needs to help their Product Owners succeed! [The Scrum Master Toolbox Podcast Recommends]

De método tecnológico a filosofía de gestiónLa metodología Agile y Scrum surgió en 2001 como una forma de gestionar proyectos en el ámbito de las tecnologías de la información y el desarrollo de software. Con el tiempo, ha evolucionado hacia un sistema de gestión aplicable no solo a proyectos tecnológicos, sino a iniciativas empresariales de todo tipo. En esencia, permite a las organizaciones generar valor de forma más eficiente en comparación con la gestión tradicional.Principios del manifiesto AgileEl manifiesto Agile establece que es preferible fomentar la interacción entre personas en lugar de basarse únicamente en procesos definidos. También defiende la adaptación al cambio por encima de seguir un plan rígido y prioriza la colaboración con el cliente frente a la firma de contratos exhaustivos. Estos valores han moldeado lo que hoy conocemos como Agile.El objetivo central de Agile es minimizar el desperdicio, una preocupación compartida con metodologías como Lean. ¿Cuál es el mayor desperdicio en un proyecto? Desarrollar algo que no aporta valor al cliente.Cómo evitar el desperdicioPara prevenir este error, Agile propone:Mantener una comunicación constante con el cliente.Entregar pequeños bloques de valor de forma continua.Ajustar el rumbo con base en la retroalimentación del cliente.Estas prácticas permiten que el proyecto evolucione de manera más precisa y efectiva.Scrum: la metodología más extendidaScrum, la herramienta más popular dentro de Agile, combina elementos de distintas metodologías. Su propósito es facilitar entregas parciales y constantes de valor por parte de equipos multidisciplinarios.Características clave de ScrumDivisión en entregables pequeños: El trabajo se organiza en bloques llamados Sprints, unidades de tiempo fijas que se repiten cíclicamente. Cada Sprint genera valor que puede validarse con el cliente.Equipos reducidos y diversos: Usualmente compuestos por 8 a 10 personas que representan distintas perspectivas del proyecto.Roles definidos: El Scrum Master garantiza el cumplimiento del método, mientras que el Product Owner recoge las necesidades del cliente y guía al equipo hacia ese objetivo.Aprender para mejorarAl finalizar cada Sprint se realizan dos tipos de retroalimentación:Retroalimentación interna, que permite al equipo mejorar su dinámica de trabajo.Retroalimentación del entregable, que evalúa si lo producido realmente genera valor para el cliente.Este sistema iterativo evita que se invierta tiempo y recursos en soluciones que no serán apreciadas.

Scrum isn't just a framework—it's a mindset, a way of thinking, and a lens through which we see work, teams, and leadership. In this episode, Kate and Ryan dive into nine bite-sized pieces of wisdom—some from Agile, some from life—that reinforce what it really means to work with agility.From confusing activity with productivity to killing your darlings, from sustainable pace to the danger of “we've always done it this way,” each insight connects back to values that drive high-performing, resilient, and human-centered teams. Whether you're a Scrum Master, Product Owner, or just someone trying to lead with more intention, this conversation offers practical reminders and fresh energy.And yes… there's even a M*A*S*H story you won't want to miss.

Lilia Pulova: Business Case Ownership—The Product Owner's Core Duty 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: Always Present and Inspirational Lilia describes an exceptional Product Owner whose defining characteristic was consistent presence with the team. This presence went beyond just showing up - it was inspirational and made team members genuinely care about their delivery and the product they were building. The Product Owner served as the vital connection between the team and the organization's wider mission, helping everyone understand how their work contributed to the bigger picture. This constant engagement and visibility created a motivated team that took pride in their product development efforts. The Bad Product Owner: Unprepared and Responsibility-Shifting Lilia encountered a Product Owner who exemplified poor practices by consistently arriving at backlog refinement meetings without any preparation, expecting developers to provide business context instead. This approach was fundamentally wrong because developers aren't equipped to discuss business expectations or product direction - that's the Product Owner's responsibility. This individual habitually said "yes" to all tickets without consideration, shifted decision-making responsibility to the team, and relied on architects to manage the product and determine sprint priorities. Product Owners must own the business case rather than delegate it, and keep the business rationale constantly visible to the team. Self-reflection Question: How do you ensure your Product Owner maintains proper preparation and ownership of business decisions rather than shifting these responsibilities to the development team? [The Scrum Master Toolbox Podcast Recommends]

Episode 75 of the Space Industry podcast by satsearch is a conversation with Sergio Sanchez, a software engineer and the Product Owner of the Flight Dynamics System at satsearch Trusted Supplier Terma.Terma is a Denmark based provider of aerospace and defense related products and their space portfolio features a variety of essential electronics and software tools for space missions. In the podcast we discuss various aspects of flight dynamics systems:The importance of flight dynamics in develop satellite constellationsHow they streamline operations, orbit determination, and reduce workloadsExamples of formation flying in space missionsMission applications and future scenarios that such solutions enableYou can find out more about Terma here on their satsearch supplier hub.And if you would like to learn more about the space industry and our work at satsearch building the global space supply chain, please take a look at our blog.[Music from Uppbeat (free for Creators!): https://uppbeat.io/t/all-good-folks/when-we-get-there License code: Y4KZEAESHXDHNYRA]

Today's guest is Trinh Nguyen, Product Owner of ServiceNow at Okta. Founded in 2009, Okta is the leading independent identity management partner. Driven by a vision to empower everyone to safely use any technology, Okta champions neutrality - offering organizations, employees and end users the flexibility to work seamlessly across any device or platform. Today, two-thirds of the Fortune 100, over 40% of the Forbes Global 2000, and thousands of other organizations rely on Okta to protect their digital ecosystems.In the episode, Trinh talks about:0:00 Her journey from IT ops to ServiceNow platform lead5:07 Why late nights aren't ideal, but global teamwork matters6:17 How success isn't technical depth; it's data-driven, value-based storytelling7:30 From out-of-box start to growth & how AI will drive next-level impact10:03 Stakeholder buy-in comes from vision, scalability and ROI09:22 Success is a collaborative effort, as partnership and shared vision drive adoption13:39 Tech needs more women with diverse paths, big impact and no fear15:50 Mentorship through strong women from trusted guidance, observation and inspiration17:33 Advice to believe in yourself; challenges pass and growth follows19:10 Excited about agentic AI which is improving processes autonomously

Agile in Construction: Why Construction Teams Need Product Owner Thinking with Luca Cotta Ramusino 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 Customer Value Detective Luca discovered that applying the Product Owner role in construction requires thinking like a customer and understanding that "it's the customer that defines what value is." The great Product Owner in construction acts as a customer value detective, constantly asking "which task out of these is going to move the yardstick?" They ensure that work always serves a customer—if you can't identify your customer, you should stop and find one. This mindset transforms how construction teams approach their daily huddles and project planning, viewing everything through the lens of customer value rather than just task completion. The Bad Product Owner: The Waste Accumulator The bad Product Owner in construction fails to eliminate waste from processes, allowing non-value-adding activities to persist simply because "that's how we've always done it." They struggle to have candid conversations with customers and fail to tease out real requirements. Instead of transforming language into customer reality, they ask customers directly "what they want" without understanding that customers are better at identifying what they don't want than articulating what they need. This approach leads to projects that complete tasks without delivering real value. In this segment, refer to The Last Planner Method. Self-reflection Question: Can you clearly identify the customer for every piece of work your team performs, and how do you ensure that work truly moves the project toward completion? [The Scrum Master Toolbox Podcast Recommends]

Stuart Tipples: The Ghost Product Owner vs. The Storytelling Master 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 Storytelling Master Stuart describes an exceptional Product Owner who worked with an API team on what could have been a dry, unsexy product. This PO excelled by maintaining clear availability through established office hours, showing up consistently for the team, and avoiding micromanagement. The standout quality was their ability to tell compelling stories that created clarity and got the team onboard with the vision. Through storytelling, this PO helped the team communicate the value of their work, transforming a potentially mundane product into something meaningful and engaging for both the team and stakeholders. The Bad Product Owner: The Ghost with the Most Stuart encountered a problematic Product Owner working with a customer-portal team dealing with edge cases, legacy systems, and messy code. This PO earned the nickname "The Ghost with the Most" because they were never available when needed. They would miss sprint planning sessions, delay or skip backlog refinement entirely, and leave team members to fill the gap while juggling their own responsibilities. Stuart learned to address this directly by outlining how the PO's behavior affected the team and delivery, asking "Can I help you?" The PO initially reacted defensively but eventually admitted they weren't happy in the role. Self-reflection Question: How effectively does your Product Owner use storytelling to create clarity and help the team understand the value of their work? [Scrum Master Toolbox Podcast Recommends]

Laura Kendrick and Cort Sharp hijack the mic to share what it’s really like behind the scenes at Mountain Goat. From Zoom bloopers to unexpected team bonding, they unpack how a fully remote team built a thriving, human-centered workplace. Overview In this special takeover episode, Laura Kendrick and Cort Sharp pull back the curtain on what goes into running hundreds of Scrum and Product Owner classes virtually—and why Mountain Goat's remote team still feels so close-knit. With stories of early tech headaches, Slack banter, hilarious costume moments, and the quiet rituals that keep the team connected, they explore how remote work can actually foster strong relationships and top-tier collaboration. If you’ve ever wondered how to make a distributed team work (or just want a peek at some Zoom-era growing pains), this one’s for you. References and resources mentioned in the show: Laura Kendrick Cort Sharp #61: The Complex Factors in The Office Vs. Remote Debate with Scott Dunn #147: The Power of Quiet Influence with Casey Sinnema Run a Daily Scrum Your Team Will Love Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years. Laura Kendrick is the producer of the Agile Mentors Podcast and a seasoned Scrum Master who keeps virtual classes running smoothly. Outside the podcast, she helps clients apply Scrum techniques to their marketing and business strategy, bringing structure and momentum to big, creative ideas. Auto-generated Transcript: Laura Kendrick (00:00) Welcome in Agile Mentors. As you may have noticed, I am not Brian Milner. I am Laura Kendrick, and this is Cort Sharp. And if you have taken a class with us at Mountain Goat in the last five years, there is a good chance that you have met one or actually both of us. Cort Sharp (00:19) I think it's like 90 % chance, 95 % honestly. We've been in so many of these classes. Laura Kendrick (00:26) Definitely, and oftentimes together too with one of us TAing, one of us producing, sometimes one of us teaching court. Cort Sharp (00:33) once in a while, once in a while. Yeah. Laura Kendrick (00:37) So we thought we would come on over here and hijack the podcast to share a little bit about some of the insights that we have gained from doing about a billion, maybe a little exaggeration. Cort Sharp (00:49) Roughly. Roughly. We've done roughly a billion classes with Mountain Goat. Yes. Laura Kendrick (00:56) We have seen a lot in the certifying of Scrum Masters and product owners and advanced product owners and Scrum Masters and all of the evolution of the classes that we have done. We actually hold quite a bit of insight into what is happening in this world. And so we thought we would come in, steal the podcast, and share a little bit of what we have seen, learned, observed, and really just kind of Honestly, some of the laughs and fun that we've had along the way. Cort Sharp (01:25) Also, I think, I don't know, just your intro right there is talking about, hey, we've seen the evolution of these classes. That just got my brain going of like, remember the first class that we did? Way like 2020. I mean, I was in my parents' basement with really terrible internet. It was a struggle. Laura Kendrick (01:40) Yeah. Cort Sharp (01:49) But we were working on like Miro boards or mural. One of the two, forget which, which tool it was, but that was, yeah, that was before team home. And then we got to see the first version of team home. We helped do a little testing with it. And then we've seen it grow all the way into this awesome tool that we have nowadays. And I don't know, just, just to me, I think it's cool to see how we've been iterating and be part of that process of the iteration process, um, to develop these classes and these courses into. Laura Kendrick (01:52) Mm-hmm. Mural. Yep. Mm-hmm. Cort Sharp (02:20) the truly awesomeness that they are today. Personally, I'd rather take a virtual class than an in-person class with Mountain Goat at this point. Laura Kendrick (02:27) It's funny that you say that because I notice actually the iteration of the experience like outside of the tech piece because you know, that's where my brain goes. Here's the difference between court and I. I'm noticing the interactions. But I've noticed, mean how people are interacting a little bit differently in the online space, how even our team interacts, like all of those things has become so much more sophisticated and amazing and Cort Sharp (02:39) Yeah, just a bit. Laura Kendrick (02:54) I mean, honestly, we sometimes talk on our team between like the producing and TA team where like I've referred to it as a perfect game if we don't need anything from the outside team, which occasionally we need a lot of support from the outside team, but we've we've got this down at this point. And it is it's become those first classes. I remember them being super stressful, like, my gosh, the breakout rooms and all the things and just being like, I mean, you couldn't do. Cort Sharp (03:17) Yes. Laura Kendrick (03:21) It was almost like learning how to drive where you felt like if you turned the radio knob up, you might actually turn the whole car. And it was like, so much anxiety. Cort Sharp (03:31) I mean, but we just didn't know Zoom then. Zoom didn't even know itself then, right? What Zoom is, ⁓ for those of you who don't know, we host all of our virtual classes on Zoom. And learning that platform, like I'd used it once maybe for some just, yeah, here's Zoom exists in one of my college classes. That was about it. But yeah, totally. was like, man, what does this button do? Hopefully it doesn't end the meeting and kick everyone out. Laura Kendrick (03:34) Yeah. Yeah. Yeah. That's so true. Yeah, no kidding. But you know what's really interesting too, though, is that it's been over five years now for both of us being part of the Mountain Goat team. And we all work remotely. And other than you and Mike for a little while being right down the road from each other, none of us had any actual interpersonal interaction with each other outside of Zoom email and Slack and the occasional, know, fretted text message of like, are you late? Where are you? Cort Sharp (03:58) Absolutely, yeah, totally. Yeah. Laura Kendrick (04:26) But other than that it like we truly were of and still are a fully remote team and the crazy thing about it is we have at this point once gotten together as a full team in person and it was such an interesting experience being having been fully remote and then being in person and in particular the team that is live on the classes Cort Sharp (04:39) Yep. Yep. Laura Kendrick (04:51) It was a very different interaction because we have this time built into our classes where the team gets on the Zoom call 30 minutes earlier than the students do. And we get this time to just honestly have like water cooler chat and like friend chat or occasionally see Mike get on and you can't hear him, but you can see that he is quite angry at his very elaborate tech system that is not working correctly. Cort Sharp (05:14) you That does happen. Yes, it does. ⁓ Laura Kendrick (05:21) these moments, I feel like they really bonded us together. Because when we got together in person, it was old friends. wasn't even fast friends. It was old friends. And the banter even that goes on in Slack is fun and engaging and not rigid and confining. Cort Sharp (05:31) Yeah. Yes, absolutely. I agree with that. I mean, I'm just thinking back to like the first time because that was the first time I met you in person. aside from being like, wow, she's a lot shorter than I thought she would be. Laura Kendrick (05:47) Mm-hmm. shorter. By the way, court is like 6-4. Cort Sharp (05:55) Yeah, yeah. Not that you're short. But I've just always ever seen like, the profile like the profile picture. That's all that it's really ever been. So I'm like, yeah, you're like, what I would consider normal height, which you totally are. But in my mind, I was like, yeah, it's weird seeing, you know, your legs. That's funny. ⁓ Laura Kendrick (06:14) We digress. Cort Sharp (06:15) But aside from that, was like we've known each other for three, four, four years because we've had that time to get to know each other. We've had that time to talk about just life events, what's going on, where we live, what's happening, what the deal is going on with life. Because we've been very intentional about having that time with that. The 30 minutes before each class were originally very much so used to take care of any tech problems. As the years have gone by, we've for the most part figured out the tech problems. Sometimes, you know, we'll change something out. Laura Kendrick (06:48) Except, hold on, except last week in Lance's class, we were talking about his dog and suddenly it looked as though Lance in his entire room did a cartwheel because the camera just fell. This is not a small camera. Cort Sharp (07:02) It said, nope, I'm out. ⁓ man. Laura Kendrick (07:06) So we still occasionally have the tech problem. Cort Sharp (07:09) Yes we do, yes we do. That's why we still do the 30 vimits. Laura Kendrick (07:14) The crazy thing about that is that when we landed at this in-person meeting, there were members of the team that at that time, and I in particular had never had any interaction with. so like other than the odd email or Slack message, so it was like really knew their name, but didn't really work with them up until that moment. And it was really interesting because at one point, the way that the leadership team had mentioned of like, well, if you need somebody to step in and talk to Mike for you, if you're not comfortable. And I remember looking at court and being like, Mike's the one I'm most comfortable with in this room because of that 30 minutes. I feel like I know Mike. I feel like we have an actual interpersonal relationship where I have no problem speaking up and saying the things that I need to. And that has made like those little water cooler times, those little Cort Sharp (07:54) Yeah. Laura Kendrick (08:06) bantery questions, them asking about my kids or hobbies or whatever. And just knowing those things made a huge difference in our team functioning. The communication across time zones was so much better and easier and safer. Cort Sharp (08:24) Absolutely. We were talking a little bit before we were recording about just people who want pure in-person no matter what. I think at this point, I will always push back on that and say, you might not get that quote unquote collaboration time that's naturally built in, but if you're intentional about it and you provide the space and provide the resources, Laura Kendrick (08:32) Hmm. Cort Sharp (08:50) And also, kind of push people along, have some, I don't know, working agreements or something of, hey, our cameras are on whenever we're talking with each other, unless something like drastic is going on or something's happening, right? Which I think we're going to get into in a little bit, but it's massive. It's crazy. Laura Kendrick (09:03) That's huge. Yeah, I mean, it is. I think we can definitely speak to that in our own experience because we've had, of course, there are moments where people don't have cameras. There are moments where people have bad connections and we'll encourage them in class, like turn off your camera, save your bandwidth. But there are also moments where we are doing private classes for companies. In particular, we've done some with companies that work with like Department of Defense. So there's like real security. issues there and so they don't turn their cameras on. Their cameras are totally disabled on their computers. And it is, I have to say those classes are some of the most like energy draining classes I'm ever present in because I'll be there with the trainer and I feel like I have to give all this emotional feedback because when you are talking to a black screen, that's, it's really hard to just. Cort Sharp (09:47) Hmm. Laura Kendrick (09:58) survive that because you're not getting any feedback from anyone. So you don't know what's happening and you're constantly questioning and the kind of banter in your own mind is like, God, is it landing? Is it not? And you're just not getting any of that physical feedback. So I feel like when I'm on a class with a trainer like that, I feel like I have to be like, that's funny. I'm like, yeah, good point. Cort Sharp (10:19) Yeah, you're kidding. Laura Kendrick (10:21) I'm tired Cort Sharp (10:22) You No, I get that. And I've had some pretty similar experiences too. I might not be as in tune with the emotional side as stated earlier. So I might not help the trainers out nearly as much as I probably should. But I do think cameras on just can make all the difference. And again, situations where it's just not possible. Absolutely understand that. One of our trainers, Lance, he Laura Kendrick (10:39) Mm-hmm. Cort Sharp (10:47) He always likes to throw out the phrase, look, let's approach everything with grace, patience, and mercy. So I like, which I really appreciate, and I like that he throws that out there. But I think that's a good thing to keep in mind of like, know, even though you have the company policy, you have the working agreement, whatever it is that says, look, camera's on all the time, sometimes it's just not possible. Sometimes it just doesn't happen. I recently had to figure out internet in the middle of nowhere, because that's where I live now. Laura Kendrick (10:52) Mm. No. Cort Sharp (11:15) And I was worried for a while that I wouldn't be able to put my camera on. But, you know, if if they came down to that, I know that it would be, hey, you know, it's a it's a unique situation. It's something different. And we're going to do we're going to work the best that we can with it and try to figure out maybe you can turn your camera on for any time you're talking or just any time you have something to say or, you know, if you're agreeing with something, you could briefly turn your camera on to show like, yeah, I'm nodding. I'm agreeing. I'm doing whatever. Right. But Laura Kendrick (11:45) Honestly, I think recently I had a very busy day and we communicate in back channels, of course through email, but also we use Slack as a team. And so I sent a direct message to court about something and I just like, I sent it in a voice? No. And court's response was, didn't know you could do that in Slack. But in those moments, I think there are other ways of doing it too, where you can bring the humanity out, where it's not just words. Cort Sharp (12:01) Yeah. Laura Kendrick (12:09) So often I'm actually thinking about there was one time that you and I were talking about something and I misread it as like, I like kicked something, like some hornet's nest in there. Like you were upset with me, but you were like, no, that was not my intention. And it's an amazing thing that that's only happened once in five years. There was that subtle nuanced miscommunication of I thought I had offended in some way and I hadn't. Cort Sharp (12:18) So. Yeah. Laura Kendrick (12:34) Just keeping that in mind though, in written word, tone is interpreted because probably what happened is I like offended my kid or my partner and was bringing that into the conversation with court. And it had nothing to do with what was actually happening, but adding in those personal things of your face, your voice, those things really do help move that human connection, which enables the teamwork that we've seen at Mountain Go. Cort Sharp (12:42) Yep. Yep. Mm-hmm. Laura Kendrick (13:00) I mean, it's amazing the way this team functions and it is not perfect. There are definitely communications missteps. There are definitely like, oops, forgot to leave that piece out of the information packet. It happens. It happens to everybody, but we're able to recover really quickly or even it's a safe enough space to be able to speak up and say, I think I got left out on this. And it's responded to in a really gracious and amazing way. Cort Sharp (13:26) It absolutely is. I mean, Mountain Goat's been remote for longer than the COVID stuff, the pandemic stuff happened. Laura Kendrick (13:33) Yeah. Well, Lisa's been with them for what, 10 years? I think it was nearly 10 years when we started, maybe 15. And Hunter's around the same. So yeah, they've been spread for a long time. Cort Sharp (13:42) Something like that, Uh-huh. ⁓ I know that they had an office space and that office space changed just in case people wanted to like come in, come to the office. I think at one point, one of them was in Colorado, which is kind of funny because several people live on the West coast. And then it's like, okay, yeah, come on, come on, swing by the... Colorado office on just a random Tuesday. Yeah, fly in, have fun. I don't know. Yeah, why not? I don't know what the deal was or what it was like, but they've been fully remote. And I think with the kind of runway that they've had leading up until the time where everyone had to be fully remote has really benefited Mountain Go in a lot of ways, because a lot of those early, like, how do we work remote? How do we do this? Laura Kendrick (14:09) I'd do that. Yeah, let's do it. Cort Sharp (14:31) kind of was ironed out, but back to your, your point to just like, it's, it's incredible how much support there is. It's incredible how much, how well communication again, it's not perfect, but how well we're able to communicate with each other and how well we're able to just say, yeah, let's, let's hop on a call real quick or here. I think most of us have like personal phone numbers. We, we use that as a very much so last resort type deal. Laura Kendrick (14:57) Yeah. Cort Sharp (14:59) But even then, it's nice to just have those open lines of communication and know that those are always available, but also know that people are kind of in our corner all the time too. And I think you have a pretty good story about this one. Something happened in a class a few years ago. Laura Kendrick (15:09) Mm-hmm. Yeah. Yeah. It was early on we had, it was a non-Mike class. So it was one of the other instructors and there was a student who was just challenging. And in the end, it didn't go well in the moment, to put it, just to kind of like not go into grave detail about it. But Mike wasn't there, right? And so The thing that was interesting though is the first piece of communication that came from Mike, which was before that class even broke, right? Because it was one of those things of like, we have to share. As a team, we can't hide it. We have to share that something happened in class that was less than ideal. And so we did. And the immediate response from Mike was in support of the team. And later on, he did go and review the tape of the, because the classes are recorded, not for this purpose. They're recorded actually so that the students get a recording of the class afterwards and can return to what, you know, all the things that they learned because it's a lot to take in in two days. But in this one instance, it was beneficial in this way because Mike could actually see rather than taking people's words, what happened. And I think the important thing is not even what happened after, but what happened in the moment. that he instantaneously was like, I've got you. Like no matter how this goes, we're a team and I'm gonna support you as well. And that was actually, that was pretty early on for me. And it was in a moment where I didn't know Mike that well yet. And it was actually this very solidifying moment for me that was like, I'm in the right place. Like I am part of this team, not just a minion or an employee. Like they care about all of us. Cort Sharp (16:48) Mm-hmm. Laura Kendrick (16:56) and we're in this together, even if it turns out that we're in some form of trouble, it's still going to be thoughtfully managed and handled rather than just the kind of lashing out that can happen in so many environments. Cort Sharp (17:12) Right. And, and that experience, cause I think we were all included on that email. Like I, I wasn't in the class when it happened, but I do remember getting that email and it just was a clear communication from kind of head honcho Mike, right? A top dog saying, yeah, no, we, we got your back. on, we're on the same team. We're all working towards the same goal. And when I, when I read the email, I was like, wow, that was an eventful class. but. Laura Kendrick (17:26) Mm-hmm. us. Cort Sharp (17:38) My second thought, my second thought was, huh, this very similar to what you were saying of like, wow, this is a great place to be. This is a great company to work for. These are great people to be working with and alongside. ⁓ but also like, I know so many people whose managers, whose higher ups would say, Nope, you're in the wrong. You should have done better. Your toast, blah, blah, blah, blah. Like putting all the blame on you. Absolutely. Yeah. Yeah. Laura Kendrick (17:52) Mm-hmm. Yeah. The knee jerk. Yeah. Yeah. Cort Sharp (18:07) And it just, makes me think all the time of like one really blessed, like very fortunate to be here, very fortunate to work with mountain goat. but also people don't quit jobs. They quit managers. They quit leadership more often than not. And, not that I'm talking about quitting mountain goat, but, neither, neither of us are throwing that out there right now, but just like, Laura Kendrick (18:20) Mmm. Yeah. No, but interestingly in five years, I've not seen anybody quit. I mean, we've had people kind of go down separate paths, but nobody has been throwing their hands up and been like, I'm done. I can't be in this. There have been people who have taken other opportunities that they needed to take for their own businesses. But yeah, nobody's quit. In five years, no one has quit, which speaks volumes to the culture that is created in an environment where Cort Sharp (18:37) Mm-hmm. Laura Kendrick (18:57) And I also want to be clear that that response from Mike also, it wasn't disparaging to the other party either. It was simply a, like, it just let us know that I see you and this, you were in a hard moment in the moment and you had to react like a human being and you as a team, I've got your back and this is, you know, great. And to be fair to that was like in the heat of COVID. Cort Sharp (19:24) Yes, yeah It was yeah Laura Kendrick (19:27) good times. But there's also been a lot of fun that's happened in class too, which is, I think that makes a big difference. Like where we are, I don't want to say allowed because I don't think that's right, but like part of the culture is to have fun. Like Mike is a pretty funny guy. Brian's a pretty funny guy. Like honestly, the whole team is quite humorous and it's, we're allowed to like make these really fun things and Cort Sharp (19:48) Yes. Laura Kendrick (19:52) in response to like when we see them in class, like, we foster those two and it becomes this really fun working environment, not only for us, for our students. You brought up one that I had totally forgotten about with the costume. That was good. Cort Sharp (20:06) ⁓ yeah, I, I, yeah, I'll, I'll get into the costume thing, but I think the word you're looking for instead of allowed is enabled. Like we're, we're enabled to have fun. We're encouraged. Absolutely. Yeah. A hundred percent. If you ever hung out with Mike or, or taking a class with him, you've probably heard some funny stories. Laura Kendrick (20:13) Yeah, Encouraged, in fact. And my gosh, the one class too where Mike was asked how long they'd have access to like the videos and stuff. my gosh, Mike ended the class and it was a super engaged Chipper class. Everyone was laughing and Mike brought it down. Cause he did his usual thing where he talked about, what does he say? You have access as long as the internet exists and I'm alive. And then he went into great detail. great detailed speculation about what will happen once he's not alive. It went on for like five minutes. Cort Sharp (20:58) Yeah, where where he's like, yeah, you know, my kids will probably be like, what's this? What's this old website that dad's still hosting? Guess we'll we'll close that up 10 years down the line or whatever. Laura Kendrick (21:09) Dumbfounded. It was so good. But anyhow. Cort Sharp (21:13) man. But there was, I don't even remember why this happened in the class. don't think it was around like Halloween time or something. think the person, actually, I think the person does this to go to like local children's hospitals or local hospitals and just visit. But I get on and I'm normally the PM producer. So I normally hop on in the afternoon. And I took over from Laura and Laura Kendrick (21:22) No, it wasn't. think so. Cort Sharp (21:39) Laura was like, yeah, you know, pretty normal class. This happens, whatever. We're good. And I hop on and people start turning their cameras on. And then all of a sudden there's this dude in a Captain America costume. Like what? He's got the mask. He's got the, the, the uniform. He's got the shield and everything. And I was like, what is happening? What is going on? Come to find out he was telling his story. Laura Kendrick (21:50) Like full on math. Cort Sharp (22:04) Yeah, I do this. This is cool. And Mike was like, that'd be awesome to see. He went out, put it on and took the rest of the classes Captain America. So we have certified Captain America. Laura Kendrick (22:12) Awesome. We've had, there was the guy who was put on like a crazy hat for the first session and then came back for session two with a different crazy hat. And then other people started wearing crazy hats. And by the end of it, like by the final session, almost the entire class was sitting there with some like their kids stuff on their heads. it was. Cort Sharp (22:34) You Laura Kendrick (22:36) But was this one, like it stands out of the billion classes we've done. It stands out in our minds as these really fun moments. I remember the class where it was a private class, so it was for a company or team. And there were, it took me until the very end to, it was early on, so it took me until the very end to get up the gumption. There were five mics in the class. And finally I was like, I'm just gonna put them all in the same room and see if anybody notices. Cort Sharp (22:36) People just... Yes. Didn't they notice like right away, they all came back and they're like, team Mike is back in action or something, right? Laura Kendrick (23:04) I don't think they said anything, but they did. The instructor went into the room and like, yeah, they noticed. Good. My passive aggressive humor worked. Cort Sharp (23:10) Hehehehehe It's fun. It's all good. But it's also like going back to us being able to do this before I figured out kind of my background situation, I would always put up virtual backgrounds and I would just change your background every time and see if people noticed. And it wasn't, it was a lot of Disney. Yes. Laura Kendrick (23:23) Mm-hmm. Disney. That's the thing though. That also, that kind of stuff built a little bit of a relationship as well. like it was, court was always going to have something for Disney. I had one that I would, when I finally found the one I liked, I kept that one for a long time. And Mike would occasionally, when I wasn't in a class, he would send me a screenshot of somebody via email and be like, somebody's in your house with you. Cause they would have the same background. Cort Sharp (23:52) Yeah! Laura Kendrick (23:56) those little tiny things make the relationships and make the team function and make us giggle. So I'd be like out with my kids and see an email and be like, oh no, Mike, what does he need? And then click in and be like, you know, actually more often than not, it would probably be like, am I missing class? See, I'd be like, oh, that's funny. But you know, it builds that relationship. And I think it's why this remote working has worked so well for us. And I'm totally with you where I, when people are Cort Sharp (24:13) You Yeah. Laura Kendrick (24:26) railing against it because of my experience. like, you're crazy. This is great. Cort Sharp (24:31) Exactly. I'm like, how can you not want to just chill out, hang out in your home, chat with some people, get some work done, and like, you're good. Who despises that? Who doesn't like that? don't know. It's, Exactly, yeah. But I do think it does, it comes down to being intentional with it. We were talking about that 30 minutes before that used to be primarily tech troubleshooting. Laura Kendrick (24:47) I know, you get to do things on your own time too. Cort Sharp (25:01) but has since kind of evolved into, okay, so everything, like, I don't know about you, but the vast majority of time, unless a camera's fallen, the vast majority of time, it's, all right, does everything look good? Yeah? Cool. Sure does. Whoever I'm working with, awesome. So, what'd you do this weekend? how was this? ⁓ sorry, sorry that the Avs lost to the Dallas Stars. Yeah, I'm sorry too. Stuff like that, right? Where it's just, Laura Kendrick (25:19) Yeah. It's water cooler talk. Cort Sharp (25:29) It's fun, but we're very intentional with having that time to do that. And I think if you're not intentional in setting up that time, whether if you're working remote hybrid, you're not going to get it. And it's not just going to naturally happen because it is so much more difficult to produce. it's impossible for it to just kind of naturally pop up without taking away from some other intentional time. so I think in, in this this world that we're living in where there is the option to work remotely and there is this really big push to go back in person. I'm saying stick with remote, take your 15, 15 minute daily standup, and turn it into, you know, say, Hey, I'll be on 10, 15 minutes early. If anyone wants to come hang out, come chat. And make it worth it. Make it a valuable time because that is the time to connect and that is the time to say, yeah, cool. How are the kids? How was your weekend? Did you grill up some good hot dogs during this last weekend? What'd you do? Like, what was going on? ⁓ Build up that stuff. Laura Kendrick (26:23) Yeah. We also have Slack channels too, that are like that. Like there's a Slack channel for our team that's just movies, books and TV shows. That people, it'll get active at certain times and it'll be totally dead for a while and nobody's cultivating it. It's simply that somebody will pop in like, I just watched this and it's great. And they've set up also like the automatic bots, cause Mike's a big fan of James Bond. So like if somebody mentions James Bond, the Slack bot will say something quippy and it- Cort Sharp (26:39) Yeah. ⁓ Laura Kendrick (26:58) But it adds that little, like, little bit of humor, little bit of humanness to even though, like, the people that we have time to interact with like that is the team that's in class. So I don't, I mean, it wasn't until we were in person that I met our CTO. He was kind of an enigma, you know? Cort Sharp (27:10) Yeah. Mm-hmm. He was just in the background. Things just magically showed up digitally. Laura Kendrick (27:23) It was in my email and my Slack sometimes, but it creates that thing of like, now I know things about Hunter. Yes, of course it was because we were in person. I heard lots of stories and all that fun stuff. But also I know about like some of his like TV watching stuff. I know occasionally like what his wife likes to watch because sometimes he'll like pepper in something that, she dragged me into this and not my cup of tea. But it's those little bitty things that you start to learn about the people. Cort Sharp (27:39) Mm-hmm. Laura Kendrick (27:50) that makes them human and gives that space. And I also, think it's important to have it be a little bit of white space. so often we talk about cultivating the conversation and like, can you have icebreakers and get people engaged? And yes, those things are so important, but when it's with a team, you need to do those things, but you also need to create the empty space where maybe you have that daily standup or that... weekly meeting or monthly meeting, whatever that is for your team. And maybe at the end of it, it's just leaving the call going and allowing people to just talk. I mean, we did that as a producer team that we would have a meeting as producers that would be very structured and then kind of the official meeting would end. And there would be times where as a team we'd be on that Zoom. I'm like, thank goodness nobody needs this channel. Cause like we'd be in there for like two and a half hours. Cort Sharp (28:26) Yeah. Yeah. Laura Kendrick (28:42) just talking. And of course, it wasn't, you know, it wasn't billing time. It wasn't, you know, it was just us being friends and hearing each other and sometimes ranting and complaining and doing the things of like, this part was hard and like, yeah, well, people need the space to do that and feel seen and heard. And the only place they're going to get that is in the white space. Cort Sharp (29:01) Yep. Exactly. Yep. And where my head went when you were talking about the white space, I love where you just went to because that's absolutely very true. But where my mind went was the newest kind of Slack channel that that's been set up, which is the artificial intelligence. Yeah. Where we just we just it's cool because I'm interested in AI. I think everyone's interested in AI right now. Things are things are going in all sorts of wild directions with it. There's there's all sorts of possibilities that we can do with it. Laura Kendrick (29:17) ⁓ Yeah, that one's Yeah. Cort Sharp (29:32) And Hunter just threw out, who wants in? If you want in, cool, I'll get you in. If not, and you're not interested in AI, let me know when you are, because it'll be at some point, I was going to say. It's just another full group one. Yeah, we just. Laura Kendrick (29:39) Yeah. Pretty sure the whole team's in there. But it is fun. Like Hunter and Mike do deep dives and Brian too. And I'm like, wow, I just get to swim in that pool. It's really Cort Sharp (29:50) Yes. Yeah, yeah. You just kind of get a glean from what's posted in there and say, oh yeah, I am really interested in the automation side of AI. I want to do, I think I threw in there one time, like this whole GitHub repository that has just from zero to hero AI, here's a two week crash course. And I've been working my way through that. It's taken a lot longer than two weeks for me. I've been working my way through that. And it's opened my eyes to say, okay, now this awesome thing, think Mike just threw in there something about someone using it at Disney, I think it was, and how they were using it at Disney to propose, here's a cool way that we can use AI to help our proposals go faster or help our marketing campaigns go faster or whatever it is. And just learning and seeing and... Laura Kendrick (30:38) Yeah. Cort Sharp (30:44) growing together as a team as well and having that space of, yeah, you know, here's what here, here are these articles that I'm reading. Here's the ones that stuck out to me. And to have that space, I think also is, is really interesting to me too, not just because I like learning, but it's also like, I feel like, okay, I can talk with Mike about AI. I can talk with Hunter about AI. I can talk with whoever about it. And we're all relatively on the same page because we're all relatively getting the same information. Laura Kendrick (31:14) Yeah, yeah. I feel like having the Slack channel has been really helpful and all the white space and even honestly the in-person event, there was white space built into that too. There was definitely a lot of structured meetings because of course when you are bringing everyone in from all over the country and actually the world, have a team member who is in the UK too. Cort Sharp (31:26) yeah. Laura Kendrick (31:37) flying a great distance and being in a space together, it's got to be structured. You have to make that worth the time and effort and investment. But also there were dinners, there were shows that happened, there was fun built into it, and there were options of not just like, I'm forcing you to go to this, but like, here's a choice. Would you like to do this or that? And those things have made a huge difference in breeding the like belongingness. Cort Sharp (31:55) Mm-hmm. Laura Kendrick (32:05) and the feeling like we are actually a team. And even though there are definitely times where the frustrations arise, of course, I mean, who doesn't have frustrations, but it's a space where they can be vocalized, they can be talked through, and it's all due to that togetherness that we have, that connectedness that has been built through, honestly, Cort Sharp (32:05) Yeah. Mm-hmm. Laura Kendrick (32:30) just being in these like casual fun spaces is where that comes from in my opinion. Cort Sharp (32:36) Yeah, I agree with that. Just having the space to talk about whatever. But I think it's all rooted in communication, right? So in various methods of communicating and various ways of communicating too, where it's not just exclusively Slack, email, written text, we have that space there. But we do still run into some communication problems, right? There's... Laura Kendrick (32:41) Yeah. For sure, for sure. Cort Sharp (32:58) there's all sorts of communication problems that we're gonna run into because especially we are text-based heavy, but we're not exclusively text-based. But I think you were talking about a story where Mike was late one time or Mike's late story about communication and what was going on with that. Laura Kendrick (33:12) he tells it in class. He tells a story in class with that. It's one of his examples that he will pull into fairly frequently with an experience with a team where somebody was always late to the daily standup and they realized that it had to do with the fact that they had to drop their kid off at school. And so it was that simple communication shift of asking instead of assuming, asking which... They've put into practice too, like I recall early on hearing like, do you prefer to be communicated with? And like we've had these conversations that court and I have a tendency to be more slack people. But Brian has stated that for him, like when he's teaching slack is like his emergency line. And so like knowing that I'm not going to send him something through slack unless I desperately need him to see it when I can land it in his email versus Lisa and Laura are much more Cort Sharp (33:43) yeah. Mm-hmm. Mm-hmm. Laura Kendrick (34:04) they're going to be in the email. Like that's just where they live and they are less likely to be in Slack. So it's just knowing those things have also helped us build the right kind of streams of communication. I'm pretty sure Hunter is everywhere all at once. Like he's omnipresent. You can get him anywhere. I know it. I'm in New York and he's in California. I'm pretty sure if I whispered his name, he's hearing it right now. Cort Sharp (34:06) Right. my gosh. He's the enigma. He's the enigma everywhere. I was gonna say, I'm surprised he hasn't popped into this. We've said his name three times. It's, he just knows everything and he's always got everything coming through and no matter what you need, he's any message away. Slack, email, could be carry your pigeon. I don't know, something like that, right? Laura Kendrick (34:43) Yeah, his next Halloween costume needs to be Beetlejuice, so I'm sending that to him. my goodness. But I think at the end of the day, the practices that have been put into place that you may have felt in our classes too, have helped really grow this team into what it is. There's a lot of strength here. There's a lot of fun here, but there's a lot of hard work here too. And a lot of, there have been hard moments where we've all just kind of put our heads down together and moved through the hard moments as a team with a lot of support and a lot of. Cort Sharp (35:12) Mm-hmm. Laura Kendrick (35:15) Just trying to be in it and be like kind of move things where it needs to go. I don't know what the right word is as a team. It's redundant. Cort Sharp (35:22) I think it. Yeah. But I think that that does show in our classes a lot, right? You and I have both taken a class outside of the mountain goat sphere, ⁓ and I'm not I'm not dogging on anyone. I'm not trying to talk down on anyone. But I got out of that class. I was like, man, we are light years ahead of that. Laura Kendrick (35:30) Mm-hmm. Mm-hmm. Cort Sharp (35:49) that kind of interaction and that kind of experience. was the information that I got out of that class was awesome, superb. It was great. But just the amount of energy and effort and time that has been invested into these Mountain Goat courses, it's far and away just, it shows. And it shows how much of a level up it is to take a class with Mountain Goat. And I do think partly, you know, I'm boosting my own ego here. But I do think partly it is because we are surrounded with some awesome people and we have some awesome people working together and awesome support on every call, every class that you take with us, right? You don't have to, like the instructor can focus on just instructing. And we, more often than not, we are typically in charge of everything else. Make sure that any tech problems, any issues, anything that's going on, right? Yeah. Laura Kendrick (36:32) Yeah. Yeah. I remember the early days. Like you just brought up a memory that apparently I had stored in the trauma bank. I remember the early days though being, because I would often, because I'm on the East Coast, court is in mountain times. So, often I would be the early person just because it's easier for me. was mid morning for me. we would start class and it would be just, especially honestly when like people were figuring out Zoom and all this stuff, it was... stressful. Like they were just, it was just question, question, question, problem, problem, problem. And we would get to the first breakout and I would send everyone away and the instructor would be like, that was great. And I'm like, was, you know, just totally frazzled. But the point was, is no one else felt that. And it was, I was in my Slack and working with the team, working with Hunter, things fixed, working with Lisa, making sure the person was in the right place. Cort Sharp (37:20) Yeah, glad. Mm-hmm. Laura Kendrick (37:33) and doing all these things. And though that has died down because we've all gotten very good at our job and the systems in place are amazing at this point, it still is like, that's the whole point. We worked as a team so that the instructor could deliver an amazing class and be present with his students. And we could be here or her, because we do have hers too, I should say. They're students. And we were here taking care of the things that needed to be taken care of, which was, yeah. Cort Sharp (37:54) Yes. Laura Kendrick (38:00) Though I had forgotten about that. Thanks for that. Cort Sharp (38:02) Yeah, sure. Yeah, it's gotten easy, right? ⁓ Laura Kendrick (38:04) Yeah, it does. But that's at the end of the day, that's how a good team is. I think that we can kind of end it with this thing of Mike has created this environment and it definitely comes from him. Like it's is rooted in the founder for us because we're a small team, small but mighty. But he it's rooted in his like engine of creativity, efficiency, and just love of innovation. And that has kind of Cort Sharp (38:18) Mm-hmm. Laura Kendrick (38:34) folding that in with seeing all the people as humans, and with flaws and different talents and all those things and human interaction is messy and folding all of that in has actually been what has bred these amazing class experiences for our students and also this rewarding and fantastic team experience for the people behind the scenes as well. And I think the lesson Cort Sharp (38:39) Yes. Yep. Laura Kendrick (38:59) comes from that, that if we can fold those things in together and make space for humans to be humans and also have this amazing expectation of creativity and innovation, then it's all going to happen. Cort Sharp (39:06) Mm-hmm. Mm-hmm. Yeah, absolutely. I 100 % agree with that. I mean, it does come down to Mike and Mike is a fantastic leader. It's awesome. I also want to raise Mike, but. Laura Kendrick (39:28) Nice. Not passive aggressive at all. On that note. Cort Sharp (39:29) Yeah, you know. No. I'm just joking, right? We're able to have fun. We're able to joke around. But it does come down to leadership, right? And I think that's true on any team. And we have just we've been so fortunate to be able to experience it firsthand and go through this awesome transformation from being in person to fully remote, even in the class teaching stuff. And it's been really, really fun. really, really enjoyable. I, you know, you don't love every day. There are jobs, right? It's a job. But I'm not gonna lie. I'm not gonna lie. It has been fun. It has been enjoyable. But I don't look back on it and be like, wow, these last five years were just all terrible. No, it's we've had great leadership. We've had great interactions with with everyone. And I think Laura Kendrick (40:05) You should have just left it at really, really fun and enjoyable. Mic drop, goodbye. Cort Sharp (40:28) It's just come down to the people that we're working with and the people that we're engaging with consistently. And our leadership, Mike, has fostered an environment very, very well that is around fun, around communication, around enabling us to grow, to learn, to try new things, to move forward. And I really feel bad for companies who don't have that kind of leadership. that's, it's a tough spot to be in, but, I'm really, we're really blessed and really fortunate to, to be able to work here. And I hope this, this little peek behind the curtain, kind of encourages you to you, the listener, guess, whoever, whoever's out there to take a, take a little step back and say, okay, what, what am I doing as a leader within my sphere of influence to help my team be a little more human and embrace the humanity side of stuff? Not just pushing for more, we need more, more productivity, more AI, more everything, right? Yeah. Use AI, make it a tool, but just remember you're, building stuff for, for people. You're working with people all the time. And I think that's something that Mike has never forgotten and never will forget and never will let fall to the wayside that we're all people and we're all here working with each other. Laura Kendrick (41:43) Yeah. Couldn't agree more. Well, on that amazing note, thank you, Cort, for joining me in this hijacking of the podcast, the Agile Mentors podcast. And we're going to turn it back over to Brian, who's going to walk you right on out. Cort Sharp (41:54) Happy to.

Join Jim McDonald and Jeff Steadman on Identity at the Center as they sit down with Kristina Yasuda, Product Owner, and Dr. Torsten Lodderstedt, Project Lead for the German EUDI Wallet project. Recorded at EIC 2025, this episode delves into the ambitious European Union initiative to create a digital identity wallet for all its citizens.Kristina and Torsten discuss the vision behind the EUDI Wallet, the political will driving it, and the funding making it a reality. They explore the challenges and complexities of aligning multiple parties, standardizing technical specifications, and the goal of digitizing everything from government-issued IDs to driving licenses and ePrescriptions.Learn about the Federal Agency for Breakthrough Innovation (SPRIN-D), the importance of a transparent and collaborative development process, and how Germany aims to provide a secure, privacy-preserving, and interoperable digital wallet ecosystem. The discussion also touches on digital sovereignty, the role of platform providers like Google and Apple, the aggressive timelines, and the potential global impact of this initiative.Find out how the EUDI Wallet aims to put users in the driver's seat, ensure non-discriminatory access, and foster a flourishing digital economy in Europe.Chapters00:00 Introduction: Vision, Political Will, and Funding00:50 Blockchain vs Federated Identity: Bridging the Gap01:47 Welcome to the Identity of the Center Podcast03:18 Meet the Guests: German EUDI Wallet Project03:42 Christina's Journey into Identity06:05 Torsten's Background in Identity08:31 The EUDI Wallet Project: Scope and Goals12:19 Challenges and Opportunities in Digital Identity15:38 Production and Adoption of Digital Wallets20:53 Digital Sovereignty and Interoperability26:16 Government's Role in Digital Identity26:54 Certification and Recognition of Wallet Providers27:21 Cultural Differences in Government-Provided IDs27:53 Challenges and Timelines for Digital Wallet Implementation28:25 Legal Obligations and Compliance29:10 Public vs. Private Sector in Digital Identity30:13 Barriers to Widespread Adoption31:26 Complexities of Wallet-Based Systems33:23 Global Interoperability and Standards33:59 Technical Specifications and Convergence36:05 Multi-Step Process for Implementation38:26 Transition Period and Global Considerations42:49 Digital Driver's License and Real-World Applications46:17 Final Thoughts and Future Outlook46:23 Fun and Lighthearted EndingConnect with Kristina: https://www.linkedin.com/in/kristinayasudaConnect with Dr. Torsten: https://www.linkedin.com/in/dr-torsten-lodderstedt/Connect with us on LinkedIn:Jim McDonald: https://www.linkedin.com/in/jimmcdonaldpmp/Jeff Steadman: https://www.linkedin.com/in/jeffsteadman/Visit the show on the web at http://idacpodcast.comKeywords:EUDI Wallet, Digital Identity, European Union, Germany, Kristina Yasuda, Torsten Lodderstedt, Identity Management, Self-Sovereign Identity (SSI), Digital Sovereignty, Interoperability, Technical Standards, OpenID, Verified Credentials, Federal Agency for Breakthrough Innovation, Sprint, EIC 2025, Government Issued ID, Digital Transformation, Privacy, Security, User Control, Mobile Driver's License, IDAC, Identity at the Center, Jeff Steadman, Jim McDonald#EUDIWallet #DigitalIdentity #EuropeanUnion #Germany #KristinaYasuda #TorstenLodderstedt #IdentityManagement #SelfSovereignIdentity #SSI #DigitalSovereignty #Interoperability #OpenID #VerifiedCredentials #EIC2025 #GovernmentID #DigitalTransformation #Privacy #Security #UserControl #MobileDriverLicense #IDAC #IdentityAtTheCenter #JeffSteadman #JimMcDonald #DigitalWallet #EU

Joel Bancroft-Connors: The No-Scroll Bar Rule—Empowering PO's Through Constraints 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 Collaborative Innovator Joel describes an exceptional Product Owner scenario at a large insurance organization where complementary skills created magic. Working with two different people - a business expert who understood insurance but lacked development knowledge, and a designer with user experience expertise - Joel suggested the designer take on the Product Owner role while collaborating closely with the business person.  This collaboration between complementary skills produced outstanding results. The great Product Owner understood that their role wasn't to control every detail but to unleash developer creativity by providing problems and context rather than prescriptive solutions. Joel's approach of "give the developers a problem and a canvas" allowed the team to innovate while staying focused on customer needs. This Product Owner fostered innovation rather than preventing it, demonstrating how effective collaboration can transform product development. The Bad Product Owner: The Business Analyst That Couldn't Let Go Joel identifies a problematic anti-pattern: the Business Analyst who transitions to Product Owner but can't abandon their documentation-heavy approach. While Business Analysts can make excellent Product Owners with proper support, those who insist on documenting everything create communication bottlenecks and slow down delivery. This creates a "telephone game" effect between the BA/PO and developers. Joel encountered one such individual who would declare "the developers can't do that" without giving them the opportunity to explore solutions. Following his "no-scroll bar rule" for documentation, Joel emphasizes that Product Owners should provide just enough information to enable developer creativity, not overwhelming detail that stifles innovation. When the problematic BA was replaced with someone who understood customers and trusted developers, the team's innovation flourished. In this segment, we refer to the book Liftoff, by Larsen and Nies. Self-reflection Question: Are you enabling developer innovation by providing problems and context, or are you stifling creativity with excessive documentation and control? [Scrum Master Toolbox Podcast Recommends]

Гость выпуска — Кирилл Островский, продакт и основатель стартапов. После опыта в крупных компаниях и стартап-экосистеме США он переехал в Остин, где открыл бизнес по ремонту деревянных террас и запустил DeepDetekt — продукт для распознавания дипфейков.Мы обсудили, почему он ушел с топовой позиции в корпорации, как запускал и перезапускал стартап в США, с какими вызовами столкнулся и как искал рынок. Поговорили про попытку создать продукт для проведения discovery calls, про фандрайзинг, ошибки на этапе кастдева и что в итоге привело к закрытию бизнеса. Разобрали, каково это — строить несколько проектов одновременно, и какие выводы он сделал, уходя в локальный офлайн-бизнес и работу с AI.Кирилл Островский (Kirill Ostrovskii) - ex Project Director Mail.ru, Product Owner в Сбере и Альфа банке. LinkedIn: https://www.linkedin.com/in/kirillostrovskii/ Платформы для поиска и найма местных специалистов для выполнения различных бытовых и профессиональных услуг в США:Taskrabbit - https://www.taskrabbit.com/Thumbtack - https://www.thumbtack.com/Angi - https://www.angi.com***Записывайтесь на карьерную консультацию (резюме, LinkedIn, карьерная стратегия, поиск работы в США): https://annanaumova.comКоучинг (синдром самозванца, прокрастинация, неуверенность в себе, страхи, лень) https://annanaumova.notion.site/3f6ea5ce89694c93afb1156df3c903abОнлайн курс "Идеальное резюме и поиск работы в США":https://go.mbastrategy.com/resumecoursemainГайд "Идеальное американское резюме":https://go.mbastrategy.com/usresumeГайд "Как оформить профиль в LinkedIn, чтобы рекрутеры не смогли пройти мимо": https://go.mbastrategy.com/linkedinguideМой Telegram-канал: https://t.me/prodcastUSAМой Instagram: https://www.instagram.com/prodcast.us/Prodcast в соцсетях и на всех подкаст платформахhttps://linktr.ee/prodcastUS⏰ Timecodes ⏰00:00 Начало9:14 Сколько можно заработать на ремонте террас в Техасе?14:35 Сколько ты уже заработал?16:50 Как продавать американцу?28:08 Где и как ты ищешь клиентов?32:20 Как американцы реагируют на то, что ты русский?37:39 Какие требования к основателю бизнеса по ремонту, сотрудникам и организации?40:17 Как планируешь расширяться?47:39 Насколько сложно заниматься таким бизнесом?55:42 Расскажи про Deep Detect - что это? Как это работает? 1:01:12 Как выглядит команда?1:03:16 Как монетизируетесь? Какие планы у стартапа?1:10:06 Что можешь пожелать тем, кто планирует переезжать в США или уже в США и хочет открыть свой бизнес?

We're talking about either the terrifying or totally mundane new world of "vibe coding" - using AI to generate code without deep technical expertise. Joining Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel for this podcast, we're happy to welcome back to the podcast Lenar Mukhamadiev, CEO of iDelsoft (https://idelsoft.com)!Listen as we discuss how this trend is changing product development, software engineering careers, and business innovation. Stick around while we argue over resistance, how vibe coding enables faster market testing and many more points, including:Accelerating time-to-market for new ideasEvolving role of professional developersUnderstanding business problems is more valuable than codingEmergence of "product engineers," or notA future where everyone is a software creator#AIinTech #ProductDevelopment #FutureOfWork= = = = = = = = = = = =YouTubeSubscribe on YouTubeAppleSpotify= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Deniz Ari: Why Great Product Owners Listen—Communication Lessons from Product Ownership Extremes The Great Product Owner: The Power of Clear Communication Deniz describes a truly exemplary Product Owner who excelled through outstanding communication skills. This PO was an exceptional listener who maintained openness throughout all interactions. They ensured the team thoroughly understood requirements and priorities, always clearly articulating the rationale behind decisions. With a well-defined product vision and transparent prioritization process, this PO successfully bridged the gap between the development team and clients. Deniz emphasizes how this clear communication style naturally fostered team motivation, as everyone understood not just what they were building, but why it mattered. The Bad Product Owner: The Tyrant PO Deniz shares a challenging experience with a problematic Product Owner during what initially appeared to be a straightforward public sector migration project with adequate budget and timeline. Despite these favorable conditions, the situation deteriorated when the PO began pushing the team to work overtime, overstepping boundaries by questioning architectural decisions, and inappropriately assuming Scrum Master responsibilities. Described as a "tyrant" or "despot," this PO exhibited extremely poor communication skills and preferred dictating rather than collaborating. When Deniz attempted to address these issues, the situation became so toxic that it affected Deniz's health, ultimately leading to their decision to leave the project. The PO subsequently claimed no Scrum Master was needed. Deniz reflects that sometimes the best option is to recognize when a situation cannot be changed and to move on. Self-reflection Question: What boundaries would you establish with a dominant Product Owner, and at what point would you decide that the situation cannot be improved? [The Scrum Master Toolbox Podcast Recommends]

Deniz Ari: Why Your Process Changes Are Failing—The Stakeholder Alignment Problem 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. Deniz explores the challenges of implementing change in organizations, emphasizing that change is always a long and difficult process requiring patience and trust. Drawing on the Change Curve concept, Deniz shares a personal experience trying to improve project visibility by cleaning up backlogs in JIRA for 10 in-flight projects. Despite good intentions, Deniz found themselves as the only person using the tool, with team members and Product Owners using different systems that better suited their specific needs—POs wanting only high-level items while the development team needed to split items into smaller tasks. Through this experience, Deniz learned the crucial importance of having all stakeholders (Product Owners, development teams, and managers) aligned on using the same tool, and understanding the unique perspectives of each group before implementing process changes. In this episode, we refer to the Change Curve.  Self-reflection Question: What changes have you attempted to implement that failed because you didn't fully understand the different needs and perspectives of all stakeholders involved? [The Scrum Master Toolbox Podcast Recommends]

Do you want to hear a story about stifling growth and creativity through the lens of one developer's personal story?You're in luck! Join Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel as they watch and react to Theo's YouTube video: "Being a good engineer kinda sucks," April 28, 2025.It's a tale about the tension between excelling at your craft versus navigating organizational politics and dysfunction. That's right, today, we're talking about themes of career development, team dynamics, and leadership, so feel free to stick around for our thoughts on these and:The sustainability trap of overworking to meet unrealistic expectationsHow organizational politics can punish innovation and excellenceThe importance of product sense vs. documentation-driven developmentFinding and nurturing relationships with like-minded professionals#Leadership #ProductManagement #CareerDevelopment #TechCareersLINKS= = = = = = = = = = = =YouTubeAppleSpotifyREFERENCES= = = = = = = = = = = =Check Out Theo's Video here: https://www.youtube.com/watch?v=3VuM1GCadt4...and his YouTube Channel: https://www.youtube.com/@t3dotgg...and his website: https://t3.gg/MUSIC= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Deniz Ari: Security Team Breakdown—The Devastating Impact of Poor Product Ownership 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. Deniz shares the story of a security project with a team of eight experienced, senior engineers working on mission-critical systems. Despite initial motivation and clear architectural solutions, the team soon exhibited signs of negative behavior including complaints and criticism. The root cause traced back to frequent Product Owner changes—several within less than a year—and poor client management. Instead of shielding the team, the PO directly transferred stress from clients to the team, demanded overtime, and created unnecessary tension by bringing unfiltered conflicts to the team and requesting excessive details. Deniz emphasizes the importance of avoiding unnecessary tensions, being more political when necessary to protect the team, and being mindful of tone in written communications. Self-reflection Question: In what ways might you be failing to set proper boundaries in your role, and how could establishing clearer limits improve both your effectiveness and your team's performance? Featured Book of the Week: Boundaries by Henrik Cloud Deniz recommends "Boundaries" by Henrik Cloud, a book about human relationships and personal limitations. The book addresses crucial questions: Does your life feel out of control? Do you keep saying yes to everyone? Are you taking responsibility for others' feelings and problems? Have you forgotten your own limitations? Deniz explains how this book helped them learn to say "no" while still considering others' realities and feelings, and understanding why we often struggle with setting boundaries. Deniz highlights that being a Scrum Master involves much more than just processes and methods—it requires healthy personal boundaries. [Scrum Master Toolbox Podcast Recommends]

Simina Fodor: Why the 'Why' Matters—Product Owner Communication Lessons 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: Transparency and Customer Focus This exemplary Product Owner shaped Simina's entire view of product management and even inspired her to consider a future transition to that role. Despite not having a traditional product background (coming instead from support), this PO demonstrated exceptional openness to both giving and receiving feedback. They consistently explained the logic behind decisions, sharing the "why" that motivated their priorities. What truly set them apart was bringing customer perspectives and use cases directly to the team, helping developers understand the features through the lens of personas and user scenarios. The PO's transparency extended to their own professional journey, openly sharing how they grew into the role, which created an atmosphere of continuous learning and development. The Bad Product Owner: The Ghost Commander This experienced Product Owner approached the role with a command-and-control mindset carried over from previous Project Management experience, believing that backlog grooming was "beneath them." Essentially a ghost to the team, they avoided retrospectives while issuing constantly shifting priorities with little explanation or logic. The PO would issue commands and demand immediate responses without considering consequences, creating a toxic environment that threatened to destroy team morale. Simina recommends coaching such Product Owners on agile mindset principles and seeking leadership support when necessary to prevent team deterioration. Self-reflection Question: How can you effectively bridge the gap between command-and-control Product Owners and teams seeking more transparency and collaboration? [Scrum Master Toolbox Podcast Recommends]

Simina Fodor: The Courage to Question—Signs of a Healthy Agile Team 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. For Simina, Scrum Master success goes far beyond facilitation skills – it's about what happens when you're not in the room. True success means creating a self-sustaining team that maintains healthy practices even in your absence. Simina looks for indicators like: Do team members feel safe raising concerns regularly? Can they push back with the Product Owner and offer suggestions? Do they proactively ask for the "why" behind requests instead of blindly following directions? She emphasizes that successful teams raise dependencies early in the sprint, have the courage to plan work with other teams, and handle integrations independently. The ultimate test of Scrum Master effectiveness is whether the team continues to thrive even when you step away for a few days. Self-reflection Question: What specific behaviors would indicate that your team has reached a level of self-sustainability that would allow you to step back? Featured Retrospective Format for the Week: Start/Stop/Continue Simina advocates for the simplicity of the Start/Stop/Continue retrospective format. After experimenting with numerous complex approaches, she found that sometimes the most straightforward formats yield the best results. This classic structure cuts through noise and focuses teams on what truly matters: what new practices they should begin, what isn't working and should stop, and what's effective and should continue. Simina appreciates how this format's simplicity makes it accessible and easy to follow, allowing teams to concentrate on meaningful conversation rather than getting lost in complicated retrospective mechanics. [Scrum Master Toolbox Podcast Recommends]

BONUS: Nesrine Changuel shares how to create emotionally connected, delightful products! In this BONUS episode, we explore the concept of product delight with Nesrine Changuel. Nesrine shares insights from her extensive experience at companies like Skype, Spotify, Google Meet, and Chrome to help us understand how to create lovable tech experiences that drive user loyalty and differentiation. We explore the Delight Grid Framework she created, and discuss the importance of emotional connection in product design. We also touch on practical ways to incorporate delight into everyday product decisions. The Essence of Delight in Products "Creating emotional connection between users and products... What I'm usually vocal about is that it's not enough to solve functional needs if you want to create sustainable growth, and more particularly if you want to have your users love the product and create habits using your product." Nesrine explains that while most companies know how to solve functional problems, truly delightful products go beyond functionality to create emotional connections with users. This connection comes from anticipating user needs and surprising them on both functional and emotional levels. She emphasizes that delight emerges when users experience both joy and surprise simultaneously, which is key to exceeding expectations and building brand loyalty. Moving Beyond User Complaints "Most features that are built in products are coming from users' complaints... What I'm trying to be clear about is that if you want to build an emotional connection, it's about opening up a little bit more of your source of opportunities." Many teams focus primarily on addressing user complaints, which puts them in a reactive position. Nesrine encourages organizations to anticipate user needs by engaging with users in comfortable environments before problems arise. She suggests looking beyond direct feature requests and investigating how users feel while using the product, how they experience the journey, and what emotions arise during the experience. This proactive approach opens new opportunities for creating delightful experiences that users may not explicitly request. In this segment we refer to the KANO model for categorizing product features. Understanding Emotional Demotivators: The Zoom Fatigue Example "I tried to interview many users and realized that, of course, with the fact that we all moved into video conferencing, some demotivators started to surface like boredom, low interaction, overwhelm. There was a term that started to show up at the time - it's called zoom fatigue." Nesrine shares how her team at Google Meet tackled emotional demotivators by first deeply understanding them. By investigating "Zoom fatigue," they discovered through Stanford research that one major cause was the fatigue from constantly seeing yourself on screen. This insight led them to develop the "minimize self view" feature, allowing users to broadcast their video without seeing themselves. This example demonstrates how understanding emotional pain points can lead to features that create delight by addressing unspoken needs. The Delight Grid Framework "We want to delight the users, but because we don't know how, we end up only doing performers or hygiene features." Nesrine introduces her Delight Grid Framework, which helps product teams balance functional and emotional needs. The framework begins by identifying emotional motivators through empathetic user research. These motivators are then placed in a grid alongside functional needs to classify features as: Low Delight: Features that only solve functional needs Surface Delight: Features that only address emotional needs (like celebratory animations) Deep Delight: Features that solve both functional needs and emotional motivators She emphasizes that the most successful products prioritize deep delight features, which create lasting emotional connections while solving real problems. Detecting Opportunities Through User Journey Mapping "I use customer journey maps... One of the elements is feelings... If you do the exercise very well and put the feeling element into your journey map, you can draw a line showing peak moments and valley moments - these are pivotal moments for connecting with users at the emotional level." Nesrine advocates for using customer journey maps to identify emotional highs and lows throughout the user experience. By focusing on these "pivotal moments," teams can find opportunities to amplify positive emotions or transform negative ones into delightful experiences. She encourages teams to celebrate positive emotional peaks with users and find ways to turn valleys into more positive experiences. Real-World Example: Restaurant QR Code Payment "The waiter came with a note, and on the note, there is a QR code... What a relief that experience was! I've been very, very surprised, and they turned that moment of frustration and fear into something super fun." Nesrine shares a delightful dining experience where a restaurant transformed the typically frustrating moment of splitting the bill by providing a QR code that led to an app where diners could easily select what they ordered and pay individually. This example illustrates how identifying emotional pain points (bill-splitting anxiety) and addressing them can turn a negative experience into a memorable, delightful one that creates loyal customers. Creating a Culture of Delight Across Teams "It's very important to have the same language. If the marketing team believes in emotional connection, and the designer believes in emotional connection, and then suddenly engineers and PMs don't even know what you're talking about, that creates a gap." For delight to become central to product development, Nesrine emphasizes the importance of creating a shared language and understanding across all teams. This shared vision ensures everyone from designers to engineers is aligned on the goal of creating emotionally connected experiences, allowing for better collaboration and more cohesive product development. Recommended Reading Nesrine refers us to Emotional Design by Don Norman Designing for emotion, by Aaron Walter And Dan Olsen's The Lean Product Playbook About Nesrine Changuel Nesrine Changuel is a product leader, coach, and author with over a decade of experience at Skype, Spotify, Google Meet, and Chrome. She specializes in designing emotionally connected, delightful products. Her book, Delight, introduces a framework for creating lovable tech experiences that drive user loyalty and differentiation. You can link with Nesrine Changuel on LinkedIn and follow Nesrine's website.

Carmen Jurado: Beyond the Backlog—How Great Product Owners Embrace Team Collaboration The Great Product Owner: Standing with the Team  Carmen shares that the best Product Owners she's encountered are those who stand with their teams. Drawing from her own recent experience as a Product Owner, she emphasizes the importance of being there for your team, recognizing that they make you look good. Great Product Owners understand that achievements are team efforts, not individual accomplishments. Carmen also highlights that exemplary Product Owners have a deep understanding of the goals, values, and principles of Agile methodologies, allowing them to better support their teams and leverage agile practices effectively. In this segment we refer to the book Generative AI in a Nutshell. The Bad Product Owner: The Novice Who Does Everything Carmen describes a common anti-pattern she encountered: the inexperienced Product Owner who attempts to handle everything independently. This particular PO was preparing reviews and planning sessions alone, feeling that these events wouldn't happen otherwise. The team wasn't engaged, and the backlog had ballooned to over 300 items. Carmen helped this PO sort through the backlog to start with a clean slate and conducted a stakeholder mapping session to manage difficult stakeholders, particularly a CFO who was treating the PO as merely a scribe. They also worked to involve the team in Scrum events, reducing the burden on the PO. Carmen emphasizes the importance of keeping the team updated on process changes and the value of having a PO who can openly discuss their challenges. Self-reflection Question: As a Scrum Master, how can you help both experienced and novice Product Owners find the right balance between taking ownership and enabling team participation? [Scrum Master Toolbox Podcast Recommends]

Chris Sims: The Empathy Advantage, How Great POs Connect Teams with Users 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: Deep Market Knowledge Creates Team Empathy Brad exemplifies a truly effective Product Owner through his exceptional understanding of end users and customers in the investment management space. What sets Brad apart is not just his deep domain knowledge, but his established relationships with gatekeepers at customer organizations. These connections provide valuable insights that inform product decisions. Most importantly, Brad regularly spends time with the development team, helping them empathize with stakeholders and understand the real-world impact of their work. His user stories consistently focus on actual users and why the requested features matter, creating clear context for developers and fostering meaningful connections between technical work and business outcomes. The Bad Product Owner: The Disempowered Proxy Problem Chris identifies a common anti-pattern: the disempowered proxy Product Owner. This situation occurs when someone performs the day-to-day PO responsibilities for the team, but lacks true authority to make decisions. Instead, an unseen "real PO" holds ultimate control and can swoop in at any time to change priorities or requirements. This arrangement quickly erodes team trust as they realize the proxy must continually defer decisions, creating delays and uncertainty. Chris suggests either empowering the proxy with more decision-making authority while keeping stakeholders appropriately involved, or having the higher-level PO commit to spending sufficient time with the team to fulfill the true Product Owner role themselves. Self-reflection Question: How might you identify and address power imbalances in the Product Owner role within your organization? [Scrum Master Toolbox Podcast Recommends]

Chris Sims: Middle Management, The Forgotten Layer in Agile Transformations 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. Chris Sims recounts his experience with a rapidly growing startup that decided to adopt Scrum to address slowing delivery. When a VP championed the initiative, Chris provided training that generated excitement at the team level. However, they overlooked a critical component: the middle management layer. As teams embraced Scrum, they found themselves caught between multiple sources of direction—their direct managers, project managers, and newly established Product Owners with backlogs. This created confusion as middle managers, who weren't included in the transformation discussions, continued operating in their traditional ways. The result was teams appearing busy yet delivering slowly. Chris emphasizes the importance of considering how management roles evolve during agile transformations, deliberately redefining job descriptions, and helping managers find ways to bring value in the new structure rather than undermining it unintentionally. Self-reflection Question: In your organization's agile transformation, how are you addressing the needs and concerns of middle managers whose roles might be significantly impacted? [Scrum Master Toolbox Podcast Recommends]

Richard Brenner: Hypothesis-Driven Product Ownership, The Experimental Mindset 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 Experimenter Richard describes great Product Owners as "experimenters" who understand that everything they do is a hypothesis requiring validation. The best POs establish feedback loops early, actively engage with users and clients, and approach product development with a scientific mindset. Richard shares an experience working with a "coaching PO" who excelled at involving everyone in defining what needed to be done.  This PO was inspiring and helped the team participate in both building and decision-making processes. Richard emphasizes that the relationship between PO and team must be a true partnership—not hierarchical—for success to occur. Great POs facilitate team involvement rather than dictating direction, creating an environment where collaborative problem-solving thrives. In this segment, we refer to the Role Expectation Matrix Retrospective, and the Product Owner Sprint Checklist, a hands-on coaching tool for anyone interested in helping PO's prepare and lead successful Sprints with their teams. The Bad Product Owner: The Tech Visionary Disconnected from Users Richard recounts working with a high-level sponsor, a medical doctor interested in technology, who hired multiple development teams (up to four Scrum teams) to build a product. While technically knowledgeable, this PO had very concrete ideas about both the technology and solution based on assumptions about client needs.  The team developed impressive technology, including a domain-specific language (DSL), and felt they were performing well—until they delivered to actual clients. Only then did they discover users couldn't effectively use the software, requiring a complete rethinking of the UX concept. This experience taught Richard the critical distinction between the customer (the sponsor/PO) and the actual end users, demonstrating how even technically sophisticated Product Owners can miss essential user needs without proper validation. Self-reflection Question: How might you help Product Owners in your organization balance their vision with the practical realities of user needs and feedback? [Scrum Master Toolbox Podcast Recommends]

Richard Brenner: Contracting for Success,  Establishing Clear Agile Coaching Outcomes 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. Richard reflects on his evolution in defining success as a Scrum Master and Agile Coach. Initially, he believed that if his team was successful, he was successful—but soon realized this perspective was incomplete. Top management wanted tangible evidence of coaching impact, which became problematic without clearly defined metrics. Richard now advocates for establishing a coaching agreement at the beginning of any engagement, with both management and teams defining what success looks like for the coach. He emphasizes the importance of dual-sided accountability as a natural outcome of proper contracting, using metrics that matter to the organization such as flow metrics and outcome metrics to demonstrate coaching value. Self-reflection Question: How are you measuring your own success as a coach or Scrum Master, and have you created explicit agreements with both teams and management about what success looks like? Featured Retrospective Format for the Week: Solution Focused Retrospective Richard recommends the Solution Focused Retrospective from the book "Solution Focused Coaching for Agile Teams." While traditional retrospective formats from books like "Agile Retrospectives" typically open a topic and dig deeply into the problem space, the solution-focused approach suggests spending only a short time discussing problems before pivoting to designing the desired future state. This format focuses on identifying the next step and emphasizing what positive outcomes the team wants to achieve, rather than dwelling on what's wrong. Richard values this approach for its ability to maintain a positive, forward-thinking mindset within teams. [Scrum Master Toolbox Podcast Recommends]

Richard Brenner: When Individual Performance Metrics Block Agile Transformation 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. Richard shares an experience of implementing Agile methods in a large organization that initially showed promising signs with management "pull" for change. The transformation began well with cross-functional teams created through self-selection workshops. However, unexpected resistance emerged during the kick-off day, particularly from a line manager and his team. When investigating the source of this resistance, Richard discovered that the company's bonus structure was tied to individual performance metrics, fundamentally conflicting with Agile's team-oriented approach.  This insight led to developing a pilot for a team-focused performance management system. After three months, the team held a retrospective with all stakeholders, where management demonstrated remarkable leadership by empowering teams to redesign their structure when the initial setup wasn't working. This flexibility allowed even the most vocal critics to become part of the solution. Self-reflection Question: In what ways might your organization's reward structures be unintentionally blocking successful Agile adoption? [Scrum Master Toolbox Podcast Recommends]