Podcasts about agile alliance

What if the real power lies not in choosing a side—but in mastering both? We explore how blending agile and traditional project management is redefining success across industries.In this thought-provoking episode, I'm joined by Lenka Pinka, Chief of Staff to the CEO at Project Management Institute, and Sandy Mamoli, Agile Coach, former Olympian, and Agile Alliance board member, to unpack one of the most persistent tensions in the world of work: agile vs. traditional project management.But what if this debate is outdated—and even unhelpful?Together, Lenka and Sandy challenge the false binary and advocate for a more nuanced, collaborative approach. Drawing from their global experience across industries and methodologies, they explain how today's most successful organizations don't choose sides—they blend practices fluidly based on context, outcomes, and evolving needs.This conversation is full of compelling insights for both project professionals and agile practitioners. From fears of “agile dilution” to misconceptions about governance, we explore how shared values and a focus on delivery can bridge methodological divides. As Sandy puts it, the new PMI–Agile Alliance partnership is like "two fully whole, independent people who together create something magical."Whether you see yourself as a traditional project manager, a scrum master, or somewhere in between, this episode will reshape how you think about frameworks, governance, and the future of work. If you're ready to move past methodology wars and start focusing on what really drives success, this is your episode. Listen now, and join the conversation on how we can build better ways of working—together. In this episode, we discuss:0:00 Introduction and Guest Backgrounds10:41 PMI and Agile Alliance Partnerships18:11 Community Reactions and Concerns27:19 Product Management and Project Convergence39:38 Governance in Agile EnvironmentsSupport the showThank you for listening to Agile Ideas! If you enjoyed this episode, please share it with someone who might benefit from our discussions. Remember to rate us on your preferred podcast platform and follow us on social media for updates and more insightful content.Thank you for listening. If you enjoyed this episode, I'd really appreciate it if you could share it with your friends and rate us. Let's spread the #AgileIdeas together! We'd like to hear any feedback. www.agilemanagementoffice.com/contact Don't miss out on exclusive access to special events, checklists, and blogs that are not available everywhere. Subscribe to our newsletter now at www.agilemanagementoffice.com/subscribe. You can also find us on most social media channels by searching 'Agile Ideas'. Follow me, your host, on LinkedIn - go to Fatimah Abbouchi - www.linkedin.com/in/fatimahabbouchi/ For all things Agile Ideas and to stay connected, visit our website below. It's your one-stop destination for all our episodes, blogs, and more. We hope you found today's episode enlightening. Until next time, keep innovating and exploring new Agile Ideas!Learn more about podcast host Fatimah Abbouchi...

BONUS: Maria Chec Explores the Divide Between Agile Leaders and Practitioners In this BONUS episode, we explore Agile leadership with Maria Chec, author and host of Agile State of Mind. Maria shares insights from her analysis of Miro's Agile Survey, revealing a concerning disconnect between how Agile leaders and practitioners experience agile methodologies. We explore the roots of this divide, discuss practical approaches to bridging the gap, and consider the implications of recent industry developments like the PMI-Agile Alliance merger. Maria offers valuable perspectives on creating truly collaborative environments where frameworks serve the teams, not the other way around. The Disconnect Between Leaders and Practitioners "Practitioners feel pressured to comply with agile practices when they don't seem to add value." Maria highlights a stark divide revealed in Miro's survey of 1,200 agile practitioners and leaders. When asked if agile is living up to its original values, leaders and practitioners gave drastically different responses. For example, 69% of practitioners felt processes and tools overshadow individuals in their organizations, while only 43% of leaders shared this view. Similarly, 58% of practitioners believed documentation was prioritized over delivering final products, compared to just 39% of leaders. These disparities point to a fundamental disconnect in how agile is experienced at different organizational levels, with practitioners often feeling frameworks are imposed rather than collaboratively implemented. When Frameworks Become the Problem "The framework is too rigid... The framework is too complex... We have to change too much to use the framework." The issue isn't with agile frameworks themselves but how they're applied, Maria argues. Leaders often implement frameworks like SAFe without sufficient practitioner input or adaptation to organizational context. This creates an anti-pattern of "magical thinking" where companies believe they can install off-the-shelf solutions that worked elsewhere without considering their unique circumstances. The practitioners, who must live with these frameworks daily, experience frustration when rigid implementations fail to address their actual needs. Conway's Law comes into play here – the structure imposed by leadership often doesn't align with how teams naturally need to collaborate based on the systems they're building. The Role of Psychological Safety "Can I really admit that something the leadership made me do is not working for me? Will I be the only one admitting it?" This disconnect reveals deeper issues around psychological safety and trust within organizations. Many practitioners fear speaking up about framework problems, especially when they've just endured yet another organizational transformation. Maria emphasizes that without psychological safety, feedback loops break down, preventing the continuous improvement that's central to agile philosophy. Leaders must create environments where teams feel safe to provide honest feedback about what's working and what isn't, without fear of being singled out or dismissed. Without this safety, frameworks become rigid implementations rather than adaptable approaches that evolve with team needs. Reconnecting Through Gemba Walks "Be there where the value is created and know what's going on." To bridge the gap between leadership vision and practitioner reality, Maria strongly recommends Gemba walks – a concept from Lean and Toyota where leaders go to where value is created. This practice helps leaders understand the actual work being done and build relationships with team members. Maria references Project Aristotle at Google, which found that trust and psychological safety are fundamental to team success. She also notes the importance of leaders articulating a meaningful mission to inspire teams, sharing her experience at a taxi-hailing app where the CEO's vision of reducing urban parking needs made her feel she was "building something for the future." Leaders should regularly spend time where the actual work happens Teams need to understand how their work contributes to a larger purpose Open communication channels must be genuine, not just symbolic In this segment, we refer to Management 3.0 and Managing For Happiness by Jurgen Appelo.  The PMI-Agile Alliance Merger and the Future of Agile "Have we really found better ways? Why are Agile Alliance and PMI merging?" The recent merger between the Project Management Institute and Agile Alliance represents a surprising development in the industry. Maria takes an optimistic view, wondering if this indicates PMI recognizing that agile is truly the way forward. She acknowledges the perception that "Agile is dead" discussions highlight a crisis in the movement, but suggests the merger might be an opportunity to influence project management with agile values. She emphasizes how AI is creating massive changes that require experimentation and adaptation – precisely what agile approaches enable. This industry shift offers agile practitioners the chance to shape how traditional and agile methodologies might complement each other in the future. The merger could be seen as closing a circle or as an opportunity for cross-pollination "Agile is dead" discussions reflect growing pains rather than true failure Rapid technological changes with AI require more experimentation, not less Breaking Down Silos with "Glue Roles" "What are the 'glue roles' that you need in your organization?" Maria introduces her concept of "glue roles" – positions that help break down silos and foster collaboration regardless of what they're called. Whether they're RTEs (Release Train Engineers), Agile Coaches, or Technical Project Managers, these roles can transform organizational effectiveness when focused on enabling teams rather than enforcing processes. She observes that nature constantly changes, yet we expect our companies to remain static. This mindset prevents the adaptation necessary for true agility. Instead, organizations need individuals who can facilitate communication, remove barriers, and help teams collaborate effectively across boundaries. Focus on the function of collaboration rather than rigid role definitions Adapt roles to organizational needs rather than forcing organizational change to fit frameworks Use these roles to foster psychological safety and open communication Learning Through Experimentation "We need to experiment." Looking toward the future, Maria emphasizes the importance of experimentation in the face of rapid technological change, particularly with AI. She notes that while tech professionals are often thought to be early adopters, AI tools like ChatGPT are being embraced across all industries. The accelerating pace of change means we can no longer plan years ahead with certainty – what we use today may be obsolete in two years. This reality makes agile approaches even more relevant, as they embrace change rather than fight it. She encourages agile practitioners to openly discuss how they use these new tools, adapting their practices rather than clinging to outdated methods. The accelerating pace of change makes long-term planning increasingly difficult AI is already transforming work across all industries, not just tech Agile principles of adaptation and experimentation are more relevant than ever About Maria Chec Maria Chec is a seasoned Agile leader, ProKanban Trainer, and creator of Agile State of Mind. With over a decade of experience, she specializes in transforming teams through SAFe, OKRs, and process optimization, achieving remarkable productivity gains. Maria's mission is empowering teams to thrive through collaboration and adaptability. You can link with Maria Chec on LinkedIn and subscribe to Maria Chec's Substack.

EP140 — Waterfall No ha muerto: El caso PMI y Agile AllianceEn este episodio platicamos sobre aquella relación que por allá en Enero de 2025 sorprendió al mundo Agile: la Agile Alliance se relaciona con PMI. ¿Y que tiene de especial eso? pues la PMI siempre ha sido considerada como la antítesis del mundo Agile, y con esta fusión, asimilación, o relación, muchos pusieron el grito en el cielo: las voces de que Agile Ha Muerto!, surgieron y resonaron con más fuerza. Pero ¿son sensatas esas reacciones? ¿qué implica esta relación? ¿hubo una compra de Agile Alliance? ¿refleja esto alguna crisis de Agile? ¿hay alguna alternativa válida a Agile?.Ya es tiempo en que Hormigas Agilistas se involucre en este tema, ya con cierta perspectiva luego de varios meses, e incluso siendo conscientes que es un tema no cerrado, y aun existen planes para continuarlo en próximos episodios con otras interesantes hormigas invitadas.Sin embargo nos valemos de este tema para platicar sobre el rol del proyecto en las organizaciones, y el por qué este concepto (la “P” de PMI), sigue siendo uno de los baluartes de muchas organizaciones en su “concepción clásica de la entrega valor”, a pesar de las múltiples alternativas que existen. También analizamos la crisis en las comunidades, y la situación de Agile Alliance posiblemente reflejada en nuestras comunidades Agile, y cómo algunas comunidades dan la pelea.Otro interesante episodio, con las hormigas: Arturo Robles Maloof, Antonio Gallardo Burgos, Rodrigo Burgos Noceti.Si deseas conocer más sobre este episodio y todos los demás, visita el sitio: HormigasAgilistas.CL o en https://medium.com/hormigas-agilistas/¡Gracias por ser parte del Universo de Hormigas Agilistas!IMPORTANTE: Siempre es bueno recordar que en Hormigas Agilistas Podcasts no somos buscadores de la verdad, el objetivo acá no es indicar los que se debe hacer; más bien, abrimos el micrófono para que las personas puedan contar sus experiencias, sus ‘heridas de guerra', y así los oyentes puedan tomar lo que más le haga sentido en sus organizaciones y avanzar en la mejora continua.#PMI #AgileAlliance #Agile #ComunidadesAgiles #Producto #Valor #HormigasAgilistas

BONUS: X-Matrix and Obeya: How to Make Strategy Visible and Actionable for Everyone with Jim Benson and Karl Scotland In this BONUS episode, we explore the groundbreaking work of two renowned agilists - Karl Scotland and Jim Benson. Together, they've developed innovative approaches to making strategy accessible and actionable across organizations. We delve into how their combined expertise in X-Matrix strategy deployment and Obeya visualization creates powerful frameworks for aligning teams and keeping strategic conversations alive throughout execution. The Genesis of Strategic Visualization "It's not about whether agile works or not. It's about whether your business is being successful." Karl Scotland shares how his journey from tactical agile practices to strategic thinking began with a deceptively simple question: "How will we know if this agile thing is working?" This fundamental inquiry exposed a common gap in organizations - the disconnect between implementation methodologies and measurable business outcomes. Karl explains how this led him to develop the X-Matrix, a powerful visualization tool that connects true north, aspirations, strategies, tactics, and evidence on a single page, creating coherence across organizational efforts. Jim Benson reflects on his complementary path, observing how organizations often focus intensely on transformations without creating clear alignment between corporate needs, team activities, and customer value. This absence of a "full story" connecting strategic intent to daily work leaves teams uncertain if they're actually doing the right things. Jim highlights how their combined approach addresses this critical gap through collaborative strategy development and visual management. Seeing Strategy, Tactics, and Work in One Place "Strategy has often been things that C-level people do when they go on a retreat to Cancun...and everybody's like 'why?' and they're like 'Cancun'...the story of how that came about isn't there." Karl and Jim introduce their innovative approaches to making strategy visible and actionable. The X-Matrix provides a powerful framework for capturing the five key elements of strategy (True North, Aspirations, Strategies, Tactics, and Evidence) on a single sheet, showing how these elements correlate. This creates a comprehensive strategic story that answers what an organization is doing, why they're doing it, how they'll know it's working, and what success ultimately looks like. This strategic framework then comes to life in the Obeya room, which Jim describes as a physical or virtual space containing a family of visualizations. These include value stream maps, A3s, time series data, personal Kanbans, collaborative problem-solving tools, and KPIs - all designed to support the execution of the strategy articulated in the X-Matrix. By bringing these elements together, teams can maintain a living strategic conversation, allowing for continuous learning and adaptation based on real evidence. In this section, we also refer to:  Esko Kilpi's Interactive Value Creation blog, where he explores different aspects of value creation, including how conversations are the core interaction pattern. The Catch-ball process from Lean The Backbriefing, From Stephen Bungay's book The Art of Action   Maintaining Living Strategic Conversations "You don't create an annual strategy, but you create a living strategic conversation within the organization." The power of connecting X-Matrix and Obeya approaches lies in their ability to catalyze and sustain meaningful strategic conversations. Karl describes the X-Matrix as an "architecture for your Obeya" and emphasizes the importance of continuous strategy development rather than static planning. He introduces concepts like "catch-ball" from Lean and "backbriefing" from military commander Stephen Bungay, which create feedback loops to ensure shared understanding and effective execution. Jim highlights how this approach transforms strategy from an annual event into an ongoing dialogue where everyone can see how their work connects to larger goals. He emphasizes the importance of choosing language carefully, noting his appreciation for Karl's use of "evidence" rather than "metrics" - a subtle but significant distinction that encourages learning and psychological safety rather than mere measurement. This creates environments where people feel safe to discuss what's actually happening rather than hiding problems. The Changing Landscape of Agile and Strategy "I want people to own the process themselves, which is the agreements of how they will interact, and then they deploy tools like their Obeya to facilitate that process and those interactions." When discussing the recent PMI and Agile Alliance merger, both speakers offer thoughtful perspectives on the evolution of agile methodologies. Jim describes this as part of an ongoing commodification of agile practices, suggesting that we're entering a post-framework era where teams can draw from multiple approaches to craft ways of working that suit their specific context rather than adhering to rigid methodologies. Karl reflects on how the early agile community started with like-minded people coming together to share ideas and be "heretics," but eventually evolved into larger, more commercially-driven conferences and organizations. He sees the future in smaller, more focused communities of practice developing around specific interests or approaches - like the collaboration he and Jim have renewed with their course and strategic visualization work. Creating Professional Engagement Through Visualization "The word 'evidence' is a painfully poignant word... Evidence is something that grows over time based on investigation." A fascinating insight from this conversation is Jim's observation about the transformative power of visualization and language in creating psychological safety. He notes that when organizations approach their Kanban or Obeya with a learning mindset - seeking evidence rather than just tracking metrics - the entire conversation changes. Problems become opportunities for learning rather than failures to hide. Karl's careful choice of terminology in his TASTE model (True North, Aspirations, Strategies, Tactics, Evidence) reflects this intention, deliberately moving away from terms like "annual targets" or "process metrics" to encourage more holistic thinking. This approach helps create environments where strategic conversations can flourish across organizational boundaries, keeping everyone aligned on both direction and progress. About Karl Scotland and Jim Benson Karl Scotland is known for his groundbreaking work with the X-Matrix, integrating Agile principles with strategic planning. His innovative approach focuses on aligning True North, aspirations, strategies, tactics, and evidence into a single, collaborative visualization. Karl has extensive experience helping organizations develop continuous strategy development practices that connect strategic intent with execution. You can link with Karl Scotland on LinkedIn. Jim Benson is the visionary author of Personal Kanban and The Collaboration Equation. Jim's expertise lies in collaborative management, visualizing work, and fostering humane, team-driven environments. Through his work at Modus Institute, Jim helps organizations create systems that support continuous improvement and meaningful workplace conversations. You can link with Jim Benson on LinkedIn.

In this special episode, host Andy Cleff breaks explosive news about the Agile Uprising's hostile takeover of the entire agile establishment. Listen as he reveals how the community-driven coalition has acquired PMI, Agile Alliance, ISO, and Scrum.org in one fell swoop—and why their surprise acquisition of Cologuard might be the most disruptive move of all. Learn about the immediate changes to certification processes, the dramatic condensing of the Scrum Guide, and the coalition's "more than generous offer" to Scaled Agile. This episode will leave you either cheering for the revolution or checking your calendar.. how close to the 91st day of the year are we? The agile world will never be the same... or will it? About the Agile Uprising If you enjoyed this episode, please give us a review, a rating, or leave comments on iTunes, Stitcher or your podcasting platform of choice. It really helps others find us.  Much thanks to the artist  from  who provided us our outro music free-of-charge!  If you like what you heard,     to find more music you might enjoy! If you'd like to join the discussion and share your stories,  please jump into the fray at our  We at the Agile Uprising are committed to being totally free.  However, if you'd like to contribute and help us defray hosting and production costs we do have a .  Who knows, you might even get some surprises in the mail! Sound Effects and Image Credits Ch-Ching.wav by hgernhardt -- https://freesound.org/s/402651/ -- License: Attribution NonCommercial 4.0 Paper Shredder by aunrea -- https://freesound.org/s/495666/ -- License: Creative Commons 0 Aha Agreement by kanyonwyvern -- https://freesound.org/s/713754/ -- License: Creative Commons 0 FX dramatic music.wav by v0idation -- https://freesound.org/s/115139/ -- License: Creative Commons 0 Applause, huge, thunderous by peridactyloptrix -- https://freesound.org/s/196094/ -- License: Creative Commons 0 record scratch.wav by luffy -- https://freesound.org/s/3536/ -- License: Attribution 4.0 Ba-Dum-Tish#1.wav by Timbre -- https://freesound.org/s/84427/ -- License: Attribution NonCommercial 4.0 Ba-da-dum.wav by Simon_Lacelle -- https://freesound.org/s/37215/ -- License: Attribution 4.0 Beep warning by SamsterBirdies -- https://freesound.org/s/467882/ -- License: Creative Commons 0 another magic wand spell tinkle.flac by Timbre -- https://freesound.org/s/221683/ -- License: Attribution NonCommercial 4.0 another magic wand spell tinkle.flac by Timbre -- https://freesound.org/s/221683/ -- License: Attribution NonCommercial 4.0 Generic Interior Walla by brunoboselli -- https://freesound.org/s/757318/ -- License: Creative Commons 0 wah wah sad trombone.wav by kirbydx -- https://freesound.org/s/175409/ -- License: Creative Commons 0 Party Pack, Balloons, Deflate, Moderate, 03-02.wav by InspectorJ -- https://freesound.org/s/484269/ -- License: Attribution 4.0 STORYENDING_02.wav by phantastonia -- https://freesound.org/s/617068/ -- License: Attribution 4.0 15.wav by adcbicycle -- https://freesound.org/s/13824/ -- License: Creative Commons 0 34-muchos papeles moviendose.wav by Tomycatts -- https://freesound.org/s/429340/ -- License: Creative Commons 0 Human laughing - Various.wav by ThisIsMiniMe -- https://freesound.org/s/327396/ -- License: Attribution NonCommercial 4.0 FX wait 1.wav by v0idation -- https://freesound.org/s/115143/ -- License: Creative Commons 0 Opening A Curtain.wav by EmilZendera98 -- https://freesound.org/s/446046/ -- License: Attribution 4.0 TaDa!.aif by jimhancock -- https://freesound.org/s/256128/ -- License: Creative Commons 0 Megaphone via Freepik.com  

We're exploring the growing anti-Agile sentiment among developers as the agile-industrial complex has stitched together a grotesque imitation of what was once a vibrant movement. Like Frankenstein's creation, what began with noble intentions has transformed into something both villagers and developers flee from in horror!Before lighting our torches and brandishing our pitchforks, we examine the common complaints: lightning-rod meetings that drain life force, the monster of micromanagement wearing agile's skin, the cruel illusion of self-organization, and the chains of cross-team dependencies binding teams to their suffering. We dissect the organizational structures that, like misguided scientists, fundamentally misunderstand the natural advantages of agility, creating abominations that shamble through corporate hallways.#AgileLeadership #ProductDevelopment #TeamEmpowermentReferences:AA199 - W. Edwards Deming's Profound Knowledge for Transforming Organizations, 2025Eric Ries - The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, 2011Jeffrey Bezos - Bezos API Mandate, 2002Who Moved My Cheese - Spencer Johnson, 1998Extreme Ownership: How U.S. Navy SEALs Lead and Win - Jocko Willink, 2017= = = = = = = = = = = =YouTube= = = = = = = = = = = =Subscribe on YouTubeAppleSpotify= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

This is a special episode, where I introduce the "Big Agile Questions" survey and review some of the questions that you've already submitted! Thank you all who did! You can find the submission form here. Submit your questions, as we will be reviewing these in future episodes! To join 25,341 other Agilists on our Newsletter (˜1 post/week), visit this page, and join. The Power of Asking Better Questions At every major turning point in history, from the Renaissance to the Industrial Revolution, progress has begun with asking better questions. The Agile movement itself started with the authors of the Agile Manifesto questioning traditional software development methods. Now, in 2025, with significant changes in the industry including PMI's acquisition of the Agile Alliance, the community faces a crucial moment to shape its future direction through thoughtful inquiry and reflection. "Throughout history, the biggest leaps forward have come from people willing to ask difficult, sometimes even quite challenging, questions." The Future Beyond Agile

Agile Is Dead! Who Cares? Many people despise Agile and claim it's dead for good, while others still defend it. But now, with Agile Alliance joining the Project Management Institute (PMI), the future is anything but certain. 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/

