Podcasts about scrum masters

  • 732PODCASTS
  • 4,874EPISODES
  • 24mAVG DURATION
  • 1DAILY NEW EPISODE
  • Sep 2, 2025LATEST

POPULARITY

20172018201920202021202220232024

Categories



Best podcasts about scrum masters

Show all podcasts related to scrum masters

Latest podcast episodes about scrum masters

The Daily Standup
The Birth of the Agile Delivery Manager = No More ScrumMasters

The Daily Standup

Play Episode Listen Later Sep 2, 2025 11:26


The Birth of the Agile Delivery Manager = No More ScrumMastersIn 2025, we formally changed the title of Scrum Master to Agile Delivery Manager (ADM) in our technology division. This renaming wasn't a rebrand for the sake of optics. It reflected a deeper evolution already happening, rooted in the expanding scope of delivery leadership, the adoption of Flow Metrics and Value Stream Management, and our real-world shift from strict Scrum toward a more customized Kanban-based model.It was this year that the name finally clicked. After assigning Value Stream Architect responsibilities to our Scrum Masters and giving them ownership of delivery metrics, team-level delivery health, and collaboration across roles within their Agile team, I realized the title “Scrum Master” no longer fit their role. I even considered Agile Value Stream Manager, but it felt too narrow and platform-specific.That's when Agile Delivery Manager stood out, not only as a better label but also as a more accurate reflection of the mindset and mission.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Coffee & Change
Episode 157: Vectors of Change with Nate Amidon

Coffee & Change

Play Episode Listen Later Sep 1, 2025 68:07


Today's guest knows what it means to lead when the stakes are high. Nate Amidon spent 15 years guiding people and programs across the U.S. Air Force, Microsoft, Boeing, and Alaska Airlines. He's an Air Force C-17 evaluator pilot with more than 3,200 flight hours—including 800 in combat—and over 1,500 hours as an instructor teaching young pilots how to fly, make decisions under pressure, and lead crews on global missions. When he transitioned from active duty, Nate brought that same discipline into technology—consulting as a Project Manager, Scrum Master, and Scaled Agile Framework coach on enterprise software programs. He went on to found Form100 Consulting, where he helps clients apply military-tested leadership practices to build strong, high-performing teams that endure. In our conversation, Nate and I talked about how hard that transition actually was. Even with a degree from the Air Force Academy and an MBA, landing his first role at Microsoft wasn't simple—and it showed him how untapped the veteran talent pool really is. That frustration was the spark for Form100, where he now connects veterans with organizations desperate for alignment, communication, and trust. We also dug into why veterans are uniquely equipped for tech: they're trained to see the whole mission, not just their own slice. They know how to drive clarity in chaos, how to align teams across silos, and how to solve problems with urgency but also with care. Nate reminded us that in technology, speed without alignment is just drift. Veterans bring the perspective to check the vector, build relationships, and keep the team moving in the right direction. Nate holds a Management degree from the U.S. Air Force Academy, an MBA from the University of Nebraska, and certifications spanning PMP, CSM, SPC, Lean Six Sigma, and DevOps. He also continues to serve as a reservist C-17 pilot with the 313th Airlift Squadron.

Scrum Master Toolbox Podcast
The SECI Model of Knowledge Management Applied to Team Retrospectives | Salum Abdul-Rahman

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 28, 2025 14:46


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

The MisFitNation
8 Deployments, 26 Years of Service & Building Stronger Veteran Families Derek Funk MisFitNation

The MisFitNation

Play Episode Listen Later Aug 28, 2025 56:09


This week on The MisFitNation Show, host Rich LaMonica sits down with Derek Funk—a 13-year U.S. Army Veteran and longtime contractor who served an additional 13 years supporting Identity Intelligence missions with NGIC. With 8 combat deployments to Iraq and Afghanistan under his belt, Derek brings a gritty, honest perspective on service, sacrifice, and what it really means to continue the mission after the uniform comes off. Today, Derek works as a Scrum Master for Booz Allen, supporting the USMC on PEO Digital, and sits on the Board of Directors for Living Free Together, an organization focused on helping military and Veteran families rebuild, reconnect, and thrive. In this episode, we'll dive into:

5amMesterScrum
Mixing Reviews - Retros into Planning #5amMesterScrum Show 1273

5amMesterScrum

Play Episode Listen Later Aug 28, 2025 10:05


Mixing pieces from Sprint Reviews and Retros into discussion at the Sprint Planning session.  Something all Scrum Masters or agile coaches should do.. Make them think a little bit more before blasting off from Sprint Planning. Our #5amMesterScrum show 1273 as a part of our 4R Thursday - Roles, Reviews, Retros and Requirements programing 

Sheffield Digital Podcast
How did you get here: Interview with Angel Takooree - Founder of Dot and Dash Consulting

Sheffield Digital Podcast

Play Episode Listen Later Aug 28, 2025 43:31


Angel shares her unconventional career path, transitioning from over 20 years in the food industry to the tech world and eventually founding her own consultancy. She discusses the inspiration behind her career change, the importance of continual learning, and her expertise in using playful methodologies like LEGO® SERIOUS PLAY® and AI Design Sprints™ to help organizations navigate change and develop strategies. Angel emphasises the value of resilience, curiosity, and a hands-on approach in her journey. She also touches on her experiences in sketching, the challenges and rewards of starting anew in a different industry, and her vision for the future of her consultancy. This episode is a must-listen for anyone considering a major career change.Angel has a background in Product Development, Project Management, User Experience, User Research, and Service Design, and favours analogue methods for digital problems, creating fun and engaging workshops for remarkable results. Before co-founding Dot & Dash Consulting, she led the development of innovative food products for major brands. With over 20 years as a consultant and a pivot to the digital sector, her vast experience in manufacturing, health, education, mobile gaming, betting, and design fuels her innovative ideas.Angel holds certifications as an AI Design Sprint™ Facilitator, along with being a LEGO® Serious Play® method and materials facilitator, Scrum Master, and Design Sprint Facilitator. Additionally, she plays leadership and director roles in volunteer organisations.Subscribe to the podcastIf you'd like to have new episodes of the show appear right in your podcast player, you can subscribe via our page on Apple Podcasts and follow the show on Spotify, or search for us in your podcast app of choice!Notes and LinksThis interview was recorded online by Sarah Lister on 28th May 2025.LinksDot & Dash Consulting - website Dot & Dash Consulting - Sheffield Digital Company Spotlight Angel Takooree on LinkedInDid we miss something you're looking for? Just get in touch and let us know. Join the conversationWe're really keen to get your feedback on the podcast. You can email info@sheffield.digitalThank you for the musicThanks to Alex Mclean – aka Yaxu – for the show's intro music, licensed under CC BY-SA 3.0.

Scrum Master Toolbox Podcast
From Lunch Conversations to Company-Wide Change—The Power of Creating Communities of Practice | Salum Abdul-Rahman

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 27, 2025 12:04


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

The Daily Standup
What If Scrum Masters Only Want To Act On A Team Level?

The Daily Standup

Play Episode Listen Later Aug 27, 2025 7:44


What If Scrum Masters Only Want To Act On A Team Level?I recently had an interesting conversation with a manager at a large organization. We discussed the evolving role of Scrum Masters, the growing questions about their value, and whether organizations are seeing actual returns on these investments.

Scrum Master Toolbox Podcast
From Isolation to Integration—Rebuilding Agile Team Connection For Remote Teams | Salum Abdul-Rahman

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 26, 2025 17:48


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

Military Transition Academy Podcast
Is PMP Certification Worth It? Testimonials, Ep 142

Military Transition Academy Podcast

Play Episode Listen Later Aug 26, 2025 26:52


Episode 142: Is PMP Certification Worth It? – TestimonialsFor many service members and veterans, one of the biggest questions is: Is earning the PMP® certification really worth it?In this special episode of the Vets2PM Military Transition Academy Podcast, you'll hear directly from three veterans who answered that question for themselves. Each testimonial shares how Vets2PM trained and prepared them to:✔️ Pass their certification exams✔️ Translate their military skills into project management language✔️ Launch meaningful and lucrative project management careersIf you've been wondering whether PMP® is the right move for your career, this episode will give you honest insight from those who've been in your boots.Find out more about the Vets2PM PMP Exam Prep Course and Career Preparation Program: Master Project Leadership Workshop | Vets2PM, Premier Authorized Training Partner in project management (PMP, CAPM, PMI-ACP, and Scrum Master) certification and credential preparation courses.

Dream Employer
SEZON II #EP10 - Kate Hobler

Dream Employer

Play Episode Listen Later Aug 26, 2025 47:04


Gościnią tego odcinka jest Kate Hobler założycielka OrgScapes, trenerka i konsultantka, autorka książki Kompetentny Scrum Master. Przewodnik po rozwoju Scrum Masterów i Agile Coachów dla HR, zarządzających oraz samych zainteresowanych”.W tym odcinku rozmawiamy o znaczeniu zwinności organizacyjnej, roli minimalistycznego przywództwa, wdrażaniu neuroróżnorodności oraz wyzwaniach pracy w zespołach rozproszonych i międzynarodowych. Jak podkreśla w naszej rozmowie Kate podstawą zwinności, skutecznego przywództwa jest uważność na drugiego człowieka. Kate dowodzi, że poznanie i zrozumienie indywidualnych cech, preferencji i kulturowych uwarunkowań pracowników jest kluczem do budowania efektywnych i wspierających środowisk pracy.

Scrum Master Toolbox Podcast
The Expert Who Couldn't Connect: An Agile Team Integration Challenge | Salum Abdul-Rahman

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 25, 2025 14:56


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

Pipoca Ágil
#726 PILULA ÁGIL - O seu Scrum Master está omisso? O que fazer?

Pipoca Ágil

Play Episode Listen Later Aug 23, 2025 33:58


O seu Scrum Master está omisso?O que fazer?

Scrum Master Toolbox Podcast
The Risk-Aware Scrum Master: Preventing Problems Before They Happen | Irene Castagnotto

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 21, 2025 17:32


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

Antiintuitiv - der Podcast für systemisches Denken in der Wirtschaft