The Agile Alliance partners with PMI—what does it mean for Agile’s future? Plus, how AI is reshaping Scrum Master roles and why honesty (even when it stings) is the key to career growth. Brian Milner and Cort Sharp tackle these hot topics in a no-holds-barred discussion. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Cort Sharp dive into the recent Agile Alliance-PMI partnership and its potential impact on the Agile community. They also explore AI’s growing influence on Scrum Master roles—will it replace them or elevate their value? Finally, they tackle a tricky but crucial topic: when to speak up in the workplace, balancing honesty with career preservation. If you want to stay ahead in Agile’s evolving landscape, this is a must-listen! References and resources mentioned in the show: #32: Scrum in High School Sports with Cort Sharp #82: The Intersection of AI and Agile with Emilia Breton #129: 2025: The Year Agile Meets AI and Hyper-Personalization with Lance Dacy #132: Can Nice Guys Finish First? with Scott Dunn Mike Cohn’s Better User Stories Course Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years. Auto-generated Transcript: Brian Milner (00:00) Welcome in. Welcome back, everybody. This is the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, we're going to do something a little different. We're in this mode right now. We've kind of been open to some suggestions recently about maybe we should try some experiments and try some different things. And so today's going to be one of those little experiments. We have someone that's going to be with us, Mr. Cort Sharp. So welcome in, Cort. Cort (00:23) Hey Brian, thanks for having me on. Brian Milner (00:26) Absolutely. Cort is our community manager for the Agile Mentors community. And Cort and I do classes together a lot. He is often the producer in the classes. So we see each other a lot. We talk a lot. Cort's also a certified Scrum professional. So he's been doing this and has encountered Scrum in some kind of unusual circumstances as well. He's a high school swim coach. There's an episode that we talked about that. way back so that anyone wants to dig that out, they can go back and find that and learn a little bit more about it. But we just thought it would be good to have maybe periodically a little check in about maybe some stories that have come up in the news about Agile or things that have been flashing through social media feeds or anything like that. know, Cort and I are a little bit different age groups, a little bit, more than a little bit. And I'm sure the of things that cross court's radar may be a little bit different than the things that cross mine. And we just thought maybe it would be an interesting kind of thing to have a little discussion, the two of us, about some of these major burning issues and things that people are talking about on LinkedIn and Twitter and, I'm sorry, X, anywhere else. I'm going to kind of... Give the reins over to court here a little bit, because I know he's pulled some things that he wants to talk about, and we'll just kind of see where we go. Cort (01:40) Awesome, yeah, thanks Brian. Not just X and LinkedIn, we're also looking through Instagram, YouTube Shorts, where the cool kids hang out, I guess is. That's at least what my swimmers tell me. Brian Milner (01:50) Okay, okay I Got it I got a yeah, I you know, I had to learn a lot about an Instagram with my daughters and I still don't get it. just I mean I have fun flipping through stuff but I don't I could never like get a following there because I just don't understand how to Do all the but that's old guy talking. So Cort (02:11) It's a weird place, Brian. I don't blame you. It's totally good. But I've seen a few things come across my feed, and we've kind of had lighter versions of this conversation, whether it's in classes or just kind of on the side or something like that. So we just kind of thought, hey, let's sit down and actually go into depth about this, because I'm curious what your thoughts are on some of these things. And I don't know. Brian Milner (02:14) Yeah Cort (02:35) Hopefully I'm able to add into the conversation a little bit more than just here's a young guy yelling at a cloud instead of an old guy yelling at a cloud, right? No, I hope not. But let's come out and I'm gonna come out swinging at you. So the biggest news bite that I have found over the last couple of months or the last month-ish is that the Agile Alliance and PMI Brian Milner (02:37) Ha ha. young guy and old guy yelling at each other. That's not what anyone wants to hear. Yeah. Yeah. Cort (03:02) have entered, have announced that they're entering a partnership. We don't really know a ton about what that partnership looks like, but it is presumed that the Agile Alliance will be hosting some kind of content through PMI or PMI will be hosting some kind of content that the Agile Alliance has created. So I'm just curious, like, what are your thoughts on that? Do you think it's a good move, bad move, any kind of potential impacts that you see? It's a big one. Brian Milner (03:30) Yeah, way to start with a softball that we just, yeah, mean, it's obviously a hot button topic right now. I've heard lots, I've read lots of opinions of people on different kind of forums and discussion boards and things where people are talking about kind of, what does this mean? That kind of thing. And so here's kind of, Cort (03:34) Hahaha Brian Milner (03:57) Here's kind of what I've heard from both sides, right? The people who are kind of anti feel like this is maybe a little bit of a betrayal. And I think that the reasoning behind that kind of feels like maybe historically or somewhere maybe further into the past, the PMI may have been a little bit of an antagonist towards the Agile movement, or some people feel that way. I'm not saying this is my opinion, but this is what I've heard. Some people might feel that way. And so they feel like, would you attach your name to something like that? But I've also heard from people who are pro and have said, look, the basics of the deal are that it's not going to change anything for the Agile Alliance other than the name. It's officially the PMI Agile Alliance. But other than that, what I've heard from people who are board members that have posted Cort (04:43) Sure, yeah. Brian Milner (04:50) from the Agile Alliance have said, it's just nothing more than our name is now different. We're autonomous. We can still do the things we've always done. And we feel like the connection to this larger organization will enable us and help us. And I know the Agile Alliance has gone through some tough times, as a lot of us in the industry have, with the conferences. At least I know the conferences last year was kind of not what people have hoped, and not just the Agile Alliance conference, but other conferences have had down attendance and other things. Maybe just a sign of the times, I don't know. But personally, I kind of look at it and I got to preface this. got to, before we talk about anything else, right? Because now we're going to get into opinion. But I would just say, let me preface by saying the opinions you are about to hear. are not the official opinions of Mountain Goat Software. They are just the opinions of the individuals that you will be listening to. So this is just one guy's opinion, right? I think I would just say I get it from both sides. I understand. I see kind of the concern. From the people who are pro and they say, look, it's just the name, I don't know why anyone would freak out about that. It's just a, we're just putting letters PMI in front of our name. hear that, but I've also heard other people counter that to be like, yeah, but it would be like Greenpeace saying, you know, we're now Exxon Greenpeace, you know? And I don't think, I think that's quite, you know, a huge overstatement. I don't think that's the same thing at all. And I, you know, I recognize that the PMI has, you know, they've adapted. anyone who thinks that they're the same way that they've always been, I think is wrong. I think that they have incorporated over time more and more agile ideas into their certifications and other things. they certainly, I feel like they've recognized the agile sort of the future and they've tried to invest more heavily. I think this is a sign of that as well. They're trying to invest a little bit more into agile because they see it as, you this is the future of project management. You know. But they also see it as one of the paths. It's one way of doing project work. And it's not the only way. There are other ways that are good as well. I don't know that I disagree with that. Depends on the project. It depends on what it is you're trying to do. But we talk about this in class. If I know what it is that we're going to make, I know exactly how to make it, the customer knows what they want, and we're not changing anything along the way, then Cort (07:02) Yeah. Yeah. Brian Milner (07:16) Agile may not be the right way. But if any of those things are not true, then I think Agile is the right way. end of the world, no. I don't see it as the end of the world. I don't see it as the sky's falling. I think it is a sign of the times. I think it is sort of a benchmark kind of thing to say, wow, things have reached this point where they've joined forces. I think that's not an indication of either side bending a huge amount, but that both sides have bent and met in the middle. And that's kind of my opinion on it. The sky's not falling, but I don't really know how it will change things moving forward. They tell us it's not going to really. We'll see. Cort (07:58) I think I agree with a lot of what you're saying. And that's what I've seen as well amongst the social media spheres. Kind of a lot of discourse of, this is really bad, or, this is not as bad as you think it's going to be, or, this is actually really good. Because I think one point that I agree with a little bit more so is, in principle, at face value, This might not be what the Agile Alliance was founded on or anything that goes, or I wouldn't say anything, but it doesn't align with the foundational values of the Agile Alliance. But in the long run, I think this might be pretty beneficial for Agile as a whole, because PMI is massive. They have a huge reach, very big name recognition, and for them to acknowledge, not only acknowledge, but acknowledge in this way and bring in Agile into this space within their reach, I don't see a ton of harm that could really be brought to it purely on the basis of our reach, PMI's reach is significantly larger than the Agile alliances. So it just helps Agile grow a little bit more so and get a little further reach. Do you agree with that? you disagree? Thoughts on that? Brian Milner (09:14) Yeah, I mean, I've heard Mike say this before, where he says, you we talk about partnerships, you know, who's bringing more to the table? Is the Agile Alliance funneling more attention, eyeballs to the PMI by this Alliance, or is the Agile Alliance getting more eyeballs and more attention because of the audience of the PMI? I would think it's the Agile Alliance is getting more. Like you said, I think the PMI is a huge behemoth, pretty highly recognizable. their certifications have been out. They're kind of one of the first of those kinds of certifications that existed out there. And I just think that they're probably bringing more to the table to the Agile Alliance than the Agile Alliance is bringing to them. Cort (09:56) Yeah, yeah, the Agile Alliance is kind of getting the better end of the deal, so to speak, as far as exposure goes. Brian Milner (10:00) Yeah, but I think time will tell. I think that's really what I would say to anyone is just don't freak out too much yet. You need to just wait and see what will happen. When the moves happen, if something happens, it's like all of a sudden now the Agile Alliance can't in any way talk about how traditional waterfall is not a great way of doing things. Well, now I would raise the alarm and say, OK, well, now you see the compromise. But if that doesn't happen, if it truly is, as I've been hearing, it's just a naming, we're autonomous, I don't see the grave harm. Cort (10:33) Right, right. Right. I think one thing that's kind of overlooked or maybe just a little glazed over that people didn't pay too much attention to is they didn't announce this as a merger. They announced this as a partnership. So to me, when I hear partnership, hear two entities working independently with a common goal of whatever it may be. Brian Milner (10:54) Yep. Yep. Yeah, a little insider baseball on that because I have heard some discussions around that as well. And just what I've heard is, there is a trickiness there because the agile Alliance is a nonprofit organization. And so from a for-profit organization, you cannot acquire a nonprofit organization unless that nonprofit organization changes and becomes a for-profit entity. Cort (11:28) in for profit. Yeah. Brian Milner (11:31) I'm not a lawyer. I don't know any of that kind of insider, the legalese that's around that. But I've heard a little bit of conversation around the fact that it might have been an acquisition had they been a for-profit company. But since they were a nonprofit, it's a partnership. So that may be the case or not. I don't know. Cort (11:50) So that brings up just a question to me then. A lot of times when companies merge, they tend to merge as either an industry or a sector is kind of starting to go down, trickle down a little bit. And they merge as a method of of like bulking up, strengthening where they can, trying to... that they acquire, they merge in order to withstand the rough times. Do you think that that might be what's at play here? Where just from a business perspective, this is kind of the business smart move for both entities, both organizations, so that they can withstand, I think I saw somewhere like a 35 % reduction in middle management positions, postings or something like that, right? Brian Milner (12:31) Yeah. Yeah, absolutely. mean, I think, the, the past few years have been kind of difficult economically. please don't think I'm being political and saying that at all. I'm just, yeah, I can only state what I've, I've seen and heard from other people in the industry. And I've, you know, I've heard about people talking about less job postings, those going down. I've heard about, know, trainers and coaches and other things. you know, losing percentages of their students or their coaching engagements or other things. So I've just heard that it's been, and we've kind of experienced some of that as well, decline a little bit. I don't think it's that one of those two entities had a decline. I think they both are kind of recognizing this is a tough economic climate and strength in numbers. You know, if we can support each other and maybe that's the path forward is that we kind of combine forces and combine and conquer a little bit. So I think you're right. I think that may have forced it and it's just the opportunity presented itself. Cort (13:37) Just kind of a contextual thing where the context of kind of where we're at right now. That's really what drove it. Yeah, I can see that. could totally see that. Awesome. Well, let's jump over to our next kind of topic right now. Everyone's favorite topic right now, AI, right? We've talked about it substantially. But kind of with that whole idea of Brian Milner (13:52) Sure. Yeah. Yep. Yeah. Cort (14:03) or that little note that we had there of these mid-level management positions, we're not seeing them rise in open positions. We're kind of seeing them get squeezed down a little bit. We're seeing them reduced. And a lot of that is attributed to AI, where a lot of these mid-level management positions are tasks that can be done by AI, because a lot of it is kind of this data analysis stuff and what do we move forward with? Relating it to Scrum specifically with AI being on the rise and Scrum Master roles appearing to be bringing less value as a result, because I think you've seen it, I've seen it a lot. A lot of my friends are talking about it. I've seen it a lot on social media. Actually one Instagram reel that sticks out to me right now is someone was like, hey, do you want to get into tech without having to learn how to code, be a scrum master. It's super easy. You just take a two day course and you're going to make $110,000 a year or whatever. And it's like, you know, little tongue in cheek, but at the same time, I think there's some truth to what that real was saying. Um, however, with that, I think a lot of scrum masters are being shoehorned into roles or have been shoehorned into roles of. Logging meetings. creating meetings, facilitating those meetings and then entering in the next one and saying, Hey, everyone has to show up here and, you need a story point this. I need point values for this bug before we start working on anything. and a lot of that seems to be replaced with AI or at least is able to be replaced with AI. So Scrum Masters now are in a position where they have to drive more value. where, where do you think Scrum Masters? in their role can bring more value? And do you know of any resources that are either widely available, freely available, available at a lower cost to help Scrum Masters learn how to actually bring more value to their role? Brian Milner (16:04) Yeah. Well, the first thing I'll start off in saying is, you know, one of the great things about living in today's world is there is so there's such a wealth of information that's free. You know, I can learn how to do, I can learn how to cook anything in the world by just finding the video on social media and not all of a sudden, you know, I've got everything I need to make a great dish. I may not taste the same as the person who did it, but you know, I can learn how to do pretty much anything. I can Google, you know, how to You know change out my doorbell, which is one thing I did over the holidays You know like that's the kind of thing that there's a full video showing exactly it step-by-step Here's how to do everything and and I think that you know for Us a scrum masters. There's there are some skills. I think that are gonna be More and more relevant more and more needed and I think you just have to put yourself in the frame of reference of what would AI do a good job of? this is such a answer because if my job as a scrum master is to just schedule meetings, well, then yeah, I'm in trouble because an AI can do that really easily. And you don't even need AI for that. All you just need is to have people enter when they're available. There's dozens of websites where you can do that. do that. My D &D group does that to try to find the nights we can play. It's easy to do that, and you don't need any AI for it. So if you reduce what a scrum master is down to something as simplistic as let's schedule meetings, well, then yeah, you're in danger. I think what's going to happen is that more and more, it's going to be the soft skill kind of things that are going to differentiate the Scrum Master profession. I think that AI is going to have a hard time with managing interpersonal relationships. It's going to have a hard time helping the team navigate through conflict. It's going to have a hard time picking up on details, how safe does the team feel, how well are they working together. AI can do certain things really well, but there's a reasoning that's not there now. I don't know if that's coming. I don't know if that's tomorrow, if that's 10 years from now, or a year from now, or six months. But I know that now, even though they say thinking or other things like that, it's not really thinking. It's just digging up more data. And it can process a large amount of data and give you some insights from it. That is something that it does well. but it can't intuit, you know? It doesn't have emotional intelligence. And yeah. Cort (18:47) Yeah. Yeah, think one spot or one really good definition of where AI is fantastic that I read recently is AI is absolutely incredible when there is a set of very clear specific rules. So the book that was reading that said that they use chess, example, right? Where chess has a very, as a set of very specific rules. and AI can beat any grandmaster easy. Really just like chess.com can beat any grandmaster at this point, right? Because it's able to analyze potential outcomes based on a set of rules and a scenario that it's given in. Whereas a lot of humans, we think, or a lot of human chess grandmasters, they think in a way of like, here's one specific strategy that has worked in this scenario. I'm going to go that down that route. So AI can inference, so to speak, they're going to go down this route because that's what has happened in the past. And based on that set of rules that has happened in the past, here we go. So I think you're entirely right with those softer skills where you're interacting in a space that has some guidelines, but not necessarily a set of clearly defined rules is where AI is going to struggle right now. Absolutely. Yeah, totally. Brian Milner (20:07) Yeah, I'll tell you, Cort, too, one of the things that I'm really interested in, and I've talked to you about this and some other people, I'm really interested to see how AI, especially for coding, because more and more coders are taking advantage of coding assistants. And there are some stories out there and some companies that are more and more reducing the reliance on a person to code and using more AI to do coding. Some claim that they can do it all with AI. I would be really suspicious if there's no human involved at all. But what I'm really curious about is how does it change the process? If you are using an AI coding assistant, Does that change any other part of your process? How do you verify that the code that the AI has produced is correct? Is there a pairing? Is there a peer review of that that the team does? I suspect that there's practices and things like that that are popping up all over the place that just haven't been codified yet. There hasn't been a white paper that says, here's what you do. to try to ensure that it matches well with the rest of the code or here's how you know that it matches your standards or other things. I suspect that there's plenty of those kind of things out there and I'm just kind of waiting to hear those reports. Cort (21:25) Right? Yeah. Yeah, think, gosh, was, was Mark Zuckerberg was on the Joe Rogan podcast not too long ago. and he was saying like, yeah, by the end of 2025, Facebook is already doing it or Metta is already doing this. Sorry. Metta is already doing this where they're starting to replace their mid-level programmers, their mid-level developers with AI. And Zuckerberg was saying like, it's expensive right out of the gate. Brian Milner (21:54) Yeah. Cort (21:59) Right. It's going to be a lot of time, but we see the value in this long-term. so I wonder if, if that white paper is going to come from either meta or alphabet or one of those ones, right. Brian Milner (22:09) Yeah. Well, the domino effect of this is also going to be fascinating to watch because you said that they're talking about mid-level. I've heard a lot more about junior level being replaced, Like the entry level kind of stuff. And so, okay, let's say you do that, right? And you're hanging on to your senior people who have the experience. What happens when they move on? Right? When those senior people are gone, you haven't had anyone coming up the pipeline because you replaced it with AI for the junior stuff. And you're depending on more senior, more skilled advanced people to verify, to go through and fix the issues that AI is producing. They're going to be gone. They're going to retire. You know? So I don't know how that, that will be my first question to someone like Zuckerberg about that. Cort (22:54) Right? Yeah. Yeah. Brian Milner (23:02) when they said something like that is, what's your continuity plan for moving up programmers into more senior skill level? How are you going to build that into your long-term process if you're going to replace junior and mid-level people with AI? That's going to be a train wreck that's going to happen at some point. Cort (23:27) I, cause a lot of times we talk about in courses or I've heard it a few times and I totally agree with this and subscribe to this idea that the goal of a scrub master is to work themselves out of a job. So I wonder if it's that kind of same kind of mentality that these bigger tech companies have with AI of, know, AI is going to work a developer out of a job or a developer is going to work themselves out of a job through AI being able to. code better than them, faster than them, be more precise, stuff like that. However, caveat to that, Mike was the one that said the goal of a scrum master or a good scrum master should be to work themselves out of a job, comma, I've never seen that happen. So Mike has never seen that happen, right? I don't think you've ever seen that happen. I've never seen that happen. I don't think anyone's really ever seen that happen. I don't think any scrum master has successfully done that. Brian Milner (24:10) Right. Cort (24:20) so I wonder if it's going to get to that, that kind of same point where it's like a developer will never work them themselves out of a job. It's just the cost of entry to a good developer job or to a developer job as a human. Just got up a little bit more, right? Where, where those senior positions are the only ones open. So you gotta create whatever experiences you can. Right. Brian Milner (24:42) mean, should, in reality, it should be like any other tool that people use to do a job. And it should be the kind of thing where, hey, now we have calculators, and I don't have to manually do the computations on my own. Does that mean that I don't need the reasoning and logic of knowing which computations to make? No. Someone still needs to know how to do that kind of thing. And I think that's how it shifts a little bit is. I don't know that it ever, I shouldn't say that ever. think it's, my, I'm not an AI expert, but my experience dabbling with this kind of stuff and reading articles and talking to people in the industry is that it's not there yet. It's, it's, it's good. It does a good job at, you know, being an assistant level, co-pilot level, that kind of thing, but it's not. Cort (25:29) Mm-hmm. Brian Milner (25:32) hey, let's fire our 10 developers because now we've got an AI that will do exactly what they did. It still takes reasoning and logic to know which path to go down, to ask it what to do. And I think that's just how it shifts a little bit is now there's a tool that does the more mundane part of that, but we still need the information, the logic, the reasoning to design it. Cort (25:44) Right. Right. Right. Yeah, totally. This this reminds me a lot of your conversation that you had with Lance. It's the first episode of twenty twenty five. You and Lance sat down and talked about AI and hyper hyper personalization. AI being used as a tool, which you and Lance discussed fairly thoroughly. You guys went into a little bit of depth about that. It's a tool that delivers value, but where do you think it's delivering value to, or who do you think it's delivering value to? Is it developers, the company as a whole, customers? Where do you see that value stream starting? And do you think it could eventually get to somewhere else, deliver value elsewhere? Brian Milner (26:17) Yeah. I mean, it's kind of like to me asking like, how do you, where do you see streets and roads and highways deliver value? know, like it's, there's a million places they deliver value. There's a million industries. There's a million different things that they do. And I kind of see AI, you know, as a much, much, much more advanced version of that. But just to say, they're, Does it deliver value to customers? Yes, it delivers value to customers. It might make their lives easier or make it more simple to get to what they need. Does it deliver value to the organization? Sure, it delivers to the companies because it's going to help reduce time to market and speed and maybe cost as well. Although cost, we'll see. That's kind of an interesting thing because, you know, Cort (27:26) huh. Brian Milner (27:33) You read lot of articles about how OpenAI is not profitable yet. And it's taking a huge amount of data, a huge amount of data centers, a huge amount of energy. So that runway runs out at some point. And even charging $200 a pop for their pro model a month, it's not profitable. I mean, they say that membership level is not profitable right now. Cort (27:46) Right. Right. Yeah. Right. Right. Brian Milner (27:59) So that doesn't continue forever. At some point, that money runs out. And when that does, how does it get paid for? So will it reduce costs by that point when that runway runs out and the consumers of the AI product have to pay the real cost of what it takes to run it? I don't know. Hopefully, it goes down by then. Cort (28:18) Yeah. Yeah. In that same episode with you and Lance, you talk a lot about AI as a tool, right? And it's not something that you are scared of personally because it is a tool and you view it as a tool and an aid to you being more productive. I'm just curious your thoughts on, let's take it back over to our scrum masters, right? So. someone starting out as a Scrum Master role or recently got put into a Scrum Master role, how do you think that AI can be used as a tool to aid Scrum Masters? Do you think it should take over kind of backlog prioritization so that Scrum Masters can focus a little more on those interpersonal connections? Do you think it should take over managing meetings or running meeting ceremonies so that Scrum Masters can focus on more important things? Brian Milner (29:10) I kind of, the hair on the back of my neck goes up a little bit or I cringe a little bit about the words take over. Because I'm not sure there's anything I would say that it should take over right now. I think that there are some things that it can assist with and do a better job. Like it can, you can offload the manual portion of doing that to the AI. But you know, yeah. We've talked about scheduling meetings. That's an easy thing for something like AI to do. And it does a good job. One of my favorite things that I've learned is you can dump a bunch of data into it and then ask a big open-ended question like, what are maybe some insights from this data that I'm missing? What are some key? Cort (29:37) Right. Brian Milner (29:54) takeaways that I should have from this mass of data that you sort through. And that's a really good job of interpreting that kind of thing for us. So I think it's those kind of things that, from a Scrum Master perspective, I think you can probably use it to do a lot of things like charting out velocity and tracking other trends in our velocity. Cort (30:00) Right. Brian Milner (30:15) or the trends in other data maybe that I collect for my team that I'm not aware of. I think it starts to fail a lot in the creative areas. I'll just give you a practical example from my standpoint. I spoke at couple of conferences. I try to speak at conferences on occasion. And when you do that, you have to submit papers of saying, here's what I want to talk about. I cannot use AI and go to it right now and say, hey, Cort (30:34) No, Brian Milner (30:37) I want to speak at conferences next year about AI or about Agile and Scrum kind of topics. What are some ideas? What are some things I can talk about? It's not going to give me anything that's worth anything if I ask that question. But if I already have the idea, it can help me flesh out the idea. It can help me kind of with the way I present the idea. But the idea is mine, right? Cort (30:49) Right. Brian Milner (31:03) And I kind of think that's the thing is from a Scrum Master perspective, use it for the things that would take a lot of manual time to do. But you have to know your stuff to know that you need that thing. Cort (31:12) huh. OK, so yeah, just speaking out loud here, use an AI as like, hey, I'm noodling on this idea to get a little more engagement in our daily standups. Walk me through how this would go, or something like that. Brian Milner (31:34) Yeah, I mean, there's some particulars there. you probably want to prompt it to say, you know, I want you to act as an agile expert. Ask me all the questions that you need to ask me about why my daily scrums are failing and help me figure out, you know, three next steps I could take to try to improve the daily scrum of my team. That would be the kind of prompt I would enter. and kind of hear what the question, let it ask you questions, let it refine it a little bit, and it'll give you some things to try. Now, maybe only one of those things is worthwhile, but if you have one of them that's worthwhile, it's worthwhile. Cort (32:10) Yeah, yeah, absolutely. Right, totally. Cool. Let's step away from AI real quick. I got one more question for you. And this can be like a, yep, we'll wrap it up after this one. One more question for you. And this was actually from the last episode with Scott, where the whole idea of it was you need to be nice by being honest, realistic, and I put in quotation marks, mean. Just being nice by being Brian Milner (32:16) All right, then we got to wrap up. Cort (32:35) Brutally honest, I guess in a good way of putting it when So again as the younger guy in this conversation as the one who doesn't quite have as much experience in having potentially career altering conversations as I like to call them When should I bring those up when should I be that kind of mean nice guy? Is it any time that I have my my foot in the door of? the CEO or someone who has a little more pull? Is it, should I only do it when I'm prompted or is there some other time that I should be bringing up these topics that are probably important, but you know, not the nice guy way of bringing them up. Brian Milner (33:13) Yeah, we were talking about the thing that I mentioned about the scenario where the guy found himself in the elevator with the CEO. And yeah, I do think there's an important kind of thing to keep in mind there where, you know, businesses are gonna expect you to kind of follow the chain of command a little bit. so, you know, I think you've got to balance that in with this. I'm not saying that you should... hey, everything that you think might be wrong in the company, go schedule a meeting with your CEO and go run and tell them. Like that's gonna make everyone between you and the CEO really mad and your CEO really mad, right? You gotta follow your chain of command a little bit. If I have a manager, I wanna be always kind of frank and honest with my manager so that they know they can trust me, that I'm gonna tell them. Cort (33:49) Yeah, yeah. Brian Milner (34:02) the reality and there it's just how blunt are you? How much do you soften when you say those things and try to say it in a polite way rather than saying, this sucks. You have to be able to play that game a little bit. But I I think you should always be honest with the people in your immediate chain of command. Cort (34:13) Right, right. Brian Milner (34:24) you, there's no, you know, definitive line about when you overstep that and go above and beyond. You kind of have to interpret that yourself. You can't do it too often, but if there are times when you feel like something is vital and it could actually have a real negative impact on your business, then, know, occasionally maybe it is okay to then go out of your chain of command and say, I just think this is really vital. And I think the company needs to know this. So I've kind of gone out of the normal chain of command. You're going to make the chain of command mad when you do that. So you have to weigh that and say, is it worth it? Do I feel like I can defend that I went outside the chain of command in this instance? that people won't see it as I'm always going outside the chain of command, but this was important enough to do it. Cort (35:10) Sure. Right. Okay. Awesome. Well, thanks, Brian. Thanks for getting that last one in there. Yeah. Brian Milner (35:18) Yeah. Yeah. Yeah, yeah, no, this has been fun. And we'll do this more often. We'll have some check-ins and try some more experience experiments. All right. Cort (35:30) Awesome. Well, thanks for having me on. Thanks for letting me ask these questions. thanks for a great conversation. I appreciate it. Yeah. Brian Milner (35:33) Yeah. Yeah. Thanks, Cort.

Give Us FeedbackIn episode 97 of the ACN podcast, we explore Agile's role in mergers and acquisitions (M&A), emphasizing the early involvement of Agile leaders to foster collaboration, transparency, and cultural alignment. Drawing from personal experiences, we discuss overcoming M&A challenges like resistance to change and cultural clashes through Agile's iterative, feedback-driven approach. The episode also touches on PMI's acquisition of Agile Alliance.Join Shawna Cullinan, Jörg Pietruszka,  Diana Larsen,  Sheila Eckert, Sheila McGrath, April Mills,  Hendrik Esser, Ray Arell, and all the callers to the monthly live event as we explore this topic.  For details on the next live event or how to support our show, please visit  acnpodcast.org.Support the show

Explore the implications of the Agile Alliance and PMI partnership in this insightful episode. Learn how it could reshape agile practices, improve leadership strategies, and challenge your perspectives on organizational alignment and adaptability. Stay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Following the PMI Global and Agile Alliance annoucement of merging effort together, A.Frédéric Joly, CEO of AFJ Solutions Holding Group have this to say on his special Podcast, this Wednesday, January 8, 2025.Here's the transcript: “Good day, everyone, and thank you for tuning in. Today, I want to address a significant development in the Agile and project management communities. On […] The post The Agile Crossroads: From PMI's Takeover to Building an Agora for Responsible Agility appeared first on Agile Lounge.

Join Alex and Bob as they discuss the latest merger between PMI and Agile Alliance! How will this impact your Atlassian Jira practice, your Agile methodologies, your scrum meetings, and more? Join our experts to find out! https://www.agilealliance.org/agile-a...

Today PMI announced that The Agile Alliance was joining PMI to form the PMI Agile Alliance. This is obviously going to cause a great deal of debate in the Agile and project management communities. I am very excited about what this could mean for the future of Project Management and Agile - and here is why.

In this episode of the Agile Mentors Podcast, Brian Milner chats with Murman about the value of attending Agile conferences, the importance of networking, and the impact of volunteering in the Agile community. They share personal stories, advice on making the most of conference experiences, and insights into how volunteering can open up new opportunities for personal and professional growth. Overview Brian Milner and Chris Murman dive into the world of Agile conferences, focusing on the upcoming Agile 2025 event and the benefits of attending. They discuss the evolving purpose of conferences, why networking and volunteering are crucial, and how approaching conferences with an open mind can lead to unexpected learning and connections. Chris also shares his journey from attendee to conference chair, providing a behind-the-scenes look at what goes into creating a memorable conference experience. Whether you're a conference regular or considering attending your first one, this episode offers valuable perspectives on getting the most out of these unique events. References and resources mentioned in the show: Agile 2025 Chris Murman Connect with Chris on LinkedIn Agile Alliance Speaker Submission Tips Webinar #105: Scrum Conferences & Neurodiversity with Brian Milner Special Episode Scrum Gathering Denver 2022 Mountain Goat Software’s Accurate Agile Planning Course Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: 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. Chris Murman is the Agile 2025 Conference Chair with over 15 years of experience in product management and leadership, He has directed successful launches for top brands like Verizon, NBC Universal, and Chick-fil-A. As the Executive Director of Product at JP Morgan Chase, and leads 20 cross-functional teams, driving innovative financial solutions and spearheading AI/ML initiatives that save over 6,000 man-hours per quarter. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, a very special friend is here with us, Mr. Chris Murman. Welcome in, Chris. Chris (00:11) What's up, Brian? I don't know that I'm a mentor, but I'm here anyways. Brian (00:12) You're definitely a mentor. In fact, we're going to explain to people why you are here in just a moment. Chris is an Agile coach extraordinaire. He has been in the community for quite a while. And he is a fellow Dallas native here with me. And we connect a little bit at the last year's Dallas conference here for Agile. Chris (00:19) Okay, okay, sure. Sure, sure. Brian (00:40) And one of the things that I noted in that conference was they announced the next one, which is coming up in Denver, end of July, beginning of August -ish, we'll put it that way. And he was announced as the chair of that conference. So Chris is actually going to be in charge or leading or behind the scenes for just about everything that's going to take place at that Agile 2025 conference in Denver. So I wanted to have Chris on to talk about that a little bit. Don't think of this as an ad. It's not an ad for it because what I wanted to kind of help people understand was kind of the why behind it. When I normally talk about the conference, it's maybe a month or two before. Well, now it's next summer. So you have some time to plan. And now is the right time to kind of put that kind of stuff in your calendar if it's something that you're thinking about doing. or even maybe thinking about maybe should you volunteer or something like that for it. So Chris, how did you get involved with this kind of thing? How did you get involved with helping out with the conferences? What made you decide to help out in any way, shape or form? Chris (01:54) Well, like many, when I first started the work, I I fell into Agile backwards just like everybody else did. None of us did this on purpose. It just came along and we just started doing it and then it became something to do. in the 2010s when Agile was riding high and I... I saw these conferences as really cool learning opportunities and connection opportunities. People that I knew from the, that you and I both know from the local area, from meetups, would tell me about these conferences. I was attending DFW Scrum the last time that Agile 20XX was in Dallas. I did not go, but. cause I, was too late for me to find out and it was kind of pricey. And so I was like, so like conferences are where you just go and meet people and then they're like, yeah, you should just kind of go. So as, as with many of us who are like, well, how do I pay for these conferences to go? just said, well, I'll submit to speak. And, I don't know about you, but my first few submissions were not great. I, I, I. People always laugh when I say this, but I would literally copy and paste the headline and the entire copy of blog posts that I thought would be really cool to talk about. Because I started my blog, that was kind of how Chris Murman .com is kind of how people first started meeting me because I would promote it on platforms and stuff. Agile Twitter used to be really fun back in those days too. So I would just copy and paste the entire blog post as my abstract. And of course, now knowing what I know, like that was, that's just the worst thing to do in the world. but I didn't know what else to do. So I fell flat on my face the first few years and started getting some advice and feedback and such, and started getting accepted to speak around 2016. Spoke at. Spoke at several conferences that year, spoke at several conferences in 2017. 2018 comes along and they're like, and I'm like, hey, how do I help out? Like this is really cool. I connected with the Agile Alliance community, that specific conference community very, very well. And I'm like, well, how can I help? And they're like, here's three or four people, email them until they say yes. And I'm not. Brian (04:18) Yeah. Hahaha. Chris (04:34) I just was annoying and said, no, I'm not kidding. I want to help. And I got to chair a track. You know, I chaired all kinds of tracks for the next few years. coming out of COVID, I got asked to be on the program team. which is just when people are like, what's the difference between leading a track and leading like the entire program? Think of it as like, The track is like one tiny, tiny sliver in the program team has to go really very narrow across everything to know where everything is. Not that I know every set. I still, I'm like, that was that session was the conference that year. But, so we just have to be more broad in what are the themes that we want to talk about? What are the things that we want to do? and, and, you know, when you join the program team, you know, one of these years it's going to be your year. And then when you. when you're a conference chair, that's your final year on the program team. And then you just go back to civilian life, I guess. I don't know, which is, don't, I don't ask Dana. I don't know what civilian life is on the side of the conference just yet, but I will very soon. So I don't know. It's a, that's a rambling answer, but it's for the most part, that's really how I got going was just, I just wanted to go. You know what I mean? I just wanted to be there. And the only way I could do it was to get a free ticket. Brian (05:34) Ha ha ha. Yeah. Yeah, yeah, that's a, well, that's a great answer. I mean, I, I think I'm kind of, I mean, I probably have a little bit, there was probably a few more years I submitted before I got accepted to speak at the Agile Conference, but I probably submitted three or four years before I got something accepted. And that's even after reviewing a few years and seeing what good and bad submissions were like, you know, and trying to understand that. Chris (06:22) Thank Brian (06:25) But we were talking a little bit beforehand about just the concept of a conference in today's world. I know that we've seen sort of a decline in people who are attending conferences a little bit. And I'm not really sure whether this is a momentary thing or an economy -based thing or what. But when people ask you why attend a conference, what What do you tell people? Chris (06:55) Well, there's many things that you can get out of a conference. That's the cool part about it is that you can attend the conference for many reasons. And I would say now in 2024, coming into next year, 25, I don't know that the reasons for attending the conference are the same as they used to be, right? Because when we first started coming, there's this like, I don't mean to sound pedantic or like over inflate myself, but there's a level of like fame in our community. We have a tiny, tiny community. So you can get agile famous a lot of different ways. Like now you can just be an influencer and write like Chris Stone is a perfect example of someone who just cranks out a ton of content that it's for the most part pretty good and get the following that way. And then people meet you that way. Brian (07:27) You Yeah, yeah. Chris (07:53) there were a lot of ways that you could meet people back then. you could really meet a ton of people there. You could make a ton of connections. So ultimately, I just really wanted to learn. I love learning and I love being connecting with other people. I did theater as a kid, was performing at church as a kid. I was just that person that was always on a stage. so speaking is just another extension of that. You being in a training room all the time, again, it's just a performance. You're just giving a performance where there's hopefully... a few nuggets of wisdom. When I realized that that's all that it was, well then I wanted to do it. You know, I don't think that, but I don't know that that's the same anymore. I don't, you know, I don't hear people say, I learned a ton at this conference every year, right? Because a lot of work, we're, Brian (08:39) Right. Yeah. Hmm. Chris (08:59) we're rehashing the ideas in a new way. We're trying to explore things in a new way, but we're really kind of taking many people feel like that we're just taking the same rock and turning it over and just getting seeing if we'll be surprised the next time we flip the rock over, right? Like there's only so many times you can flip that rock over before you don't find anything new anymore. So, I, it is interesting to think about why do we What is the purpose of a conference? You know, because do you want to be known so you can get paid, right? Or get a job? You know, there's a lot of people that want a job. So can you get a job by going to a conference? I don't know. I don't, there weren't a lot of jobs in 2023 to hand out. There were some to be had this year. If you attended the conference and were looking like there were several people that had things to talk about and interviews to be had. Brian (09:28) Yeah. Chris (09:55) some of the jobs are starting to come back. like, okay, well, do you go because you want a job or if you're learning, like, well, what do you want to learn that you can't just learn from watching YouTube or TikTok or, you know, attend like, as you know, training classes are also struggling in the community. like, what is what what is learning in 2024 2025 in the agile community? I think it's worth thinking about, you know what I mean? Brian (10:23) Yeah, no, I agree. And I think, from my perspective, I think it's changed a little bit. It's shifted a little bit over time. I think when I first started to go, there was an idea of, yes, I wanted to network and I wanted to understand and meet other people in the community. But as an introvert, I, you know, that kind of scares the crap out of me. And, you know, I can only do a little bit of that before I just feel like my battery is completely depleted. But, you know, when I think when I first went, I did have the idea that I wanted to learn. wanted to kind of be on the cutting edge. I wanted to hear the cutting edge thoughts of people who were out there. And, you know, now I think I still have that mentality when I go, I still want to hear, you know, I want someone to challenge me, you know, like that's, what I really want to hear from, from a speaker is tell me something about this. don't know, or tell me something that, you know, would challenge my, my existing way of thinking about this. so that I can go back and examine it and think, huh, I never really thought of it that way, but maybe that's true and maybe I need to re -examine that. But you know, that's kind of rare. That's not something that you get from just a lot of talks. I know one of the things I try to do when I give a talk is I wanna end with something that I would say, hey, what's the one thing you commit to changing as a result of this? Like what's the one big idea? What's the one... If you left this room and don't remember anything else, what's the one thing that you wanna just star or circle in your notebook and say, I'm gonna go find out more about that or I'm gonna do something about that. And that's where I try to kind of drive toward the whole talk. But I've been in others that, like you said, maybe a little bit more of a rehash of something I've heard before. But I've never left a conference without feeling challenged in some way, even if it's not, even if it's just from a one -on -one conversation that I've had with people, you know, I've been challenged about ideas and had to go back and re -examine and think through things. I'd say it's more, you know, now my balance has shifted. It is more networking now for me than it is that challenging thought, but I still want to find that nugget somewhere in there in the conference time. Chris (12:41) So what you said is really interesting and I want to hone in on the specific words you mentioned about challenged, right? the, I do want to, you know, before it sounds like I'm not poo -pooing the idea of conferences in any way, shape or form, but what Brian just mentioned is something that I tell the people all the time. I said it from the stage this year in Dallas, which is like, you get out of it, what you put into it. If you come in with a beginner's mind intending to be challenged, intending to have your assumptions questioned and said, maybe I didn't think about this the way that... I would say that that's probably the thing that I learned every time is that something that I thought was true or wasn't true may not, right? Brian (13:11) Yeah, yeah. Chris (13:35) You know that half of the conferences are new people every year, right? There's someone new to agile every every year there are there. Thousands of people new to it every year. That's the cool thing about it is that every year there are people that like I just got my CSM like holy cow. That's so like can you imagine showing up to a conference and everybody's like this sucks. I don't want to be here like you're not going to learn anything. I don't get anything out of it like what an awful experience for. Brian (13:35) Yeah. You Chris (14:03) someone that's new and excited and just wants to, like, there will be something you haven't heard before. But for the most part, the reason why I always get something is because I show up expecting to hear something I haven't heard before. The story won't come out exactly the way you think, right? Or, Brian (14:09) Yeah. Chris (14:22) the story that they tell, because a good conference is always a great idea plus you, right? It's your stories, your experiences, how this affected you that matters. So sharing your soul, bearing your soul requires the audience to kind of be like, want to be, I want to have someone, you know, kind of bear themselves to me. I want to hear someone be vulnerable. Brian (14:45) Yeah. Chris (14:48) And those are always the best sessions that you and I always have, is when someone is super vulnerable, super vulnerable with where they are. I thought this was the only way to do this. That's my favorite is when I hear a speaker say, I thought this was the only way to do this. There are so many roads up the mountain that we have for our work. There is not one way to do it. So find a new, come to find a new one. There's a technique that you've probably not tried before or done, or if you have, you didn't do it the way that they did before, that'll seem easier. that's the whole purpose of listening to these things, but it, it, it requires you to show up with more than just here's my tray, man. I have some agile, please. Right. Like that's, this is not a buffet, right? Like you have to like, go find it, right. Seeking positive intent means I have to go seek it. Right. I have to go seek information that I want to have. Brian (15:21) Yeah. Hahaha. Chris (15:41) and then go get it. Because if I don't, I'm just going to go, yeah, it's cool. I mean, I met some cool people, but I didn't really. OK, well, then you didn't show up with the mentality of being challenged. I challenge our friends, people that have been coming for years, I challenge them every year. You will get something if you want to. Right? If you don't get something, it's because you didn't want to get anything out of it. Brian (16:01) Right. I mean, I think we're all kind of guilty sometimes of setting our conference path, choosing the sessions and things that we go to based on things that maybe we already have some familiarity with. And that sounds interesting. yeah, I researched that a little bit. Let me see what they have to say about that. I've tried to intentionally now try to find things that I have no background in. I have no experience in because those are the things that are really going to push me. Those are the things that I don't really have. any knowledge of or forethought on and I'm gonna be taken to a different place. I remember I used to be, I used to get this like really anxious, nervous feeling when I would find out I was wrong about something. You know, I'd be in a conversation at a dinner table with someone and they'd say, well, actually, you know, that's not the way to do it. They'd start to do something else and I'd start to feel kind of anxious about that. But now, now I've like, that's swapped for me. Now when I hear that, when someone says, no, actually there's another way to think about that. Chris (16:41) you Brian (16:57) I start to get excited. Like it's actually excitement in me because I start to feel like, great, wow, I didn't, this is something new. This is something I had never heard before. And now this is the point where I can grow and break through, you know. Chris (17:11) Well, there's, I mean, and there's people that we all, if we've been in these communities before, we can all think of someone that always challenges us, right? Like I can't have a conversation with Michael Sahota without him challenging something that I thought, I just thought was true. And I'm like, no, it's not like, or it might be, but not always. So there's always someone that's just like, Brian (17:20) Yeah. Yeah. Chris (17:37) sit down so that I can break your mind real quick. And that's always fun. You know, another thing to think about is like, what we get out of the conference also dictates who's going to pay the bill, right? Because we hear in the community a lot, well, companies aren't paying for conferences anymore. Brian (17:41) Yeah Mm, yeah, yeah. Chris (17:59) That's not true for some aspects of IT. Like all the developer conferences, companies love footing the bill for that. The Microsoft conference, they love footing the bill for that because they send technologists there that come back smarter and can code better and more efficiently and whatever, right? Like better, faster, cheaper, all those things, right? Like they will get something out of it. So the... think the reason why we have to say what do you want at the conference is like, it's gonna kind of dictate who pays the bill. If the purpose of Brian and I who have been to this conference many times and have met so many of the cool people, that's the best part of me going every year is I get to see Matt Barkholm again. Like one of my favorite people in the world that I do not see other than over Zoom, right? Or any number of people, right? Any number of people. Brian (18:47) Hahaha. Chris (18:56) There's always someone new that I had spoken to online but never met in person. Someone that just, again, someone that just started the work and someone that's like, hey, I read something that you wrote about this years ago and it was really cool. That's cool, right? You won't get that if you don't go out and network and stuff. But here's the thing, if you're there for connections, companies aren't interested in footing the bill for connections. They're interested in footing the bill for... Brian (19:23) Right. Chris (19:26) learn something, improve something, come away with something. And if Agilent are going to the conferences and just like, I met some really cool people, what else? I met some cool people. All right, cool. I'm not paying next year for you to go to that, right? That's what a lot of companies are trying to do. So we have to sort of imagine like, if the goal is to get companies to pay for people to go again, well, then we need to... That's something that we've asked ourselves in the program team. Like what would get, like what is a program that companies will reimburse for? I think it's, and I don't know that we've got a strong answer either. Everybody's got, I think, there's a lot of I thinks and not a lot of I knows, right? I guess is a good way to think of it. Brian (20:00) Yeah. Yeah. Yeah. Well, the other thing I wanted to kind of, because you are, you know, kind of the ultimate volunteer for this upcoming conferences as the chair, you know, I've tried to tell the audience here from time to time about the kind of the benefits of volunteering and why I do it as a speaker, why I've done it in the past as a reviewer. It seems like there's just so many different ways to get involved for something like this so that you don't have to just sit on the sidelines. You can actually be a part of this. And that's a, for me, that's an easy way to have a quick in with the community because you're interacting with people prior to it. So when you show up, it's like, hey, I know you and I know you, because we've been talking and working together on this stuff for a while. So. What kind of case do you make to people for volunteering for a conference like this, like a big conference? Chris (21:12) It's so again, going back to like, what do want to get out of it? I think the purpose of volunteering is to kind of learn how the sausage is made to a degree. if someone's like, I'm not really interested in seeing how my sausage is made, then you don't belong in the agile community. Like this is the community of people that want to see Brian (21:22) Yeah. Chris (21:32) Sausage being stuffed into its casing and just cranked out right like this is this is the community for that like I won't use any more sausage metaphors that although I The the The funny thing about how Volunteering works is that? Brian (21:41) Hahaha Chris (21:50) You can volunteer in the slightest of ways, just a few hours a week reviewing. When you're like, well, I want to review, that's fine, but I want to be a track chair. Because people always want to be a part of deciding the content. This is what I've always wanted to hear about. This is what I've always wanted to hear about. And of course, then I always ask the question of, OK, well, then someone has to submit that idea. all right, it's one thing to say, want to hear about this. It's another thing to say, how do I get that content out of a group of submissions every year, which we get thousands every year at the conference. And we got thousands, right? Like, you know, for all of the online hubbub over the conference every year over who gets accepted and who doesn't, like thousands of people submit wanting to speak every year. regardless of how they feel about whether they, when they get the rejection letter or the acceptance letter, like thousands of people want to speak at this conference. It's cool. Like it's a cool thing to do, but not everybody is a speaker, right? You can be a purple shirt and volunteer. In fact, some of my favorite people in the community are lifelong purple shirters that have done it multiple years. There are people that do it for a couple of years and meet people and then and they move on to another role. mean, there's just a bunch of different ways that you could be involved in doing something that doesn't involve speaking or deciding who speaks. And also, I will say, it's also really hard to cull thousands of submissions. into something that makes sense for everybody else. Because then you have to go find keynote speakers. There are people that are invited to speak who are luminaries in the industry. And how do you meet those people? So all of that is really like the fact that I can say I can email. any number of people, I won't use the name so I don't offend the people that I don't use, but like I can email any number of them and they're like, yeah, Chris, Agile, Agile 20XX guy. I, it would be cool if they're like, I just like Chris and I want to be friends with them, but you know, that's not the way the world works. so I, you know, networking in ways that don't always show up in a job or whatever is just, I'm, I'm just here to. Brian (24:00) Hahaha Right. Right. Chris (24:25) find good content and show the community that and the rest kind of takes care of itself, you know? Brian (24:32) Yeah. I mean, I'll say to, you know, just to give people kind of an idea of my path with the agile conference, you know, I probably submitted four or five years before I got accepted. And a couple of those years spent as just a reviewer for, you know, a track or, you know, with a certain team, not as a chair, but just as a reviewer. there's a, there's a, if you want to do that, you can do that. Right? mean, it's pretty much, it's easy to get into that kind of a mode if that's something that you're interested in. And I tell people who want to speak like that to me was one of the biggest and best educations I could have had on learning about speaking was reviewing what other people wanted to speak about. Cause you know, there's kind of two parts to speaking. There's the... the marketing side of getting your thing selected, and then there's the actual talk. But the part of trying to come up with your idea of the talk and frame it and put it in an interesting way and learning how to structure your talk in a way that would be interesting for people to listen to, that's a skill in itself. And the best way I learned about that was just reading others, reading what other people were submitting to do and... Chris is right. mean, there's so many submissions that, you know, even as just a reviewer for one track, I was sad for all the ones that I knew would not get to be heard because there's so many good ideas. it's, know, Sophie's choice about how you try to decide which one of these two things or which one of these 10 things, you know, you've got one slot and 10 of them that are 10 or 20 that are just amazing. and you can only take one, you know? So it's difficult, but reading those submissions to me was a really great education. Chris (26:33) Yeah, if you think about it this way, we always enter the room to build the schedule with, there's X amount of slots that we have plus X number of alternates and such. we always, you try to look at it like, like you look at the whole schedule and say, okay, is there an aspect of our work that we missed? Well, we didn't really get a, we haven't gotten a retro talk yet. okay, well there was one over here. So, cause you know, you're trying to balance it for like there's meat and potatoes kinds of sessions and then there's like the big idea sort of sessions. Then there's the workshops that are very engaging and meant to create something. Brian (27:16) Yeah. Chris (27:26) you know, there's a lot of, again, there's a lot of roads up that mountain. I would say that the joy of speaking now, if I could, anybody that wants to do it, the best advice I would say is like, you need to want to speak so that you can be a better presenter and organizer of your thoughts. Because, Brian (27:46) Yeah. Chris (27:49) Really, the abstract and the basic, there is essentially a formula to filling out a submission to a conference. I, with CP Richardson, who's now on the board, I did a webinar last November on what makes a good submission. It's something that I've gotten super passionate about. Again, it's recorded, it's on the Agile Alliance site if you wanna find it. There is a formula that anybody can follow and get selected, right? I had some, I had several people reach out and say, I watched your video and I follow what you said. And then I got accepted to speak, which for the record, watching what I say will not get you accepted to speak. You can follow the formula. You can, you can follow the formula exactly and still not get it because there's only so many slots and it's really hard to get in. but. Brian (28:26) Ha Chris (28:41) Once you follow the formula, then it's just down to like, does the idea resonate with the community? And I can't, I can't give you a formula for that because I'm not in anybody's brain, but, you know, I, again, it's always a great top, a great idea. Plus your stories and experiences is what really defines what a good submission is. And so you have to get that straight before you type a single word out. But then once you go through the submission process and there's edits, feedback, all that kind of stuff. Then you got to get accepted. Once you get accepted, then you got to build the session. And we find that a lot of times it's a rare breed of someone that knows how to write a good submission and can put on a good show. Not everybody can do that. And of course, a good show is a relative term, right? You don't got to be big and bombastic and loud to be good, right? Brian's not that and Brian's great in a room, right? So you can... Brian (29:16) Yeah. Chris (29:35) you have to kind of construct it in a way that makes sense. So, but again, the cool part is, that because I had people help me, mostly because I just annoyed the hell out of them and saying, please, please give me, please give me some help. I just want to keep passing it along. So I mean, I still get people at 12 months a year, I get people saying, I have an idea and I'd love to run it by you that they hit me up on LinkedIn or whatnot. So. Brian (30:04) Yeah. Chris (30:05) It's just something that I care about now. I got so much better with organizing my ideas and writing them and presenting them that it's a gift that I want to just keep passing on to people. I guess this is because I didn't intend this to be the cross that I bared, it is regardless. Brian (30:21) Yeah Well, the only other advice I'd throw out to people, there was a shift that happened with me too, where I went from, I want to be a speaker, let me find a topic. There's a very big difference from having that attitude to living your life and saying, wow, I'm really passionate about this. I'd love to talk about this. If you find the topic first that you resonate with and connect with, then it's, you you're a little more personally connected when you submit. So it can be more painful if you don't get picked, you know, when that happens. But on the other hand, when you do get picked, man, you're so excited about giving that talk. It's not just that you got picked, but it's like, I can't wait to tell people about this, this thing. And to me, that's, that's the magic. Like when that happens, you, you, yeah, you can't, you're, you're, it's not even nervous. You're, just so excited to tell people what you've learned about. Chris (31:21) Yeah, another piece of advice I tell people is as you're reading things, it doesn't have to be a book. It could just be an article or a video that you watch. As I always say, when I'm reading a book on something that has nothing to do, like I don't really buy a ton of agile books anymore. I buy a lot of social psychology, social economics, behavioral economics is a lot of my favorites. like Daniel Pink books is a tried and true. I met Daniel Pink once and he's like, what is it with you agile people that just love what I do? And I'm like, I don't know. I just, I don't know. I'm like, we just read it. So, but I read these books with looking for a lens into my world, right? I always read stuff that has nothing to do with IT. Brian (32:02) Yeah Yeah. Chris (32:16) that or leading teams or whatever it is your world, whatever you think it is. Find something that has nothing to do with your world and then say, how does that identify or how does that relate to my work? That's my favorite thing. I read a book on many years ago on, it was called The Control Heuristic. It was like where control comes from as an idea and psychology and why. We struggle with it. And I immediately turned that into a leadership talk on why we're all control freaks and here's, know, and what, what do we, what do we do about the fact that we're all control freaks? Like, again, I didn't read a book and say, I'm going to do a topic on a book. It's like, no, how does that tie into dealing with executives when I'm trying to get them to release the purse strings or release some of the control of their work, right? comes in handy, right? So you have to be looking for how does that idea sit in our world and then sort of play with that idea a little. Brian (33:22) Yeah. Yeah, this has been awesome. I really appreciate you making the time for this, Chris. And for those people listening, just a quick little shout out again. Agile 2025 is happening in Denver. It is the week of July 28 through August 1. So mark your calendars. And if you're interested in volunteering, if you're interested in being a reviewer or one of the Purple Shirt people who help out, Purple Shirt people help out at the actual conference making it kind of flow, right? They make sure it actually works. Yeah, yeah, the talks would not happen without them. Actually, nothing would happen without them. Yeah. Chris (33:54) They're the lifeblood of the conference. Yes. Nothing would happen without them. Nothing would happen without them. Yeah, if you hit me up on LinkedIn, my name is just how it appears here on LinkedIn. Toss me your idea. Yes, will, and I said, I shot my mouth off about mentoring people through their talks. That means you too. I... hit me up. Like there's no excuse for you to not because the worst thing that happens is you get to come to the conference. So, yeah. Brian (34:29) There we go. So mark your calendars, make sure that you reserve those dates, like I said, just block it off. Even if you don't know whether you can get the money to do it right now, block the dates off, and you're gonna be much more likely to actually attend if you do that, because then you'll see it coming up, and they go, yeah, that's coming up, I should do that. So Chris, thanks again for coming on, I appreciate you making the time, and thanks for joining us. Chris (34:56) Yeah, thanks for having me, Brian.