Teamarbeit wird anspruchsvoller. Agile Frameworks und generell das Arbeiten in crossfunktionalen Teams mit viel Selbststeuerung braucht gute Konzepte, damit wirklich Hochleistungsteams entstehen. Michel Eggebrecht hat in seinem Job viele Stationen durchlaufen. Sowohl als Führungskraft als auch als Scrum Master, agile Coach, Release Train Engineer und mittlerweile Organisationsentwickler. In zwei Büchern hat er die Dos and Don'ts der agilen Teamarbeit beschrieben. Zusammen mit PRAXISFELD bietet er Organisationsberatung an. Wir sprechen über Manager, die von außen "hineinregieren", die Veränderung von Mindsets, die Anforderungen für die Zusammensetzung von Teams, Konflikte, Transformationen, Regeln, die Rolle von Führung, Entscheidungen, Macht und Organisationsdesign.

Agile Mentors Podcast
#154: The Underpowered PO with Barnaby Golden

Agile Mentors Podcast

Play Episode Listen Later Aug 20, 2025 30:26


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

Scrum Master Toolbox Podcast
When Proactive Help Backfires - A Gen Z Scrum Master's Learning Journey | Irene Castagnotto

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 18, 2025 15:15


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

Scrum Master Toolbox Podcast
When Technical Expertise Becomes Product Owner Micro-Managements | Somya Mehra

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 15, 2025 16:25


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

Scrum Master Toolbox Podcast
Why Collaboration Should Be Your Team's Primary Goal | Somya Mehra

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 14, 2025 13:26


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

Develpreneur: Become a Better Developer and Entrepreneur
Revisiting “Done” in Agile: Why a Clear Definition Matters More Than You Think

Develpreneur: Become a Better Developer and Entrepreneur

Play Episode Listen Later Aug 14, 2025 25:41


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

Scrum Master Toolbox Podcast
From Top-Down to Collaborative—Reimagining Organizational Restructuring | Somya Mehra

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 13, 2025 13:26


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]

Agile Mentors Podcast
#153: Getting Real Buy-In for Agile Transformation with Scott Dunn

Agile Mentors Podcast

Play Episode Listen Later Aug 13, 2025 34:17


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

Scrum Master Toolbox Podcast
How Upper Management Can Destroy a High-Performing Team in Minutes | Somya Mehra

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 12, 2025 16:13


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

Scrum Master Toolbox Podcast
Learning to Spot Team Performance Warning Signs Early As A Scrum Master | Somya Mehra

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 11, 2025 14:56


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

Scrum Master Toolbox Podcast
How Decision Journals Can Transform Product Owner Behavior | Florian Georgescu

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 8, 2025 17:27


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]

Scrum Master Toolbox Podcast
When Teams Embody Agility Without Having To Thinking About It | Florian Georgescu

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 7, 2025 13:15


Florian Georgescu: When Teams Embody Agility Without Having To Thinking About It 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. Florian defines success for Scrum Masters as achieving teams that embody agility naturally, without conscious effort. He identifies key behaviors that indicate true team maturity: team members openly discuss their needs and how to fulfill them, they embrace constructive conflict as productive and necessary, and developers can communicate with business stakeholders in accessible language rather than technical jargon. This level of success represents the ultimate goal for Scrum Masters – creating self-organizing teams that have internalized agile principles so deeply that they become second nature, enabling authentic collaboration and effective business communication. Featured Retrospective Format for the Week: Naikan Retrospective The Naikan Retrospective, based on a Japanese self-reflection practice, proved invaluable when Florian's team faced a catastrophic release failure during a Champions League game at a sports betting company. This format addresses three key questions: "What have I done successfully for my team?", "What did I get back from my team?", and "How did I support my team in these hard moments?" Despite initial concerns about team acceptance, this retrospective format provided structured relief during high-tension situations, allowed team members to express missing support needs, and created lasting positive impact. The human-centered approach helped the team process failure constructively and build stronger relationships through structured self-reflection. self-reflection Question: What behaviors in your team indicate they're truly embodying agility, and how might you recognize when they no longer need your guidance? [The Scrum Master Toolbox Podcast Recommends]

The Daily Standup
Dedicated vs. Rotating Scrum Masters

The Daily Standup

Play Episode Listen Later Aug 7, 2025 6:27


Dedicated vs. Rotating Scrum MastersI spent my first five years as a Scrum Master primarily dedicated to one team. As a result, I got to know team members deeply. Even 10+ years after I left, I'm still in close contact with some of them. Due to frequent changes in the team — people come and go — improving team dynamics was a continuous effort. However, after a while, our team understood Scrum, and I could shift my focus towards the broader organization and our customers.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Scrum Master Toolbox Podcast
From Resistance to Effective Change Leadership in Agile Adoption | Florian Georgescu

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 6, 2025 13:51


Florian Georgescu: From Resistance to Effective Change Leadership in Agile Adoption 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. Florian shares his transformation from resisting organizational standardization to becoming a champion of strategic alignment. Initially fearing that standardization would stifle innovation and turn agile practices into rigid frameworks, he discovered the bigger picture when he became scrum master chapter lead for 12 scrum masters across multiple locations and cultures. The breakthrough came from implementing a three-level standardization approach: level 1 for non-negotiables, level 2 for encouraged patterns, and level 3 for team-specific innovations. Using the 80/20 principle, they focused on the 20% of standards that would create 80% of alignment. The scrum master chapter became a learning hub where teams could share their level 3 innovations, creating a balance between consistency and creativity that enabled effective cross-tribe collaboration. Self-reflection Question: How might you balance the need for organizational alignment with preserving team autonomy and innovation in your current context? [The Scrum Master Toolbox Podcast Recommends]

Agile Mentors Podcast
#152: The Five Pillars of Real Agile Improvement with Mike Cohn

Agile Mentors Podcast

Play Episode Listen Later Aug 6, 2025 39:31


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.

Scrum Master Toolbox Podcast
When Knowledge Hoarding Destroys Team Dynamics | Florian Georgescu

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 5, 2025 14:36


Florian Georgescu: When Knowledge Hoarding Destroys Team Dynamics 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. Florian describes a payment system development team where an experienced tech lead unknowingly created a dangerous dependency. This senior developer, while well-intentioned, became the single point of knowledge and decision-making for the entire team. Other developers began copying his behavior, creating a culture where team members were afraid to ask questions for fear of appearing incompetent. When this key developer left, the team fell apart - planning sessions became confusing, technical discussions stalled, and two junior developers quit citing lack of learning opportunities. The story demonstrates how knowledge hoarding, even when unintentional, can destroy team resilience and create toxic dynamics that stifle growth and collaboration. In this segment, we refer to the Monday episode with Florian as context for the story he shares on this episode. Self-reflection Question: How might knowledge hoarding be happening in your team, and what steps could you take to encourage more distributed learning and decision-making? Featured Book of the Week: The Responsibility Process by Christopher Avery Florian The Responsibility Process by Christopher Avery particularly valuable for understanding the stages people go through when taking responsibility. The book's framework helped him process his own burnout experience and provides crucial insights for helping teams accept responsibility for their outcomes. Florian emphasizes how the responsibility process is essential for understanding what you can influence when you want to take ownership, making it a powerful tool for both personal growth and team development. In this segment, we refer to the Responsibility Process, by Christopher Avery, who was a previous guest on our Audiobook project: Tips From the Trenches, Scrum Master Edition.  [The Scrum Master Toolbox Podcast Recommends]

Scrum Master Toolbox Podcast
From Burnout to Balance: A Scrum Master's Reality Check | Florian Georgescu

Scrum Master Toolbox Podcast

Play Episode Listen Later Aug 4, 2025 15:48


Florian Georgescu: From Burnout to Balance: A Scrum Master's Reality Check 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. Florian shares his experience of trying to single-handedly transform an entire IT service company, leading to what he calls the "superman scrum master syndrome." His story highlights the dangers of trying to be everywhere for everyone and create perfect change from the beginning.  Working with a coach, Florian recognized the warning signs of burnout - exhaustion, frustration, and the unhealthy need to control everything. His journey teaches us that sustainable change takes time, and it's perfectly acceptable for things not to be perfect from the start. The key insight is learning to pace yourself and accept that meaningful transformation is a gradual process, not a solo mission. Self-reflection Question: When have you found yourself trying to be the "superman" in your role, and what signs helped you recognize it was unsustainable? [The Scrum Master Toolbox Podcast Recommends]

Scrum Master Toolbox Podcast
Measuring Success Through Team Evolution | Anamaria Ungureanu

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 31, 2025 15:26


Anamaria Ungureanu: Tracking Scrum Team Behavioral Evolution Over Time 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 defines Scrum Master success by focusing on team behavioral trends and performance evolution over time. She monitors how teams increase trust with stakeholders, demonstrate commitment, and apply agile behaviors consistently. Her approach emphasizes seeking regular feedback from stakeholders and conducting honest self-assessments to ensure the Scrum Master role is truly maximizing team performance. Success isn't measured by a single moment but by sustained positive change in team dynamics and delivery capabilities. Featured Retrospective Format for the Week: Stop/Start/Continue with Enhanced Focus Anamaria recommends the classic Stop/Start/Continue format but emphasizes the importance of varying the questions and bringing both quantitative and qualitative data to drive meaningful conversations. She suggests picking specific themes for each retrospective (like testing) and ensuring that discussions lead to concrete, actionable outcomes rather than just surface-level feedback. Self-reflection Question: How do you currently measure your effectiveness as a Scrum Master, and what trends in your teams indicate genuine progress versus superficial compliance? [The Scrum Master Toolbox Podcast Recommends]

Scrum.org Community
Ask a PST - Scrum Master Edition with Bart Versteegen

Scrum.org Community

Play Episode Listen Later Jul 30, 2025 61:40 Transcription Available


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!

Scrum Master Toolbox Podcast
Knowledge Hoarding and Team Dependencies | Anamaria Ungureanu

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 29, 2025 18:41