In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn reveal the keys to achieving lasting success with Agile methodologies. From embracing experimentation and fostering a culture of continuous improvement to improving communication with consistent vocabulary, they offer practical, relatable insights for Agile practitioners at all levels. Overview Brian and Mike discuss the essential ingredients to Agile success, touching on the power of experimentation, the need for flexible coaching, and building a culture of continuous improvement. The conversation dives deep into the importance of effective communication within teams, especially through user stories and consistent vocabulary, ensuring that Agile teams stay aligned. With personal anecdotes and actionable tips, this episode provides a roadmap for anyone looking to excel with Agile. References and resources mentioned in the show: Mike Cohn Essential Scrum by Ken Rubin Agile & Scrum Glossary #85: Effectively Managing Dependencies with Ken Rubin Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin Creating a Software Engineering Culture by Karl Wiegers Private Scrum & Agile Training Agile For Leaders Working on a Scrum Team Classes Story Writing Workshop Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. 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 (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today we have our favorite back with us, Mike Cohn is here. Welcome back, Mike. Mike (00:12) Thanks, Brian. It's good to be here. Hi, everybody. Brian (00:15) So happy when Mike can make time and be with us here on the show. Obviously Mike has a lot of wisdom and experience to share with us. So we wanted to bring him in because we were talking about doing an episode titled The Secret Staggile Success. I remember back in the day in the 80s, was a movie called The Secret to My Success. There was a really obscure movie. was Michael J. Fox. Yes, it was Michael J. Fox. Mike (00:37) Michael J. Fox? Yeah, so it's not that obscure. Brian (00:41) But I still hear that theme song in my head. when we talked about this title, that's what I thought about. But we wanted to talk about maybe some hidden things or things that aren't as immediately apparent to people that are crucial to being successful when you go agile or if your teams are working in an agile way. So let's just open things up, Mike. What's one of the things you had thought about when we talked about this? Mike (01:10) think the number one secret to Agile success for me is being willing to experiment, to try new things. And if you think back, Agile itself, Scrum itself, began as experiments. They were probably teams going, know, this waterfall stuff we've been doing doesn't work. Let's try something different. Somebody else went, yeah, let's do something unusual, and let's try iterating or something. And so Agile itself began as experiments. And yet I see teams kind of get stuck in the mud and not willing to experiment. And I think that's to their detriment. We want to try things out. And silly, trivial examples, try different sprint links. Don't do a one -week sprint link and go, Agile doesn't work. It's not for us. No. Brian (01:52) Yeah. Mike (01:59) Maybe one week sprints are for you. Try a three week iteration or I try something different. And I think the the idea of experimentation is how we come up with new ideas. It's how we learn. It's how we get better. And so if you're going to succeed, you better have that that focus on experimentation. Brian (02:19) Yeah, there's a surprising number of Scrum Masters I've encountered that I'll hear stories about how they run the same exact retrospective, every single retrospective. And I just think, what are you doing? How can you be trying to communicate this and teach the team that this whole thing is based on doing little small experiments and seeing what the result is, when you're not willing to try something new in just how you run a retrospective? So yeah, I completely agree. I think the key there for me is demonstrate it. If you want them to pick up on that, then do it yourself. Mike (02:56) worked with a company years ago that fired their scrum master for basically for being too rigid. He had read something in Ken Schwaber's second book, and I don't want to pick on Ken's book, but he has this wacky sentence in there, and there are wacky sentences in my books, right? So somebody can go find those, and I mean, I get it. But anyway, Ken wrote that the daily scrum must be conducted left to right, starting with the person on the left of the scrum master. And it's like, what? Why is this mandatory? It must be left to right. Anyway, this guy read that in the book and insisted that the Daily Scrum be left to right, starting with the person on left of the Scrum Master. And his team knew that was insane, right? It's just nuts. And so they would mess with him. They would do things like he would call on the person to his left and the person on the right would start talking. he would point to the person on the left to start and they were standing in a semi -circle. They would move, right? So the person on the left was no longer on the left. And they were just messing with him over this. And he would just get mad and insisted it had to be left right because the book said so. And I don't know what it was with him, but he was just stuck on this. Ultimately ended up getting fired for it. Yeah, I heard this story because I ran into him at a conference and I saw him there and he Brian (04:14) Wow. Mike (04:20) looked a little down. It's like, you know, said his name and how are you doing? And he told me this story. And he said, you know, he'd gotten better since then. But, you know, don't get stuck on things. It's just not the it's just not a very agile mindset. Brian (04:34) Yeah. I mean, if you can't, no matter what it is too, I think that if you can't point to what you hope to achieve from doing it that way, or what's the purpose behind us doing it that way, that's questionable part of your process to just say, I can't point to any reason why this, any good that this thing does going left to right person by person, but. Ken said we should do it. I guess, no, I mean, if there's no reason, if you don't see the benefit in it, why would we do that? Mike (05:07) Knowing Ken, I think he was just trying to make it easier for people. Here's one less thing you got to think about. Start on your left and go around the room. But the way it's written and the way this guy interpreted it was like, shalt go left to right. It's like you've got to be willing to, I think, out the way that a known proven way start out that way. So yeah, go ahead and start left to right. It says so. I don't know any different. Might as well go this way. Brian (05:17) You Mike (05:35) But then experiment, learn, figure it out for yourselves. I I can't think of a successful company or team that I've worked with that ever quoted this Scrum Guide at me, right? You know, they may start out exactly the way a Scrum Guide says, or my favorite is Ken Rubin's Essential Scrum Book, start out in a known proven way, but then experiment, make agile your own. Don't throw away the important stuff, and that's why you have to start in a known proven way, but as you get experience, experiment, throw things out. Brian (05:46) Yeah. I love that. Yeah, I think that's a really good one. So a good one to start us off. Thanks for that. Mike (06:12) Yeah, that's, that's what I'm buying. Brian, can I ask you for one of your secrets to agile success? Brian (06:17) Sure. Well, and this one I know it's going to be a little, know, boy, it'd be nice if I could do that, but I, you know, we can't do that. And I understand that this is not going to be for everyone, but one of the things that I think is important is to have some kind of a coaching presence. Now, just to be clear about this, this doesn't mean that you have to, you know, fight tooth and nail to hire some outside consultant or anything like that. I understand budgets are tight and there may not be an ability to do that. But I think if I, you know, if you're a scrum master, then I think that having the ability to continue your learning journey and grow is really important and, and having someone you can go and bounce things off of. So if you can't have someone, if you, if you can't have someone on staff or someone there that's an outside consultant that can help you and coach you through the early stages, I think that could be really, really helpful. And to me, it's an accelerator. I think that kind of thing is something that can really, yes, we will go through training. We understand kind of the basics, but then the coach is sort of like pouring gasoline on that fire to say, now we're going to go from zero to 60 and I'm going to help you get there because I know the pitfalls to look out for and I know how to get you there. But if you don't have that ability, I think it's important to maintain some of those mentorship relationships that you can find through different community groups. Mike (07:18) Mm Brian (07:44) Maybe you'd find some kind of a weekly meetup or a monthly meetup or something that you could go to. Even if it's just a meetup of peers, right? There's not someone that you would say, that person's been in this for 10 years. No, we're all kind of in the same place. But if we can meet up in their network of my peers and let's talk about what's going on at your place, I'll talk about what's going on at my place, and we can share with each other and... help each other find the best solutions. Even that level, I think of coaching is really imperative and can really make an impact on how successful your implementation is. Mike (08:25) I think you're right. I think back to the earliest days of Agile, and at least of Agile training. And I'm thinking back to when I was teaching public courses on Agile in 2003, 2004, 2000, actually, the early days. One of the big benefits of the class, beyond whatever learning somebody had in the class, one of the big benefits was just feeling like you weren't alone in the world. And I remember people describing a problem, whatever it was. Like, my bosses aren't on board with this. and somebody would describe a problem and then somebody else in the class would just merely sympathize. Right. Yeah, mine too. I'm struggling with that too. That was like one level of support that was awesome. It was even better if there was somebody in the class who said something like, yeah, we had that problem and here's what we did. Right. But these were not people who were any smarter than each other. It wasn't like the person who'd worked through the problem was that much smarter. They probably just had a six month head start and Having that ability to go into a class and hear that you weren't alone and that your problems were not that unique was extremely valuable for people even way back then when there were not a lot of people doing this. Brian (09:32) Yeah, and I've said this before, and I probably said this to you, Mike, but one of the things I think people love the most when they come to the advanced classes that we offer is really being able to get sympathy from others, the camaraderie of talking to somebody else and saying, yeah, I've gone through that. It's not, I tell people at beginning of the class, it's Mike (09:48) Mm -hmm. Brian (09:59) likely not going to be a teaching point that sticks with you as much as it's going to be hearing from your peers and actually getting to learn from each other that's going to stick with you as much through those classes. to me, I think that's one of the reasons why those classes are so much fun is because I learned from the people who come to them. Mike (10:20) absolutely, absolutely. Some of what you're describing is why we set up our Agile mentors community years ago. Agile mentors community, not just the podcast, is a community we have where people who take one of our courses get a free membership. I hired a consultant to kind of give me advice on some business stuff years ago. he used the try. And I asked him, hey, we're thinking about starting this community. What do you think? I don't remember if he said do it or don't, but I do remember a term he used. He called it a continuity program. And it was a way to continue a relationship with people who taken our courses. And like I said, we give it away free to people who take classes because we know that a class isn't enough to get people successful, but it's a start. It gets people over some hurdles. It gives them the foundations of the education they need. But they're going to have ongoing questions. And our community has been wonderful because we have so many good people in there who helped each other out. And again, they're often somebody who's just six months ahead in their journey, helping somebody who's right behind them or, you know, there's somebody just in a similar industry and can sympathize or give advice on how they worked through a problem. Brian (11:29) Yeah, that's awesome. So we talked about experimentation, we talked about coaching. Mike, what was another one that was on your list? Mike (11:36) One for me is to focus more on practices than frameworks. The frameworks get all the attention. Should we do Scrum or should we do Kanban? Should we do extreme programming, going back a little bit more when that was extremely popular, still around, but not as popular? Should we do safe? And so people focus on their frameworks because they're these big, visible things. And I think what we want to do more is pick the right practices for us. Now, that's not to diminish frameworks. I think the frameworks are good. They're a good starting point. But I've said for years, if I have a team and they start with Scrum or if they start with Kanban, if they're doing the good old inspect and adapt thing, they're going to end up in the same place. They're going to invent the right Agile for them. And very likely, that's going to be some elements of Scrum, some elements of Kanban, perhaps some elements of Safe if it's big. I don't think it matters all that much where you start. I think it's worthy of some consideration. But if you're inspecting and adapting, you're going to end up in the same place. And that means that Agile needs to be thought of more as a set of practices rather than we do Scrum or we do Kanban. Brian (12:49) Yeah. Yeah, I love that. And, and, you know, we've talked about the kind of that concept before of, you know, trying to fit the right practices in place. I know when even on this podcast, when we talked about scaling and then couple of those episodes, we talked about how, you know, it may be better for you to, to, find the unique collection of practices that fits your situation. because, know, a lot of these frameworks, they're designed to handle everything. They're designed to handle any possible scenario and. Mike (13:14) Mm -hmm. Brian (13:18) You're not going to encounter every possible scenario. You're going to encounter the ones that are only particular to you. Yeah. Mike (13:24) Yeah, absolutely. Yeah, I've thought that there's I don't want to do this. I've never taken the time to really run this as an initiative. But I felt like there are a core set of practices that kind of everybody should do be iterative, right? know, inspect and adapt, right? Those type of things. But then there's a set of practices that are good for startups, let's say there's another set of practices that are good for people in the banking industry. Right. And that everybody in the banking industry should be doing a certain set of practices, and those will differ a little bit than perhaps every company in the game industry. And so there's these set of practices out there that can be grouped, but they do also need to be kind of tailored and hand -chosen for your particular organization. Brian (14:11) Yeah, yeah, I like that kind of the idea like a template, right? I mean, like when you use the template on a software program, that's a starting place, but you're expected to kind of customize it a little bit to your specific needs. Yeah, I like that. Mike (14:25) Yeah, wouldn't it be great if you're a startup and somebody said, here are the 20 practices you really got to do if you're to be successful as a startup. Here are the 10 you should think about, and then the rest, see if you like them. Same thing, bank. the bank, might have 30 practices you start with. Ivar Jakobson, who's the inventor of use cases, part of the unified method back with Bucin Rumba. He's had an initiative going on the last handful of years where he talks about method prisons and that the practices are all kind of locked up in these methodology prisons like Scrum and Kanban and everything else. And he talks about like free the practices, right? Let the practices loose of these method prisons and let people just more readily select the set of practices that are best for them. Brian (15:15) Love it. Yeah, I love it. That's a great concept. Mike (15:17) Yeah, I think it's a great, it's a great approach. It's got some traction, but it's something that more people need to hear and do. Brian (15:22) Yeah, I think that there's also maybe some stuff mixed in there with what you were saying that I've heard from the heart of Agile people. There's a lot of good stuff that's overlapped there as well. So that's awesome. Mike (15:32) Absolutely. What's another secret you can reveal Brian? Brian (15:37) Sure. Now, this is a big one, but what I would say is maybe moving in a different direction, the idea of how important the culture is and just setting the right culture even more so than trying to get things like time boxes correct. I was talking with a friend of mine at a conference recently and one of the things we kind of discussed was that whole inspect and adapt process, how important that just getting that ingrained into the DNA of what the team does. And Mike, like you said earlier, if they have that inspect and adapt built into who they are, then the practices come. The practices will actually kind of coincide with those because they'll find the right things to do. Like you said, they'll end up at the same place, right? They'll end up at the things that really are important to them. But I've seen lots of places where they go straight to the rule book and want to implement all the rules as quickly and possibly as they can. If the teams don't understand, when something goes wrong, when something does not happen the way that we thought it should, then that's a target to inspect. and dig in and find out why it happened that way, and then find a new way of doing it. I've told the story in classes before that I've encountered multiple situations, scenarios where I've worked with teams where they'll be doing something that they've identified as a problem. They've said, hey, yeah, this is wrong, this doesn't work. well, that's what I'm saying. Mike (17:26) Why are they doing it then? Brian (17:32) They'll identify something and say, yeah, that's not good. We need to do something else. But then they'll stop and say, all right, so let's really, we want to find the right thing to do to replace that with. So let's take the next two months and really investigate, find, and then we'll come back and we'll change in two months over this new thing. And my advice to them is always, so you're gonna just intentionally do the wrong thing for two months? Right. Mike (17:59) for two more months. Brian (18:01) You know, like you should try one of the other possibilities because you could get lucky and that could be the first thing you try. You know, and oftentimes it is something that is better because your gut instinct is usually pretty good about that kind of stuff. So yeah, try it. Something's not going well, all right? Then we're not doing that again, right? We're gonna try something new, whatever that is, and we're gonna try something new and then we'll do the same thing at the end of the next sprint. Mike (18:27) Mm -hmm. Yep. One of my favorite comedians, this guy named Bob Newhart died early, he was earlier this year. And he has this one comedy routine that he does where he's a psychiatrist and somebody walks into his office and she describes some problem he has. And he's like, okay, I'm going to give you the advice. It boils down to two words. And she goes like, should I take notes? Should I write the two words down? It's like, nope, you'll remember them. And he just looks her really like stern in the eye and says, stop it. Brian (18:54) you You Mike (18:59) She has a phone question. He's like, just stop it, right? Whatever you're doing, just stop it. And which is like just hilarious, right? Imagining, you know, some psychiatrist or therapist giving the advice of just stop doing whatever it is you're doing. But it's so reminiscent of what I've seen with agile teams, right? And with what you're describing here, you know, we're doing the wrong thing. We need to change, but we're going to stall looking for the perfect answer instead of just stopping and figuring out something, right? Just try something different. Brian (19:28) Yeah. And if our culture is a culture of always inspecting and adapting, then like you said, we'll end up at the right place because when something's wrong, we'll change it. And we won't just sit on something that we, I don't know how many times I've seen the organizations where you talk to people and take them out for a beer and they'll say, well, here's the real problems. everyone knows what the problems are. So why not fix it? Why not change it? Mike (19:41) Mm -hmm. Yeah. It's hard. It's hard in a lot of organizations. You and I both do sessions where we'll talk to executives, right? And to me, it's a really fun, like 90 minute training session that we have because the way we deliberately set that up was to talk about the benefits of agile. So we get people kind of interested, right? you know, those benefits. But then we tell them why it's going to be hard and what they're as executives, what was leaders, what they're going to have to change. And what I find is when we do that, if the leader starts arguing with me, because I tell them, look, here's going be hard. You're going to have to change this. You're going have to stop doing this. If they start arguing with me, we'll change that behavior if we get those benefits, then we know we've got them hooked and they want to be agile. But if I say agile's great, here are hard things you're going to have to change personally. And they're like, yeah, that'd be hard. We probably wouldn't make those changes. I don't want to go anywhere near working with that company. They're not going to succeed. They don't have a culture that's going to make those changes. And so I love doing those executive sessions because we hear it's just so instant, it's instant feedback on whether this company has a chance of being successful or not. Brian (21:06) Love him. Is there another one on from your list, Mike (21:10) One that I want to add is a little bit more about not just having one team be successful, but if you're working to get a set of teams, your department, your group, something like that. I think it's really important to have a consistent vocabulary across teams. Because we're talking about this idea of continuous improvement. And if your team and my team are using words differently, how do we share ideas back and forth? And that sharing of ideas is really important. if we don't have a consistent vocabulary, think it's hard to do. I worked with a team a couple years ago. I worked with this team, and I'm there for like two or three days. I think I'm there on the second day. And they've been using the words sprint and iteration interchangeably, just both words. And I'm sure you've encountered that. It's kind of normal. I think it kind of depends on if you grew up in the Scrum world, you call them sprints. If you grew up more generically agile, you call them iterations. They're using both words. And the second day I'm in a meeting and somebody says, well, yeah, that's how we do it in a sprint, but it's totally different when we're in an iteration. And I'm like, huh? What's the difference? And the guy had a really great answer. He said, a sprint is when we're working overtime and iteration is when we're going at a sustainable pace. That actually, there's a lot of logic to that. It's kind of a cool idea. I could see that. Brian (22:17) Ha ha ha. Mike (22:37) But I could tell by looking around the room that others were surprised as well. They'd been using the words interchangeably too. They didn't know there was this specific meaning that, I don't know, three Algel coaches had decided three years ago, this is how we use the words. But it wasn't part of, to your word, moment ago, culture. It wasn't part of their culture. And so some teams were calling them sprints, some teams were calling them iterations, and it was just creating a lot of confusion. when we found out that there were different meanings and different rules for whether you were in a sprint or iteration. So. Brian (23:08) Yeah. It reminds me of a Dilbert cartoon I saw a while ago, or it's been several years now, it was about, were talking to their big dumb boss, right? And they were saying, yeah, we're in the middle of a project and we're about halfway through, but we need, you know, six more months to complete this. All right. What's the project you're working on? We're taking all of our website addresses and we are transforming them into URLs. Right. Yeah. It's yeah. Okay. Yeah. Obviously, the boss didn't know the difference, right? Mike (23:37) That's a nice project, right? That's my assignment next month. Yeah, the vocabulary just creates confusion. like how Ken Rubin, I mentioned him earlier, the author of Essential Scrum, my favorite book on Scrum. You've had him as a guest before. I love how he writes his books. He starts out, I just start out, I just plunge in. just like, just start writing. And I have an outline, but I just start writing. Ken sits down for seriously months, I think it is. Brian (23:39) Right. Right. Mike (24:07) and defines a glossary, right? Here's how I'm gonna use certain words. then he, man, if he says a word means a certain thing, he uses it that way every single time. And he has a wonderful, agile glossary on his website, inolution .com. And so he's like defined every kind of agile word you could look for. He's got it defined there. But that's how he starts, right? So he defines all these words. And then if he writes a book and he... Brian (24:10) Wow. Mike (24:33) wants to use the term sprint, he knows exactly how he's going to use it. That's an easy one, but he will define all those words so they're clear up front. We do these working on a Scrum team classes for companies, which is a of a private whole team training class. And some of the feedback we get is that it really helped them get their vocabulary consistent. It allowed them to talk about ways to improve that were challenging until they had a common vocabulary. What is a Scrum master? What are the responsibilities of a Scrum Master? And that's not just defining the word sprint, but it's defining a more complex word and saying, what does it really mean? But if you don't have agreement on what a Scrum Master is or who is on the team or things like that, it's really hard to talk about that across a larger group. And so that, to me, is one of the secrets to Agile success is that consistent vocabulary. Brian (25:25) Yeah, I'm glad you mentioned that class because one of the things that that that we do periodically when we are not here every time. One of things that we do when we have one of those classes is I'll meet with their with a company in advance and have a conversation about what is it that you really want to get out of this. And one of the most consistent things that I hear over and over again from companies that come to us is we want consistent vocabulary. We want a consistent language that people use across this so that When we say something, means the same thing across all our teams. Mike (25:58) I think it's become more of an issue the last, I don't know, five, 10 years or whatever it is because we've got so many people that know Agile by now, right? But of course, they were trained by different people. They were trained in different ways. And so they'll be coming to it and using terms slightly differently. I'm going give a little example here. Velocity, right? Velocity can really mean two different things to people. Velocity can mean the amount of forward progress you made. in a sprint, right? How much forward progress did we get? Instead, velocity could mean capacity to do work. How much work did we get done in the last sprint? And forward progress, capacity to do work are slightly different things, right? And if we don't have agreement on that term, we're going to get into those fights about, bugs count towards velocity, right? Well, if you're using velocity to mean capacity to do work, yeah, bugs should count. If you're using velocity to mean forward progress, no. Bugs shouldn't count. And defining velocity, having that conversation with the team, once you get that figured out, a whole set of problems go away. All those discussions about what gets points, they all go away instantly. But most teams don't think to have that conversation. And they will have some team members using velocity one way, others another way. Important to get that defined. It's not hard, but it's important to get that consistency. Brian, do you have another secret, or have we revealed all the secrets? Brian (27:24) Yeah, I got one more. I got one more. you might, you know, if you're listening this far, you may notice that I have a sickness. I picked all C words. I don't know why, but that's just what I had to do. But my last C word was communicate. And really just the idea here was, you know, if you've ever gone to see a youth sports team, you know, a kid's soccer, kids basketball, whatever, right? If you ever go to see any of those things, one of the things that you will hear over and over screamed from the sideline from the coaches is, talk to each other. And it's a really important part of learning how to play that sport is, hey, I've got a call for the ball. I've got to let everyone else know, hey, here's what I need. And I think that's an important part of Scrum as well. Scrum is a team sport. It's a... Mike (28:02) Haha. Brian (28:19) You know, I apologize to people in classes and say, apologize for the sports analogy, but scrum is a sports analogy. You know, it comes from rugby and, it's, it's intentionally there as a team sports so that people can, can recognize and look at that and say, yeah, we're not, we're not playing golf, right? We're, we're, playing this as a team altogether at the same time with the same goal. And so you got to talk to each other. You got to have communication. I know, you know, Mike (28:24) Yeah, itself, Brian (28:47) One of the main ways that we try to help that here at Mountain Goat is when we talk about things like user stories. That's a main tool that the teams will use in their communication back and forth between the business and the developers. And I know in your Better User Stories course, we go in detail about that. And we also have this thing that we do occasionally called a story writing workshop that's kind of more coaching, where we'll sit down with people and kind of Mike (29:01) Mm -hmm. Brian (29:17) actually work through stories that they're writing to help them effectively communicate what they're trying to get across to the developers. Any communication takes practice. Any relationship, the communication grows and gets better the more you do it. Mike (29:36) I think it's a good point about using user stories as an example, because one of the user story mistakes people make is to think that user stories exist to document an agreement. They don't. They exist to facilitate a conversation. And then the conversation is where we're going to figure out the specific needs and things like that. Yeah, maybe we could document that. It's got to be documented for various reasons. in many organizations, but the story itself is there's a reminder to have a conversation, right? It's not there to document an agreement, which is different from things that came before, like a use case or IEEE 830 document, right? Those did document agreements. User stories, they're there to make sure we talk. Brian (30:13) Right, right. Those were in essence contracts, right? I mean, they were, you shall do this, the system shall and whatever. But yeah, user stories, not that. I love the way that you put that and I've said that for years as well. It's a placeholder for the conversation. Mike (30:28) Well, let's add one more C then. didn't realize you were on a C theme here. So let's add one more secret to Agile success with a C. Crack the whip, right? Yell at your team, make them work harder, right? That's the secret to Agile success. I shouldn't say that because you'll pull that out as a little clip. crack the whip on your Agile team. That's how you get them successful, right? Brian (30:30) Hahaha! Hahaha. I can guarantee you that's gonna be the cold open here for our show. It's Mike Cone saying, the secret is cracking the whip. I love it. Well. Mike (30:59) So there was a great book by a guy named Carl Weigers on culture. is like creating a software engineering culture. And he has these little gray boxes in there. There are things not to do, right? Don't do this. But the boxes don't say don't do this, right? You have to have read like the intro to like, hey, don't do the things in the gray boxes. But he also has like anti -patterns in there. And I just remember being a, a, I think it was a director, VP at the company. And I showed it to one of the directors. I'm like, man, look at this. He's got guys highlighted all the things to do in the boxes here. And he was like, really? We should do that? Okay. And he was like, ready to go do these things. I was like, no, no, no, these are the things not to do. So you gotta be careful with things like crack the whip, right? It's, you know, a direct quote. It sounds pretty horrible. It's a joke. It's like, hopefully people understand. So. Brian (31:42) That's hilarious. Yeah, yeah, I think everyone who's, you know, listening to this would understand that, right? Would understand that that's a joke, but and just in case. Mike (31:56) As a guy who had the whip cracked on me as a young developer, I've always been a very much do not crack the whip. I'd rather I'm always after people's energy rather than their time. Right. It's kind of like we do four day work weeks, right? I'd rather have energy than time. And so, don't think cracking the whip is the way to succeed. Brian (32:15) Yeah, I'm in the same boat. remember having a boss once that used to take me into the server room to yell at me because he could raise his voice in there and nobody would hear it. So, that was fun. Right, right. Well, this has been great, Mike. I really appreciate you making time for this. And I think everyone's going to get a of good tips out of this. Mike (32:23) You I gotta remember that. Great, thanks for having me, Brian. Bye.