Anamaria Ungureanu: The Tech Lead Who Nearly Destroyed the 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. Anamaria describes a seven-member software team that initially seemed engaged but began self-destructing when a senior tech lead refused to embrace transparency and knowledge sharing principles.  The situation escalated when this key team member's four-day absence completely blocked the team's ability to deliver, creating a dangerous single point of failure. Through careful retrospective facilitation and strategic motivation techniques, including offering the specialist new learning opportunities while gradually transferring their legacy knowledge to teammates, Anamaria helped the team overcome knowledge silos and establish sustainable collaboration patterns. Featured Book of the Week: Never Split the Difference by Chris Voss Anamaria recommends “Never Split the Difference” by Chris Voss, a negotiation masterpiece because it taught her essential communication strategies for establishing trust and navigating tense situations. She emphasizes that negotiation is a critical Scrum Master skill, and Voss's techniques help build rapport with stakeholders while managing difficult conversations that arise during team transformations and organizational change initiatives. Self-reflection Question: What knowledge silos exist in your teams, and how might you motivate specialists to share their expertise while providing them with new growth opportunities? [The Scrum Master Toolbox Podcast Recommends]

Scrum Master Toolbox Podcast
Goal Clarity—The Missing Piece in Agile Team Performance | Anamaria Ungureanu

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 28, 2025 13:39


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]

ARCLight Agile
The Heart of Team Leadership: Engage, Empower, Elevate

ARCLight Agile

Play Episode Listen Later Jul 28, 2025 33:00


What does it truly mean to lead a team—without being “the boss”?  In this episode, we explore the Team Leadership domain of the Leadership Growth Wheel, diving into three essential skills: engagement, delegation with accountability, and empowerment.  Whether you're a Scrum Master, project manager, or informal team lead, this conversation offers practical insights on how to ignite motivation, encourage ownership, and build resilient, self-managing teams.  Discover what gets in the way of trust, how to avoid the trap of micromanagement, and why psychological safety and empathy are the bedrock of empowered teams.

Scrum Master Toolbox Podcast
Situational Leadership for Scrum Masters - Knowing When to Step Back | Anh Vu

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 24, 2025 14:34


Anh Vu: Situational Leadership for Scrum Masters - Knowing When to Step Back 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. Anh defines success for Scrum Masters through a simple but powerful test: when you take vacation and return to find the team working exceptionally well without you. This ultimate measure of success focuses on building self-organization and enabling true team autonomy. He emphasizes that Scrum adoption should serve as a metaphor for autonomy and self-organization, with the Scrum Master's stance evolving alongside the team's growth. Drawing from Situational Leadership principles, Anh points out that a team can only become as autonomous as the Scrum Master can envision and facilitate. The key is recognizing when to step back and allow the team to demonstrate their independence while ensuring they have the foundation and confidence to succeed. Featured Retrospective Format for the Week: Free Form Retrospective Anh advocates for the free form retrospective format, which requires only a whiteboard, table, and people gathering for open reflection based on the previous sprint's goals. Rather than following structured formats, he invites team members to share their insights freely, considering the retrospective successful as long as the team leaves with 1-3 actionable insights. This approach works particularly well with teams he knows well, where trust and communication patterns have been established. He builds on this by incorporating silent thinking time to start conversations, a habit developed over time that makes teams more comfortable sharing in the free form format. Anh also recommends conducting retrospectives during in-office days when the team can eat together, investing heavily in these face-to-face interactions to strengthen team bonds. Self-reflection Question: What would happen if you took a week off from your current role - would your team continue to thrive, or would they struggle without your direct involvement? [The Scrum Master Toolbox Podcast Recommends]

Scrum Master Toolbox Podcast
From Individual Stars to Team Players - Transforming Competitive Developers | Anh Vu

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 22, 2025 13:56


Anh Vu: From Individual Stars to Team Players - Transforming Competitive Developers 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. Anh recounts his first Scrum project as a Scrum Master for a payment company, leading a team of five developers working on a new product with new technology and devices. The challenge was compounded by the fact that this was a completely new team where members didn't know each other. What started as an attempt to make work visible quickly deteriorated when developers began competing to prove they were the best rather than collaborating toward shared goals. Each developer focused solely on their individual tasks without considering the overall outcome, and when bugs appeared at the end of sprints, blame games began.  This anti-pattern of developers not prioritizing team results created a cycle where team members wouldn't help each other, ultimately undermining the project's success. Anh's key learning was that the root problem wasn't process-related but trust-related, and as a Scrum Master, addressing surface-level issues isn't enough - the real work lies in building foundational trust within the team. Self-reflection Question: In your current team, are individual achievements being celebrated more than collective success, and how might this be affecting overall team trust and collaboration? Featured Book of the Week: The Five Dysfunctions of a Team Anh recommends "The Five Dysfunctions of a Team" as essential reading for understanding team dynamics. He emphasizes that trust is the basic foundation for people to succeed together, and this book provides both the why and the how for building that trust. According to Anh, trust serves as the foundation for all teams, making it crucial knowledge for both Scrum Masters and Project Managers who need to facilitate effective team collaboration. [The Scrum Master Toolbox Podcast Recommends]

Scrum Master Toolbox Podcast
The Hidden Cost of Skipping Scrum Ceremonies | Anh Vu

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 21, 2025 14:45


Anh Vu: The Hidden Cost of Skipping Scrum Ceremonies 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. Anh shares his experience as a new Project Manager who was confident about understanding Scrum but quickly discovered the complexity of implementing it effectively. His team's daily meetings turned into lengthy debates about solutions, consuming excessive time and energy, leading team members to complain about meeting overload. When the team suggested moving discussions to Slack to avoid meetings, this created new problems with missed insights and additional coordination challenges.  Anh explains how they fell into the "Scrum-but" anti-pattern, where teams claim to use Scrum while avoiding its core practices. The real learning came when he realized that successful framework implementation requires connecting core values with mechanics - for example, linking transparency from Scrum values to actual practices. His key insight: always share the "why" behind everything you do, and remember the Shu-Ha-Ri principle - make it work first before making changes. Self-reflection Question: How might you be unconsciously implementing "framework-but" patterns in your current role, and what core values should you reconnect with your daily practices? [The Scrum Master Toolbox Podcast Recommends]

Scrum Master Toolbox Podcast
Business Analyst to Product Owner—More Than a Title Change | Joelle Tegwen

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 18, 2025 15:04


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]

Scrum Master Toolbox Podcast
Building High-Performing Teams Through Three Essential Elements | Joelle Tegwen

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 17, 2025 12:13


Joelle Tegwen: Building High-Performing Teams Through Three Essential Elements 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. Joelle identifies three essential characteristics for Scrum Master success: psychological safety, collaboration, and cross-skilling with role blurring. She emphasizes the importance of teams being comfortable with conflict, drawing from Amy Edmondson's work and Google's Project Aristotle research. Her approach involves mapping where a team currently stands and focusing on one of these three characteristics at a time. The key is building relationships where challenging each other becomes positive behavior, being clear about what you're trying to achieve with the team, and regularly checking in for feedback. Success comes from creating an environment where team members can grow beyond their individual silos while maintaining strong collaborative relationships. Featured Retrospective Format for the Week: Sailboat Retrospective As a consultant frequently joining new teams, Joelle relies on the Sailboat retrospective format to quickly understand where teams are positioned. Teams use the sailboat metaphor to explain their current situation, which gives her rapid insight into their challenges and strengths. This format is particularly valuable because it helps her identify what not to change - understanding what the team considers their strengths prevents well-intentioned interference with what's already working well. The visual metaphor makes it easy for teams to express complex dynamics while providing the facilitator with actionable intelligence for coaching direction. Self-reflection Question: Looking at your current team through the sailboat metaphor, what would you identify as the wind in your sails versus the anchors holding you back, and how might this perspective change your improvement priorities? [The Scrum Master Toolbox Podcast Recommends]

The FIT4PRIVACY Podcast - For those who care about privacy
How is the CISO Role Changing with Aman Tara and Punit Bhatia in the FIT4PRIVACY Podcast E143 S06

The FIT4PRIVACY Podcast - For those who care about privacy

Play Episode Listen Later Jul 17, 2025 20:11


The CISO role is no longer just about protecting IT assets — it's about navigating AI risks, complex regulations, and building digital trust across the enterprise. In an era where digital trust is more important than ever, how do CISOs stay ahead of evolving threats? What impact does AI have on cybersecurity and privacy compliance? And how can organizations empower every employee to contribute to ongoing digital safety? Join cybersecurity expert and former military major Aman Tara in conversation with Punit Bhatia as they explore the evolving responsibilities of CISOs in today's digital landscape. Aman shares why CISOs must think like hackers to stay ahead, how to manage emerging AI threats, and ways to ensure compliance with global data privacy laws. If you want to understand the future of cybersecurity leadership and how to foster trust in an AI-driven era, this episode is a must-watch! KEY CONVERSION 00:01:44 What is Digital Trust for Aman Tara 00:02:44 What role does the CISO play in creating Digital Trust? 00:04:59 How to manage overlap in a CISO role with privacy function 00:06:17 Do you have regular meetings with privacy counterparts? 00:08:19 Impact of AI and emerging technologies on the role of CISO 00:09:58 How Should a CISO respond when using unsafe tools and create risk in organization? 00:12:00 What can everyone do to ensure ongoing digital trust and safety? 00:15:17 Amman's Book and Personal Journey  ABOUT GUEST Aman Tara is an ex-military Major and a qualified attorney. He holds an associate diploma in Software Engineering, a bachelor's degree in Life Sciences and Economics, a degree in Law, and his MBA from Iowa, USA. He is a Certified Information System Auditor, Certified Data Privacy Solutions Engineer, Certified Fraud Examiner, Certified Amazon Web Services Cloud Practitioner and a Scrum Master. He has also done a Cybersecurity course at Massachusetts Institute of Technology (MIT).  After serving in the military for a decade in various combat and staff roles, he moved to the corporate world in 2011. He has worked on IT audits, IT security and Cybersecurity assessments, Third Party Risk Management projects for various Fortune 500 companies across the USA and South Asia. Presently, he is the Executive Director for one of the world's largest banks, working in their Cybersecurity department and Board of Directors of three Non-Profit Organizations based outside of the USA.  He has been featured in articles overseas and invited as speaker for various US based and international seminars. He conducts workshops for corporates on stress management, hosts a live radio show every week in Texas, USA, and has also authored a book ‘Just Did It'.  ABOUT HOST Punit Bhatia is one of the leading privacy experts who works independently and has worked with professionals in over 30 countries. Punit works with business and privacy leaders to create an organization culture with high privacy awareness and compliance as a business priority. Selectively, Punit is open to mentor and coach professionals.  Punit is the author of books “Be Ready for GDPR' which was rated as the best GDPR Book, “AI & Privacy – How to Find Balance”, “Intro To GDPR”, and “Be an Effective DPO”. Punit is a global speaker who has spoken at over 30 global events. Punit is the creator and host of the FIT4PRIVACY Podcast. This podcast has been featured amongst top GDPR and privacy podcasts.  As a person, Punit is an avid thinker and believes in thinking, believing, and acting in line with one's value to have joy in life. He has developed the philosophy named ‘ABC for joy of life' which passionately shares. Punit is based out of Belgium, the heart of Europe.  RESOURCES Websites www.fit4privacy.com,www.punitbhatia.com, https://www.linkedin.com/in/aman-tara-cisa-cdpse-cfe-b6095483/ Podcast https://www.fit4privacy.com/podcast Blog https://www.fit4privacy.com/blog YouTube http://youtube.com/fit4privacy   