David Starr is a Principal Solutions Architect at Microsoft, focusing on Azure and cloud marketplaces. With over 20 years of experience, he has led software development initiatives, held architectural responsibilities, built high-performance teams, and fostered technical learning. He is passionate about delivering great software, designing cloud-scale solutions, and quality-focused engineering practices.   He has contributed to or led several team initiatives that enable and accelerate the Azure Marketplace, such as the Marketplace FastTrack Copilot using Azure Open AI, the SaaS Accelerator, the Data Sales Accelerator, and the .NET and Java SaaS fulfillment libraries. Additionally, he is the program owner for Mastering the Marketplace, a comprehensive learning platform for Microsoft partners and customers.   Topics of Discussion: [6:09] Agile methodologies, Scrum, and software development leadership. [6:38] Working with Agile Alliance and Scrum.org. [7:50] What David learned working for several years at GoDaddy. [9:49] Using Azure Marketplace to sell software and services, with examples of successful partners and their experiences. [15:20] Who has full admin rights on MongoDB? [17:49] Pricing models for AI models in Azure Marketplace. [21:56] AI cost estimation and model selection. [29:40] Azure Cloud Marketplace and AI advancements, with insights on how to get started with product development.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Ep 149 with David Starr David Starr LinkedIn “Making HIPAA and HiTRUST Compliance Easier” Azure for Executives ElegantCode ElegantCode on X David Starr on PluralSight AgileTeam Practices with Scrum Mastering the Marketplace   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Agile World in English is Back with Sabrina C E Noto and Karl A L Smith, the special announcement is that Agile World team will be attending the Agile2024, the European Experience presented by the Agile Alliance and hosted by the Agile Business Consortium. The Agile2024 Conference is a two location event Manchester and Dallas with talks being shared between the two locations live. In this show we hear from Claire Cocks and Peter Coesmans from the Agile Business Consortium about the face to face event in Manchester on the 24th of July to the 26th July from 1pm at Manchester Conference Centre, near Manchester Piccadilly. Agile World will be at the (free access) World Café (https://www.agilebusiness.org/knowledge-base/events/world-caf-championing-business-agility.html) on the morning of the 24th of July from 9am to 12pm. The Agile Business Consortium Agility Insights Report (based upon new industry case studies) to be launched during the Café and there will be focused discussions on Agility in Finance, Agility in Marketing, Agility in HR for great knowledge building and sharing. Claire describes how to get a special deal on the tickets for the Agile2024 Conference as a Members Discount Select The Agile Alliance Member and/or Agile Business Consortium Professional - (approx. £375) plus VAT - $450.00. The Speakers include Arie van Bennekum who will be in Manchester plus a host of other fantastic speakers split between Manchester and Texas a full list is here. A second announcement was made by by Peter about Agile ESG with an invitation for everyone to become involved and Claire about the Sustainability Dojo. Claire Cocks Peter Coesmans Agile2024 the European Experience Manchester Conference Centre Sackville Street, Manchester, M1 3BB Agile2024 Grapevine, Dallas, Texas #Agile_World #AgileWorld #Agile #AgileTalkShow #AgileManifiesto #AgileCoach #ScrumMaster Co Hosts ⁠⁠Sabrina C E Noto ⁠⁠Karl A L Smith⁠⁠ © 2024 ⁠⁠⁠⁠⁠⁠⁠⁠⁠Agile World ®⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠News and Broadcast Network⁠⁠ ⁠California, USA | Music by Debs from ⁠⁠Detoxen⁠⁠ (Facebook)

Join Brian and John Barratt as they delve into the current state of the agile industry, exploring the impact of economic downturns on agile coaches and Scrum Masters, and discover innovative strategies to navigate these challenging times. Overview In this episode, Brian and John Barratt dissect the current state of the agile industry, focusing on the effects of economic downturns on agile coaches and scrum masters. They discuss the reasons behind organizational layoffs and cost-cutting measures, emphasizing the need for innovation to thrive during challenging periods. The conversation shifts to redefining the roles of scrum masters and agile coaches, highlighting the importance of delivering value and outcomes rather than merely facilitating meetings. John introduces two essential resources—the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics—to support agile practitioners in their professional development. The episode concludes with a discussion on the significance of mentorship and continuous improvement within the agile community. Tune in for invaluable insights and practical tools to enhance your agile journey. Listen Now to Discover: [1:08] - Brian welcomes Certified Scrum Trainer®, Certified Team Coach®, & Certified Enterprise Coach®, and host of the Clean At Work podcast, John Barratt. [4:42] - John reveals the core issues behind struggling organizations and shares how innovation can allow an organization to thrive during challenging times. [5:50] - Brian and John analyze the impact of economic downturns on organizations and agility, offering strategies to navigate these challenging times successfully. [10:04] - Brian and John explore the role of Scrum and Agile in an economic downturn. [16:08] - Join Brian and the Mountain Goat Software team for not only a Certified ScrumMaster® class but a full year of membership, learning, and support from Mike Cohn, Brian, and the Agile Mentors Community. You don’t have to lead alone. [17:09] - Brian poses an opportunity to expand the definition of done of Scrum leadership. [19:43] - John introduces the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics as powerful resources to help Agile practitioners and leaders enhance their skills and progress in their development. [23:42] - John shares the tool of Agile Scoping, based on From Contempt to Curiosity by Caitlin Walker, to lean into Scrum success within an organization. [32:25] - Brian shares a big thank you to John for joining him on the show. [33:04] - We invite you to share this episode with a friend and subscribe to the Agile Mentors Podcast. [33:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. [34:16] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. References and resources mentioned in the show: John Barratt Clean At Work podcast Scrum Events Meetup #93: The Rise of Human Skills and Agile Acumen with Evan Leyburn The Agile Army - John Barratt Agile Coaching Growth Wheel Agile Coaching Code of Ethics Agile Scoping From Contempt to Curiosity by Caitlin Walker Agile 2024 - The European Experience - Manchester Agile Coach Camp UK Certified ScrumMaster® Training and Scrum Certification Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Mountain Goat Software Certified Scrum and Agile Training Schedule 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. John Barratt is a Certified Enterprise Coach® (CEC) and Certified Scrum Trainer® (CST), passionate about helping individuals, teams, and organizations achieve their best through agile coaching approaches. With a background in the military and a keen interest in systemic modeling, John constantly seeks new ideas and innovations to support organizational resilience and agility. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner, and with me today, I have a good friend of mine that I've been trying to get on the show for a while. Mr. John Barrett is with us. Welcome in, John. John Barratt (00:14) Thank you for having me Brian. It's been a while. We've been trying. We're here today. I'm really pleased. Brian (00:18) Yeah, very, very excited. John and I have seen each other at conferences for years. We've crossed paths. And I kind of jokingly said to him, I'm threatening to have a conversation with you not at a conference at some point. And that was kind of how we started this. For those who aren't familiar with John and his work, John works with a company called Agile Affinity. John Barratt (00:34) Hahaha! Brian (00:43) He is a certified Scrum trainer, a certified team coach, and certified enterprise coach. So he has the holy trifecta of Scrum Alliance certifications there from the guide community. He's a coach and trainer. Couple of interesting things. First of all, we'll talk a little bit about this, but John has his own podcast called the Clean at Work podcast that we can talk about here a little bit. But another interesting thing that he told me before, I didn't realize this, but John actually started in the military. So do you want to say anything about that? How long were you in the military? John Barratt (01:19) Yeah, so I was in the military for six years, joined accidentally when I was 18. So I went into the career office with a friend who was joining. And they were like, you're a bright lad, you can earn all of this money. So it was either go to university and getting lots of debt or join the army, get lots of training and get paid and see the world. So no thoughts of joining before that day accidentally joined. Did six years including a tour of Iraq. And the important thing about that for me is when I left, I felt really isolated. So Army is all about team, right? Team focus. Left the Army, was in IT, and it felt totally different. People were there stabbing me in the back, not supporting me. And then I found this thing called Agile, which was about teams again. And this thing called Scrum, where it was a team game. I was like, this is what I've been missing. Where's this been for the last two years since I left the army? And the rest is history. I did do a keynote at Central Agile Spain. I'm not sure what year, but it is on YouTube for anyone who's interested in hearing more about how the army is actually rather agile in my humble opinion. Brian (02:22) Yeah. That's awesome. We'll find that and put that in the show notes here. So if people are interested in finding that, they can go and watch that. John Barratt (02:45) Yeah, we'll have to dust it out of the archives. Brian (02:48) Well, yeah, yeah, I'm sure we can find it. But we were talking before this about our topic and I think this is going to be a topic that's interesting to a lot of people. Really, really kind of diving into the state of the industry right now and what we're seeing as far as the economy in the agile industry. You know, there's there's several organizations that have laid people off You know, there's there's less demand at the moment in the coaching kind of realm So kind of what's behind that the the shifts and you know What might be driving this kind of thing? So I know John you got some opinions on this. So let us have it John Barratt (03:18) Mm -hmm. Yeah, so I don't want to talk too much about the global economics. I don't pretend to be an expert on why we're seeing a recession. We can talk about, you know, COVID and the cost of that and also the war in Ukraine and, you know, all of the pain and suffering that that's caused much more than, you know, what we're seeing, which is, you know, a few people being laid off. So I don't want to go into that. But what I do want to really explore is, so if an organization is struggling, there's two elements. for that. Do they try and cut back as much cost as possible or do they try and innovate themselves out of that recession? Do they try and do something different and in a unique way? Unfortunately what I'm seeing a lot of is the first one which is cut back, reduce cost as much as possible and that's to the detriment of the the Scrim masses and and agile coaches that we see and I'm going to talk a little bit why they are the ones that often are in danger in a minute. Instead of where they should go, which my bias opinion should go, right? What I'm trying to do in the company that I run is to actually lean into that as an opportunity and try and innovate and see, well, what is possible in this new, exciting world that we're perhaps moving into? Where do we need to go when organizations are struggling? What are the opportunities, an example, AI that we've seen and what difference will that make in the next few years? I mean, who knows? Brian (05:14) Yeah, yeah, I think it's fascinating and you know, there's something I've talked about with some friends for several years and that is that I think there's sort of a, boy, I don't know how deep we want to go on this, but you know, you have a lot of executives now that get hired to come into a company and it's gamesmanship because the idea is I've got to increase our... our stock price by however many percentage points. And my bonus is tied to that. The more I can increase it, the more I get a bonus. Well, it's kind of like if you go to a team and tell them, hey, can you do more story points? They can certainly game that and all of a sudden have more story points. Well, the same thing with a short -term kind of executive. If you're in an organization and you're only going to be there for a couple of years, And you know your site is, if I can raise it three percentage points, I get a bonus. Well, there's a lot of easy cuts I can make that all of a sudden I've gone up three percentage points. But the long term of that company has not benefited. It's only the short term. And it just feels like, I don't know if it's a day trader thing, if that's really why this is kind of becoming more prevalent or not. But it seems like investing is kind of more of the short term. Now, and it used to be when you buy a stock, you'd buy it for 10, 20 years because you believed in that company and you expected to pay off over the long run. There's still a little of that, but it seems much more short -sighted. And I think that's trickled down to our, like I said, I don't know how deep we want to get on this. I think that's trickled down to our executives. And I think from the executive, that's trickled down to the employees. And that's really affected how... John Barratt (06:41) Mm -hmm. Brian (07:06) you know, when we've had layoffs and we've had downturns in the economy that just, hey, this is an easy way for us to show an increase in profits. John Barratt (07:15) Yeah, I think that's a really good point. It reminds me of Craig Lammon's laws, structure leads culture. And when we talk about structure, we don't ever just mean the hierarchy, we mean the bonus system, how people are rewarded and paid and all of those things. And so if you're rewarding shortism by giving these execs bonuses based on Brian (07:34) Yeah. John Barratt (07:41) profit for this year or as you said stock increase by 3 % then they will cut costs because what looks good for short term and for stocks is to have the minimum operational expense possible right if they can keep that as low as possible then that looks like a solid company because they're keeping controlling costs they talk about and and If they're working on margins and profits start to go down, which is what we're seeing as a trend at least UK, US, I can't say if it's completely global, but it seems like a large percent of the company and the organizations are going in that way, then what they do is to keep their margins so that they get their bonus is they start to reduce that, right? Because they need to keep that buffer. If they were to do what I'm suggesting, which is to lean into that and perhaps spend a little bit, spend some money to make some money, or at least keep it lying and try some innovative stuff, then that's high risk for them. Hmm. Brian (08:50) Yeah. Yeah, I've seen things before that have said that when there is economic downturns, that their evidence shows that the companies that invest more during the economic downturns actually end up increasing their positions to a much greater extent when the downturn starts to turn around because... John Barratt (09:02) Mm -hmm. Brian (09:14) they haven't just set idle or they haven't tried to reduce, they've tried to invest and now they're positioned to really take advantage of it once the economy starts flowing again. I'm not like you, I'm no economic expert, I'm no economist. So I don't know all the ins and outs of what's causing that. But it certainly has caused pain in our sector. And I think a lot of sectors, because I have I know lots of people who have gone through layoffs, not just in the tech industry recently. So I guess kind of the question that I ask about this as far as the agile community is concerned is, if we were delivering value, right? If it was undeniable that what we were doing was increasing profits, increasing value to our customers, I think that would make it a lot. harder for these kind of layoffs to happen. So I don't want to entirely say, hey, it's bad leadership, right? I think we have to take ownership a little bit. John Barratt (10:23) Yeah, and I'm going to say something I think is quite controversial here, which I actually blame servant leadership for this. So I know in the latest version of the Scrum Guide, we use the word true leadership, but I still like the word servant leadership. And I've actually changed my mindset and how I teach these things over the last few years because of this, because we've started to see this trend. Brian (10:28) Go for it. All right. John Barratt (10:51) And I've seen it in organizations where I've worked, I've left one year later, and then they've made all the agile coaches redundant. And I think it's down to how we use and perceive servant leadership. So historically, I was always, you know, Scrum Master or Agile Coach is the great person in the background. They let everyone else take the credit. They're there to help and support the team and to do all of that stuff, which is great, right? until someone with a balance sheet comes along and goes, what are all these scrum masters who aren't delivering any value, right? They're an overhead. They're seen as an overhead. Not delivering any value. No one can even tell me what value they've created. These developers over here, they're doing great. And the product owner is really maximizing the value of this product. But these scrum masters, they don't add any value. Because that's what we told them to do, right? We taught them to... Brian (11:29) Yeah. John Barratt (11:49) give everyone else the credit and serve everyone else and be in the background. So I think we've got a lot to blame, Brian, as trainers for, well, I don't know how you've taught it in the past, but I feel a little bit guilty. Don't worry, I've got the answer, but I just want to hear from you, what you, where you are with that one. Brian (12:04) No, no, no, no. Yeah. I'll tell you my opinion and you'll tell me if I'm correct or not. Yeah, no, I agree. I definitely think that's part of it. But maybe this will be a little controversial. I kind of spoke about this recently at the Scrum Gathering in my talk. In the trend that we've seen, John Barratt (12:15) Yeah! Brian (12:40) that I kind of talk about the diminishing of the perception of value of the Scrum Master. And I think that there's kind of multiple parts to that. I think part of it could be, hey, leadership doesn't really understand the value. But I think that there is a secondary part of that, that they're not seeing the value. And if they're not seeing the value, then I think that that's John Barratt (12:48) Mm -hmm. Mm -hmm. Brian (13:08) that rest on us. I think that we have to partly do a better job of helping them to understand it, but partly doing a better job of delivering it. And again, don't want to get too controversial here, but in our industry, in our training industry, You know, we've done lots of two day classes. We've done lots of things where we get people out the door and then they're in place and they're doing things. And the follow -up, you and I both know the follow -up is so important. You can't just take a two day class and then you're set for life. It's two days, but that's a kickoff and you got to continue that. and if I, if I take a two day class and I kind of slide backwards a little bit from that class and I get in and I'm a scrum master, there's, John Barratt (13:43) Mm -hmm. Yeah. Brian (14:01) Unfortunately, I think there's a lot of scrum masters out there who see their job as meeting scheduler. I'm here to schedule meetings, and that's the value I bring. Well, I can't blame a leader for letting that person go, because anybody can schedule meetings. It doesn't really take a lot of skill to do that. John Barratt (14:08) Mm -hmm. Yeah. Brian (14:26) The skills that we should be adding are those soft skills, the conflict resolution and understanding the personality types that make up our team. And essentially what I talked about in my talk was that first phrase of the Agile Manifesto, individuals and interactions over processes and tools. It's about individuals and interactions. We have to know the people that make up our team, not every team in the world, but our team. And we have to know. how they work best together. And I think people who do that, there's enormous value for that. So I would propose to you there's a shared blame, right? I think there's a blame there that we need to do a better job of showing the executives, but we also need to do a better job of actually providing value for the executives. John Barratt (14:58) Mm -hmm. Yeah. Yeah, yeah, I'm just, I was just, you know, I'm new to running CSMs and things like that. And one of the things I've brought in is a follow -up session. So, you know, a month after the training, they can have 30 minutes and we can talk about stuff. And that's really where you appreciate that the CSM isn't enough, right, to be a Scrum Master because you... There's only so much you can do, but the thing that always lacks, at least I haven't managed to perfect it yet, is those soft skills, right, which are the things that are important because you can't cover that in half an hour, an hour, right? All of those things are a full one, two, well, I'm being generous, just touching the sides with a one, two day course in some of those. And it's good to see the Scrim Alliance moving into some of those, you know, competency based or what they call skills based. courses where we can go a bit deeper into those key things. Because they're talking about, well, how can I do this? And in my head, it's obvious, but it's clearly not. So there's a huge gap between putting someone on a two -day course and thinking they can be a scrum master. And we do see a lot of bad scrum masters in the industry. And it certainly does cost everyone, even the good ones, some credibility. Right? Because... And if there's more ones, and it's not bad because they're bad people or trying to do a bad job, it's just that they haven't been equipped to do the job, right? Yeah, it's as simple as that. Brian (17:03) Yeah. At one of the tables I was at at the recent guide retreat at the Scrum gathering, we were having a discussion around this. And one of the things that kind of struck me as that was going on was, you know what it sounds like? It sounds like we don't have a stringent enough definition of done. Like when we think about someone who's you're now ready to be a Scrum master, well, that definition of done right now is a two day class. Right? And. John Barratt (17:22) Mm -hmm. Brian (17:32) I think we have to put in the expectation that, no, this is a component of that definition of done, but there's actually more that you need in order to, you know, this is an important role. This is somebody who is shepherding and guiding a team to be successful in this. So if someone's not qualified in doing that, it's no wonder that we see a bunch of bad scum out there because the person leading it isn't qualified, you know? John Barratt (17:38) Hmm. Yeah, and actually, I was just thinking an apprenticeship approach would be a much better idea, right, for this type of work. I often give the metaphor in my classes that agile coaching is a craft, Scrum Mastery is a craft. And imagine you're a carpenter, you don't get better at being a carpenter by reading lots of theory about good joints and all of this stuff. You know, you pick up a few things, you get better at Scrum Mastery or agile coaching. Brian (18:07) Yeah. John Barratt (18:29) by working and getting feedback. Our work is with the people, right? And people are a lot more complex than would, so we have to do even more of it to get any good. And of course, in carpentry, you wouldn't think about, we'll do a two -day training course. You would do an apprenticeship, right? And they do it for years before they become like a master carpenter. Yet we have scrimmasters after two days. Brian (18:58) Yeah. Yeah, no, I completely agree. And for the organization, I know when you've seen organizations that have sort of that layer, that hierarchy of we have Scrum Masters, but we have coaches, and we have enterprise coaches. When you have that kind of structure where you can have the phrase we use as mentor and be mentored. And if you can be in that place where you mentor others and you're also being mentored, John Barratt (19:21) Mm -hmm. Brian (19:28) That I think is really key to reaching the next level, to being able to kind of grow into what it is that you want to become in this industry. John Barratt (19:39) Yeah, I mean, I can't solve that problem very easily myself. You know, we've got a certified team coach and enterprise coach in the Scrim Alliance. It needs to be a bit more of a gap, I think, between that and CSPSM and we'll see what comes out in the next few years. But there is a couple of resources that I have worked on to try and help with this. So I've been on a mission to try and professionalize the world of agile coaching for at least five years. And the two things that I've found that have helped most people, is something called the Agile Coaching Growth Wheel, which you may have heard of. We'll put the link in the chat to that, which has kind of all of the competencies that we think you need in Agile Coaching, which is the set of competencies that a Scrum Master needs. So not Agile Coach, Agile Coaching, Scrum Master, Agile Coach, or any, you know, job title could be anything, right? It doesn't really matter. So that's a really useful tool. gives you all the areas, but it also gives you guidance, like a one to five guidance that almost uses the apprenticeship type thing. I can't remember all the levels, I think it uses like the Drift for scale, but it says at level one, you should be able to do these sorts of things. At level two, you should be able to do these sorts of things. And that gives people at least a starting point. You don't know what you don't know, right? Brian (20:58) Right. No, I think that's awesome. And we definitely will put that in our links and make sure that people can find that. Yeah, you're right. That kind of apprenticeship idea, I know that I could not have gotten to where I am without the mentors I've had. John Barratt (21:15) Mmm. Brian (21:18) And it's people who have, for no benefit of their own, have taken their own time to say, I'm going to invest time in this person and help them reach the next level. And I've tried to carry that forward as I've grown in this career as well, because I think it's important. I think we have to help the next group that's coming along. Yeah. John Barratt (21:44) Mm -hmm. I was thinking becoming a CST is almost like that apprenticeship type system, right? Where you have to do the co -trains with different people. They're like mentors, right? Different diversity, different types and groups. And you learn, both people learn from doing the co -train. And I think personally, it'd be a shame if they ever... Brian (21:54) Yeah. John Barratt (22:16) remove that concept because I think it's the closest we've got to an apprenticeship. Brian (22:21) Yeah. Yeah, and it works, right? I mean, I think that it does a good job of getting people to the level they need to be. There's still a lot, I mean, that doesn't do it all on its own, but it is, you know, I think anyone who's been through it, I think you would probably agree with this as well, is, you know, that was a foundational part of becoming a CST for me, is being able to observe and watch others and learn from them and... get feedback on how I was doing it. So I think you're right. That could be a very intriguing addition if there was someone who kind of incorporated that into the process. And I think that would give organizations kind of a confidence to say, I can trust this person. John Barratt (23:10) Which is what we really want with the CCCTCs, right? It's that stamp. I can trust that person. Second tool I wanted to highlight was the Agile Coaching Code of Ethics. So this was an initiative we did with the Agile Alliance. And the beauty of when we created this code of ethics, it was for people who were just starting out as well as experienced professionals. So you can read through that and that's kind of your rule sheet of Brian (23:25) Yeah. John Barratt (23:40) I'm new to this. This is the minimum standard we expect from a Scrum Master or an Agile coach in this industry. Because you don't know what you don't know again. But we've tried to make it as simple as possible. A simple list of these are the things you should definitely do if you want to be ethical in your work. Brian (24:00) Yeah. Yeah, that's a good resource as well. And we'll make sure we have that linked. Was there another resource as well that you wanted to mention, or is it just those two? John Barratt (24:12) So it's the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics. So we've talked a lot about the problem of where we're at, and we've given a couple of pointers. I wanted to talk a little bit about how I've changed my direction from this original kind of servant leadership type focus, which seems to be having some... Brian (24:36) Yeah. John Barratt (24:40) traction and benefit and value to people. And it's a couple of tools combined. So I created something a couple of years ago called Agile Scoping, which was based on Clean Scoping. So Clean Scoping is something that Caitlin Walker created based on Clean Language around how she scoped out a new piece of work. If you want to know more, then I highly recommend her book from Content Curiosity. Brian (24:44) Awesome. John Barratt (25:10) Bit biased, but one of the best books I've ever read. Not an agile book at all, but just a truly incredible story about how she's used clean language and something we call systemic modeling, which is using clean language in groups, with youths that have been kicked out of school, for example, and how they went from all individuals to suddenly kind of helping and supporting and understanding each other. Brian (25:31) Hmm, yeah. John Barratt (25:40) So great book. But anyway, Agile Scoping was based on that and it starts off with a discovery phase. We call that initial scoping, which is setting out kind of, is this work set up for success? So is the person in charge actually got enough influence over the system to actually make any change? So if you are doing Scrum. Do they have permission to actually change the structure into something that is actually going to help Scrum succeed? Have they tried different things before? And also this thing called congruency. So it's what they're saying aligned to what they're doing. So asking for those examples of, okay, you're saying that this, have you tried that before? Those sort of things. Very high level, just checking it out. And you can do that in an interview as well. So this isn't just for an external person. I always think that interviews should be two -way, right? It's not just a one -way thing. I want to check that if I'm signing up 40 hours a week or however many, that this is an organization that actually wants to be agile. I mean, I always put my hand out to the people on my training and people I meet at conferences where they're really struggling, right? And it's a really hard environment. And I always think, wow, you've got way more patience than I have. I really respect that. but my patients' levels are very low. So if I'm going to work with a client, I need to have a feeling that they can work at a pace, right? Brian (27:20) Yeah, right. Right. John Barratt (27:21) So that's level one and that's fine. Then we do an organizational scoping phase where you work with as many people as possible. You're looking at the problems that the organization says they've got, what the culture is now, where they want it to be, running some workshops, finding out what's happening. And again, we call it scoping because you can scope it to the level that you've been brought into. So if you're a Scrum Master working with one team and it's... One product owner, small product, that's fine. That's your scope if it's a whole organization, much wider. At the end of that, you create a coaching plan with the organization. So you have a session and you agree up to four outcomes is what I've found. So we move into outcome -based approach. So even if you skip all of the other stuff, what I would say is move away from any output thinking. As a scrum -rosterer, Brian (28:10) Yeah. John Barratt (28:18) even if it's just in your yearly appraisal, make it clear these are the outcomes that we're looking for. And these are more business related outcomes or things that are going to actually make a difference to the organization. So it could be things like make more money for the organization, could be increase employee engagement, increase customer engagement, number of active users in your mobile app, whatever those are. But they're nothing to really do with Agile, they're to do with... Brian (28:42) Yeah. John Barratt (28:47) that the organization wants to set. Those go into a coaching plan. We have a coaching agreement canvas that you can use to put all of that in. And then it's really clear, like these are the things that I'm going to help and support you with as a Scrim Master or Agile coach. There's a bit more risk, right? Because if you don't meet them, then you've got to have a conversation, but at least then it's visible, right? These are what I'm saying I'm going to help with. This is what you've said you want help with. And now we're going to do a number of experiments to try and get there. And that's where we get into that continuous improvement cycle of trying to involve, adapt, inspect, work on all of those things that are happening within your team, within your department, within your organization, depending on where your scope is, constantly evolving and looking at. where we're at. We might have some lead -in indicators as well, perhaps in there to help us cycle time, lead time, throughput. Those can be useful, but really we're looking at end value and we're measuring our performance of a Scrum Master Agile Coach based on the value being given. We're not letting the product owner take all of that praise and credit. Of course, we don't want to be too arrogant and go too far the other way. It's a team effort. but we're at least putting our, you know, more, I think skin in the game is the thing. What I've seen in the past is, you know, bit of a puppy dog type thing, Scrum Master, ooh, shiny over here, great, shiny over there, no, skin in the game, this is a partnership, and we're gonna work on this together. Sorry, I spoke for a long time, though. Brian (30:16) Yeah. Love that. No, no, no. I love that. You were saying great stuff. And I mean, I love the bit about outcome -based kind of approaches to it. I think that's really, really important. I've always thought, you know, like the performance, I'm always really hesitant about performance -based kind of metrics. And I always want to shift more to output outcome -based kind of metrics, not output. And I think that because that's, You're right. A business doesn't care how agile we are. A business cares if we're increasing our bottom line, if we're increasing our membership, all the business goals that you might have. That's what they care about. And agile -ism means to that. John Barratt (31:17) Yeah, I have a big shiver when teams have like agile maturity models. Like the word maturity, first of all, like if I say to you, Brian, you're immature, Brian. You know, that's just like, why would you do that? And also if I, you know, it's many people have said agile is never the goal, right? We're never trying to be agile for agile sake. We're doing it to help organizations and, you know. Brian (31:23) Ha ha ha. John Barratt (31:44) Therefore, why would you want to know how mature a team is when that's not actually that important, right? Could be a very leading indicator, perhaps, of where you're trying to get to, but it scares me when I see those sort of things. Brian (32:04) Yeah, this is great. This is great stuff. And there's so I mean, from what you've said, there's so many good links that we're going to be able to put in our show notes for this. We'll also, by the way, make sure that people can get in touch with you, John, if they want to follow up and learn more individually from you, because that's always really important here as well. And I know it's conference season. There's a lot of conferences going on. And you were telling me you're going to be at the Europe. John Barratt (32:12) Mm -hmm. Brian (32:33) Agile 24 conference, right? John Barratt (32:36) Yeah, so I've decided to do my part for the environment and not fly out to America for the third time this year. So I'm going to be in the Agile Alliance Manchester in July. I'm doing two sessions there. One looking at product refinement using clean language and the other one how to help and support self -managing teams with Caitlin herself. So if you like the idea of the stuff I was talking with Caitlin. and that's the session for you. Also going to be in Agile Prague this year, Agile Coach Camp UK, which I run, but unfortunately that is full. So there is a waiting list if you did want to try and sneak into that. And I'm sure I'll be at a few other places as well. There's also my monthly meetup that I run with a number of other colleagues called Scrum Event. It's actually the second largest Scrum Alliance user group in the world. Brian (33:33) Awesome. John Barratt (33:34) and we tend to have some pretty cool speakers there, so watch out for that. Brian (33:40) That's awesome. Yeah. We'll try to link to all of that so that people can find it. But yeah, if you're going to be at any of those conferences or if you're on the fence about going to the conference, you can hear great speakers like John there. So make sure that if you do, that you go up and say hello and tell them that you were listening to the podcast and heard this and were interested. And that's why you're there. Well, John, I appreciate your time. We're recording this on a Friday afternoon for you. And I know that's really precious time at the end of a week. So I really appreciate you giving us your time here and sharing your knowledge with us. John Barratt (34:19) Thank you for inviting me and having me. It's been a blast. Brian (34:24) Absolutely.

Join Brian as he delves into the powerful response to his talk on neurodiversity at the Global Scrum Gathering in New Orleans, which emphasized small but significant changes to make environments more accommodating. Overview In this episode, Brian shares his memorable experience at the Global Scrum Gathering in New Orleans, emphasizing the event's stellar organization and inclusive atmosphere. He reflects on the success of his talk on neurodiversity, which resonated deeply with attendees and sparked meaningful conversations. Brian also underscores the importance of attending conferences for networking, learning, and expanding professional connections. Encouraging listener feedback and engagement, Brian hopes to inspire more inclusive practices within teams and the broader Agile community. Tune in for insights on fostering inclusivity, the value of professional gatherings, and much more. Listen Now to Discover: [1:08] - Brian warmly welcomes listeners and invites you to join an engaging conversation about the value and insights gained from Agile conferences. [2:45] - Brian kicks off with heartfelt gratitude to the behind-the-scenes teams whose hard work and dedication ensure these conferences run seamlessly and effortlessly. [5:04] - Brian celebrates the often-overlooked joys of conferences, from hearing fresh voices and engaging in hallway conversations to making meaningful connections and sparking innovative ideas. [9:57] - Brian highlights and commends the Scrum Gathering for its intentional efforts to accommodate and include attendees with neurodiversity and those with additional needs. [14:15] - Brian shares that the goal of his talk was to demonstrate how small changes can create a more inclusive environment, such as playing neurodivergent-friendly music, dimming bright lights, and establishing quiet spaces. [20:18] - Brian discusses the overwhelmingly positive response to his talk and expresses his hope that these inclusive practices will be adopted widely, transforming the way we all work with our teams. [23:08] - Brian encourages listeners to attend future conferences to gain new insights, broaden their horizons, and forge valuable connections. [24:20] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. If you’d like to continue this discussion, join the Agile Mentors Community. [24:33] - We invite you to like and subscribe to the Agile Mentors Podcast and pass this episode along to a friend. References and resources mentioned in the show: Slide Deck From Brian’s Talk #76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell Scrum Alliance’s Global Scrum Gathering AJR Brothers Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Auto-generated Transcript: Brian (00:00) Agile Mentors, how the heck are you? How's your week going? Hope it's going pretty well for you. I wanted to spend some time with you on this week's episode because I just had an event that took place that was really, really a phenomenal event. And I wanna kind of share with you some personal insights that I had from it and just sort of give you a picture of what it's like. If you've never been to a conference before, Maybe I can entice you to maybe go to one. I think you'll benefit from it. And I think you'll kind of see your career maybe even go in new directions if you decide to go to one. We just had the global Scrum gathering that took place in New Orleans. That was the 2024 conference. And the Scrum Alliance has changed things up a little bit. I don't know if people are familiar with this or if you're aware of this, but... Scrimmelines used to have two conferences every year. They used to have one that was somewhere in the US, and then they would have another one that was mostly in Europe. But now they've kind of switched up their strategy. They're going to have one in the US one year. And then next year, it'll be somewhere else globally. So they're really leaning into that global title here for global Scrum gathering. Next year's, I believe they announced here at the end of our conference, is going to be at Munich. So still staying within Europe, but that's not always going to be the case. So there won't be one in the US next year. It'll be the first year that that happens. So every two years, if you're here in the US, you get a chance to attend. If you're somewhere else in the world, maybe there'll be one that appears in a location near you. And that might be a little bit more convenient for you to attend. But I want to talk about this one that was in New Orleans. And I have to start by just, I want to say to all the support staff, to all the people who volunteered their time from. from the teams that helped set up the rooms to the program team that helped kind of put this all together and create the environment and select the talks and everything else. Phenomenal job. Just phenomenal job. I couldn't have asked for it to have been run any better. I saw zero hiccups in my time there and just had a fabulous conference. It was a great time. Enjoyed the heck out of it. Enjoyed New Orleans. It's always great to realize I had not actually visited New Orleans prior to this of all the places. It's not very far from where I live, but for whatever reason, it was just one of those black holes in my map. It was one place I had never been to and it was a place I loved. I thought it was just amazing to meet some of the local people there. and to get a flavor of what it was like on Bourbon Street and Frenchman Street and some other parts of the town after the conference. It was just a really great experience. I was very pleased with the whole thing. And so I just want to make sure that that's out there, right? There's a lot of volunteers that go into working for a conference. I've been a part of that group from time to time. I've reviewed different submissions. If you're not familiar with that process, Speakers at a conference submit their ideas. It's no guarantee anyone's going to get picked. In fact, it's a very, very small percentage. They end up getting picked. So it's a very tough process for the reviewers. And it takes a team of them. They have different tracks that they take submissions in. And they kind of have to whittle those down. One of my friends who was on the team was describing to me, you might have one talk on, or you might think about a topic like daily scrums. And you might have five submissions on daily scrums that are all amazing talks. They all sound like they'd be incredible with great speakers. But somehow they have to whittle that down. They can't have five talks on Daily Scrums. They've got to limit it. And they've got to have talks on things that they feel the majority of the visitors are going to be interested in. So it's a thankless job that goes on behind the scenes. And I just want to publicly thank them. I know I got to rub shoulders with several of the people on different aspects of the teams and just really, really appreciate all the work that you guys did to make it such a successful conference. I really always enjoy the scrum gathering conferences. I think they're, they're, they're a fun event. they, they always have a Monday mingle kind of activity. That's always, something you, you write home about if you will, just something fun to do. this year we had a location was not very far from, the hotel so we could walk there. And just had lots of things that were going on there, food and drink and that sort of stuff. But it just gives you a nice kind of off campus place to unwind and interact with other people and kind of maybe meet some people that you wouldn't get a chance to otherwise. So I always appreciate some of those social events. Even though I'm an introvert, I just enjoy having different space, kind of a different opportunity to do that sort of thing. And I just want to say, you know, the talks I heard this year were incredible. I heard some really good first time speakers that had never spoken before. And I love the fact that, you know, they're doing that, that they are expanding and it's not just the same crop of people that you hear every single conference. You know, it's a different set of people and it really depends on your topic. It depends on what it is you're trying to talk about. So I was really thankful to get to hear some new voices there in our community. And the only thing that I wish I could change about that, and this is the same no matter what conference it is, every conference I have this issue, it always seems like the ones you want to go hear the most are if you're speaking, they're happening when you're speaking, or they're all grouped into the same time slot. And you'll get three or four talks that you really wanted to go to. And you got to pick. You got to choose one of those that you can go to and kind of just plug in there. I'm not one that likes to bounce between the different rooms. I don't have any problem if someone does that. I don't have any problem if someone does that in my talk. But I just like to commit. And that's kind of the way I look at it, is when I come in there, I'm committed, I'm here, I'm giving my full attention. I want to learn from this person. and leave with something I didn't know in advance. So really, really enjoyed that. There was a talk that was put on by women in Agile that was three new speakers that were three women who had not spoken before. Really enjoyed that and loved their approach. They have a mentor for each person that kind of helps them prepare and get ready for it. So that was awesome. Really enjoyed listening to that. And just... I don't want to call out any specific talk because they were all so good. I will say there have been years in the past when I have had sort of slots where I've thought, there's not really one I want to hear in this slot. So maybe I've set out or I've done something else. That wasn't the case for this one. Every slot had something I was like, I've really got to go hear that. I've got to hear that person talk or really want to hear about that topic. So just really enjoyed that. Couple milestones, kind of, I noticed that happened here. One of my mentors and someone I've had in the podcast, David Hawks was there and he's kind of publicly announced this now that he's retiring, he's stepping back a little bit from doing this stuff and he gave his last conference talk. So it was neat to be there to see his last one. He's a really engaging speaker and always has really deep kind of... needy content for you to chew over that you leave thinking about. So it was kind of an honor to be there for the last thing that he did at a conference. And the other thing to say is that I really kind of just enjoy the one -off conversations, the hallway conversations. There's breakfast and lunch every day. And when you do those, you sit down at a table, you've got to find a spot. And sometimes I'm just trying to find any open spot. But what I'm trying to do is find the table with people that I don't know, that I haven't met before, that I want to. maybe rub shoulders with and learn a little bit more about what they're doing their organizations. So those are a great time that they're kind of built in naturally to try to meet some new people. And you know, I'll tell you, I wore a little thing at this conference before it broke on me, but I had a little pin that was kind of my emotional, no, it was my social meter. That's what it was. And it had like a high and a low ranking on it. And you know, I'd start out every day with it on the high ranking. I'm ready to go. I'm excited. And as the day went on, it would kind of go a little bit further down. And by the end of the day, I was spent. I didn't really have any more I could give out. And I just wanted to wear that sort of a visual fair warning to people. If they saw me and they saw where my meter was, they could say, OK, Brian's kind of running low. Maybe. Maybe I'll wait till tomorrow and have that conversation. Not that I'm going to be mean or rude to anyone, but just there are times when you just are all empty. You're just out, and you don't have anything more that you can give. And that's certainly the way I feel sometimes at the end of some of these long days. I've been known sometimes to just go up and spend time taking a nap in my room, maybe doing some emails or something, just something to give me a break to go away. And that's sometimes something I need in these kind of big social environments. I do want to really, really congratulate the Scrum Alliance on one thing that I noticed particularly here in this conference. They clearly made an effort to make some accommodations for some different personality types, neuro types, and you know, I've shared with this podcast before that my talk here at the Scrum Gathering was on neurodiversity and how to be more inclusive of different neurotypes in your teams. I'll get to that talk in just a second. But there were things that I had been studying and learning about that were small accommodations that people could make that helped some of these different neurotypes. And it was clear that the Scrum Alliance had deliberately made an effort to do that. One thing that I didn't know was going to happen until I got there, for every keynote presentation they had on their big video monitor, they had transcription. So there was closed captioning of anything that was being said, which is a very important feature for some various neurodiversity types. And I was very, very pleased to see that. I just thought that was a good change that they made. Small change, not really anything big that they had to do to do that, but it makes a big difference for a segment of the population. And I'm really thankful that they did that. The other thing that I noticed that they did was they had a quiet room. There was a room that was right in the mix of all the other conference rooms where presentations were going on that was a quiet room. It was dim lighting. They had some nice cushy soft like beanbag chairs that were in there. They actually had like some soft quiet like atmospheric kind of effect noises going on like waterfalls and that sort of thing. Rain rainfall, ocean waves, things that were very peaceful and quiet. And they also had made available in that room earplugs for people. And for those that have noise sensitivities, sometimes you can walk into these conference rooms and I can say, I've been guilty of this as a speaker. I want to create an exciting atmosphere. So I blare the upbeat music as people are coming in just to get people in the right kind of excited mood. Well, if I have noise sensitivities, that's going to not only not be exciting, it's going to be painful. And having the ability for someone to self -regulate that and say, I'm going to put my earplugs in for this, because it's just a louder place. It's a louder room. Even just listening to certain talks, you would hear a talk next door where a speaker would just their plan for their talk was much more interactive. So there'd be a lot of audience participation and shouting outs and clapping and laughing and that sort of stuff. And it can be disruptive for the room next door. I don't fault any rooms for being more interactive or fun for the attendees, but you know, noise has a bleed through effect. And I was just happy that they thought that far ahead and said, you know, we're going to have some people here who might have that sensitivity to noise. And it doesn't cost very much for us to provide a handful of earplugs. I don't know how many of them were taken, but I would imagine there wasn't a ton. They didn't run out, as far as I know. But having a place like that, I took advantage of the quiet room. I knew that it was a place where I could go and collect my thoughts. And I would sit down with my laptop and maybe just make some notes of things I wanted to make sure I captured. No one was going to interrupt me. That was kind of the rule of the room. There was no talking in that room. So I could focus. I could come in there and do what I needed to do without disturbing anyone and really kind of recenter before I headed back out. There were some who used it for meditation and other things. And I have no problem with that. If that works for people, then I'm happy for them to do that. For me, it was just a quiet space. And I just needed a quiet space, somewhere away from all the hustle and bustle, what was going on. So just kudos to the Scrum Alliance there for that. I think that they made a couple of really intentional moves there to be more inclusive. And I, for one, as part of that neurodivergent community, really, really appreciated it. So thank you there to the Scrum Alliance. If anyone here is from the Scrum Alliance listening. Big kudos there for you on that. The other thing here is I do want to talk about my talk just briefly. And just to let you know that I did a lot of preparation for this talk. It really was the culmination of about a year's worth of research. I've done talks at other conferences before. I tried to let people know that this one was different for me. This one was very different because it was very personal. I was gonna be sharing things about my own medical diagnosis. And that's just not something that's common that I have in conference talks. I don't normally go into a conference talk and say, hey, here's what I was diagnosed with. So that made it very, very personal. But it's also something that is prevalent throughout my family. So I was sharing information from my family as well. Again, like I've said here on the podcast, I wouldn't share that if I didn't have permission. I don't volunteer that for others in my family. If they say that it's OK, then I will. If they don't, then I don't share that information. But it was very personal. And I was much more connected, I think, to the material. I really, really had a vested interest in the outcome. You know, I wanted to show some real practical ways that people could make small changes and become more inclusive. So that was my goal. And one of the things I tried to do, if you attended my talk, you may not even recognize all these things, but I wanted to first teach by demonstration. I wanted to kind of have things in place that... that would show that you can make small changes to be more inclusive. So just a couple of things I want to highlight here. One was a very, very, very subtle thing that I don't think anyone caught. But I did have music on that I turned down fairly quiet. I didn't want it to be that loud. I wanted to be loud enough for people to hear, but I didn't want it to be very loud. And I just had a playlist that was playing where I was playing one band in particular. I was playing a band called AJR. Some of you may be familiar with them, some of you may not, but AJR is a trio of brothers who are neurodivergent and their music is very neurodivergent friendly. They've sort of been seen as kind of, I don't know how to put it, but... figureheads, I guess, of neurodivergent movement. There's lots of neurodivergent people who go to their concerts. There's lots of commentary and stuff about how they're very open about that in their lyrics. So that was a slight little nod there. If anyone caught that, then congratulations. You caught the most subtle way that I did that. But that was one of the ways I was trying to make it a little bit more friendly. One of the other things I did, I turned down the lights in the room. There was overhead cans that you would have kind of typical in any kind of conference room. But they also had some like a chandelier that was over the middle of it. There were kind of some circles. And I found the light control panel and found out I could turn off the cans that were in the room and just have the overhead kind of chandelier. And it really kind of brought the light level down. It wasn't dark. It wasn't... so dark that you couldn't see in the room or anything like that. It was still enough that you could see. No darker than you would find in maybe a restaurant, right? But it was a lower level of light. And that was very intentional. I was trying to help people who had light sensitivities to not have to struggle or worry about that. So that was something I did intentionally. I. Probably the biggest thing I did was I set aside two tables at the back of the room that I call quiet tables. Most of the time you go to a conference, there's an expectation that you do some interactive kind of work there. I had a lot of data to get out, so I couldn't do as much interactivity as I normally do in a talk. But I did have one big activity that I did kind of towards the back part of my talk. And I wanted to have a couple of tables that if people just were not comfortable, group participation. They didn't want to have to talk to others. They wanted to just come and show up and take in the information. I wanted them to be able to do that. So I set aside two tables. I put a little sign on the table that said, this is a quiet table. If you sit here, please understand these seats are designated for people who don't want to be a part of group activities and would rather just sit quietly while we have any kind of a group activity. And I set those aside. And I. As people were coming into the room, I saw people that were starting to sit at those tables and I walked over and I just wanted to check on the people that were some of the first people sitting there and saying, I don't want to interrupt you. I just want to make sure that you've seen the sign so that you know what to expect here at this table. And I had these three wonderful women that were sitting at one of the tables and they responded very emphatically like, yes, no, we absolutely read that. We loved it and we felt like, hey, he gets us. And that just made my day. I was just so excited that they felt that way and they felt welcomed, right? That's kind of what I was trying to do is create a welcoming atmosphere that nobody felt left out. Everybody felt included, normal. I did some other things too, like we put out some little badges that said, embrace neurodiversity, that people could put on their name badges, just to kind of raise awareness across the conference from that point on. I also put little fidget toys at each spot that people could take with them. Just a small little fidget keychain kind of thing that people could have. Not anything terribly elaborate, but just a small little thing. So all these things were just ways I thought of in advance to try to make it a more welcoming environment for people to participate. Getting to the talk itself, as a speaker, I'm pleased with how it went. It kind of went the way I'd hoped it would go. One small technical thing with a poll that I did at the beginning, but you know now I'm kind of insider baseballing this and I don't really Didn't really Contribute hugely in any negative way. I was able to call out the numbers and we just moved on right That was not a major part of the presentation anyway So, you know, I'm I'm as pleased with how it went as I probably could have been for anything like that I I could tell things were resonating with people. I got nods. I got verbal agreement from people in different parts of the talk. So, you know, and we stay within our time box. We met that the way we needed to. So that all went pretty well. But you don't really know until after. And it's after that really kind of made my conference for me because... not just immediately after, but for the remainder of that conference. I spoke on Tuesday. It went on, the conference was Monday, Tuesday and Wednesday. So for the remainder of day on Tuesday, into the night on Tuesday, and then before I left on Wednesday, I just had random people that would come up to me at various points and thank me for giving the talk. I had one person tell me, thank you and said, I felt seen. And that just almost brought a tear to my eye. I was so excited to hear that. And that was part of what I was really attempting to do there, is I wanted people to understand that there are differences in how people process things and how people's brains work. And hopefully we can take that back to our teams and change how we approach how we work with our teams. I'm not going to go too much into the detail of the talk. We will make the slides available here in our show notes. So if you want to see the slides like I gave the presentation, I gave it the presentation, we'll make that available for you. There's no recording of it, unfortunately. The Scrim Alliance doesn't do that. They don't record them and then publish them later. Some conferences I know do. do that, but the Scrum Alliance is not one of them. But I will make the slides available to you if you want to dig into that more. The other thing I'd say is if you really want to dig in the topic more, find my previous podcast episode, which we'll also put in the show notes. That was with Susan Fitzell. She is a specialist in that area and helped me to understand some things. And that was a kind of key episode. on that topic. So those are some places I can point you to if you want to get into that, the heart of that, that topic area. But, you know, hearing those kinds of things, those personal kind of congratulations and just people who I didn't know who'd come up and say, you know, they felt seen and that just made the conference for me. I was so pleased that that was the case. Because just as it was very personal for me, it was personal for them too. It connected to them on a very personal level. And I hope that that can make a change in our teams. I hope that that's something that some of those people who are in the room can take back and implement just one thing. One thing they can change in how they work with their teams. All in all, it was a great conference. I really enjoyed it. And Scrum Alliance just put on a great conference this year. as they always do. They always put on a great conference. So thanks to my friends at Scrum Alliance for inviting me and having me there to speak. Thank you for all the volunteers who worked on it. Thank you to each person that I had a conversation with, especially the new friends that I didn't really know before the conference. I... I really enjoy, and the ones that I haven't seen for a while that I kind of got to rub shoulders with there. Again, I really appreciate you coming up and saying hello. And I did have a few people from the podcast who came up and said, hey, listen to the podcast. That's always a pleasure when that happens. It just helps me to know that, hey, this is actually resonating. This is making an impact for people. So. I heartily appreciate that. If you ever see me at a conference, please do. Don't hesitate. Come up and say hello and tell me that you listen to the podcast. You'll make my day if you do that. So that wraps up Scrum Gathering 2024, New Orleans. I should say global Scrum Gathering. And if you didn't attend this year's, if you're in Europe, maybe consider attending the Munich one next year. I don't know where the following year is going to be in 2026, but it will be back here in the States somewhere. And we'll have to wait and find out where that's going to be. On my calendar, the next conference I have coming up is an exciting one for me. It's Agile 2024 that's taking place in Dallas. So if you go to the Agile Alliance, agilealliance .org, you can find information about that conference and join me there. I'm going to be talking about conflict and how we can have conflict competent teams. So I'm excited to talk about that and dive into that topic with everyone in Agile 2024. So. Just wanted to give you a brief recap of what happened there and what it was like, and give you an insider view of what it's like. If you haven't ever attended a conference, I encourage you to give it a shot, especially, you know, I'm based in the Dallas area. If you happen to be in the Dallas area and you're on the fence about attending the conference there in July, you got no excuse. It's in your backyard, right? It's right there. You'll hear some amazing speakers. You'll widen your network. You'll be surprised at kind of the connections you make and what you walk away with from a conference. So just highly encourage you to give it a shot. So that'll wrap us on this episode. It was just me, so I won't do a separate little closing thing. If you wanna give me any feedback on this, just reach out to me and send me an email podcast at mountaingoatsoftware .com and I'll get that. Or you can go to our Agile Mentors Community and post in our discussion forum there. That's a place where you can interact with me. As always, like and subscribe, all that social jazz. Make sure that you... You keep this in your inbox. We always appreciate that. And as we always ask, tell a friend. If you liked the episode, if you liked any of our episodes, pass that on to a friend and let them know about this podcast that you found. That's it for this time. We'll see you again on another episode of the Agile Mentors Podcast.

Join Brian and Mike Cohn as they dissect the vital roles and responsibilities of the product owner, from story mapping to stakeholder management. This episode is a treasure trove for anyone looking to sharpen their Agile skills and understand the nuanced demands of a product owner. Overview In this insightful episode, Brian and Mike Cohn explore the multifaceted role of product owners in Agile development, discussing everything from market analysis and vision creation to the nuts and bolts of sprint planning and retrospectives. Emphasizing flexibility and adaptability, Brian and Mike offer a comprehensive look at how product owners can excel by focusing on strategic planning and fostering strong team dynamics. This episode is essential for product owners seeking to enhance their impact in Agile environments and drive successful outcomes. Listen Now to Discover: [1:07] - Brian welcomes special guest Mountain Goat Software and Agile Alliance founder Mike Cohn. [1:31] - Brian introduces Mountain Goat Software’s What Happens When for a Product Owner, and Mike flips the script, setting Brian, as the creator, into the guest seat on this episode. [3:16] - Join Brian as he explores the vital, behind-the-scenes efforts of product owners that set the stage for Scrum success, all before the first sprint begins. [6:24] - Brian explains the dynamics of crafting a product vision, clarifying how much responsibility lies with the product owner and how much is shared with the team. [7:46] - Brian offers expert guidance on the optimal timing for creating a story map within the Scrum process. [9:46] - Brian and Mike explore the optimal quantity of backlog items to have ready before adding them to a sprint. [13:45] - Join Brian as he explains the importance of setting a product goal in Scrum, detailing how it enhances functionality and guides the development process. [17:03] - Brian invites you to download Mountain Goat Software’s What Happens When for Product Owners, a comprehensive guide designed to support your Scrum journey. [17:43] - Brian explains how to effectively integrate road mapping into the Scrum process, ensuring it adds valuable foresight and preparation without causing shortsightedness. [19:55] - Mike suggests a strategy for managing stakeholders who overemphasize the product roadmap, offering a creative approach to preserve the flexibility and adaptability that effective road mapping allows. [22:48] - Brian delves into the critical role and strategies of effective sprint planning, essential for driving successful Scrum projects. [24:20] - Brian offers his perspective on the significance and involvement of the product owner in the daily scrum, detailing their role and contributions. [26:15] - Mike recounts a memorable story about receiving exceptionally impressive customer feedback at trustworthy.com, highlighting the impact of genuine client interactions. [28:30] - Brian emphasizes that the product owner is an integral part of the team and its goals, underscoring their collaborative role rather than being separate. [29:18] - Brian explores the crucial involvement of the product owner in the backlog refinement process, detailing their responsibilities and impact. [30:48] - Brian explains why he views the sprint review as the product owner's event and offers strategies for executing it effectively. [32:17] - Brian delves into the product owner's essential participation in the retrospective, emphasizing that their insights and experiences are crucial for the team's growth and improvement. [34:10] - Brian outlines ways the product owner can proactively prepare for the next sprint, ensuring a smooth transition and effective planning. [35:27] - Brian discusses a key pitfall that product owners should avoid to ensure success in their role. [37:35] - Brian shares a big thank you to Mike for taking over this episode of the show. [37:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. [38:08] - We invite you to like and subscribe to the Agile Mentors Podcast and share the episode with a friend who could benefit. [38:56] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. References and resources mentioned in the show: Mike Cohn What Happens When For Product Owners trustworthy.com Subscribe to the Agile Mentors Podcast Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: 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 (00:00) Welcome in Agile Mentors, we are back. We are here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and today I have the big man back with me, the OG, we've got Mike Cohn in the house with us. Welcome in, Mike. Mike (00:15) Hey, Brian, thanks for having me back. Brian (00:18) Always happy to have Mike here. Always a pleasure to have him here and learn from his experience. And really, really grateful he's here. We wanted to have Mike on because we have something that we put together recently. Honestly, it's kind of been something we've been talking about we just haven't put together. We had a document that we had out there called What Happens When for Scrum Master. And we just didn't have one of those for a product owner. So I did some work there on the side on that and put it together. And we're getting that out for people so that you can find that and download it from our site. And we wanted Mike to come on to share his wisdom in that area as well, because a lot of this is stuff that I put together. But we wanted to get Mike's insights on these areas as well. Does that sound about right, Mike? Mike (01:11) That's what we agreed to do, but it's not what I'm going to do. Brian (01:14) Okay. Sounds good. Mike (01:19) I'm going to turn the tables on you, Brian, because it's your PDF. It's your document. You're the ideas behind this. So I kind of want to turn it around and take over. I'm going to kind of interview you, ask you things. I mean, I'll chime in with opinions here, of course. I can never shut my mouth long enough to not share an opinion. But it's your PDF. I want to ask you some questions about it, if that's OK with you. And I assume we'll have the link for this in the show notes for folks. They can get the. Brian (01:41) Sure, fair game. Yeah, absolutely. Yeah, they'll be in the show notes. Anyone can find this. If you want to download it now and follow along, just pause, you know, go find that in the show notes and you can follow along as we talk through this. Mike (01:55) Great. So Brian, you separated the document out into things that a product owner does. And of course, I mean, kind of naturally you did it by timeframe, right? Do this before you even go and do this every sprint, things like that. I want to talk to you about some of the stuff that we do before the project that a good product owner should do before a project. You had in there a couple of things like do market analysis and create a vision. You tell me more about what you would expect of a great product owner in that world. Brian (02:25) Yeah, that first bullet point, what I was trying to capture is that there's some behind the scenes kind of product, standard product work that we don't really account for in a scrum sense. Things like market analysis and trying to understand the competitive landscape. There's a whole discipline there of activity and work that goes on behind the scenes. And I think it's important to understand, that Scrum isn't in any way saying throw that out or that that's not needed, that is something that would come, in my opinion, before you even begin this kind of work. Scrum does not include in it a process that would say, let's verify that they should fund this product. Let's do a pitch. So the CEO of, you know, here's why you should have this product. That's what I was trying to capture in that first bullet point is just understand there are some standard kind of product development work that goes on that we're not, we're kind of skipping over a little bit. Mike (03:36) That's one of the things I've always loved about Scrum is that Scrum is silent, deliberately so on many topics. And occasionally I will have somebody that I'll meet and they'll say, Scrum doesn't say how we should do product envisioning, right? It doesn't say how we should do that. So I guess we don't do it. It's like, well, Scrum doesn't say that you should code, right? Nowhere in the Scrum guide does it say code your software product, right? Yet if you're doing a software product, somebody's coding, right? Somebody's doing something. And so I like that Scrum is deliberately silent on a lot of things like this because you're talking about doing this market analysis. I work with plenty of companies that are doing internal software. And if we're doing internal software, we're not going to do a market analysis, just kind of internal user needs analysis perhaps, but it's going to be very different. And so I do like that flexibility there. Brian (04:13) Hmm, yeah. Yeah. So that's a good point, though, is depending on the product, it is sort of more as needed or as it would fit. Like you said, if it's an internal product, it's going to look very different than if you're doing a public -facing one. Mike (04:40) I think for any of the steps that you've outlined, I think they can vary. I'm sure some are going to be the same for everybody, but I always think of it as commercial development, right? We're making Microsoft Word, right? I think of it as in -house development, right? We're making a payroll system to pay our employees or contract development are kind of the three big branches to me. And then things get very different within those three types of development. I'm thinking more product development there specifically, but of course we can be using this for non -product things. Brian (05:10) Well, and I do want to say that that second bullet point, they're talking about vision. That's where I honestly, from my perspective, that's where the product owner portion of this begins, right? Because that's sort of the first thing you need to do. And in fact, when we teach our CSPO class, this is, you know, if you've been through a CSPO class with us, you will recognize this order because that's exactly how we go through it in our CSPO class, very deliberately. You know, that Mike (05:39) I'm sorry, I was getting off there, but I was getting interested in something you're saying there. So product owner kind of starting with the vision. I know that the team can influence the vision, right? But where would you draw the line or how much of the vision is the product owners? Is it like, you know, I'm the product owner dictator. Here's my vision, shut up and build it. Brian (06:02) Yeah, I don't know that there's one answer there. I mean, I have seen in certain situations where it's more of a group effort. And that might be part of that earlier genesis of the product, where we go through an effort to define the vision with other key stakeholders, with leaders in the organization. I do think that there is sort of a separate activity that I would take with the team itself. So I might spend a deal of time with key stakeholders developing a vision, but then I might also then have a separate meeting with the team once that's established to say, you know, here's kind of what we're defining it as. Let's walk through this. Tell me if you agree, disagree, or how you might improve or change this. Just so that we, you know, part of our job as a product owner is to cast that vision. and help people get caught up in the excitement for what it is we're trying to do. So that's kind of the purpose there I see of doing that. Mike (07:04) Yeah. Yeah, the more excited we get people about it, the better off we're going to be throughout the course of the project. You also have some things in here about things to do before the first sprint about identifying users, possibly go into the persona level, but then also story mapping. I want to ask you about the story maps for a second. What's your guideline? Because somebody asked me this recently, I'm curious on your answer. What's your guideline for when we should create a story map? Do you do always, only at the start, only in the middle? What's your advice? Brian (07:35) Creating it, I always created at the start. I mean, my, just, and again, this is my experience, right? But what I have found to be useful is to do it at the beginning. And it's sort of right in that order, right? I've done the vision, I've talked, I figure out who my users are. And then I wanna know what the general big picture is for my product. I wanna be able to step back from a 50 ,000 foot view and say, all right, here's kind of the step by step of what we're gonna be doing. Because, you know, kind of like a product backlog, it's a living, breathing document. It's not done, you know, we do it once at the beginning of our product and then it's done set forever. It's constantly adapting and changing as we add new feature areas, as we, you know, understand differently how our users would interact with the product. We're going to adjust and change it. I want it to always reflect reality. Mike (08:30) Do you, so let's talk about reality there. I mean, I agree with that, but what I see is story maps that are hard to keep up to date. Are you seeing teams that really succeed at keeping them up to date all the time? I know the living breathing thing for like a couple months and then it's like the dusty old story map, right? Brian (08:47) Yeah, well, this is kind of one of the things where it was kind of hard for me to put this in a time frame because there's really two time frames that I would like this to appear in. Yes, I do think we should do it before the first sprint. And by the way, again, there, I would do this in multiple rounds with different sets of stakeholders. But then once it's established, I kind of would slide that into that quarterly kind of activity to say, we may not touch it every quarter, but every quarter I would want to... Mike (09:03) Sure. Brian (09:16) check in on it and just say, is this still accurate? Do we need to adjust it? Do we need to do anything different about it? Mike (09:16) Okay. see that. A couple of the things on the before the first spring here, you've got identify assumptions, possibly test some of those, and then create a product goal. And then the last couple of you got, you know, get enough of the backlog written to get started. And a sprinkle, how much of the backlog do you think a team should have to get going? I mean, I know it's probably not like seven and a half items, but you know, you're looking for, you know, one sprint, one or two sprints, eight sprints. Brian (09:45) Bye. Well, no, Mike nailed it. It's seven and a half. Seven and a half items. No, just kidding. Now we can start. No, yeah, I mean, it's, you know, that's why I use the term enough, right? What is enough? Well, you know what enough is, right? You kind of know what that is. There's a, you know, there's a goal that we have in general that we've, lots of us trainers and coaches have put out there to say, Mike (09:52) seven and a half backlog items. There we go. Once you've written seven and a half, we can get started. Brian (10:14) you want to aim for about two to three sprints worth of items that are in ready to go shape. They're ready to move into a sprint and start at any given time. I don't know that you need two to three sprints to start. Yeah, I mean, I think you need, I think there's sometimes a hesitancy in teams to get everything documented upfront. And I'm trying to help people kind of push past that to say, no, we don't need to have everything. Mike (10:25) That's a start. Brian (10:42) We just gotta have enough to start. And when I'm working with a team, I wanna get them into that first sprint as soon as possible because they're gonna learn much more from just doing it than they are from talking about it beforehand. That's why I've never been a real big fan of like a sprint zero or something like that because it just doesn't take a whole sprint to do everything that you need to do to get ready for your first sprint. Mike (10:58) Right. Yeah, I think you're right. I mean, to me, I always put it in terms of like, we're gambling our time, right? Is it worth gambling more of our valuable time writing more backlogs, or should we just play and get started? And if we're a company whose name is invoices are us, right? You know, should we go ahead and write some stories about the invoicing part of the system? Yeah, I bet we should. But if we're not sure that, I don't know what we're building, but if we're not sure invoice is going to be part of it, don't write anything about that on the backlog yet. Just put one big item, do invoices, right? Break it down when you get there. So. Brian (11:36) Yeah. Yeah, I mean, you typically know where you need to start. You know, there's a million things you could do. But when you have a big idea for a product and you're starting fresh and you're starting new with it, at least in my experience, again, I found like, I always know where I'm starting. And that's what I would encourage you to do is just get it out there, get it started. Even if you don't have all the different features and aspects of it thought through, that's OK. Mike (11:44) Right. Brian (12:05) You just want to start making progress so you learn. Mike (12:08) That reminds me of something I've shared with a lot of leadership teams that I've met with over the years, which is that I'll tell them that they're basically solving the wrong problem. And they're trying to answer the question of what should we build? What should the product be? And that's totally the wrong question. The right question is what should we build next? What's that next one or two steps that would tell you what the next four or five steps will be? And so simplify the question, not what are we building, but what are we building next? And I think you're right there. Brian (12:26) Yeah, yeah. Mike (12:36) one sprint worth is enough and put in the backlog if you need to write more backlog items. Go from there. Brian (12:41) Yeah. And I don't want anyone to hear us incorrectly here. I mean, part of the reason that we had them there to identify assumptions and try to test hypothesis is I don't want to open a, the silly example I always use in classes, I don't want to open a store that sells lip balms online and not test whether people want to buy lip balm online or not. There's some fundamental assumptions that you're going to have to test and know. Mike (12:48) Thank you. Brian (13:11) probably before you're gonna even get with a team and start getting up and running on this. And that should happen here. Mike (13:16) Yeah. I was with a company, this is years ago, they were in Boston, we finished the engagement, I'm walking next to my rental car, and one of the guys walks out with me, one of the like VPs, and he's like, I got a question for you. He says, how often should we cancel projects? And I said, Brian (13:34) Seven and a half. Mike (13:35) I don't know, seven and a half. I said, I don't know. So I don't know how often, but you should be canceling a fair number of projects. You get started, you find out it's going to take twice as long as you thought, or you get started, and it's not really going to deliver the value that you hoped for. So you stop. And he's like, I thought so. He said something like, I've been here, I think, eight years, we've never canceled a project. And it's like, OK, that's bad. You should get into these and find out your assumptions are wrong. Brian (13:51) Yeah. Wow. Yeah. Mike (14:04) I want to talk about your quarterly items on here. And you've got a couple, let me just kind of read some of these here. So you've got establish a product goal. That's a relatively new thing in Scrum. I mean, I still think of 2020 as relatively new, but as a old timer with Scrum, product goal is one of the newer enhancements. You've got doing the story writing workshop. So you're supporting what you said there. Talk to me about the product goal here. Brian (14:19) Yeah. Yeah, so I feel silly talking to Mike Cohen about what a product goal is. Product goals are just that neck, they're a milestone, right? And that's typically the way I talk about this in class is to say, especially when you're starting something new, you may not know everything that you're gonna do, but you know the next big thing that you need to accomplish. You know the next big mile marker that you're gonna hit in the life of your product. Mike (14:56) Mm -hmm. Brian (14:59) And that's what we want to establish with the product goal. Something that's going to take longer than a sprint, multiple sprints to do. I've got this in the quarterly section. And that's kind of how we tend to talk about it a lot here at Mountain Goat. But even in class, we'll even say quarterly -ish. Right, right, bigger than a sprint. And sometimes it'll be longer. Sometimes it'll be shorter. That's OK. Mike (15:16) It's the bigger than a sprint section, right? Brian (15:25) You just want to have that big thing that the team can keep their eyes on and kind of know, you know, here's, you got a sprint goal that tells us why what we're doing in this sprint is important and how my small task feeds into that. And you've got this product goal to say, how does the sprints work fit into this bigger picture of what we're trying to do? So you're making those... Mike (15:47) Yeah. Brian (15:50) connections consciously for the developers so that they are not just, hey, here's a laundry list of stuff to do, but here's the objective we're trying to accomplish. Mike (16:01) Yep. I think it's important to have something that's out there bigger than a sprint. A sprint is just, it's just kind of suboptimizing, right? I think about if you're climbing a mountain and a sprint is like, what's the highest thing I see and just always walk into the highest thing you see. Meanwhile, those are all false summits. The real summit is, you know, behind some valley, but you don't see it because you don't set out that bigger goal. And I like how you talked about it quarterly because if the goal's too big, if it's too far out there, we're not going to feel very motivated. about it. I had this the wackest example of this. I hope the guy's not listening. Actually, I hope he is. But he was told me he was on a project with the large particle collider. And he said his whole project won't be due for 40 years, right? I mean, I don't get it. But it's like they've got to run like 40 years worth of data before it's like totally done. And I just picture myself showing up for work on a 40 year project, right? Brian (16:31) Right. Yeah. Mike (16:57) I know you, you're going to be reading Dallas Cowboys news for the first 35 years, right? You know, sports news and you know. Brian (17:04) That's a 40 year project too. Mike (17:07) Well, you're not going to take it serious for 35 years. Then you're going to wake up and go, the deadline's only five years away. I better get to work on this. And then what I would do is realize, wow, I'll be retired after 40 years. So anyway, I've been silly. But I mean, you're on a project with a 40 -year deadline. How do you say motivated? And I think three months is a really good time where I can see a bigger impact than a sprint. But it's not so far. Brian (17:15) Right. Right, right, exactly. Yeah. Yeah. Mike (17:34) that that student syndrome kicks in and I feel, I don't really have to worry about it. Let's go to a long lunch. We'll get to work on it tomorrow. So I do like the quarter -ish approach there. You mentioned here a couple others here. These are probably straightforward, but manage and maintain the economics of your project, assess stakeholder relations, and road mapping. You want to talk about any of those, maybe road mapping especially? Brian (17:46) Yeah, yeah. Yeah, road mapping, I think, is an important aspect. I mean, it kind of goes along with that product goal. But I do get people who come through a product owner class that will say, I don't like this approach because it seems like it's all so short -sighted. And we're not really having the big picture of where we're going. And in my world, we have this year -long thing, or 10 year. I've worked with some teams that build automobiles and they're on a three -year release cycle. They're working on the model year that's three years ahead. I've worked with some teams that do aerospace kind of stuff and they're working on a space launch that's multi -years out in the future. Mike (18:34) Yeah. Brian (18:43) And when you ask them, how certain are you that you're really going to be working on this five years from now? Pretty darn certain, right? Because it's there. We're building toward that launch date's going to be there. So I think that that roadmap is an important step for a product owner. Now, I just want to be clear about this. When I say a roadmap, I'm not talking about setting hard and fast dates and saying, we're going to be here by this date. We're going to be there by this date. Mike (18:50) Yeah. Brian (19:12) It's okay for us to say, here's kind of where we feel things are gonna fall, but I really am a strong proponent of the forecasting method, like kind of looking ahead and seeing, you know, kind of based on yesterday's weather kind of thing, right? Here's what the weather was like at this time last year. So it's probably a good indicator of where we're gonna be at this season this year, that sort of thing. So I'm a proponent of the forecasting forward. And I think a roadmap can fall very well in line with that because we can slot things and say, here's kind of this quarter's, here's the next quarter kind of things that we're thinking that are gonna take place. And if one thing moves forward or backwards, one of those sections, that's not a big deal. It's not gonna change earth shatteringly the course of our product, but it does allow for preparation. And that's what I think is the most important thing that people lose sight of in sort of forecasting and projecting forward is why do we do this in the first place? Well, we do it most of the time because there's someone else who needs to get ready. They need to be prepared. They need to be ready when this is delivered to do XYZ. And that's what we're trying to accomplish with this. We can do that with forecasting. Mike (20:32) Yeah, I think you talk about taking those things seriously. And if we miss one, it's not the end of the world. Except there's always somebody in an organization who's going to say it is the end of the world. The danger for me with roadmaps is how serious people take them. They'll look at it and go, we got a roadmap. It says we're going to come out with this in 12 months. I bet we're going to do exactly these 12 things. And so that literalness to a roadmap. Brian (20:50) Yeah. Mike (20:59) is scary. I've only done this a couple of times, but I like the result is I put together roadmaps for with teams in a couple of organizations. And we kind of modeled them on the idea of the old, I don't know, 200 or 300 year ago, 400 year ago maps, right? And you would have like, you know, the. horrible map of what the world looked like, right? And there'd be Darby Dragons right on the edge of the map. And we actually did that on a roadmap, right? It had stacks of items are going to be delivered. You know, this, this six months, this six months. And then below there, we had just put a few things in kind of an unreadable font at Darby Dragons below there. Trying to reiterate that you can't take this that literally, but there often is somebody who's like, my annual bonus is tied to that box on the roadmap. Brian (21:24) I'm going to go ahead and close the video. Right. Well, you can see this in, you know, I'm not going to get on a tangent here on safe, but you even see this in safe when people do things like PI planning and they plan out the next quarter. One of the pitfalls that I think a lot of organizations fall into when they do that is that they see it as a commitment. That the team is making a commitment to getting all that work done in that PI, in that program increment. And that's not the way it's intended. It's intended as here's our loose plan. We know what we're going to do in the next sprint, but the other sprints are Mike (21:48) Right. Yep. Brian (22:17) more fluid and we'll adjust as we need to. Mike (22:20) Yeah, I've written so many times about a plan is not a commitment or commitment is not a guarantee, right? You know, I can make a commitment to this. I'm going to commit to do my best. We're going to commit to try to achieve these. But I love a Clint Eastwood quote, one of his movies. He said, if you want a guarantee, buy a toaster. Right. So. Those are the days when supposedly banks used to give you a toaster when you open a new account, right? That. Brian (22:25) Yeah, yeah. you can guarantee a toaster in today's world. Well, we joke in our family because my wife's grandparents have a, well, they're no longer with us, but they had a refrigerator that was from the 1950s that was sitting out in their barn that still worked perfectly. But we had, you know, our refrigerator is, you know, five years old and it's already breaking down and you have to consider replacing it. So, yeah, yeah. Mike (22:49) precede my day, but I... Wow. It's all the electronics in them, I think, right? So I want to move on to the sprint planning. So from the quarterly planning. So in sprint planning, you've got this broken out by what people do in the planning meeting daily during the sprint. So I want to start in the planning meeting. You're proposing a goal and work with developers to kind of improve that, answer questions about backlog items, and talk about your schedule as the product owner share your schedule. You want to elaborate on what you're thinking about with these sprint planning activities? Brian (23:15) Yeah, yeah. Yeah, I mean, so I think a goal is important for the sprint. I think that gets us all on the same page and it's kind of one of the teaming aspects of it. We want to all have our eyes on the prize of what it is we're trying to accomplish together so that we're not all just in different places working on different things. I think it's important that we're there in sprint planning to answering questions because that's when they come up. We're making our plan for when we're going to do something. So I think it's important that we're there to kind of help them plan how they're going to accomplish stuff. Mike (23:59) Yep. Brian (24:08) We're not telling them how to, but we're giving them the information they need to determine how. And then, you know, as far as our schedule is concerned, I think it's a great idea for a product owner in sprint planning to say, you know, here's the next two weeks of my calendar. Here's where I'm going to be out of the office these days. I'm going to be at a client site on these days, just so that people can prepare. If I'm a developer and I know I need to get approval from my product owner and I know they're going to be out for the next two days at a conference or something, well, that might... guide me in how I'm going to plan and arrange my work. Mike (24:38) Yep. Some of my favorite POs have been ones that have done something like said, look, between one and two o 'clock every day is total team time. I will never schedule a meeting. I'll always be available if you need me from one to two or one to three or eight to nine, whatever it is, but they'll have some sort of window there that is basically guaranteed access. Doesn't mean that's the only time they're available, but it's a guaranteed time, which is nice. I think it's nice. Brian (25:04) Yeah, I love that too. Mike (25:06) Talk to me about the daily scrums and what you'd expect out of a product owner during the daily standups. Brian (25:08) Ha ha ha. Yeah, daily scrums are kind of a controversial thing here for lots of reasons, but I mean, there's some who would say a product owner doesn't need to be at a daily scrum. I disagree. I think product owners do need to be there. I don't think they're required. Actually, if you want to ask me my opinion, the only people I think are required are the developers, because it's for them, it's by them. You can't have it if they're not there. If anyone else is not there, you can still have the meeting. Mike (25:14) Thank you. Brian (25:38) But the product owner, I think, is important to try to be at as many of these as they possibly can. Because just like in sprint planning, they're making a plan for what they're doing, here it's immediately before they're going to be doing this work. So it's the time when the rubber meets the road. And here's where they're going to have some real practical questions. And if you're not there to answer them, you could hold them up. You could delay them. Mike (26:04) Yeah. Brian (26:05) I also, like you said, I like to use this as an opportunity to say, here's when I'm available today. Mike (26:10) I wake that product owners attend because of the message it helps sends as well. If the PO never goes, is this project important, right? Or team members start to think, we have to show up daily and say what we did yesterday, that that person never has to do this, you know? And we started to get some resentment towards them. So I strongly encourage product owners to attend. I'm like you, that don't require, but my requirement test is always, would I cancel the meeting if this person had a dentist appointment, right? Brian (26:16) Yeah. Mike (26:41) If the product owner had a dentist appointment in the morning of planning, I'd probably say, can we do it in the afternoon? My product owner can't make the daily scrum because I've got a dentist appointment? well. We're still doing the daily scrum. But you're right. If all of the teams, this will be silly, but if all of the team members were all having dentist appointments, yeah, we'd cancel the meeting. There'd be no point. So. Brian (26:53) Right. Yeah, the Scrum Master and Product Owner can't have a daily scrum, just the two of them. Mike (27:07) What should we make them do? Let's talk about what to do during the sprint. You talked about kind of ongoing research. So you don't want to do all the research upfront on this. Brian (27:09) Right, exactly. Right, no, it's a continual thing, right? I mean, if I'm working on my product and my competitor comes out with a killer feature that's starting to gain traction, I can't do that research upfront. That's something that becomes apparent as the product kind of goes along. So I think it's important that we keep in touch with what's going on in the real world with our product and the competitors. Mike (27:43) Mm -hmm. through the marketing, through the market. The thing you had next here was about connecting with customers to hear feedback. I want to share a story on this one because it literally just happened. I told you I was out of the office. I got back like 15 minutes before we wanted to do this recording. And I'd been gone all morning, so I talked to my wife for about five minutes. And she and I had come across some software recently that we're using that looks kind of interesting. It's things like, you know, when you die, who gets access to your Facebook? Brian (27:57) Yeah. Mike (28:18) password, right? And most of my friends are pretty shifty. So I don't want to give my Facebook password now because they'd probably go post weird things. But I want you know, when I die, I want that to happen, right? And so we're looking at various software that does those things like who do you notify when after you died? Brian (28:19) Yeah. Mike (28:35) And we signed up with this company. I'm actually going to share the name because I like them so much here in a minute, but let me say why I like them. My wife and I both had interactions with them by email about totally different things. One was a little bug that I came across and then something that I think she was asking about how does the future work. But here's what I love. They contacted her today and said, can we get on the phone with you and hear what you think about our product? They're a fairly new company, I believe. what you think about our product and what you think about how we've, in particular, have like the three tiers of service that we offer, right? You know, this feature, this feature. And I just love that they're doing that, right? Because not as many companies do that as they should, right? As they should. Because I love that company, so I'm gonna mention their name, trustworthy .com. Probably nobody listening needs them, but they are just this kind of like, you know, I don't wanna say like death planning, because they're not like playing your funeral, but it's like. Brian (29:23) Hahaha. Mike (29:28) Who gets your Facebook account? What bank accounts do you have? So your heirs can figure it out. Right. So, so. Brian (29:34) Yeah, yeah, that's great. No, I love having that mission if they're, they have good customer service. Yeah, definitely. Let's, let's mention them. Mike (29:40) Yeah, and my wife and I favorably disposed of them, and that just put me over the top with them literally a half hour ago. You talk about checking in with the Scrum Master, about how you as a product owner are doing, but also staying in touch with devs. Brian (29:46) That's awesome. Yeah. Yeah, I mean, I think that it's important for us to understand that we are not somehow separate from the team. We are part of the team. So we have the same goal as everyone else, and that's to deliver as much value as we can to our customers. We have a specific role, a responsibility to play in that. But I think checking in, partly I put that on there because. checking with a scrum master. That's something that we have on our scrum master sheet is to check in with a product owner. And I do think that those two need to kind of work hand in hand over the course of a sprint. And on an ongoing basis, kind of touch base to see how are things on your end? How are things on my end? And how can we help each other to kind of achieve our goals here? Mike (30:24) Yeah. Yeah, you often notice something about somebody else before they may notice it themselves, right? We've got a couple other meetings that I'll move on to. So let's talk about refinement. Can you share what your thoughts are for a product owner's responsibilities during refinement? Brian (30:43) Mmm. Yeah. Yeah, I mean, refinement, I always hesitate to even think about it as a meeting because it's kind of more of a series of activities. And you might have multiple meetings that would need to take place here. But yeah, I think that there's a lot of prep work that goes into. If I'm going to have the stakeholders come in and help me prioritize, I've got to prep a lot of that work. I've got to have the stuff that's ready to go prior to that meeting. I can't just show up and go, let's see what we got in our backlog. And we'll just kind of wing it. Mike (31:02) Good point. if What do you think about this product owner? I don't know. Let me think now. Yeah. Did I write that one? Brian (31:21) Right. Right. I don't even know what that is. I don't know. Let me read it. Right. That's just going to waste everyone's time and frustrate people. So I think there's a lot of prep that goes into that and prepping to go into anything like estimation. Do we have the right sort of things that are going to be estimated? I don't want to waste my team's time estimating stuff that's maybe really a long way in the future. And I'm not going to look at it for a while. So, you know, I think there's a lot of prep time that goes into that. And I think that, you know, we're at the center, at the focal point of any kind of refinement activity. as a product owner. So that's going to be, I don't really know exactly how those meetings are going to play out for you, but I think that there is some configuration there that you got to plan for. Mike (32:02) I'm hearing your message. There is the old boy scout motto, be prepared, right? It's a new product owner motto, right? We'll, we'll steal it from the boy scouts. you have any, that's true. Just don't take away my Girl Scout cookies. So let's talk about the, the sprint review. what do you think a great product owner does then? Brian (32:06) Yes, yes. Yeah. Well, that's okay, because there's no more Boy Scouts. So you don't have to worry about that. Right. wow. So this is our event. I really think of this as the product owners event. Yeah, exactly. I think you're the emcee. I think you show up, you host it, you send out the invites for it. What I typically tell product owners is kick it off with kind of a look back at some things that have been done recently by the team. Here's some features that we developed in the past three to six sprints and maybe even show some statistics about the impact those things are making. Mike (32:30) you Showtime! Brian (32:56) on the product and the market, on the customers. Our customer satisfaction has gone from here to there as a result of releasing these features, those kinds of things. So I think that the meeting opens that way. Then we move into the demonstration of the work and what we've done in that sprint. And yes, I would turn that over in large part to the developers so that they can demonstrate. But then I think it circles back at the end to come back to the product owner to say, all right, let's take a peek ahead. Let's look ahead what's coming up in our product backlog. Here's what our... looking at as candidates for the next sprint. And I think that's really important. It gives the stakeholders a chance to speak up and say, hey, what about this thing that I had that was really important? I don't see that prioritized. I really need that in the next sprint. I want to have those conversations in advance, not after sprint planning, when it's sort of locked in. Yeah. Mike (33:45) Tell me about the retrospective. One of the things I noticed you had in there was that you want product owners to attend every retrospective. There's going to be pushback on that from some teams. What's your thought there? Brian (33:59) Yeah, my thought there is, again, kind of reiterating that point that we are on the team, we are a team member like anyone else. And again, we have different responsibilities. We have a named kind of set of accountabilities that we have that may differ from others. But I kind of consider it like this. If I'm on a, in the US, we'd say soccer team, but if I'm anywhere else in the world, I'd say football team. If I'm on that kind of a team and I'm the keeper, the goalkeeper. I've got a very unique role, right? I mean, there's a set of things I do that no one else does. I'm allowed to do things that nobody else is allowed to. I'm allowed to touch the ball with my hands. Nobody else is, right? But if there's a team meeting, you're not gonna have a team meeting without your goalkeeper. They're an important vital part of your team. And that's what this is. It's the team meeting to get together to say, how can we get better? How can we improve? What's going on? What's wrong? What's right? And what do we wanna focus on? Mike (34:36) Right. Yeah. Brian (34:58) So I think it's vital for a product owner to be at every one just because like I said, we're a team member. Mike (35:04) I agree. To me, it's always like, if you don't feel comfortable having your product owner at the retrospective, that's the first thing I want to talk about at the retrospective. Right? It would figure out why we're not comfortable with that so we can move past that. I do like here in the retrospective, you talked about having the product owner commit to making progress on the improvement items, which I think is important because sometimes it is product owners who have to improve. Right? So. Brian (35:31) Yeah. Yeah, I mean, one of the things we'll talk about in class is how the product owner is a vital communication relay point. They are the, I call them kind of the, it slipped my mind. What's the stone that had the different languages on it from Rosetta Stone, sorry. They're kind of the Rosetta Stone, right? Because they speak tech with the developers. They speak. Mike (35:36) Mm -hmm. Rosetta. Brian (35:57) business with the stakeholders and they translate across those two groups. So I think, yeah, I think it's important that we're there to try to, if there's communication issues with us and the developers, this is the place to work it out, right? This is the place to say, what do you need from me so that it's more clear the next time I write stories. Mike (36:02) Yep. Yeah, that's a good point. What about for the next sprint? What should product owners do this sprint to be ready for the next one? Brian (36:24) Yeah, excuse me. Yeah, I think it's important that we really get a handle on what should be prioritized, that we have a good understanding of what's going to be coming up, that we have that idea of what our next proposed sprint goal might be, where we're focused on stuff. And as I said, I want to check in with my stakeholders, especially my key stakeholders, on that prioritization so that it's not a surprise to anyone. I don't want to. I don't want anything to be a surprise when it gets to sprint planning. By the time we circle back around in sprint planning, I want my developers to have looked at these things multiple times before they see it in sprint planning. We've had estimations. We've had discussions about these. So there could have been multiple times we've had conversations about these. So by the time we get to sprint planning, it's not the first time we're looking at these things. Mike (37:00) Yeah. Yeah, it should be a surprise. Brian (37:15) And that's kind of what I'm trying to allude to here is that there's a series of activities that just are kind of the glue between one sprint to the next sprint. And if we kind of drop that ball in any way, like I said, I can't show up at sprint planning and sort of just say, well, let's see what we got, guys. I have no idea what we're going to do, but let's just take a look. Yeah, I can't wing it. Mike (37:30) Right. Yeah, wing it. Yeah, that's not a good approach for things. Brian, you told me a lot of things that product owners should do. I want to twist it a little bit and ask you for one thing product owners should not do before the sprint, during the sprint, before the project, whatever. What's one thing, the one thing you would tell product owners to not do? Brian (37:57) Wow, that's such a great question. I think probably the number one thing that I would say is to understand the boundary between the what and the how, and really to try to stay out of the how. What I mean by that is we're in charge as product owners of the what side of the equation. What is it that we're going to be doing? What are we focused on? The developers are in charge of the how. How do we accomplish this? What's the best way to deliver this? And I... I know as a product owner in my past, I've always struggled with that balance of, yeah, but I've got a vision in my head of exactly the way I want it to play out. And I have to kind of rein myself back in a little bit and say, yeah, but kind of remind yourself that that's not really my role here. My role is not to explain exactly how the page is going to need to look and exactly how this feature plays out. If I have no really discernible reason that I have to have it one way over another, right? If there's not like a legal reason or compliance that I've got to do it one way, then I want to as much as possible stay out of the house so that the developers really get to exert their expertise. Mike (38:59) Right. Yeah, that's where they're going to be, they're going to be best at. I was describing it as that there's, there is a fine line between what and how, which is why people often will struggle with it. the way I think about it is like every time we dip into that, how at all product owners dip into that at all, they start to kind of take away degrees of freedom from the team. The team has less maneuvering room on how they're going to solve the problem. And great, take away one degree of freedom here and there. It's not going to be the end of the world. Take away too many, and you over -constrained the solution. The team doesn't engage as fully. All sorts of negative things, as you've touched on. Brian (39:39) Yeah. Mike (39:40) Brian, I want to thank you for letting me take over and turn the tables on you and ask you the question. Since you had made the PDF, I wanted to be the one asking you what your thoughts were on your great PDF that we have for folks. So I'll turn it back over to you. Let it be back to your show now. Brian (39:41) Hahaha I... Yeah, no, well, thank you very much. This has been a pleasure. It's been really fun to have to see what it's like on the other side of the table a little bit. So thanks for being willing to do it, Mike, and thanks for being willing to share your insights as we walked through this.

Proft Streams BookTranscript:Agile FM radio for the agile community. Today I'm thrilled to have Luke Holman with me in the podcast here of Agile FM and I can't believe After all these episodes I had so far I haven't had you on the show, which is a big miss. You are a renowned expert in agile methodologies an author. And I think a lot of people know you from the innovation games which is a framework for collaborative decision making problem solving.You have experience that dates back way, way back into the 1990s, pre Agile, but also I heard recently that you were involved in the 2003 Agile conference. So yeah, a while back. Welcome to the show, Luke. [00:00:46] Luke Hohmann: Joe, I am so happy to be here. I've known you through the community. We've seen each other at conferences.And so it's a, it's quite an honor to be here. Thank you so much for inviting me to participate. Thanks [00:00:58] Joe Krebs: Yeah, no, absolutely. We could talk about the innovation games and fill an entire show, but today we could, but today we want to talk a little bit about value profit stream, the agile community as often. This is the recordings taking place on the 25th of June, 2024 is a little bit in a turmoil. The Agile community as a whole, there seems to be some different kind of directions people are going, looking at the roles. It's maybe a good time to talk about what value is, how we can present value because at the end of the day is, it's like, how do we sell agility within an organization or for organizations?[00:01:44] Luke Hohmann: I think it'd be a good thing to talk about. There, there's so many aspects of this that are interesting, but let's try a few. And I'll also talk about the rule of self interest in the Agile community. When we talk about value we think about it in terms of our Profit Streams book and our Profit Streams work as What are the set of tangible and intangible benefits that a product or service we use solution as the single term for product and service or any blend thereof.So it's just a little easier because we're here to solve problems for our customers. So we think of both the tangible and intangible benefits. And for the tangible benefits, we help companies create mathematical equations that capture the benefits. And we often work with our clients because technical people are good at being efficient in terms of doing things like saving time.But the reality is most companies don't need to save time. They need to have the time converted into a metric that they can understand for their business purposes. One of the examples we use in our book, and it's been proven in many of our client engagements, Is we were working with a trucking company, and they were going to be buying software that saved their drivers time.So drivers in the trucking industry have to keep detailed logs of their hours of service to make sure they're taking breaks, etc. And this solution enabled the data to be acquired automatically by connecting into the engine bus. And they knew if the truck was on and if it was moving and all that kind of technological internet of things capability that we love.And there's so many things that we can do. So the company that we were working for, and this was Qualcomm had the solution. They went to the trucking organizations and said, Hey, we can save you 20 to 30 minutes a day in driver time. And Joe, we were able to prove this. Absolutely through, the data, like the data was very clear.And the trucking company's executive said we don't really care about that. Because our drivers are union and they are paid for eight hours. So saving me 30 minutes of a driver's time doesn't actually save me money. It doesn't do anything for me. So we had to go back to the drawing board with Qualcomm and find out how to reroute drivers using the new systems so the trucking companies could deliver another package or two in a day because that's how they made money through package delivery.Or the other part of this would be the intangible side and intangible benefits can be quantified on the intangible side for challenging deliveries. We were able to allocate more time in the driver's schedule so that customer satisfaction improved. And as customer satisfaction improved, we would see less churn among customers.Oh, my package was delivered well. I want to use this company again. My, my package was delivered without any breakage. I want to use this company again. So the first step of value is to actually take a step back and try to quantify the tangible and intangible aspects of value. And then I'll just real quickly, I'll finish that off.The second of the determination of value is what we call direct and indirect benefits. A direct benefit is something that you will recognize as a benefit and it materially affects your purchase or use decision. An indirect benefit is something that you recognize, you'll say, yes, the benefit exists, but it doesn't influence you.And I'll give you a kind of a standard example. My wife and I were out shopping for a new car. I cared a lot more about the styling and color. She just doesn't care about that. And and she would readily agree yeah, that's a good looking car, but it doesn't affect my purchase decision.Whereas I was, hey, that's a really good looking car. I think I bought it. And so now let's take it into the business context. The solutions that we're creating, which are often very sophisticated, there's a collection of benefit. It's not a single benefit. And collection of benefits, you create a network of how the customer perceives those benefits.So let's go back to a trucking company that is focused on customer satisfaction is not going to really care about the not care as much. I shouldn't say they care. They don't care at all, but they're not going to care as much about like driver satisfaction. But let's say you're a trucking company and a part of.The world where it's hard to attract drivers. Now your network of benefits might emphasize driver satisfaction. So understanding not just what benefits are, but how a given market segment is going to perceive the collection of benefits is really the foundation of our approach, and then from there, what we do is from the benefits, We can derive the customer return on investment model.We can derive your pricing and packaging model. We can help you develop your solution so that you know that you're building a sustainable offering. And I'll close with this Joe. The foundation of profit streams is sustainability. If you're running a business, Or frankly, if you're running a household, you have to have a positive flow of cash coming into your business or your house, right?We can't, other than the government who prints money, right? Like a business has to have a profit to survive, to sustain itself. Now, in some cases, profits can be misused or we can have unsustainable business practices. But if you look at true sustainability involves.Three related areas. One is your solution itself has to be sustainable over time as your customers evolve as their needs evolve Your solution has to evolve to be relevant and to meet their needs So with the first part of this is solution sustainability The second part of this is economic sustainability Are you charging a price that will keep your company in business?But are you also factoring in your customers total cost of ownership? So that your customer perceives what you're selling to them as a good value something they want to keep The relation going right? We want to have economic sustainability and then the third kind of sustainability is relationship sustainability when we Sell software.We're not actually selling software. We're selling a license to use the software So the distinction is that i'm holding in my hand a pen You If I sell you my pen, I've transferred rights to you. You now own the pen. You can do what you want with it. I don't sell you software. I license software for you to use.So there's a license agreement and that license agreement determines our relationship as the provider to the customer. There's other relationships that matter. Every software package that is created has technology and licenses associated with it. So the provider is in licensing work, and there's relationships that they need to maintain.And of course, the kind of the capstone of all of these things is our relationship to society and to other parts of the world. Of the global infrastructure in which we live. And what I mean by that is if you're in Europe, you need to honor GDPR. If you're in the United States, you have to honor California CCPA.If you're selling certain kinds of fintech software, you might have to be PCI or SOX two compliant. If you're in the healthcare industry, you'll have to be HIPAA compliant. If you're in the education industry, you have to be. FERPA and COPA compliant. So the idea of compliance to us is part of that relationship.What is the relationship your company wants to have with various regulatory agencies? Are you going to try and be an organization that honors those relationships and fulfills your compliance requirements? Or are you going to be an organization that's going to try and skirt those requirements? And perhaps engage in questionable or provably unethical behavior, and so all of that is what comprises profit streams.[00:10:42] Joe Krebs: Yeah, this is it's very interesting. And as you were elaborating on this, especially on the economics, sustainability It's interesting, right? Because I think we all have seen situations as a consumer before where we felt like I need a certain service or a product, but I felt like this was too, too expensive.I've felt abused based on a very specific situation I'm in and I'm requiring a service or a product. I feel like everybody can relate to that. So finding that kind of fair spot, yeah. In terms of sustainability, I can totally see that as well as the other ones as well. So I think that's a great example.Now, if somebody hears the word profit stream, at least the first thing that came to mind for me said, what's the difference to value stream, right? [00:11:24] Luke Hohmann: That's a great question. And we should know the distinction between a profit stream and as a value stream. I credit this to my friend Avi Schneider who is well known in the scrum community.Avi, after reading the book, he said, Luke, I've come to learn and realize that all profit streams are value streams, like all squares are rectangles. But not all rectangles are squares. So the distinction that I like to talk about Joe is that typically a profit stream is going to be more aligned to what SAFe calls an operational value stream and the development value stream of SAFe would be a cost center.So now let's look at value streams and let's look at specifically operational value streams. We think of profit streams as those operational value streams that are generating revenue for a company. And so not all value streams generate revenue. For example, there are value streams provided by. Government entities that don't provide revenue, but provide services that maintain our society, which we need, and those are fantastic.But not all not all value streams are profit streams. And that's a good distinction. When the other thing that's interesting, and I give a talk on this. Is when we look at value streams, especially the operational value stream, you start to find that. We have a starting condition and we go through a sequence of steps and we get an ending benefit.Actually map in your operational value stream. When revenue occurs, you'll find that many things are costs until the very end. It's like value streams are rainbows, right? The pot of gold is at the end. And so you really have to make sure that you're understanding the steps in that operational value stream.And what we work on with our clients is that we try to help them understand the economic sustainability of looking at that sequence of flow to make sure that you are generating enough revenue at the end to support the whole flow and looking at ways you might be able to pull revenue sooner so that you can sustain yourself.[00:13:45] Joe Krebs: All right. How do you respond to somebody who is like possibly interested? Here's the word profit stream. Obviously I see dollar signs and signals and cha-ching and all of those kinds of things. For an agile audience out there who might say, Hey, but what about the team spirit? And what about sustainability of a team's, fun and learning environment?Aren't they contradictory to this? I guess the answer to that is no, right? But it's the, [00:14:14] Luke Hohmann: of course, all of those, Joe and for the listeners, Joe and I were chatting before the podcast we often do. And one of the things that I really find disappointing in the agile community is a lot of agile people seem to have this kind of disdain for management or this disdain for leadership.[00:14:32] Joe Krebs: And I think of it exactly the opposite. Business leaders over the last 20, 25 years have shoveled hundreds of millions of dollars into agile practices and transformations between the training and the tooling and the infrastructure. And they've gotten benefit from agile. I'm very proud of all the things that software people do.Earlier today I was getting a blood test. And I walked in and there was a kiosk and you just typed in your phone number scanned your driver's license and you were checked in. Software people did that. And I think what we do as software people is really cool. Yeah. Hardware and software. We designed a solution that was amazing.And of course, Joe, we want to have sustainable practices, not just in our business relationships with our customers, but true sustainability means sustainability with our employees, with our practices. With what Kent Beck wrote about very early in the community with XP, like XP is about sustainability.So to say that profit is antagonistic to sustainability is to have a very flawed understanding of what sustainability is and or what profit is. I've been a serial entrepreneur. I've started and run and sold a couple of companies. And it's really a lot of fun when you're an entrepreneur and you can give out bonus checks because you had a great year Yeah, it's not so fun when you had a bad year and you're cutting salaries or you're doing other You know doing a layoff or whatever.And so for the people in the agile community who talk about humanness of our developers my response is Yes, heck yes, we, those are things that promote sustainability. Those practices, the training the better tooling, the better computers, they require money, they require a profit.And most of us work for a for profit company. It is, I think it's pretty above average that people would be working for profit rather than for the non profit sector. Should we go a little concrete about some data points, metrics, because I don't want to I'm just going to say the word.We really don't have to go down that path at all in this kind of conversation. I think we have debunked the word velocity as a metric or something like that. I don't think we have to talk about that. But what are. Measurements, like if somebody would say, Hey, this sounds very interesting. Definitely trucking sounds good, but I'm in a totally different domain.In terms of this, I would what's a good starting point for people to say, like, how do I measure these profit streams from an IT perspective or, Yeah. [00:17:18] Luke Hohmann: And Joe if I'm not answering the question in the way that you're intending the question that's okay.I started as an engineer and for everyone listening, Joe and I had a really, a geeky out moment when I, when we started, but I started as an engineer. And then I became a manager of engineer and then I became, vice president and all that kind of stuff. And I was always trying to create the best solution for my customers.And along and in that journey, I found product management. I thought, Oh, wait a minute. Product managers are the people who are designing the solution and working with designers on the user experience side. And they're in the center of the world of this thing called creating a great solution for customers.And through that. conversation, I started to realize, Hey, I'm responsible for creating a return on the investment of the company I'm working for. And from there, I started to learn the basics of finance. And I started to, understand how to read a balance sheet, how to read what is EBITDA what's the difference between CapEx and OpEx.What is the terms of the license agreement? What is, what can go wrong in a license agreement? If it's not crafted correctly for a company, how do I know if I'm making enough money, has my economic, let's go back to the engineers has my economic model factored in a pay raise for my team next year, because there's inflation and if there's inflation and I want to pay my developers more money, How do I manage that with my margins?Either my costs are going down, which might happen. And, maybe my software part of the solution is the same price, but my hardware margins are improving because I have cost of scale manufacturing. Maybe I don't, I'm a pure SAAS company and I'm picking up some lower costs because of hosting costs are dropping.How do I economically think about these elements? So the, what I would say is this is one of those areas where Agile has to do nothing more than embrace what has been existing for a long time, which is economic models Don Reinerson's work on flow. Looking at possibly throughput accounting, but educating ourselves, educate product managers, educate themselves on what's in our book, which is not just how do I economically model, but how do I actually. Set the price point. How do I determine the packaging of what features go in? What edition of my offering and do I charge? So those kinds of things are to me they're not taught as much as they should be in the agile community, but that's why we wrote the book. [00:20:10] Joe Krebs: Oh, absolutely. I agree with you.And I think indirectly you are answering the question, at least for me, right? Because I do see certain data points being captured within agile teams that are contradictory to what you're saying right now. These are like the velocity discussions and that are happening within teams. And then all of a sudden they happen on the leadership level, whereas you're saying, actually, some of those conversations are still existent as they were before agile, but they're still applying it.Just they have to be maps. I feel like you're having a much more adult mature kind of conversation about this. And I think we're actually experiencing within teams on the ground. [00:20:48] Luke Hohmann: Yeah I think the Agile community has gotten a little wrapped up around the Axel about, I helped form the first conference in the Agile Alliance series in 2003 with Alistair Coburn and Ken Schwaber and Rebecca Wirfs Brock and a few other people.And Todd Little, and let me tell you, no one at that conference was walking around arguing about the fine distinctions between output and outcome metrics and things like that. We both have a friend, Kenny Rubin, and he's written very beautifully about this. But trust me, in the very early days, we weren't arguing about those.It's like people drink fine wine and argue, Oh, are you getting black current or dark cherry flavors in the wine? No, just have a glass of wine and enjoy it. Um, and what's happening is we're forgetting that sometimes you do need to track certain basic metrics just as a mechanism Of I think consistency and let's say you're an athlete.Let's say you wanted to run a marathon. The number of miles you run in a week or the total miles that you've run in training for American a marathon could be a vanity metric. Oh, but at the end of the day, it's also the truth that you're not going to go run 26 miles if you didn't train And a training program is going to tell you how many miles you need to run Per week and if you're not tracking how many your miles you're running per week You're not going to hit your end goal of running the actual marathon So I think that so many other aspects of what we do, there's a very healthy way to look at velocity and velocity metrics and looking at flow metrics and unhealthy ways of looking at it and rather than throwing everything into a bucket of healthy and unhealthy, we should use the agile principles of retrospection.This metric and the way that we're using us, helping us advance towards our goals. Yeah. And it is, we should probably keep doing it. And if it's not, we should look at what we need to change. [00:22:52] Joe Krebs: Yeah. It's very interesting. I also, while we were talking about the marathon, I was also thinking yes, there's definitely mileage.This is an important piece, if part of your training program, but it's sometimes, and I don't know if that makes sense, I think sometimes we're measuring how many minutes we also have used for stretching, and yes, it is. a great technique to become a marathon runner, but I don't think from purely stretching, you're becoming a good marathon runner.I think it's together. And I think it's also for metrics like these things have to balance each other out. If you're having 90 percent stretching and 10 percent running, maybe that's the wrong [00:23:25] Luke Hohmann: that's where wisdom comes in. And that's where not always trying to invent everything from scratch, right?If you were, if you really were going to go run a marathon, you'd probably go talk with other runners. You'd probably go to some running websites that like runner's world that has reputable training plans. You'd get a sense of the balance of the metrics. So it's. It's very rare that one metric on a development organization is going to be the only metric that you needed.And again, this is where people start to it's good to have these discussions to calibrate. But it's like the definition of done, right? At the definition of done, you might say our definition of done is no stop ship bugs where stop ship is defined as P one and sev zero, like separate priority severity.Then you get into people who are like if I have no stop ship bugs, but I have a bunch of small bugs, can I still ship? And I'm like, I don't know like maybe no, maybe yes. What's the, we should have a conversation about that. And the metrics are designed to use to guide us into the conversations that are most beneficial, just like.So if I looked at a team that had velocity metrics, and they were reasonably consistent. And I saw an anomaly, like a dip. I, as a manager, if I didn't already know, I would go to the team and say, Hey, I noticed that your velocity dip, everything. Okay. And if the team says actually, no Joe went on a ski trip and broke his arm and our velocity dip, cause he was in the hospital.And we're all really worried about Joe. Wow, that stinks. Maybe we should send Joe some flowers or some get well, but now I know why velocity dipped. Yeah, and it was a special cause and it'll resolve itself. Um, now the other element could be our velocity dipped because we completely misunderstood the requirement and I'd be like, okay maybe we should toss that into a retrospective.There's so many good retrospective techniques. Maybe we should toss that into one of our retrospective techniques and see if that's a special cause or if there's some other potential issue that the team might be facing. And then the team goes, Oh yeah, no, we think we're okay. It was just this one time.We didn't really understand the requirements are no, we're actually in a new area of our solution and all of us are experiencing this new thing and we need more training or we need X to really get ahead of the issue. So metrics are important, right? We keep score, right? We keep track of things.[00:26:03] Joe Krebs: Yeah. So it's interesting, right? Because we, you mentioned before that there is this general amount of metrics. Don't want to repeat them necessarily, but these are like the business metrics. And these are the things that our businesses are already using on an enterprise level with or without agile.Why are we having such a hard time in the agile community to translate that? Obviously, your book will help in the translation of all of those things. But what do you think of the pitfalls? [00:26:29] Luke Hohmann: I actually think one of the pitfalls is how some of the agile methods have defined what a product owner is.You'll see agile methods say a product owner is responsible for value. Which is great, but then they don't define it. And so we've got a generation and I spent most of my formative business careers here in silicon valley, not all of it, but a lot of it So i'm used to a silicon valley style of a product manager Knowing how to run a spreadsheet knowing how to do pricing and being trained And what we're finding, I think, Joe, is that there's this tremendously large number of people who are associated with products, but don't have this training and pricing.They don't have this training and licensing. I'll, one of the things I do with my clients is I'll walk into a situation where they're, they need to, make an improvement economically. And I'll just go to the product managers and I'll say, when was the last time you read your own license agreement, your own terms of service on your website?And they'll be like, Oh yeah. never! Like, okay we should read it. And I'll give you an example of kind of the weird things that can happen in license agreements. We were working with a smaller company. And their license agreement with, so they served larger companies and it was a conversion company.I don't want to go much further than that. Yeah. They had a contract with a larger company that said every time the larger company made a request to the smaller company and the smaller company agreed to that request, their maintenance agreement would automatically extend for one more year. So every nine months, the big company would make a request to the small company.On a very small change, the small company would make a very small change. And then now they're saddled with a responsibility for another year of support. And I said, okay this two sentence clause in your license agreement is now costing you almost 300, 000 a year. Now for a big company, you may not notice it, but this was a company with less than 8 million in revenue.That's a noticeable number for a company with eight million right now. It's still a nice company. Don't it's not it's a very good business but i'm like this two line sentence in your license and the product manager was like wow I didn't know how to interpret that. I think we're seeing this challenge in the agile community because too many Organizations have allowed this skills of pricing and economic sustainability modeling to activity.Yeah, let's say you're, let's say you're agile. I don't care what flavor of agile you're using, pick one. I don't, there's so many, it's like going to the ice cream store. So you pick one and you're putting out more value at what point. Should you raise your prices because you've added so much value?At what point should you adjust your packaging? We work with a client who they kept on shoving features into their solution Which sounds great, right? But then their sales started to slow down and that the head of Product contacted me and said it's really weird luke Every time we're adding more features our sales team is telling us it's harder to sell that's a packaging problem because what's happening is people are saying Your solution now includes Features that are not relevant to me Therefore I want a lower price because i'm not using them.That's right And the right solution is to say okay now that our product has grown in sophistication We're gonna go take this market that wasn't segmented And we're going to make it a finer grain segmentation, and we're going to really understand the needs of these customers and take this wonderful platform we've built and offered these solutions or these features to this market segment, these features to this market segment.And after we did that work with that client. Their sales returned to a healthy growing number because people bought what was relevant for them. [00:30:49] Joe Krebs: This is awesome. Luke, we started off with also with a side comment or I might have started with this agile community being in some form of transition.Yes. And I want to end with this for our podcast as well. Now we talked a little bit more from the company's perspective, from the leadership level what I have noticed, and I don't know if you would share that thought is there's a lot of agile coaches in the transformation space and organizations, and they don't really know for sure if their work actually had an economic impact for the organization.Like they say like it feels better or it feels, we feel more profitable, but do we have evidence of what we had before to what we have now? How could profit streams help future coaching and coaches out there on, not from a product perspective, but more from a transformations perspective, how can profit streams help them to make a case for themselves to actually say, Hey, the agile community is alive and kicking.Why? Why? Because we are. Increasing the economic side of organizations by X, Y, Z, what kind of parameters would, what coaches need to tweak to say okay, these are like the parts of our puzzle where we can actually make a case for ourselves and say Hey, agile coaching is important. Agile teams are important.You call them the ice cream flavors. The agile processes out there are important for you to be successful for whatever is hitting your organization in the future. How would they use that kind of profit stream?[00:32:20] Luke Hohmann: I'm inspired by there's a gentleman that if you haven't had him on your podcast, you really need to get him.His name is Peter Green and he runs a company called Humanizing Work. He's a known in the Scrum community and he used to be one of the leaders at Adobe and Adobe's transition to more agile practices. And I remember that one of the metrics that Peter really tracked was just one thing, defects found in production.And remember I said that there was only, development teams need multiple metrics, but in this case, he was using the one metric that really resonated with his leaders and he showed his leaders how when defects in productions were reduced, customer satisfaction increased when customer satisfaction increased, renewals increased.The cost of customer care went down because there's fewer defects. And fewer upset customers, developer satisfaction went up because instead of fixing bugs, you're building new features. And so what he did was. He took the time to translate something that was just a number of defects found in production into how it expressed itself in a relevant profit oriented way.So my advice to the agile coaches out there is if you believe that you're creating a more effective, more efficient, more effective, doing the right things, more efficient, doing them effective, doing them well. If you think you're creating and contributing to this organization and, for example, I'm an agile coach and my team is quote unquote happier.What does that actually mean? What, we know that stable teams, like we have data on stable teams, that stable teams produce fewer bugs. That's an argument for stable teams. So what is the data that shows that coach is creating an economic impact that is relevant to the organization? And I am said this for decades.I am always concerned that people focus on trying to achieve the happiness of developers. When I think that the happiness of developers is an outcome of other elements, meaning if I'm a developer and I have Dan Pink, if I have reasonable autonomy, I have reasonable mastery, I, I have a purpose, right?Then I'm happy. But focusing on happiness doesn't mean I'm getting autonomy. Giving me autonomy, making sure I'm trained, making sure I have a purpose. Those and I definitely think that the many of the coaches I've seen, um, they don't always understand what the deeper opportunities might be.[00:35:08] Joe Krebs: Yeah. This is some awesome advice here. And I did not have Peter on the podcast and Peter, if you're listening to this, expect a call from me. Thank you, Luke. This was really insightful. And obviously I will share the book information for all the material on the show page of Agile FM, I just want to say thank you for sharing a very different view on things from what I had in the past in terms of guests and just chat a little bit about profit streams and make this really tangible for people of what they need to, establish within the organization to be successful and ready for the future.[00:35:42] Luke Hohmann: Yeah. And Joe, thank you. I'm going to leave just two more things for the listeners. I think they're important right now. We do think the agile community, many of us who've been there a while. And many of the leaders, we think the agile community is in some form of transition or some form of change, which means.It's up to you as a listener to decide what you think that future is and then work towards that future. A few years ago, my colleague Jason Tanner and I, we sat down and we were at an offsite and we said to ourselves, where do we really believe a future or part of the future of Agile has to be? And we decided that a part of the future of Agile has to be a return to the economics. of understanding profit and sustainability, and we acted accordingly, right? We wrote a book. We've got a partner program. We're doing consulting work. We're seeing our consulting business and profit streams is skyrocketing in terms of growth because we're finding that companies are going, wait a minute, You guys are right.You're We've invested in agile. How do we measure the return and how do we make sure that we're creating a profit? So and i'm not arguing that people have to buy into our perspective What I am saying is if you assert that the agile community is changing You can't just sit there and complain about it You have to decide what part of that future you want to create And what part of that future you want to be a part of and from there?You Your life will have purpose. Your life will have direction. And I think that's part of what's happening in the agile community right now. We're seeing this kind of Oh, what are what is our future? And where are we going to be? And how is it going to work as people are trying to decide? And I would invite people to reflect on their own and make a decision on their own about what they think that future is going to be, right?[00:37:40] Joe Krebs: Look, there's something very similar to what my kids are hearing in school every day. Make it a great day or not, the choice is yours. [00:37:47] Luke Hohmann: Oh, I love it. That's a great way to close. Luke, thank you so much.

Mary Lemmer is a creative impact-driven entrepreneur, consultant, startup advisor, humorist, and global speaker helping leaders and companies innovate, navigate change and thrive in an unpredictable world. She is the founder of Improve, and designs and delivers engaging keynotes, offsites, trainings, and conference sessions. She brings two decades of experience as an entrepreneur, author, humorist, and recovering venture capitalist and startup unicorn director. She gave the TED Talk “How improv can improve your leadership and life” and has spoken at The Social Innovation Summit, TED Women, TechCon, The Positive Business Conference, multiple years at the Agile Alliance conference, among speaking and leading interactive and empowering sessions for hundreds of companies around the world. To learn more about Mary, go to her website: https://chooseimprove.com or on Linkedin: @melemmer --- Support this podcast: https://podcasters.spotify.com/pod/show/lyndsay-dowd/support

Have you ever returned to an old User Story and wondered, “what was I thinking?” On today’s episode, Mike Cohn, walks us through how and why he recently revisited and updated 200 Real Life User Story Examples from his past projects and updated a resource for you! Listen in as Mike and Brian share what worked and what didn’t work from the past, in an effort to make their user story writing skills stronger. Overview What makes a user or job story great? In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software, share Mike’s recent updates and edit to 200 Real Life User Story Examples. Listen as they revisit 200 older user stories, breaking down their analysis through the lens of more experience and an evolving technological landscape. Plus, in true iterative fashion, Mike shares how he is still working to write better user stories after years of perfecting and teaching the art of story writing. Tune in to learn what makes a great clear user story, and what makes a story that stinks. Listen Now to Discover: [00:57] - Brian is joined today by Mike Cohn who will be revisiting user stories. [02:58] - Mike talks about how he came back to these 200 user stories and decided that some of them sucked and needed updating. [04:42] - When writing user stories, Mike talks about prioritizing meaningful conversations over perfect user stories. [06:35] - Brian underscores the importance of efficient communication with developers through unconventional yet practical user stories. [07:22] - Brian points to previous podcast episodes with Mike that delve into the basics of writing user stories, in episode, #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn and #39 The Art of Writing User Stories with Mike Cohn [08:22] - Mike walks through a story written for the development of the Scrum Alliance website, noting it is framed well within the site's premise. [09:10] - Brian raises considerations about inserting information mid-story. [09:57] - Mike finds the story intriguing but suggests simplifying it by moving details into acceptance criteria, a notion that didn’t exist at the time, for clarity. [12:03] - Mike advocates for concise user stories, suggesting omitting unnecessary details and using acceptance criteria for specifics. [13:52] - In a job story example, Mike and Brian point out common mistakes from an era without distinct fields. [16:34] - Brian understands the attempt to prompt discussion in the job story but finds it normal overall. [17:32] - Mike critiques a job story for site admins approving job postings, suggesting modernizing language for notification methods and flexibility. [19:34] - Reflecting on a story about user authentication, Mike acknowledges a bias toward email-centric perspectives, and questions if this story goes too far separating the what and the how. [21:22] - Mike highlights story #42, recognizing a potential mistake in specifying UI details in a story about navigating job listings. [23:24] - If you’re struggling to get your team or organization on the same Agile page from team members to senior executives. Mountain Goat Software can help you Build a Common Understanding of Agile on your team! [24:17] - If you’re a visual learner or you’d like to follow along, you can find the pdf of all the user and job stories discussed in this episode, plus many more, right here. [25:12] - Mike defends a story about viewing detailed course pages, acknowledging UI implications but justifying the necessity of the detail. [27:13] - Mike critiques a user story about creating user accounts, cautioning against a potentially misleading "so that" clause with a specific example. [29:18] - Reflecting on the evolution of user stories, Mike emphasizes a shift from stating "I can" or "I want to" to a more neutral "I." [30:40] - Critiquing a user story about browser compatibility, Mike suggests that it's a nonfunctional requirement and better suited as part of the definition of done. [33:18] - Brian presents a user story for Mountain Goat Software’s Planning Poker tool about database indexes, expressing reservations about the commonality of developer-focused stories. [34:00] - Mike reflects on the “as a developer” story and expresses uncertainty about its inclusion, considering it potentially problematic. [36:22] - Mike critiques a story about database analysis, acknowledging its verbosity but justifying the detail as necessary for clarifying the researcher's role and objectives. [38:03] - Brian appreciates the brevity of the "I want" part of a user story and finds the "so that" clause acceptable as it provides examples and context for developers. [38:39] - Considering a story about storing results, Mike deems it not bad but potentially too long. [40:00] - Mike highlights that the best way to get better at writing stories is to write a bunch of them, acknowledging that his early stories taught him valuable lessons. [41:03] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts. [41:29] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Free download: 200 User Story Examples #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn #39 The Art of Writing User Stories with Mike Cohn User Stories Applied: For Agile Software Development by Mike Cohn Job Stories Offer a Viable Alternative to User Stories by Mike Cohn Mountain Goat Software’s Planning Poker Better User Stories Course Build a Common Understanding of Agile Subscribe to the Agile Mentors Podcast on Apple Podcasts Mountain Goat Software Certified Scrum and Agile Training Schedule 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.

If you don't already know Bob, he is a software engineer, instructor, and best-selling author. He is most recognized for developing numerous software design principles and for being a founder of the incredibly influential Agile Manifesto. Bob is the author of a number of Clean Code related books including his latest, Clean Agile: Back to Basics, where he reintroduces Agile values and principles for a new generation of programmers and nonprogrammers alike. In the past, Bob was also the editor-in-chief of C++ Report magazine and served as the first chairman of the Agile Alliance.   Topics of Discussion: [3:48] Why the term “clean” when it comes to software?  [5:16] Are people still writing “dirty” software?  [7:06] it is the developers job to maintain quality, and pretending to go fast by rushing is not a viable solution.  [9:54] Uncle Bob's upcoming book on the history of programmers.  [11:00] The first era of programmers may be the scribes of Egypt.  [15:00] How Uncle Bob went about organizing the book into different eras of programmers.  [18:10] A short backstory about Grace Hopper.  [23:33] Uncle Bob's other new book which is out now, Functional Design.  [24:54] Structure and Interpretation of Computer Programs  [28:37] Does functionality have a concise set of principles?  [33:11] Where are the shifts happening?  [34:01] The loss of Moore's Law.  [37:33] What will be the winning strategies as we prepare for a few years where things grow, but not as quickly as they have, and we sit on a plateau?  [40:51] Make it right, then you can make it fast.    Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events!  Previous episode with Uncle Bob Functional Design  Clean Coders .NET Developer Apprentice - Texas Clean Agile    Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Are you part of a struggling Agile team? Join Mike Cohn and Brian Milner in this episode as they uncover the primary signs of a team in distress. Listen in as they share the common causes of underperforming teams, and what to do to boost morale, enhance collaboration, and transform your Agile team from struggling to thriving! Overview What is the primary sign of a struggling Agile team? It's when the energy in the room feels like a deflated balloon, and laughter is a distant memory. In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software help listeners identify the signs of a struggling Agile team and the common culprits. Listen in as they unveil the key principles of cultivating a positive work environment and the vital importance of addressing CYA behavior. Plus, they share their top-notch tips on boosting team morale and enhancing collaboration, all while preventing unfinished projects and ensuring consistent delivery. Tune in to transform your Agile team from struggling to thriving! Listen Now to Discover: [01:23] - Brian welcomes back Mike Cohn to the show to discuss how to identify the signs that your team is struggling and what to do about it. [01:54] - Common causes of unfinished work. [04:45] - Do developers use Scrum as an excuse to be lazy? No—that’s rare but can be easily corrected. [07:36] - How to manage underperforming teams. [09:04] - Teams that lack excitement and laughter may be struggling. Work should be fun and enjoyable. How to create a positive work environment. [10:32] - How to break the habit of rolling unfinished work forward. [12:44] - The power of small wins to improve job satisfaction. [14:12] - How to boost morale and deliver small wins that create a sense of accomplishment. [14:30] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. Whether you want to be a Scrum Master, Product Owner, or even take an advanced certification, all courses are designed to give you the skills that agile teams and organizations value so you’ll stand out in the market. For more information click on the Mountain Goat Software Certified Scrum and Agile Training Schedule. [15:35] - What CYA is really telling you about your team. [16:59] - The role of managers in creating an environment of openness and collaboration [19:03] - How individualistic behavior—working in isolation, not collaborating—hinders teamwork. [21:08] - Introducing Swarming—a horrible way to work, you’ll get less done—but a great drill to help teams discover new ways to collaborate. [27:54] - Thank you to Mike Cohn for joining us on the show. [28:18] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to podcast@mountaingoatsoftware.com. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [27:54] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community, where we have a topic discussion for each podcast episode. References and resources mentioned in the show: #70: The Role of a Leader in Agile with Mike Cohn #39: The Art of Writing User Stories with Mike Cohn Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified ScrumMaster Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: 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.

In this episode we unpack the 6th commitment in the Code of Ethical Conduct for Agile Coaching; Upholding Social responsibility, Diversity and Inclusion. We uncover the thinking behind the section, its inclusion in the Code of Ethics and its application in coaching. About the Featured Guest Deepti Jain crafts innovative learning & networking experiences for her clients & community, help them achieve sustainable transformation and 360-degree growth. She brings a background of agile software & product development, operational excellence, enterprise architecture. In 2015 she founded "AgileVirgin", in then 2018 she joined Agile Alliance as Initiative Director for India Agile Community Dev. Follow Deepti on LinkedIn Geof Elligham is a coach, facilitator, consultant, therapist and international speaker on business agility with 30 years experience in strategy, leadership, management, delivery and education in the public and private sectors.  Follow Geof on LinkedIn Follow Geof on Twitter @geofellingham Reference(s) Code of Ethical Conduct for Agile Coaching https://www.agilealliance.org/resources/initiatives/agile-coaching-ethics/ The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg  Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile. About our Host Leslie Morse is an agilist at heart. She was leveraging agile practices and appreciating agile principles long before she even knew what they were. Her agile journey officially started in 2010 and she never looked back. Her career has taken many twists and turns. She led a digital marketing start-up in college, was involved with replatforming Lowes.com while they adopted agile practices, provided training and coaching for agile transformation across a wide array of industries, and now serves as a Product Owner for Scrum.org. She is trained in Organization and Relationship Systems Coaching (ORSC) and has been involved in with Women in Agile since its original inception at Scrum Gathering 2013 in Las Vegas. You can follow Leslie on LinkedIn (https://www.linkedin.com/in/lesliejdotnet). About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

On Friday, December 8, The Agile Alliance is hosting a MiniCon on the Future of Artificial Intelligence. During the event, Mark Kilby will be hosting a roundtable discussion with the speakers to explore the ways AI is poised to impact how we work and what it will take to utilize it in an ethical and responsible way. Mark joins me in this episode of the podcast to discuss why he made a conscious decision to get schooled up on AI, how he's going about doing it, some of the key learnings he has had along the way, and his take on what the future of AI has to offer those of us work in the agile space and project management. The Future of AI MiniCon If you'd like to learn more about the Agile Alliance's Future of AI MiniCon: https://tinyurl.com/mw5ww3w2 Contacting Mark If you'd like to contact Mark: https://www.markkilby.com/ Distributed Teams And if you need some help with distributed teams, you should pick up a copy of From Chaos to Successful Distributed Agile Teams which Mark co-authored with Johanna Rothman. I cannot recommend this book highly enough! https://tinyurl.com/22vvnyjx

There's one certainty in life: life is uncertain. Especially in our rapidly changing world, individuals and organizations are forced to adapt to constant challenges and change. The ability to improvise - the respond to each moment with openness, flexibility, and grace - is pivotal to thriving in a complex and constantly changing world. In this episode, I speak with entrepreneur Mary Lemmer about how improv can help us better navigate business and life. Mary Lemmer is a creative impact-driven entrepreneur and consultant helping leaders and companies innovate, navigate change and thrive in an unpredictable world. She is the founder of Improve, a company that improves lives, teams, companies, and impact, in ways that work and just so happen to be fun and engaging. She designs and delivers engaging keynotes, offsites, and conference sessions, bringing two decades of experience as an entrepreneur, author, humorist, and recovering venture capitalist and startup unicorn director. She gave the TED Talk “How improv can improve your leadership and life” and has spoken at The Social Innovation Summit, TED Women, TechCon, The Positive Business Conference, multiple years at the Agile Alliance conference, among speaking and leading interactive and empowering sessions for hundreds of companies around the world. In this episode, we discuss: -Mary's trip to Africa to help aspiring entrepreneurs. -Starting a business at 14 years old. -Dealing with stress, uncertainty, and lack of control in business (and life). -The blocks of "overthinking." -How improv can improve our ability to listen, communicate, and have difficult conversations. -Noticing and debunking our internal stories about other people and the world. -Improv as a mindfulness tool and what it offers that meditation doesn't. -How to use improv to improve companies and leadership. -Mary's research on improv and sleep, physiological health, and happiness. -And much more! Connect with Mary at www.marylemmer.com and learn more about Improve at www.chooseimprove.com. Have comments or questions on this episode? An idea for a future guest? I'd love to hear what you liked, agreed/disagreed with, and what you'd like to hear more of. Email: hello@the-middle-way.com Listen/Subscribe on YouTube: ⁠⁠⁠⁠https://www.youtube.com/channel/UCmga5Z4JdHziQjtCdnVhYuw⁠⁠⁠⁠ Let's connect: Website: ⁠⁠⁠⁠⁠⁠⁠⁠https://matthewgoodmanphd.com⁠⁠⁠⁠⁠⁠⁠⁠ Zen-prov! Class (Improv + Zen): ⁠⁠⁠⁠⁠zen-improv.com⁠ Instagram: ⁠⁠⁠⁠⁠⁠⁠⁠@matthewgoodmanphd⁠⁠⁠⁠⁠⁠⁠⁠ Consulting: ⁠⁠⁠⁠⁠https://the-middle-way.com⁠⁠⁠⁠⁠⁠⁠⁠⁠ /⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠https://ccg-group.eu/⁠⁠⁠⁠⁠⁠⁠⁠ Your support is a HUGE help and allows the show to continue reaching a wider audience. Please consider leaving a RATING, REVIEW, or SHARING this episode if you found the content useful. Thank you for listening! ~May you be happy. May you be healthy. May you live with ease and joy. May you be free of suffering~ --- Support this podcast: https://podcasters.spotify.com/pod/show/matthewgoodmanphd/support

In this episode we unpack the fourth commitment of the Code of Ethical Conduct for Agile Coaching;  Navigating Conflicts of Interest. Join host Leslie Morse as she explores Navigating Conflicts of Interest with Natascha Speets and Femi Odelusi.  About the Featured Guests Natascha Speets is an experienced Agile Team and Enterprise coach. Natascha helps her clients reach maturity in Agile by curating focused Agile coaching programs. In 2020, Natascha started an Agile community project to draft an Ethical Code for Agile Coaches, and It only made sense to join forces with the Agile Alliance and create a Code of Ethics that truly reflects the needs of the coaches and their clients. Femi Odelusi is a Professional Coach accredited by ICF and EMCC. He has excelled in organizational change and enabling innovative, digitally enabled business solutions. He has guided a variety of organizations as they transform in today's world of digitisation. Follow Femi on LinkedIn Follow Natascha on LinkedIn Reference(s) Code of Ethical Conduct for Agile Coaching https://www.agilealliance.org/resources/initiatives/agile-coaching-ethics/ International Coaching Federation: https://coachingfederation.org/ European Mentorship & Coaching Council: https://www.emccglobal.org/ The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg  Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile. About our Hosts Leslie Morse is an agilist at heart. She was leveraging agile practices and appreciating agile principles long before she even knew what they were. Her agile journey officially started in 2010 and she never looked back. Her career has taken many twists and turns. She led a digital marketing start-up in college, was involved with replatforming Lowes.com while they adopted agile practices, provided training and coaching for agile transformation across a wide array of industries, and now serves as a Product Owner for Scrum.org. She is trained in Organization and Relationship Systems Coaching (ORSC) and has been involved in with Women in Agile since its original inception at Scrum Gathering 2013 in Las Vegas. You can follow Leslie on LinkedIn. About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Today, Brian sits down with Mike Cohn, the CEO of Mountain Goat Software to talk about how leaders can use agile concepts in order to keep their team operating at its best. Overview Today, on the Agile Mentors Podcast, Brian sits down with Mike Cohn, the CEO of Mountain Goat Software to discuss the role of a leader role in Agile. Listen in as Mike and Brian share their combined years of knowledge to help leaders use agile concepts to avoid the pitfalls of becoming a manager “behaving badly.” Listen Now to Discover: [01:08] - Brian introduces the show and his special guest Mike Cohn here to talk about the role of a leader in the Agile space. [01:53] - "Don't command, create a culture." Mike shares the difference between Agile leaders and traditional leadership. [02:59] - The concern about a resurgence of ‘old-school’ leadership and the concerns that brings. [04:48] - Mike shares how leaders can use agile concepts like self-organization, setting goals, choosing team members, and defining constraints in order to keep the team operating at its best. (Resource: Wicked Problems, Righteous Solutions: A Catologue of Modern Engineering Paradigms). [06:26] - Brian shares options for management to allow teams to figure out how to address problems as a team. [08:23] - Trust but verify isn't ideal—Mike shares why it’s better to manage by exception, i.e. giving trust upfront and asking questions later. [11:18] - Did you know the Agile Mentors Podcast is brought to you by Mountain Goat Software? Whether you're looking to get Certified Scrum Master Training or would like ​​Advanced Certified Scrum Product Owner® training, Mountain Goat has plenty of options. To see everything Mountain Goat has to offer visit Mountain Goat Software. [12:01] - Delving into the complexity of the relationship between leadership and employees, especially when it comes to trust, self-organization, and planning. [12:48] - Mike introduces the “Cone of Uncertainty” concept, sharing that having a plan is not a problem over any horizon, (over three days, three months, or three years) but managers need to accept that the level of precision in the plan should match the timeframe. [14:23] - Mike refers to an article from Harvard Business Review that highlights the difference in scrutiny between product development deadlines and sales projections, and the need for a more balanced and flexible approach in evaluating both areas. [16:05] - Language and terminology shape our perception—how the shift from "estimating" to "forecasting" helps facilitate the recognition of uncertainty in future predictions. [19:12] - Mike shares an anecdote about a client in Kansas City, who wanted him to use the word "forecast" instead of "estimate." [20:31] - The importance of assessing metric application in a leadership context. [21:06] - Mike highlights the danger of using "velocity" as a metric for team performance, explaining how subtle pressure on teams can lead to estimate inflation, rendering velocity less reliable for forecasting and more as a tool to pressure (and demotivate) teams. [24:12] - Brian encourages leaders to reflect on the motivation behind using things like velocity as a metric to measure teams and how this relates to the principles of self-organization in Agile. [25:22] - How a lack of proper training during role transitions can lead to managers ‘behaving badly,’ despite well-intentioned actions. [26:45] - A special thank you to Mike Cohn for joining us and sharing his knowledge. If you're interested in further discussions on this topic join us in the Agile Mentors Community where you can access exclusive content, participate in discussions, and attend Q&A calls with Mike and me. [27:50] - As always we’d like to invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Wicked Problems, Righteous Solutions: A Catologue of Modern Engineering Paradigms Agile Mentors Podcast from Mountain Goat Software Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast on Apple Podcasts 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.

was held recently in two locations for the first time ever. The main event was located in Orlando, Florida while a smaller but just as valuable hub was in Edinburgh, Scotland. Board member got together attendees from both locations to discuss their experiences. spoke and attended in Orlando, while attended her very first agile conference ever in Edinburgh. The trio discussed how the logistics worked between the two locations, how the event felt, and what stood out most from the week: Many don't understand what it takes to put on the event, and what it means to the Agile Alliance every year. Murman shared some of the logistics of the event having spent a year planning it. The family feel of both locations created a great environment for connection. Finding the right session is sometimes more difficult than it seems. Managing your energy over the week can also be a challenge for the introvert in us. Finally, there's so much more that people still don't realize happens at the main location every year. Regardless of the social media discussion around location, the Agile Alliance does everything it can to create a welcoming space for like-minded people to further their agile journies together. Hopefully you can catch up on some of the content. Videos for each of the keynotes are . If you enjoyed this episode, please give us a review, a rating, or leave comments on iTunes, Stitcher or your podcasting platform of choice. It really helps others find us.  Much thanks to the artist  from  who provided us our outro music free-of-charge!  If you like what you heard,     to find more music you might enjoy! If you'd like to join the discussion and share your stories,  please jump into the fray at our  We at the Agile Uprising are committed to being totally free.  However, if you'd like to contribute and help us defray hosting and production costs we do have a .  Who knows, you might even get some surprises in the mail!

Join Brian and Agile pioneer Jim Highsmith as they dive into the riveting saga of 17 tech rebels who defied convention, unleashed their passions, and revolutionized the world of software development. Overview In this episode of the "Agile Mentors" podcast, Brian sits down with Agile pioneer Jim Highsmith to share how 17 tech rebels reshaped the software landscape. Jim shares captivating stories from his time working with NASA and Nike to the collaboration of 17 nonconformists that led to the Agile Manifesto and transformed the software industry. Listen in for a behind-the-scenes look at the circumstances that led to the birth of Agile and how camaraderie, collaboration, and a human-centric approach sparked a wildfire of support for the Agile movement. Tune in to this episode for insights, lessons, and a glimpse into the future of Agile from an industry legend. Listen Now to Discover: [01:10] - Brian introduces Jim Highsmith, a renowned figure in the Agile community. Jim is an experienced software developer, writer, and storyteller. His latest book, "Wild West to Agile," has become a sensation in the industry, earning the top spot as a new release on Amazon. He also co-authored the Agile Manifesto and the Declaration of Interdependence for Project Leaders, co-founded the Agile Alliance, and served as the first president of the Agile Leadership Network. [03:57] - Jim recounts his journey working on the NASA Apollo program and how the constant advancements in technology shaped the course of the Apollo project, offering valuable insights into the era's challenges and adaptability. [08:47] - Jim shares a fascinating story from his time at Nike, where outdated requirements left a project stagnant for 18 months. [10:34] - How waterfall methodologies left companies trapped and projects taking too long and costing too much. [11:53] - Setting the stage for the revolutionary Agile movement. [13:16] - A problem so painful leadership was on board to find a solution. [14:48] - A message from our sponsor: Mountain Goat Software has courses from Certified Scrum Master Training and Scrum Certification to Certified Scrum Product Owner Training that equips you with the sought-after skills valued by top-notch teams. Visit the Mountain Goat website for all the details. [15:40] -Jim reveals the connections and common ground that started the manifesto meeting. [18:21] - An agenda-free meeting with 17 nonconformist experts seeking common ground and how an encounter with Steve Mellor led to an unexpected alignment of intent. [21:01] - 17 individuals, each with nonconformist perspectives, agree. [21:17] - Why did 17 audacious techies revolutionize the world? And what lessons can we learn from their experience for the future? [23:39] - Where Agile's lasting impact lies and what keeps it at the forefront of change. [24:39] - Putting aside competition for collaboration and cooperation that led to change. [25:30] - What keeps Agile at the forefront of change? Brian shares a nugget of wisdom from Jim's book about Agilists. [26:38] - Finally, a language that spoke to us all!—how the Agile movement shattered the notion of interchangeable cogs and embraced our humanity, sparking a wildfire of support. [27:59] - Jim shares his thoughts on where he thinks the Agile movement is headed and why he thinks the agility of organizations and people will be a definite advantage in the future. [29:56] - Brian mentions his high recommendation for listeners to pick up Jim’s book, Wild West to Agile: Adventures in Software Development Evolution and Revolution. [31:38] - There are a ton of podcasts out there; thank you for taking the time to listen to this one. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode. [32:05] - If you've considered taking a CSM or CSPO class, check us out at Mountain Goat Software. Or join the conversation in our Agile Mentors Community. [32:32] - If you have feedback for the show or topics for future episodes, email us by clicking here, and I'll get back to you ASAP. References and resources mentioned in the show: Jim Highsmith Jim Highsmith on LinkedIn Wild West to Agile Agile Manifesto Agile Alliance Agile Leadership Network Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified ScrumMaster® Advanced Certified Scrum Product Owner® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the "Agile Mentors" Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Jim Highsmith is an experienced software developer, writer, storyteller, and industry pioneer recognized for his instrumental role in the birth of the Agile movement. His latest book, "Wild West to Agile," has become a sensation in the industry, earning the top spot as a new release on Amazon. Jim continues to inspire and guide Agile enthusiasts worldwide through his insightful stories and expertise.

Coordenar projetos relacionados entre si, que têm como objetivo produzir um resultado conjunto, é bastante desafiador! Muito se discute sobre as práticas de Gestão de Projetos e de Portfólio, mas a Gestão de Programas merece um foco especial de muitas organizações, onde profissionais nem sempre usam as práticas recomendadas para esse tipo de complexidade.   Neste episódio do Capital Projects Podcast, a conversa é com Margareth Carneiro,  Board Member da Agile Alliance e Coordenadora de Governança do INEP. Margareth, que possui mais de 30 anos de experiência em gestão, teve que buscar na prática as soluções para os desafios que enfrentou na sua carreira nas primeiras oportunidades em que se deparou com programas! E, desde então, é uma apaixonada pelo tema!  Com inúmeras certificações, Margareth foi a única mulher latino-americana a, até agora, ocupar o cargo de Diretora do PMI Internacional sem viver nos Estados Unidos.  Venha conosco aprender um pouco mais sobre a importância e complexidade da gestão de programas, além de compreender os conhecimentos necessários para atuar nesse tipo de desafio.  Dê um play e vamos juntos! Esse Podcast tem o apoio de Teams Ideas by Prosperi (⁠⁠https://www.teamsideas.com/⁠⁠) e da GSUP/Nexos (http://www.gsupgroup.com/). Tem curtido o nosso conteúdo? Que tal tornar-se membro do Capital Projects Podcast, apoiando o canal? Assim, podemos continuar crescendo e ajudando tantos profissionais da Gestão de Projetos! Acesse o link e confira os planos: ⁠⁠https://lnkd.in/d8QQ6twk⁠⁠ Acompanhe também as minhas redes: @andre_choma e ⁠⁠https://linktr.ee/andrechoma⁠⁠ Produção: Estúdios Voz – www.vozeconteudo.com.br - @estudiosvoz #capitalprojectspodcast #andrechoma #podcast #capitalprojects #projetos #portfolio #portfoliomanagement #gestaodeportfolio #gestaodeprogramas #programmanagement #margarethcarneiro #agilealliance #PMI #projectmanagementinstitute #projectmanagement #megaprojetos #megaprojects #frontendloading #FEL #PMO

Return guest Chris Li joins host Chris Murman to discuss the state of conferences today, why they matter, and how #Agile2023 is our favorite of the bunch. We also discuss how much we adore Troy Lightfoot, and why his voice was built for radio. Li and Murman then discuss Agile Advice at the conference. Since he created the space for Agile Alliance, Li speaks to the history, why it's extremely underrated in value, and why you should spend some time with the team in Orlando this year. Sparkplug Agility If you enjoyed this episode, please give us a review, a rating, or leave comments on iTunes, Stitcher or your podcasting platform of choice. It really helps others find us.  Much thanks to the artist Krebs from Machine Man Records who provided us our outro music free-of-charge!  If you like what you heard, check out these links to find more music you might enjoy! If you'd like to join the discussion and share your stories,  please jump into the fray at our Discord Server! We at the Agile Uprising are committed to being totally free.  However, if you'd like to contribute and help us defray hosting and production costs we do have a Patreon.  Who knows, you might even get some surprises in the mail!

Mike Cohn joins Brian to share his experience facilitating story-writing workshops and offers insights on creating effective user stories that deliver value to customers and focus to your team. Overview In this episode of the "Agile Mentors" podcast, Brian is joined by Agile coach and trainer Mike Cohn to discuss the art of writing user stories through story-writing workshops. Mike shares his expertise on the importance of creating user stories, including how to write them effectively and their benefits in the development process. Listen in as Mike provides valuable insights on conducting effective story-writing workshops, including the role of a skilled facilitator, keeping the conversation on track, and how using the INVEST criteria can help you create high-quality user stories that meet the needs of your users. Tune in for practical tips and strategies to improve your user story writing workshops to energize your team while giving them a clear focus on what they need to do. Listen Now to discover: [01:09] - Brian is sitting down with Mike Cohn today to discuss story writing workshops. [01:57] - Mike shares team/stakeholder writing sessions during the early 2000s that morphed into "story writing workshops" to help teams understand what they were doing. [03:37] - Mike explains why he prefers to write 20-30 stories at the start of a quarter, only writing a few new stories during the sprint, then doing another story writing workshop every three months. [05:20] - Brian clarifies that teams don't have to wait for a story writing workshop to write stories. He shares his recommendations for holding story-writing workshops once a quarter to replenish the backlog and "refill the gas tank" with new ideas. [06:03] - Mike expands on the gas tank analogy, explaining that, like filling up a gas tank, teams don't need to wait until the backlog is empty to have a story-writing workshop. [06:52] - Mike shares why he prefers a quarterly approach to story writing for its big-picture view of the coming months. [07:17] - Brian references the 2020 Scrum Guide and suggests using the product goal as the bigger idea to zero in on. [07:32] - Mike agrees with Brian's suggestion of using the product goal as a focal point during story-writing workshops sharing his idea of the importance of something to aim for beyond just the single sprint goal. [07:59] - The importance of focusing a story-writing workshop on a single goal, i.e., setting a product goal for three to six months and using it as the workshop's focus to generate necessary stories. [09:29] - Who should attend a story-writing workshop? Mike offers his suggestions to bring creativity and new ideas and build better products. [11:33] - Mike shares why he believes involving team members in story-writing workshops is a time-saving, worthwhile investment that will improve product outcomes. [12:06] -The tools for a successful story-writing workshop for everyone involved. [13:57] - Mike explains why story-writing workshops might work better online than in person. [17:19] - To keep the conversation on track, having a skilled facilitator for your story-telling workshop is crucial. [17:58] - The importance of having a scrum master or agile coach facilitating story mapping sessions for guidance through any issues with sequencing or organization of ideas. [19:16] - Collectively writing the same story simultaneously vs. brainstorming different stories and then coming together—Mike shares which he prefers and why. [21:34] - Mike shares why saving the story refinement for later is best. [24:05] - The importance of striking a balance between the level of detail in the stories and the time spent on the story-writing workshop. [25:21] - Brian shares a story about an organization he worked with recently at Mountain Goat Software that used the INVEST criteria as a definition of Done to check off every story they wrote. [25:58] - Mike explains the six attributes a team should know to create good user stories. [27:20] - Mike shares why story-writing meetings energize teams, leaving them excited about the product and the upcoming period while giving them a clear focus on what they need to do. References and resources mentioned in the show: How to Run a Successful User Story Writing Workshop Better User Stories Video Course by Mike Cohn 2020 Scrum Guide Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Scrum Alliance Subscribe to the Agile Mentors Podcast on Apple Podcasts 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 is the CEO of Mountain Goat Software and the Co-founder of Agile Alliance and Scrum Alliance. He’s passionate about agile and finds it rewarding when a company really understands agile, commits to doing it well, and succeeds dramatically. Mike’s focus is coaching, training, developing new courses, sharing ideas in his blog posts and tips, and participating in the Agile Mentors Community, especially with the live Q & A sessions.

Mike Cohn joins Brian to share his experience facilitating story-writing workshops and offers insights on creating effective user stories that deliver value to customers and focus to your team. Overview In this episode of the "Agile Mentors" podcast, Brian is joined by Agile coach and trainer Mike Cohn to discuss the art of writing user stories through story-writing workshops. Mike shares his expertise on the importance of creating user stories, including how to write them effectively and their benefits in the development process. Listen in as Mike provides valuable insights on conducting effective story-writing workshops, including the role of a skilled facilitator, keeping the conversation on track, and how using the INVEST criteria can help you create high-quality user stories that meet the needs of your users. Tune in for practical tips and strategies to improve your user story writing workshops to energize your team while giving them a clear focus on what they need to do. Listen Now to discover: [01:09] - Brian is sitting down with Mike Cohn today to discuss story writing workshops. [01:57] - Mike shares team/stakeholder writing sessions during the early 2000s that morphed into "story writing workshops" to help teams understand what they were doing. [03:37] - Mike explains why he prefers to write 20-30 stories at the start of a quarter, only writing a few new stories during the sprint, then doing another story writing workshop every three months. [05:20] - Brian clarifies that teams don't have to wait for a story writing workshop to write stories. He shares his recommendations for holding story-writing workshops once a quarter to replenish the backlog and "refill the gas tank" with new ideas. [06:03] - Mike expands on the gas tank analogy, explaining that, like filling up a gas tank, teams don't need to wait until the backlog is empty to have a story-writing workshop. [06:52] - Mike shares why he prefers a quarterly approach to story writing for its big-picture view of the coming months. [07:17] - Brian references the 2020 Scrum Guide and suggests using the product goal as the bigger idea to zero in on. [07:32] - Mike agrees with Brian's suggestion of using the product goal as a focal point during story-writing workshops sharing his idea of the importance of something to aim for beyond just the single sprint goal. [07:59] - The importance of focusing a story-writing workshop on a single goal, i.e., setting a product goal for three to six months and using it as the workshop's focus to generate necessary stories. [09:29] - Who should attend a story-writing workshop? Mike offers his suggestions to bring creativity and new ideas and build better products. [11:33] - Mike shares why he believes involving team members in story-writing workshops is a time-saving, worthwhile investment that will improve product outcomes. [12:06] -The tools for a successful story-writing workshop for everyone involved. [13:57] - Mike explains why story-writing workshops might work better online than in person. [17:19] - To keep the conversation on track, having a skilled facilitator for your story-telling workshop is crucial. [17:58] - The importance of having a scrum master or agile coach facilitating story mapping sessions for guidance through any issues with sequencing or organization of ideas. [19:16] - Collectively writing the same story simultaneously vs. brainstorming different stories and then coming together—Mike shares which he prefers and why. [21:34] - Mike shares why saving the story refinement for later is best. [24:05] - The importance of striking a balance between the level of detail in the stories and the time spent on the story-writing workshop. [25:21] - Brian shares a story about an organization he worked with recently at Mountain Goat Software that used the INVEST criteria as a definition of Done to check off every story they wrote. [25:58] - Mike explains the six attributes a team should know to create good user stories. [27:20] - Mike shares why story-writing meetings energize teams, leaving them excited about the product and the upcoming period while giving them a clear focus on what they need to do. References and resources mentioned in the show: How to Run a Successful User Story Writing Workshop Better User Stories Video Course by Mike Cohn 2020 Scrum Guide Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Scrum Alliance Subscribe to the Agile Mentors Podcast on Apple Podcasts 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 is the CEO of Mountain Goat Software and the Co-founder of Agile Alliance and Scrum Alliance. He’s passionate about agile and finds it rewarding when a company really understands agile, commits to doing it well, and succeeds dramatically. Mike’s focus is coaching, training, developing new courses, sharing ideas in his blog posts and tips, and participating in the Agile Mentors Community, especially with the live Q & A sessions.

We are joined by a group of Agile practitioners here at Farm Credit Services of America, who recently attended the Agile Alliance conference in Nashville.…

“The simplest way to describe craftsmanship is pride of workmanship. It is the mindset that you are working on something important and you are going to do it well." Today's clip is from episode 90 with Robert C. Martin, more widely known as Uncle Bob. In this clip, Uncle Bob shared some insights from his latest book, “Clean Craftsmanship”. He shared the current major challenge of the software development industry as a young discipline, which drove Uncle Bob writing the book to help define disciplines, standards, and ethics for software craftsmanship. He also touched on the five key disciplines of clean craftsmanship. Listen out for: Clean Craftsmanship - [00:00:55] Programmer as a Profession - [00:05:32] Craftsmanship - [00:08:46] Disciplines - [00:12:46] _____ Robert C. Martin's Bio Robert Martin (Uncle Bob) has been a programmer since 1970. He is the co-founder of the online video training company cleancoders.com and founder of Uncle Bob Consulting LLC. He served as Master Craftsman at 8th Light inc and is an acclaimed speaker at conferences worldwide. He is a profilic writer and has published hundreds of articles, papers, blogs, and best-selling books including: “The Clean Coder”, “Clean Code”, “Agile Software Development: Principles, Patterns, and Practices”, and “Clean Architecture”. He also served as the Editor-in-chief of the C++ Report and as the first chairman of the Agile Alliance. Follow Uncle Bob: Twitter – @unclebobmartin Clean Coder – http://cleancoder.com Clean Coders – https://cleancoders.com GitHub – https://github.com/unclebob _____ Our Sponsors Mental well-being is a silent pandemic. According to the WHO, depression and anxiety cost the global economy over USD 1 trillion every year. It's time to make a difference! Learn how to enhance your lives through a master class on mental wellness. Visit founderswellbeing.com/masterclass and enter TLJ20 for a 20% discount. Skills Matter is the global community and events platform for software professionals. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/90.

This episode explores how we help teams to achieve focus, especially with remote work.  Also, with this being our end-of-the-year podcast, we ask what we need to celebrate this year. Join Shawna Cullinan, Jörg Pietruszka,  Diana Larsen, Hendrik Esser, Ray Arell, and all the callers to the monthly live event as we explore topics related to Agile.  For details on the next live event, please visit  AgileCoachingNetwork.org.(00:00) Introduction(04:04)  Focus! How do we help people find it? (42:49) Let's celebrate!(46:30) Wrap upThe Agile Coaching Network podcast is published under CC BY-NC-ND 4.0 license and is owned by nuAgility LLC. If you want more information about the Agile Coaching Network, please go to acnpodcast.org  Also, please become a member of our nonprofit sponsor! Agile Alliance supports our show and helps to build a wonderful Agile community! Support the show

Henrik Kniberg joins Brian to talk about creating the Spotify Model. Overview There are ways to get things done, and then there are the best ways to get things done. But the only way to arrive at the right way of doing things is to try and fail, to see what works and what doesn't. Henrik Kniberg is a Certified Scrum Trainer who has worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He's also the co-creator of the Spotify Model. Today on the show, Henrik joins Brian to discuss his accidental introduction to Spotify and how he inspired the company to transition to Scrum. We discuss the leadership model that helped the startup scale while holding its own against behemoths like Apple and Google. Plus, an inside look at his time as a designer with Minecraft. Listen now to discover: [01:55] - Brian shares Henrik's Agile Product Ownership in a Nutshell that's become required viewing. [02:22] - Brian shares some of the places on Henrik's resume, including Lego, Minecraft, and Spotify. [03:42] - Henrik shares his love for playing accompaniment musical instruments. [04:08] - Brian shares his professional musical background. [04:35] - Introducing the Spotify engineering culture videos that have sparked a thousand conversations about scaling challenges. [05:10] - Henrik shares the story of his accidental introduction to Spotify and how he inspired the startups to transition to Scrum. [8:26] - Henrik describes how the lack of off-the-shelf scaling frameworks led to his work with Spotify. [08:45] - Standard Scrum, by the books, works for small teams, but for scaling at larger teams like the one at Spotify, it's hard to find a "one size fits all" approach. [10:59] - How realizing 'this is what's helping us swim' during their impressive growth got all the technical leaders of Spotify on board with using Agile. [12:50] - Henrik shares the leadership model that helped Spotify scale up. [14:58] - How Spotify used the speed of innovation to stand against goliath-like competitors like Apple and Google. [16:30] - Convincing the investors that being able to iterate quickly (rather than through roadmaps) was the key to winning the game. [18:09] - Fueling future inspiration—why Spotify instituted the twice-a-year hack weeks for their entire organization. [21:36] - Henrik shares why leadership is the key to culture and driving change in an Agile organization. [24:19] - Brian shares why it's wise to make a change where you can benefit a company rather than hanging on to the now-extinct gold watch at retirement. [25:53] - "Go ahead and copy the Spotify model… and don't worry about someone telling you that you're doing it wrong because that's just you adapting." [26:44] - How the Spotify culture videos had the opposite outcome from what Henrik had planned. [29:54] - Brian asks Henrik an important Minecraft question (as posed by his daughter.) [30:36] - Henrik shares insider information about the guiding principles for designers at Minecraft (and how that led to the creation of Striders). [32:34] - Brian shares why copy/paste is only sometimes best. [32:46] - Henrik shares how creating video games differs from life applications. Listen next time when we'll be discussing… Getting to Small with Lance Dacy References and resources mentioned in the show Agile Product Ownership in a Nutshell Spotify Engineering Culture - Part 1 (aka the "Spotify Model") Spotify Engineering Culture - Part 2 (aka the "Spotify Model") Mountain Goat Software Agile Mentors Community Scrum Alliance Subscribe to the Agile Mentors Podcast on Apple Podcasts 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? Please 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. Henrik Kniberg is former member of the board of directors of the Agile Alliance and enjoys helping companies succeed with both the technical and human sides of software development. A Certified Scrum Trainer he’s worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He’s also the co-creator of the Spotify Model.

Henrik Kniberg joins Brian to talk about creating the Spotify Model. Overview There are ways to get things done, and then there are the best ways to get things done. But the only way to arrive at the right way of doing things is to try and fail, to see what works and what doesn't. Henrik Kniberg is a Certified Scrum Trainer who has worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He's also the co-creator of the Spotify Model. Today on the show, Henrik joins Brian to discuss his accidental introduction to Spotify and how he inspired the company to transition to Scrum. We discuss the leadership model that helped the startup scale while holding its own against behemoths like Apple and Google. Plus, an inside look at his time as a designer with Minecraft. Listen now to discover: [01:55] - Brian shares Henrik's Agile Product Ownership in a Nutshell that's become required viewing. [02:22] - Brian shares some of the places on Henrik's resume, including Lego, Minecraft, and Spotify. [03:42] - Henrik shares his love for playing accompaniment musical instruments. [04:08] - Brian shares his professional musical background. [04:35] - Introducing the Spotify engineering culture videos that have sparked a thousand conversations about scaling challenges. [05:10] - Henrik shares the story of his accidental introduction to Spotify and how he inspired the startups to transition to Scrum. [8:26] - Henrik describes how the lack of off-the-shelf scaling frameworks led to his work with Spotify. [08:45] - Standard Scrum, by the books, works for small teams, but for scaling at larger teams like the one at Spotify, it's hard to find a "one size fits all" approach. [10:59] - How realizing 'this is what's helping us swim' during their impressive growth got all the technical leaders of Spotify on board with using Agile. [12:50] - Henrik shares the leadership model that helped Spotify scale up. [14:58] - How Spotify used the speed of innovation to stand against goliath-like competitors like Apple and Google. [16:30] - Convincing the investors that being able to iterate quickly (rather than through roadmaps) was the key to winning the game. [18:09] - Fueling future inspiration—why Spotify instituted the twice-a-year hack weeks for their entire organization. [21:36] - Henrik shares why leadership is the key to culture and driving change in an Agile organization. [24:19] - Brian shares why it's wise to make a change where you can benefit a company rather than hanging on to the now-extinct gold watch at retirement. [25:53] - "Go ahead and copy the Spotify model… and don't worry about someone telling you that you're doing it wrong because that's just you adapting." [26:44] - How the Spotify culture videos had the opposite outcome from what Henrik had planned. [29:54] - Brian asks Henrik an important Minecraft question (as posed by his daughter.) [30:36] - Henrik shares insider information about the guiding principles for designers at Minecraft (and how that led to the creation of Striders). [32:34] - Brian shares why copy/paste is only sometimes best. [32:46] - Henrik shares how creating video games differs from life applications. Listen next time when we'll be discussing… Getting to Small with Lance Dacy References and resources mentioned in the show Agile Product Ownership in a Nutshell Spotify Engineering Culture - Part 1 (aka the "Spotify Model") Spotify Engineering Culture - Part 2 (aka the "Spotify Model") Mountain Goat Software Agile Mentors Community Scrum Alliance Subscribe to the Agile Mentors Podcast on Apple Podcasts 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? Please 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. Henrik Kniberg is former member of the board of directors of the Agile Alliance and enjoys helping companies succeed with both the technical and human sides of software development. A Certified Scrum Trainer he’s worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He’s also the co-creator of the Spotify Model.

SPaMCAST 728 features a discussion with Anjali Leon and Nadezhda Belousova. We discussed their new model, Product Leadership Stances. One of my takeaways was how powerful the model was in helping to develop an understanding of product leadership and then highlighting gaps in how the role is practiced in organizations.  Anjali and Nadezhda's Bios! Anjali Leon is an Agility, Product, and Professional Coach, Collaboration Facilitator, and Trusted Strategic Advisor.  Through her boutique coaching and consulting practice, PPL Coach, She brings her years of experience in technology, leadership, and Agile to help her clients adapt, innovate, and thrive in the new-normal business environment - where the meaning of ‘winning' is quickly being redefined as integrating better business outcomes and our collective well-being. You can experience Anjali's authentic head, hearts and hands approach to product, people, and personal leadership through one of her unique value-driven and values-based coaching programs, workshops, and training. Anjali is an accredited trainer through ICAgile and ProKanban, is a trained co-active coach and is a committed lifelong learner. She is recognized as an inspiring speaker, conference organizer, and community leader. She is co-creator of Product Leadership Stances™, co-founder of HitRefresh – a resilience-building practice, founder of Empowering South Florida Women in Agile, and member of the advisory board for ProKanban.org. Anjali's Profile linkedin.com/in/anjali-leon Website  ppl-coach.com (Company) Twitter thepplcoach4U awakencoach AnjaliLeon Nadezhda Belousova is an Integral Master Coach™ and an independent Enterprise Business Agility Strategist who deeply cares about high-performing scalable businesses with human-centric approach and sustainability at heart. She brings a combination of psychology, multiple professional coaching approaches (ORSC, Solution-Focused coaching, Clean Language, etc.), years of extensive hands-on consulting experience in various industries, and a can-do-all mindset. Nadezhda sees organizations holistically as living systems and enables them to unleash their potential – to evolve, to re-invent themselves, to thrive. She runs a boutique organizational coaching and management consulting practice serving her clients worldwide from Berlin, Germany. Nadezhda is a mentor, speaker and a passionate contributor to a number of professional communities (European Organizational Design Forum, Agile Alliance, Business Agility Institute, etc.). LinkedIn https://www.linkedin.com/in/nadezhdabelousova Product Leadership Website: https://www.productleadershipstances.com/ Re-read Saturday News This week  we re-read Chapter 1 of Extraordinarily Badass Agile Coaching: The Journey from Beginner to Mastery and Beyond (Amazon Associate Link). Chapter 1, Introduction to Badassery in Agile Coaching, is an overview of the book including thoughts on how to read it and a whole lot more. This Week: Week 2: Introduction to Badassery in Agile Coaching  - https://bit.ly/3hcEPMs  Previous Weeks: Week 1: Logistics and Forewords - https://bit.ly/3zoAYlx  A quick advertisement: Controlling work entry requires preparation and knowledge building to establish a path to control work entry (magic wands are normally not available), which is why Jeremy Willets and I have developed a work entry workshop. Interested? Please email us at tcagley@tomcagley.com or willetsjm@gmail.com Next SPaMCAST  In the SPaMCAST 729 let's go back to basics and discuss why it is a rotten idea to have a functional product owner and a technical product owner.  Tony Timbol will also bring his “To Tell A Story” column to the podcast.   

This episode explores how sometimes coaching becomes merely an expert leader using coaching language to drive a narrow self-serving agenda.  We talk about this anti-pattern and look for better approaches to coaching others. Join Shawna Cullinan, Jörg Pietruszka,  Diana Larsen, Hendrik Esser, Ray Arell, and all the callers to the monthly live event as we explore topics related to Agile.  For details on the next live event, please visit  AgileCoachingNetwork.org.(00:00) Introduction(02:49)  Agile Transformation Strategies(46:45) Wrap upThe Agile Coaching Network podcast is published under CC BY-NC-ND 4.0 license and is owned by nuAgility LLC. If you want more information about the Agile Coaching Network, please go to AgileCoachingNetwork.org. Also, please become a member of our nonprofit sponsor! Agile Alliance supports our show and helps to build a wonderful Agile community! Support the show

This episode explores people's go-to strategies for an Agile transition within a company. We also examine what works well with those strategies, and we work to understand the key gaps. Join Shawna Cullinan, Jörg Pietruszka,  Diana Larsen, Hendrik Esser, Ray Arell, and all the callers to the monthly live event as we explore topics related to Agile.  For details on the next live event, please visit  AgileCoachingNetwork.org.(00:00) Introduction(02:44)  Agile Transformation Strategies(47:28) Wrap upThe Agile Coaching Network podcast is published under CC BY-NC-ND 4.0 license and is owned by nuAgility LLC. If you want more information about the Agile Coaching Network, please go to AgileCoachingNetwork.org. Also, please become a member of our nonprofit sponsor! Agile Alliance supports our show and helps to build a wonderful Agile community! Support the show

We recently attended the Agile2022 conference put on by the Agile Alliance and wanted to share our conversations with a few of the speakers and attendees. This episode is a conversation with Josh Kerviesky, a long-time Agile practitioner and speaker, and Chris Shinkle, SEP's Director of Innovation. We sat down with Josh prior to his keynote at the conference to talk about his journey in the Agile community and software product development world.Note: The audio for this is not our normal in studio quality, so thanks for bearing with us.You can find more information about this podcast at sep.com/podcast and subscribe wherever you get your podcasts. Thanks for listening!

We recently attended the Agile2022 conference put on by the Agile Alliance and wanted to share our conversations with a few of the speakers and attendees. This episode is a conversation with Dan Vacanti, an author and speaker in the product development world, and Chris Shinkle, SEP's Director of Innovation. We asked Dan some follow-up questions to expand on his talk from earlier in the conference. To illustrate how we interpret data, Dan used a story about Wilt Chamberlin's record breaking total points in a single basketball game. Dan emphasizes that all data have noise and it's easy to mistake noise for signal.Note: The audio for this is not our normal in studio quality, so thanks for bearing with us.You can find more information about this podcast at sep.com/podcast and subscribe wherever you get your podcasts. Thanks for listening!

https://www.linkedin.com/in/staceyackerman/?trk=nav_responsive_tab_profile (Stacey Ackerman) is a well-known thought leader in the agile software and agile marketing communities. For nearly a decade, she has successfully transformed traditionally-run companies into cultures and teams that embrace agility. She's a regular contributor on agile marketing for https://martech.org/author/stacey-ackerman/ (MarTech) and speaks at global agile conferences, including multiple years at the Global Scrum Gathering. Ackerman co-trained alongside Mike Cohn, agile guru and co-founder of the Scrum Alliance and Agile Alliance, for several years. She also helped launch a global agile community, https://learn.agilementors.com/agile-mentors/ (Agile Mentors,) where she brought together thousands of agile practitioners for learning and collaboration. Ackerman was on the leadership team for the revised https://agilemarketingmanifesto.org/ (Agile Marketing Manifesto) in 2021. Most recently, she co-founded https://www.agilemarketingnavigator.org/ (Agile Marketing Navigator), a flexible framework for implementing agile marketing. Michael Seaton, President, Level C Digital, has an extensive background leading digital marketing strategy and transformation at some of Canada's largest and most respected brands in Financial Services, Not-For-Profit, and Government. His “why” stems from a passion for developing better, smarter marketers and teams, enabling new skills and practices essential for modern marketing success. Michael authored and instructs Agile Marketing at the University of Toronto as well as the Digital Marketing Strategy & Management certificate program at UofT. He is past Co-Chair, Digital Analytics Association (Canada)and past Board of Directors with American Marketing Association (AMA-Toronto); Canadian Marketing Association (CMA); Association of Internet Marketing & Sales (AIMS); and Advisory Board, Ted Rogers School of Business at Ryerson University. About Your Host: John Cass John Cass is an expert at building content production and social media relationship systems for brands and agencies. He has worked at several companies where he's managed the development of content strategies and their execution. In addition, he has supporting experience in Technical SEO, user experience, marketing automation, and conversation optimization for the web. Follow https://www.linkedin.com/in/bostonmarketing/ (John on LinkedIn)

140 Grit and your Startup with Luke Hohmann Founder and CEO of FirstRoot, Inc. Our mission is to create the next generation of impact investors. Our unique go-to-market strategy supports all stakeholders as youth use participatory budgeting to invest real money in their schools. Youth learn the 5 C's of modern education: creativity, critical thinking, communication, collaboration, and civics as they experience true agency and stewardship over their futures, learning through their own experiences how money really works. We want to get $1K into 1M schools globally and watch what happens when youth control $1B in capital. Previously a SAFe® Framework Contributor and Principal Consultant, Luke was Founder and CEO of Conteneo, Inc. (acquired by Scaled Agile, Inc.) where he worked with an extraordinary dev team to create the Weave, Strategy Engine and Knowsy® decision agility platforms. The author of four books, numerous articles and cited as an inventor on more than a dozen patents, Luke is an internationally recognized expert in Agile Software Development. Luke co-organized the first Agile conference in 2003, has served on the Board of the Agile Alliance and in partnership with the Scrum Alliance produced the "Collaboration at Scale", the world's largest monthly webinar devoted to helping organizations with 10 or more Scrum teams in 2 or more locations scale agility. Luke is a highly sought after speaker has as keynoted such conferences as the Agile Alliance conference, Agile Australia, Lean-Agile Scotland, Agile New Zealand, the Austrian Innovation Forum, the CXPA and the SAFe Summit. Luke's is the co-founder of Every Voice Engaged Foundation, a 501c3 nonprofit that helps citizens, governments and nonprofit organizations collaboratively solve problems that are unsolvable without civic engagement. EVEF has been a leader in the Participatory Budgeting movement, helping citizens prioritize hundreds of millions of dollars through Budget Games. In partnership with The Kettering Foundation (www.kettering.org), Conteneo created Common Ground for Action, the first scalable platform for deliberative decision-making. A former United States National Junior Pairs Figure Skating Champion, Luke likes playing with his four kids, his wife's cooking and long runs in the Santa Cruz mountains. Luke's an old school Silicon Valley entrepreneur. Instead of building companies to flip, he builds companies that make the world better! We talk about For the different stages of a company's growth, how can they collaborate using games to get results? How can a company go about finding the right Investment Banker? How important is teaching financial literacy?   What is project based, learning-by-doing? And much more     Connect with Luke Hohmann (5) Luke Hohmann | LinkedIn lukehohmann@yahoo.com firstroot.co 

The podcast by project managers for project managers. Hear how teams can use agile methods and orient them towards business outcomes, which deliver business agility and build resilience. In this episode 'Maximizing Value: From PMO to Agile VMO' - you'll also hear ideas and strategies for transforming the Project Management Office into an Agile Value Management Office.   Table of Contents 01:24 … Sanjiv's Background Story02:41 … Current Trends with Enterprise Agile Transformations06:00 … Measuring Success07:33 … How to Tell When Groups are Struggling09:33 … Organizations Eliminating Project Management Function12:23 … The Value-Adding Role of the Project Manager14:59 … Lessons Learned and Retrospectives18:26 … Compare and Contrast Agile and Traditional20:37 … Defining the Agile VMO25:10 … Organizations Embracing Agile VMO26:43 … Resistance to Flexible Funding28:22 … Get in Touch with Sanjiv29:41 … Closing SANJIV AUGUSTINE: We need middle managers, including project managers, because close to 90% of successful organizational change initiatives are driven by middle management.  And that includes project managers.  So what we need to do is to find a way to more clearly define what people with that skill, that project management skill, add within the agile context. WENDY GROUNDS:  Welcome to Manage This, the podcast by project managers for project managers. My name is Wendy Grounds, and with me in the studio is Bill Yates.  This podcast is about project management.  Join us to be motivated and inspired by project stories, leadership lessons, and wise advice from industry experts from all across the world. One of those leadership experts is who we're talking to today.  Sanjiv Augustine is the founder and CEO of LitheSpeed LLC and the Agile Leadership Academy.  Sanjiv is the author of the books “From PMO to VMO,” “Managing Agile Projects,” and “Scaling Agile.”  He's been an in-the-trenches practitioner.  He's also managed many agile projects, and he has trained thousands of agile practitioners. BILL YATES:  Sanjiv is the chair of the Agile Alliance's Agile Executive Forum and the founder and moderator of the Lean Startup in the Enterprise Meetup.  He was also a founding member of the Project Management Institute's agile community of practice.  So not only is he a well-versed practitioner, but he's had a lot of influence in shaping how many of these organizations have addressed and scaled agile. WENDY GROUNDS:  Sanjiv, welcome to Manage This.  Thank you so much for being our guest. SANJIV AUGUSTINE:  Thank you very much, Wendy.  I really appreciate being here with both Bill and you. Sanjiv's Background Story WENDY GROUNDS:  Yeah, we're looking forward to tackling this topic and getting your expertise.  But before we get into that, can you tell us about your background working with organizations and those in the trenches who want to adopt agile practices, and just a little bit about what you do. SANJIV AUGUSTINE:  Thanks for this opportunity, once again.  And I want to start with about 20 years ago, believe it or not.  I've been in the industry for about 30 years.  But 20 years ago I started my agile journey.  This is with an organization that you might know.  It's the Capital One Bank.  And the CIO at that time was looking for a way to cut their time to market by 50%.  And so he went to his CTO and said, “Please find a way to do this with agile methods.”  And in those days nobody was crazy enough to sign up for that. But we ended up partnering with the CTO of Capital One and ending up rolling out agile methods, more specifically scrum, in three countries, with 5,000 people.  So it was a massive enterprise adoption.  We made mistakes along the way, learned lots of great lessons along the way, and here we are 20 years later. BILL YATES:  Yeah, you were on the cutting edge 20 years ago.  That's amazing that you guys were kind of in the lab of, okay, we think this works for scrum.