Scrum Master Toolbox Podcast
Breaking Knowledge Silos Through Strategic Skill Sharing | Joelle Tegwen

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 16, 2025 12:20


Joelle Tegwen: Breaking Knowledge Silos Through Strategic Skill Sharing 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. Working as a Scrum Master on a team rewriting an old application, Joelle faced a significant challenge: experienced developers were located in India while new, experienced developers brought in locally lacked familiarity with the medical domain. Drawing inspiration from The Phoenix Project, she implemented a skills matrix to address the knowledge silos that were preventing new team members from contributing effectively.  Using a teacher-student model, initially frustrated leaders who had to work with "students" discovered within 2-3 sprints that they were also learning new things and no longer carried the pressure of being the only ones with critical knowledge. The new team members brought fresh ideas that improved the codebase, and when the team eventually grew too large, the skills matrix facilitated smooth self-selection for team reorganization. What started as a solution to get new hires productive evolved into a comprehensive approach to knowledge sharing and team scalability. Self-reflection Question: Where do knowledge silos exist in your current team or organization, and how could you implement structured knowledge sharing to transform those constraints into learning opportunities? [The Scrum Master Toolbox Podcast Recommends]

Scrum Master Toolbox Podcast
Why Your Scrum Master Job Needs a Reset with Every Leadership Change | Joelle Tegwen

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 14, 2025 14:00


Joelle Tegwen: Why Your Scrum Master Job Needs a Reset with Every Leadership 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. Joelle shares her experience as a coach and Scrum Master at a small startup where multiple companies had merged over several years. When a new VP with a conservative approach replaced her original sponsor who favored significant change, Joelle failed to adapt her tactics and align with the new leadership's direction.  She emphasizes the critical importance of listening to feedback from leaders and avoiding the anti-pattern of only listening to peers and direct managers instead of higher-level leadership. Joelle explains that whenever you get a new leader, your job essentially starts over again, requiring you to discover their goals and style through interviews about their priorities. She stresses that change happens through people, not just actions, and that pushing too hard creates more resistance. In this segment, we refer to the book The First 90 Days by Michael D. Watkins and the Deep Canvassing Technique.  Self-reflection Question: How do you currently assess and adapt to new leadership styles in your organization, and what steps could you take to better align your change management approach with leadership expectations? [The Scrum Master Toolbox Podcast Recommends]

The Growth Mindset Gal
Ep. 213 Personal & Team Growth: Unlocking Potential Together w| Elvi Caperonis

The Growth Mindset Gal

Play Episode Listen Later Jul 14, 2025 54:39


Happy Mindful Monday Everyone! In this week's episode, our host Allie Brooke interviews the collaborative Elvi Caperonis. Elvi is a Certified Project Management Professional and Scrum Master with over 15 years of expertise in Program Management across more than five industries. As a former Technical Program Manager at Amazon and Analyst at Harvard University, Elvi leverages her extensive experience to train and empower agile teams, fostering impactful organizational success. Recognized as a LinkedIn Top Voice, she is dedicated to transforming team dynamics and promoting resilience, innovative productivity, and growth through agile methodologies and inspirational leadership. Episode Topics • What are the essential elements of a high-performing team?• How can leaders build trust and rapport within their teams?• What role does communication play in building and maintaining effective teams?• What are the most impactful strategies for personal development?• How can individuals identify their strengths and weaknesses to maximize their growth potential?• What role do support and community play in building resilience?• How can individuals learn from their failures and use them as opportunities for growth? How To Connect w| Elvi• Linkedin: ⁠https://www.linkedin.com/in/elvi-caperonis⁠• Website: ⁠www.reinvent-yourself.org The Growth METHOD. Membership◦ ⁠⁠⁠⁠⁠⁠⁠⁠Join Here!⁠⁠⁠⁠⁠⁠⁠⁠ (Both FREE and Premium)◦ Use Code:growthmindsetgal for 50% off your first month's subscription! 1:1⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ GROWTH MINDSET COACHING PROGRAMS!◦ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Application Form ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠◦ Coaching Programs⁠⁠⁠⁠⁠⁠⁠⁠ information⁠⁠⁠⁠⁠⁠⁠⁠What are the coaching sessions like?⁠⁠• Tailored weekly discussion questions and activities to spark introspection and self-discovery.• Guided reflections to help you delve deeper into your thoughts and feelings.• Thoughtfully facilitated sessions to provide maximum support, accountability, and growth.• Please apply for a FREE discovery call with me! Allie's Socials• Instagram:@thegrowthmindsetgal• TikTok: @growthmindsetgal• Email: thegrowthmindsetgal@gmail.com Links from the episode• Growth Mindset Gang ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Instagram⁠⁠⁠⁠⁠⁠⁠⁠ Broadcast Channel⁠⁠⁠⁠⁠⁠⁠⁠• Growth Mindset Gang ⁠⁠⁠⁠⁠⁠⁠⁠Newsletter ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• Growth Mindset Gal ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Website⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠• Better Help Link: Save 10% ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://betterhelp.com/growthmindsetgal⁠⁠⁠⁠⁠⁠⁠⁠ 

Scrum Master Toolbox Podcast
Selecting the Appropriate Agile Values for Organizational Impact | Pascal Papathemelis

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 10, 2025 15:27


Pascal Papathemelis: Selecting the Appropriate Agile Values for Organizational Impact 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 defines success for Scrum Masters through his recent mantra of "effectiveness over efficiency," "outcome over output," and "create value for the customer." Working with a client introducing a new digital platform, he focuses on understanding the value for both the organization and end customers while minimizing confusion in the process. Pascal emphasizes the importance of ensuring work sustainability over time by focusing on Agile values and principles and their deep understanding. He customizes the Agile Manifesto's values and principles for each organization, such as focusing on customer value, collaboration, and constant learning. Pascal strategically highlights the principles and values that address the biggest challenges facing the organization at any given time, making Agile concepts relevant and actionable for the specific context. Featured Retrospective Format for the Week: Sailboat Pascal recommends the sailboat retrospective as his preferred format, though he emphasizes that the choice depends on context and team focus. He values this metaphor-based retrospective because it helps teams discuss critical aspects of their work through different perspectives. The sailboat format allows teams to explore what propels them forward (wind), what holds them back (anchors), what they need to watch out for (rocks), and their destination (island). Pascal also uses timeline retrospectives and stresses the importance of varying retrospective formats to prevent teams from falling into routine patterns that might limit their ability to bring fresh insights to their work. He believes that good data and effective visualization are essential components of any successful retrospective format. Self-reflection Question: How effectively are you customizing Agile principles to address your organization's specific challenges and context? [The Scrum Master Toolbox Podcast Recommends]

The Daily Standup
Is Agile Disappearing? - Not Again...

The Daily Standup

Play Episode Listen Later Jul 10, 2025 11:19


Is Agile Disappearing? - Not Again...For the last two years, we've seen a fairly drastic change in the agile landscape. Large companies have laid off hundreds of thousands of agile and tech jobs (287k in 2023 and 152k in 2024). The job market for new jobs is also very different. You can't just search for Scrum Master or Agile Coach like you used to.Maybe it's because big firms have started treating agile like “a skill not a role”, as mentioned by the Business Agility Institute and scrum alliance in their “Skills in the New World of Work” research paper. You might need to be multiple things, a manager who knows agile or a technologist who knows Scrum. It's a trend that is sad but true, IMO.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Scrum Master Toolbox Podcast
From Waterfall to Agile—A Multi-Level Change Strategy | Pascal Papathemelis

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 9, 2025 15:43


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]

Scrum Master Toolbox Podcast
The Hidden Cost of Removing Scrum Masters from High-Performing Teams | Pascal Papathemelis

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 8, 2025 19:56


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]

Scrum Master Toolbox Podcast
From Mechanics to Human Factors—How Scrum Masters Grow | Pascal Papathemelis

Scrum Master Toolbox Podcast

Play Episode Listen Later Jul 7, 2025 15:37


Pascal Papathemelis: From Mechanics to Human Factors—How Scrum Masters Grow 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 his evolution as a Scrum Master, moving from focusing purely on the mechanics of Scrum to understanding the critical importance of human factors. Early in his career, Pascal worked with teams that struggled to achieve sprint goals, with stories floating from one sprint to another. Through retrospectives and continuous improvement, he learned essential tips like not taking too much into sprints and making stories smaller.  However, Pascal's biggest transformation came when he shifted focus to human elements - involving everyone in the team, improving collaboration during refinement, and developing people's skills and attitudes. He emphasizes that every person is an individual with the intention to be their best, and a good Scrum Master must sense when something is wrong and create safe environments for open conversations. Pascal highlights the importance of corridor conversations and coffee machine breakthroughs, especially before COVID, and stresses the need to invest effort in how teams start, using models like Tuckman's team growth model and Diana Larsen's Team Liftoff approach. In this segment, we also refer to the episode with Arne Roock, about the importance of team design and setup in the success of teams. Self-reflection Question: How might shifting your focus from Scrum mechanics to human factors transform the way you support your team's growth and collaboration? [The Scrum Master Toolbox Podcast Recommends]