Podcasts about agile manifesto

The Agile Manifesto - 2026Please visit:https://agiledad.com/documents to download your very own copy! 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/

What does it mean to be a "Pragmatic Programmer" when AI can write the code for you? This week, Brooke & Matt welcome the legendary Dave Thomas, co-author of the "developer's bible" (aka - The Pragmatic Programmer) and a pioneer of the Agile Manifesto, to discuss the state of our craft in 2026. Dave challenges us to rethink our relationship with AI "coworkers," explains his "Orient-Step-Learn" framework for staying sharp, and even reveals which piece of his classic advice he'd delete in this new era of automation. Whether you're a junior dev looking for "scar tissue" or a veteran engineer navigating AI-generated complexity, this is a must-watch conversation with a true industry provocateur!CONNECT WITH US:https://pragdave.me/https://www.linkedin.com/in/jedibravery/https://www.linkedin.com/in/matthewbchristiansen/Follow us onX: @DevLifePodcastX: @AngularShowBluesky: @theangularplusshow.bsky.socialThe Angular Plus Show and The DevLIfe Podcast are a part of ng-conf. ng-conf is a multi-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. Developers from across the globe converge  every year to attend talks and workshops by the Angular team and community experts.JoinAttendXBluesky        ReadWatchStock media provided by JUQBOXMUSIC/ Pond5

Agile transformed how small teams build software.But what happens when organizations grow to hundreds or thousands of people?In this episode of Le Podcast on Emerging Leadership, Alexis Monville welcomes Fabrice Bernhard, co-founder and CTO of Theodo and co-author of The Lean Tech Manifesto.Fabrice explains why the four values of the Agile Manifesto have inherent scale limits, and how Lean thinking helps organizations keep the same intention, without falling into bureaucracy.They explore:– what “value for the customer” really means at scale– why autonomy requires both leadership and architecture– how tech-enabled networks of teams work in practice– what it takes to build a true learning organization– and why Lean is not just good for people, but also for businessA grounded conversation for leaders, tech professionals, and change agents navigating growth, complexity, and responsibility.Find the transcript and the references in the companion blog post: https://blog-alexis.monville.com/en/2026/02/10/when-agile-scales-something-breaks/

Visit ⁠⁠http://pmpdoctor.com/⁠⁠ for more PMP practice questions.In the PMP Exam Mindset, "Negotiating Project Agreements" (People Domain, Task 8) is about finding the Win-Win. Forget the "hard-bargaining" movie tropes—the PM's goal is to reach a sustainable consensus that protects project objectives while maintaining healthy relationships.1. Core Mindset PrinciplesCollaboration Over Competition: Negotiation isn't about winning at the other party's expense. It's about aligning everyone to the project's success.Know Your Bounds: Always understand your BATNA (Best Alternative to a Negotiated Agreement) and your limits before entering the room.Focus on Interests, Not Positions: If a stakeholder demands "Feature X," ask why. The underlying interest is often easier to satisfy than the rigid demand.Integrity First: Never promise something the team cannot deliver just to close a deal.Analyze Bounds of Negotiation: Determine the scope, budget, and schedule flexibility before starting.Assess Priorities and Objectives: Use tools like MoSCoW Prioritization to understand what is "Must-Have" versus "Nice-to-Have."Verify Objectives Are Met: Ensure the final agreement actually solves the project's needs and is documented in an Agreement or Contract.Participate in Negotiations: You aren't just an observer; you are the bridge between the technical team and the Procurement/Legal departments.2. Key Exam Enablers (Subtasks)Based on the PMP Content Outline, you must master:3. The Agile PerspectiveIn Agile projects, negotiation is continuous. We prioritize "Customer Collaboration over Contract Negotiation" (Agile Manifesto). This means favoring flexible contracts, like Fixed-Price Incremental or Time and Materials, that allow for changing priorities.Exam Tip: The "Consensus" StrategyIf you see a question where two stakeholders disagree on a requirement, the correct answer usually involves facilitating a meeting to find common ground or using Multi-Criteria Decision Analysis to objectively rank options.

Does the Agile Manifesto still guide us? The Manifesto has been an integral part of our professional lives. Organizations and teams seem to be tired of values and principles. Is the Manifesto still relevant? Our panel today features: Daniel Doiron - https://www.linkedin.com/in/danieldoiron/ Jeremy Willets - https://www.linkedin.com/in/jeremywillets/ Jon M Quigley - https://www.linkedin.com/in/jonmquigley/ Freddie Clark - https://www.linkedin.com/in/freddie-clark/ Jeremy Berriault- berriaultandassociates.com Me

Gil Broza joins our hosts, Jim Sammons and Rich Visotcky, for the first episode of the Product Fields podcast in 2026! In this conversation, we discuss the evolving landscape of agility and product management in the age of AI. Together, we explore how AI has transformed product delivery, the importance of accountability, and the need for leaders to adapt their strategies to ensure effective team dynamics. Too often, we have seen companies go full-on into AI without any strategy or understanding of the consequences. Through our discussion, we dive into the balance between leveraging AI for efficiency while maintaining critical thinking and human oversight, and the need for a thoughtful approach to integrating AI into work processes.00:00:00 Intro00:02:04 Agility Beyond Tech: Adapting Principles for Non-Tech Teams 00:03:44 The Relevance of the Agile Manifesto, Values, and Principles 00:08:44 AI's Impact on Product Delivery and Management 00:12:15 Going Back to Principles in the Age of AI 00:16:52 Accountability in the Age of AI 00:28:03 The AI Industrial Revolution: Trust and Human Connection 00:33:58 The Atrophy of Skills in the Age of AI 00:35:07 The Impact of AI on Communication and Authenticity 00:45:38 The Dangers of Over-Reliance on AI 00:47:27 Fundamentals in the Age of AI 00:50:45 The Danger of Agency and AI 00:53:01 The Future of Work and AI Integration 00:57:46 Quantity vs. Impact 01:01:20 Closing Connect with Product Fields:

Another trip around the sun! This year's topics are drawn from a talk by Neil Postman: "All technological change is a trade-off. Technology giveth and technology taketh away." - Do we control the risk? "There is a common tendency to think of our technological creations as if they were God-given, as if they were a part of the natural order of things." - WHY? What will 2026 bring? Our panel today features: Daniel Doiron - https://www.linkedin.com/in/danieldoiron/ Jeremy Willets - https://www.linkedin.com/in/jeremywillets/ Susan Parente - linkedin.com/in/susanparente Freddie Clark - https://www.linkedin.com/in/freddie-clark/ Jeremy Berriault- berriaultandassociates.com Me

The world of delivery has changed—and program leaders must change with it.Join a new generation of leaders mastering Agile, PMBOK, and program leadership through a modern, AI-aware lens. This residency-style certification is designed for experienced professionals ready to step beyond projects and lead complex programs and portfolios with confidence, clarity, and judgment.

The world of delivery has changed—and program leaders must change with it.Join a new generation of leaders mastering Agile, PMBOK, and program leadership through a modern, AI-aware lens. This residency-style certification is designed for experienced professionals ready to step beyond projects and lead complex programs and portfolios with confidence, clarity, and judgment.

BONUS: The Agile Organization as a Learning System Think Like a Farmer, Not a Factory Manager "Go slow to go fast. If you want to go somewhere, go together as a team. Take a farmer's mentality."   Simon contrasts monoculture industrial thinking with the permaculture approach of Joel Salatin. Industrial approaches optimize for short-term efficiency but create fragile systems. Farmer thinking recognizes that healthy ecosystems require patience, diversity, and nurturing conditions for growth. The nervous system that's constantly stressed never builds much over time—think of the body, trust the body, let the body be a body. Value Masters, Not Scrum Masters "We need value masters, not Scrum Masters. Agile is a useful tool for delivering value, but value itself is primary. Everything else is secondary—Agile included."   Tom makes his most provocative point: if you asked a top manager whether they'd prefer an agile person or value delivery, the answer is obvious. Agile is one tactic among many for delivering value—not even a necessary one. The shift required is from process mastery to value mastery, from Scrum Masters to people who understand and can deliver on critical stakeholder values. The DOVE Manifesto "I wrote a paper called DOVE—Deliver Optimum Values Efficiently. It's the manifesto focusing on delivering value, delivering value, delivering value."   Tom offers his alternative to the Agile Manifesto: a set of principles laser-focused on value delivery. The document includes 10 principles on a single page that can guide any organization toward genuine impact. Everything else—processes, frameworks, methodologies—are secondary tools in service of this primary goal. Read Tom's DOVE manifesto here.  Building the Glue Between Social and Physical Technology "Value is created in interactions. That's where the social and physical technology meet—that joyous boundary where stuff gets done."   Simon describes seeing the world through two lenses: physical technology (visible tools and systems) and social technology (culture, relationships, the air we breathe). Eric Beinhoeker's insight is that progress happens at the intersection. The Gilbian learning loops provide the structure; trust and human connection provide the fuel. Together, they create organizations that can actually learn and adapt.   Further Reading To Support Your Learning Journey Resources & Further Reading Explore these curated resources to deepen your understanding of strategic planning, value-based management, and transformative organizational change.    

In this Mob Mentality Show episode, we sit down with Abid Qureshi for a candid and eye-opening look at what Agile Software Development was meant to be versus what the industry turned it into. If you've ever wondered why “Agile” feels bloated today, why teams still struggle to adapt quickly, or why universities are still teaching outdated models like Waterfall, this conversation will hit home. Abid shares his perspective on why the original movement focused on lightweight methods, experimentation, and uncovering better ways of developing software. He explains how the software industry drifted toward heavyweight processes and off-the-shelf frameworks, and what gets lost when organizations treat Agile as a set of fixed best practices (independent of a code context) instead of an ever evolving software craft. He also challenges long-held assumptions about technical excellence, design, and the true sources of agility in modern software development. We dig into: - The contrast between early agile software development and what “Agile” represents today. - Why the title “Agile Manifesto” is misleading and what the document was actually about. - How advances in technology, object-oriented programming, automated testing, and continuous integration made genuine agility possible. - Why real adaptability comes from reducing the cost of change, not adding more process. - The danger of scaling up bureaucracy instead of scaling down and improving engineering practices. - How non-technical contributors sometimes unlock unconventional, high-value ideas that technical experts overlook. - Why many higher education programs still teach waterfall-style thinking and how that hurts new developers entering the industry. - The missed opportunity for universities to lead innovation in software development instead of echoing outdated industry norms. If you care about XP, Lean thinking, software craftsmanship, technical excellence, or getting back to the heart of agility, this episode offers a practical and refreshing reset. Abid's stories and insights challenge the assumptions that hold teams back and point toward a more grounded, engineering-driven approach to modern software development. Video and Show Notes: https://youtu.be/nJI-veSJdkQ  

BONUS: The Evolution of Agile - From Project Management to Adaptive Intelligence, With Mario Aiello In this BONUS episode, we explore the remarkable journey of Mario Aiello, a veteran agility thinker who has witnessed and shaped the evolution of Agile from its earliest days. Now freshly retired, Mario shares decades of hard-won insights about what works, what doesn't, and where Agile is headed next. This conversation challenges conventional thinking about methodologies, certifications, and what it truly means to be an Agile coach in complex environments. The Early Days: Agilizing Before Agile Had a Name "I came from project management and project management was, for me, was not working. I used to be a wishful liar, basically, because I used to manipulate reports in such a way that would please the listener. I knew it was bullshit." Mario's journey into Agile began around 2001 at Sun Microsystems, where he was already experimenting with iterative approaches while the rest of the world was still firmly planted in traditional project management. Working in Palo Alto, he encountered early adopters discussing Extreme Programming and had an "aha moment" - realizing that concepts like short iterations, feedback loops, and learning could rescue him from the unsustainable madness of traditional project management. He began incorporating these ideas into his work with PRINCE2, calling stages "iterations" and making them as short as possible. His simple agile approach focused on: work on the most important thing first, finish it, then move to the next one, cooperate with each other, and continuously improve. The Trajectory of Agile: From Values to Mechanisms "When the craze of methodologies came about, I started questioning the commercialization and monetization of methodologies. That's where things started to get a little bit complicated because the general focus drifted from values and principles to mechanisms and metrics." Mario describes witnessing three distinct phases in Agile's evolution. The early days were authentic - software developers speaking from the heart about genuine needs for new ways of working. The Agile Manifesto put important truths in front of everyone. However, as methodologies became commercialized, the focus shifted dangerously away from the core values and principles toward prescriptive mechanisms, metrics, and ceremonies. Mario emphasizes that when you focus on values and principles, you discover the purpose behind changing your ways of working. When you focus only on mechanics, you end up just doing things without real purpose - and that's when Agile became a noun, with people trying to "be agile" instead of achieving agility. He's clear that he's not against methodologies like Scrum, XP, SAFe, or LeSS - but rather against their mindless application without understanding the essence behind them. Making Sense Before Methodology: The Four-Fit Framework "Agile for me has to be fit for purpose, fit for context, fit for practice, and I even include a fourth dimension - fit for improvement." Rather than jumping straight to methodology selection, Mario advocates for a sense-making approach. First, understand your purpose - why do you want Agile? Then examine your context - where do you live, how does your company work? Only after making sense of the gap between your current state and where the values and principles suggest you should be, should you choose a methodology. This might mean Scrum for complex environments, or perhaps a flow-based approach for more predictable work, or creating your own hybrid. The key insight is that anyone who understands Agile's principles and values is free to create their own approach - it's fundamentally about plan, do, inspect, and adapt. Learning Through Failure: Context is Paramount "I failed more often than I won. That teaches you - being brave enough to say I failed, I learned, I move on because I'm going to use it better next time." Mario shares pivotal learning moments from his career, including an early attempt to "agilize PRINCE2" in a command-and-control startup environment. While not an ultimate success, this battle taught him that context is paramount and cannot be ignored. You must start by understanding how things are done today - identifying what's good (keep doing it), what's bad (try to improve it), and what's ugly (eradicate it to the extent possible). This lesson shaped his next engagement at a 300-person organization, where he spent nearly five months preparing the organizational context before even introducing Scrum. He started with "simple agile" practices, then took a systems approach to the entire delivery system. A Systems Approach: From Idea to Cash "From the moment sales and marketing people get brilliant ideas they want built, until the team delivers them into production and supports them - all that is a system. You cannot have different parts finger-pointing." Mario challenges the common narrow view of software development systems. Rather than focusing only on prioritization, development, and testing, he advocates for considering everything that influences delivery - from conception through to cash. His approach involved reorganizing an entire office floor, moving away from functional silos (sales here, marketing there, development over there) to value stream-based organization around products. Everyone involved in making work happen, including security, sales, product design, and client understanding, is part of the system. In one transformation, he shifted security from being gatekeepers at the end of the line to strategic partners from day one, embedding security throughout the entire value stream. This comprehensive systems thinking happened before formal Scrum training began. Beyond the Job Description: What Can an Agile Coach Really Do? "I said to some people, I'm not a coach. I'm just somebody that happens to have experience. How can I give something that can help and maybe influence the system?" Mario admits he doesn't qualify as a coach by traditional standards - he has no formal coaching qualifications. His coaching approach comes from decades of Rugby experience and focuses on establishing relationships with teams, understanding where they're going, and helping them make sense of their path forward. He emphasizes adaptive intelligence - the probe, sense, respond cycle. Rather than trying to change everything at once and capsizing the boat, he advocates for challenging one behavior at a time, starting with the most important, encouraging adaptation, and probing quickly to check for impact of specific changes. His role became inviting people to think outside the box, beyond the rigidity of their training and certifications, helping individuals and teams who could then influence the broader system even when organizational change seemed impossible. The Future: Adaptive Intelligence and Making Room for Agile "I'm using a lot of adaptive intelligence these days - probe, sense, respond, learn and adapt. That sequence will take people places." Looking ahead, Mario believes the valuable core of Agile - its values and principles - will remain, but the way we apply them must evolve. He advocates for adaptive intelligence approaches that emphasize sense-making and continuous learning rather than rigid adherence to frameworks. As he enters retirement, Mario is determined to make room for Agile in his new life, seeking ways to give back to the community through his blog, his new Substack "Adaptive Ways," and by inviting others to think differently. He's exploring a "pay as you wish" approach to sharing his experience, recognizing that while he may not be a traditional coach or social media expert, his decades of real-world experience - with its failures and successes - holds value for those still navigating the complexity of organizational change. About Mario Aiello Retired from full-time work, Mario is an agility thinker shaped by real-world complexity, not dogma. With decades in VUCA environments, he blends strategic clarity, emotional intelligence, and creative resilience. He designs context-driven agility, guiding teams and leaders beyond frameworks toward genuine value, adaptive systems, and meaningful transformation. You can link with Mario Aiello on LinkedIn, visit his website at Agile Ways.

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview here:https://gotopia.tech/episodes/383Pragmatic Dave Thomas - Pragmatic Programmer Turned PublisherSarah Taraporewalla - CTO APAC at ThoughtworksRESOURCESDavehttps://pragdave.mehttps://twitter.com/pragdavehttps://github.com/pragdavehttps://linkedin.com/in/dave-thomas-53aa1057Sarahhttps://sarahtaraporewalla.comhttps://twitter.com/sarahtaraphttps://www.linkedin.com/in/sarahtaraporewallahttps://github.com/staraporfLinkshttps://pragprog.comhttps://agilemanifesto.orgDESCRIPTIONSarah Taraporewalla (CTO APAC at Thoughtworks) sits down with programming legend Dave Thomas—co-founder of The Pragmatic Programmer and co-creator of principles like DRY (Don't Repeat Yourself)—to discuss his latest book "Simplicity."Dave reveals why he believes "Agile is Dead" and shares his disillusionment with how agile practices have become rigid, corporate processes rather than the flexible, value-driven approach originally envisioned in the Agile Manifesto he helped create. The conversation centers around his new Orient-Step-Learn framework, designed to help individual developers master true simplicity through deliberate practice and feedback loops, emphasizing that real simplicity requires mastery and cannot be achieved overnight.Dave advocates for developers to take personal agency, reduce unnecessary dependencies, and focus on what they can control rather than waiting for organizational change, arguing that simplicity is ultimately about cutting away complexity to reveal elegant, minimal solutions.RECOMMENDED BOOKSDave Thomas • simplicity • https://amzn.to/43FghBJDave Thomas & Andy Hunt • The Pragmatic Programmer • https://amzn.to/43QuMBjDave Snowden & Friends • Cynefin • https://amzn.to/3FSnF3Inspiring Tech Leaders - The Technology PodcastInterviews with Tech Leaders and insights on the latest emerging technology trends.Listen on: Apple Podcasts SpotifyBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

In this episode, Ricardo questions whether Agile is still sufficient in the face of the speed of artificial intelligence. Created in 2001, the Agile Manifesto introduced short iterations and continuous learning to address the unpredictability of software development. However, today, tools become obsolete in days, raising questions about the relevance of 2- to 4-week cycles or a quarterly backlog. Vargas doesn't criticize Agile—on the contrary, he recognizes its essential role for organizations in dealing with volatility. The point is to reflect on how to apply it intelligently in the face of the rapidity of AI: smaller microcycles? More discipline? An "Agile 2.0" that includes governance, ethics, and social responsibility? The challenge is adapting to the current intensity of change. Listen to the podcast to learn more!

                                          Listen in as Erin and Jeff discuss: How Jeff's career as a fighter pilot, cancer researcher, and tech leader shaped the creation of Scrum. Why breaking work into small, prioritized pieces can eliminate 75% of wasted effort. The importance of “working with the willing” and creating a culture of commitment. How Scrum teams can quickly identify performance gaps and self-correct. Why adaptability and short feedback cycles are critical in the AI era … and much more.                                                  About Dr. Jeff Sutherland, co-creator of Scrum, is a global pioneer in agile methodologies. A West Point graduate and former U.S. Air Force fighter pilot, he flew over 100 missions in Vietnam, honing skills in adaptability and teamwork. After earning a Ph.D. in Biometrics and working as a cancer researcher, Jeff transitioned to technology, starting the first Scrum team in 1993 at Easel Corporation, naming it after Takeuchi and Nonaka's rugby-inspired concept. A signatory of the 2001 Agile Manifesto, he developed Scrum@Scale and founded Scrum Inc., training thousands to achieve double the productivity in half the time. His books, including Scrum: The Art of Doing Twice the Work in Half the Time and First Principles in Scrum, share his insights on building high-performing teams. How to Connect With Jeff Website: https://www.scruminc.com/ LinkedIn: https://www.linkedin.com/in/jeffsutherland Facebook: https://www.facebook.com/ScrumInc/ X profile: https://x.com/jeffsutherland YouTube: https://www.youtube.com/scruminc Recommended Resources  Book: Scrum: The Art of Doing Twice the Work in Half the Time: https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X Book: First Principles in Scrum: Advanced Strategies and Reflections: https://leanpub.com/firstprinciplesinscrum Scrum Guide: https://scrumguides.org/

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

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

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

Robert C. Martin, more often known as Uncle Bob, has been programming since 1970 and has served as a mentor to generations of software engineers. He's one of the original authors of the Agile Manifesto and played a foundational role in forming the Agile Alliance, where he served as its first chairman. But beyond titles and organizations, Bob's lasting impact comes through his writing, his lectures, and his philosophy of software craftsmanship. He has spoken at conferences around the world — QCon, Agile 20XX, IT Days, and countless other industry gatherings — always advocating for clarity, discipline, and ethical responsibility in code. And if you've ever read Clean Code, The Clean Coder, or Clean Architecture, you know that he doesn't just teach how to build systems — he challenges us to become better professionals in the process. His most recent work, Functional Design, continues this legacy, distilling decades of experience into patterns and principles that are just as relevant today as they were when he first put finger to keyboard.   Topics of Discussion: [2:22] Uncle Bob's advice for young programmers entering the field: Be cautious with AI tools, learn fundamental programming skills, and understand that AI won't replace programmers. [4:42] Get to the basics first, and then you can move on: Master core programming skills and fundamentals before relying too heavily on AI or advanced tools. [8:19] The impact of AI on experienced developers. [15:44] Highlighting the role of programmers in managing low-level details that managers and customers don't want to think about. [18:43] Programmers as language learners. [27:19] The state of Agile methodologies. [29:33] The original Agile goal of making small teams work efficiently together, which remains a crucial challenge. [35:37] Discussing the limitations of university computer science programs and the potential of trade school or apprenticeship models. [36:07] What's next for Uncle Bob?   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) Clean Agile: Back to Basics  Clean Code: A Handbook of Agile Software Craftsmanship We, Programmers: A Chronicle of Coders from Ada to AI “Uncle Bob Martin: Clean Code and How to Do Software Well - Episode 283” Functional Design: Principles, Patterns, and Practices UncleBob on GitHub The Clean Code Blog Agile Principles, Patterns, Practices Clean Coders   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

In this thought-provoking episode, we sit down with Tobias Mayer—author, coach, and longtime voice in the Agile world—to explore the journey from his early discovery of XP (Extreme Programming) in 1997 all the way to today's debate around the death of Scrum. Tobias shares his personal transformation from developer to Scrum Master, his resistance to early XP, and how he learned great practices from developers he managed. We unpack his reflections on Agile's semantic drift, the role of Scrum Masters as change agents vs. bean counters, and what happens when teams do Agile without even knowing the Agile Manifesto.

Jeff is the co-creator of Scrum and a leading expert on how the Scrum framework has evolved to meet the needs of today's business. The framework he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world. However, Jeff realized that the benefits of Scrum are not limited to software and product development. He has adapted this successful strategy for several other industries, including finance, healthcare, higher education, and telecom.   As the CEO of Scrum Inc. Jeff sets the vision for success with Scrum. He continues to share best practices with organizations around the globe and has written extensively on Scrum rules and methods. With a deep understanding of business process — gleaned from years as CTO/CEO of eleven different software companies — Jeff is able to describe the high-level organizational benefits of Scrum and what it takes to create hyperproductive teams.   Topics of Discussion: [:35] Introduction of Jeff Sutherland, co-creator of Scrum. [3:47] Jeff Sutherland's background: His experience at West Point and lessons in making work visible. [5:19] Fighter pilot experiences that influenced the operational side of Scrum. [6:02] Transition to the Air Force Academy and work in AI at Stanford. [7:38] Learning complex adaptive systems and the origin of Agile from complex systems theory. [8:30] How complex systems theory impacts Scrum and Agile teams today. [9:25] Jeff's first experiences applying Scrum in the banking industry. [11:25] The development of Scrum and the 2001 Agile Manifesto. [12:57] Making work visible and organizing teams, from West Point to Toyota to the Agile Manifesto. [13:23] Fast forward to 2024: Issues in Scrum and Agile practices, including sprint lengths and backlog grooming. [14:34] Jeff's new book: First Principles in Scrum and its relation to Scrum technology stacks. [16:23] Building autonomous systems: Lessons from radiation physics, AI, and complex adaptive systems. [19:16] The influence of autonomous robots on the creation of Scrum. [21:14] Discussion of Scrum and AI, leading to “Extreme Agile.” [22:47] Predictions for the future of Scrum and Agile: Teams becoming 30 to 100 times faster by 2030. [23:37] Example of AI in action: Developing a system to handle expense reports using Scrum principles. [29:37] Challenges with AI-generated code and the need for strong software architecture knowledge. [33:24] The importance of following Scrum “by the book” to achieve hyperproductivity. [35:30] Jeff's closing advice on adapting to extreme agile to stay competitive by 2030.   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 “How the Agile Manifesto Came To Be” Become a beta tester for Jeff Sutherland's AI software project for expense reports: support@quickaireports.com   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Are you ready to conquer the PMP exam and elevate your career? In this video, we break down a proven 4-week study plan designed to help you master the PMP exam with confidence. Whether you're navigating Agile and Hybrid methodologies, tackling knowledge gaps, or honing your strategic approach, this transformative journey will equip you with the mindset for success as a project management professional.FREE PLAN: https://projectmanagementdoctor.com/3...ELITE PMP: http://elitepmpQUIZZES ON 35 TASKS: http://pmpdoctor.comIMMERSION BOOK: https://www.amazon.com/PMP-Exam-Immer...Learn how to streamline your study process by focusing on the three critical domains—People, Process, and Business. Discover practical advice on mastering Agile principles, Hybrid techniques, and predictive project management while understanding the key components like the Agile Manifesto, Scrum Guide, and PMI standards. With insights into leadership styles, conflict resolution, and team dynamics, this guide empowers you to lead with influence and drive results.By following this structured plan, you'll target knowledge gaps, practice with mock exams, and build the confidence needed to excel. Don't miss out on expert tips and tools, including resources like the PMP Exam Immersion book and quizzes at pmpdoctor.com, to reinforce your learning and close the gaps.Start your transformative journey today! Bookmark this video, dive into the study plan, and take actionable steps toward PMP success. Visit pmpdoctor.com or check out the PMP Exam Immersion book on Amazon to boost your preparation. Let's get you certified and thriving in project management. Smash the like button, and let's make your PMP dream a reality!#projectmanagementtools #kanban #hybridprojectmanagement #projectmanagement #agileprojectmanagementvstraditionalprojectmanagementCHAPTERS:00:00 - Introduction00:50 - PMP Exam Study Strategies04:56 - People Domain in PMP07:39 - Process Domain Overview10:42 - Business Environment Insights11:15 - Conclusion and Key TakeawaysPodcast:https://open.spotify.com/show/46uJBml...Online Agile Training for PMP Exam: https://vimeo.com/ondemand/agilepmpMAIN SITE: www.praizion.comPraizion Media specializes in project management education and professional development. Please visit: www.praizion.com for project management and PMP Exam training materials.

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

Is workplace stress just about long hours? Not quite. Brian and Marcus Lagré unpack the real equation behind stress—how pressure, complexity, and security interact—and why your team’s performance depends on getting the balance right. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with Marcus Lagré, product organization coach and author of The Stress Equation, to break down the science of workplace stress. They explore the differences between mental and emotional stress, how pressure and complexity impact teams, and why security in the workplace is a game-changer for performance. Marcus shares research-backed insights on interruptions, stress contagion, and how leaders can create an environment where teams thrive without burning out. References and resources mentioned in the show: Marcus Lagré The Stress Equation by Marcus Lagré Certified ScrumMaster® Training and Scrum Certification Mountain Goat Software Certified Scrum and Agile Training Schedule 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. Marcus Lagré is an author, speaker, and consultant with 20 years of experience in software development, from small-team Scrum to massive 50+ team LeSS transformations. Creator of The Stress Equation, he helps organizations tackle workplace stress systematically, ensuring teams thrive under pressure without burning out. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here as I usually am, Brian Milner. And today we have with us a really special guest, Marcus LeGray is with us. Welcome in, Marcus. Marcus Lagre (00:13) Thanks, Brian, pleasure to be here. Brian Milner (00:15) We were saying before that I'm actually kind of butchering or Americanizing his last name. Marcus Lagre (00:20) Nah, Americanizing, yes, but butchering, no. I wouldn't say that. Brian Milner (00:24) So I'm gonna give you a chance to set the record straight. Why don't you tell us the actually the correct pronunciation? Because I probably can't do it. Marcus Lagre (00:31) Well, my... I would say La Gré, but that's with a Swedish southern accent and not even most Swedes do that, so... Brian Milner (00:34) Okay. OK. Do the Swedish people look on people in the South like we do here in America? Like they're kind of more laid back and slower and... That's funny. OK. Well, we have Marcus on because, first of all, Marcus is a product organization coach. He's an author. He's a speaker. Marcus Lagre (00:48) Yeah, yeah, I would I would say so I would I would say so yeah Brian Milner (01:03) And he has a really great book that we wanted to kind of dive into the topic of here. Because in this day and age, this is a really important topic, but his book is called The Stress Equation. So you can kind of see where we might be going there with that. Well, so let's dive in. Let's talk about that a little bit. And I think probably a good place to start would be, how would you define then stress, when you, if we're talking about stress and the stress equation, how do you define stress? Marcus Lagre (01:30) I usually use the definition of stress because I let's start like this. I think that most people have like a too narrow perspective of what stress is. Like most people probably see it as working long hours and you know, spending a lot of time at work, but it doesn't necessarily have to. And there's this definition of stress from the Oxford English Dictionary that I found really well that stress is the result of, of, of, emotional or mental strain due to adverse or demanding circumstances. So yeah, so there's differences there. And I think that most people, if you're not in a very toxic environment, you don't suffer from emotional stress a lot at work, but mental strain is probably what we're looking at most often. Brian Milner (02:04) Yeah. Okay. Yeah, I mean, I, you know, I wouldn't discount that entirely. I think that there's probably a lot of people out there that have the emotional strain of a bad boss or manager or something like that, right? But yeah, hopefully, you know, hopefully you're right that the majority might not be, you know, dealing with that. It might be more of the mental side of this. So what is mental stress then? What is a mental strain? Marcus Lagre (02:38) Well, mental strain is usually diversified by saying like emotional strain is like the stress from being like in a toxic environment, for example, which is more common than it should be. But mental strain is more of the when you have too much of a mental load, like you're trying to solve a complex problem, like you have high cognitive load in order to solve it, or you need to Brian Milner (02:48) Hmm. Marcus Lagre (03:03) Well, it's also related to cognitive load that you have a lot of context switching. So you need to change information in your working memory quite often and a lot. And that can lead to mental strain. And the problem with mental strain, as I see it in white collar worker or knowledge workers, is that most of us are, we like mental challenges. We like puzzles, we like solving problems. So we're not great at identifying when a mental challenge becomes a mental strain for us. We're used to just pushing on. we try to just, you know, it's just something that I haven't figured out yet. If I push myself just a little harder, I'll crack it. Yeah. Brian Milner (03:42) Yeah. Yeah, that's great. Yeah, I mean, I think you're right. We do like puzzles. We do like challenges. I I know one of the popular things here in the US is the escape room kind of thing. I don't know if you guys have that there as well, but we actually pay people in our free time to give us puzzles and challenges that for fun, we'll go and put ourselves under some mental duress and try to figure out. So I think you're right. there is part of us that really wants to do that. Well, if that's true, then the other side of that is, shouldn't we all be under some kind of mental stress then, since work is challenging and complex and hopefully. Marcus Lagre (04:20) Well, yeah, I mean, not all stress is bad. So I usually say that the stress that we feel at work usually comes from two different sources. So this is the equation. Like the mental strain comes from the complexity that we need to, now that we need to handle. Either the complexity of the problem that we need to solve, or if we're working in, the complexity could also be like the frustration of working in an inefficient organization. That could be part of the complexity. Brian Milner (04:23) Yeah. Marcus Lagre (04:46) So I usually say that pressure is our sense of urgency. The pressure comes from our sense of urgency in order to finish the work that we're, the task that we have at hand or whatever it is that we're trying to solve. And the complexity is whatever makes it harder for us to actually finish that work. So to relate back to what you were saying, shouldn't we be under some kind of stress? Yes, we should. If we don't have any sense of urgency, we're probably not delivering at all. And if there's zero complexity in what we're doing, That should probably be an automated task long ago. We will probably suffer from severe boredom if there's zero complexity in what we're doing. Brian Milner (05:25) Yeah, I always, you know, this comes up sometimes in classes where, I think, you know, I want to find those people who are under zero pressure at work, because I've never been in that situation. I've never had any kind of boss or organization that was like, just take as long as you need. It doesn't matter. There's always some pressure and some places it's more than others and some places it's extreme. But yeah, I think you're right. There's a right amount of pressure. that can be applied. Marcus Lagre (05:48) And there's also constructive stress. I usually diversify like constructive stress is when you try to achieve something because if you're under a lot of pressure solving something very complex, there's also pleasure in actually solving it. So there's some kind of release in the end. But if you're constantly under a lot of pressure or... Brian Milner (05:51) Hmm. Marcus Lagre (06:09) I usually say that the pressure usually comes from things like how we set deadlines, how we handle our backlog. So if you have two short deadlines, then you're under negative stress or unconstructive stress, or we have an ever-expanding backlog. We can never finish everything in this backlog. have no way of saying no to things. They just keep piling on. That's unconstructive stress, but... Brian Milner (06:30) Yeah. Marcus Lagre (06:34) A sense of urgency to reach like a goal? That's more of positive kind of stress. Brian Milner (06:39) Yeah. Yeah. I I've heard, my boss, Mike Cohn talk about before how scrum has just the right amount of pressure that it's, it's not, you know, it's, it's not the kind of, when we think about commitment and stuff inside of a sprint, it's not the kind of thing of, you're going to lose your job if you don't make this sprint commitment. But it is kind of, you know, my, my word is on the line. My name is on the line. And if I don't deliver. I'm letting down my team, I'm letting down those around me. So that's way he describes it. It's kind of just the right amount of pressure that's kind of baked into the way Scrum works. I've always liked that. I've always thought that's kind of a good take on that. So we're kind of in these pressure cookers a little bit, right? We've got pressure and sometimes more than others and we do need some kind of pressure. So we have some sense of urgency in what we're doing. How does this align with our Agile Manifesto kind of ideal of working at a sustainable pace? Is the pressure going to crack us under trying to keep a sustainable pace? And what if we don't have any say over the amount of pressure we have? Marcus Lagre (07:46) Well, if you don't have any say, then I usually say that the pressure isn't a force of nature, that it usually stems from someone's decisions. And if we don't have a say in it, then we can't influence that pressure really as a team maybe. But from a leadership perspective, if you put unlimited pressure on the team, you're gonna see decreasing results anyway. It's not... constructive, you're going to burn your people, you're going to lose, worst case, lose them from the company, either because they change jobs or because they burn out and they have to go on sick leave. So and that's going to cost you in the end. But also that you're going to see either a lot more well, as I said, either a lot of people leaving or people doing quite quitting. That's that's what's going to be because once caring about your own performance becomes dangerous, people are gonna put in the bare minimum. That's the people you're gonna keep. Brian Milner (08:41) Yeah. Yeah. I'm sure there's lots of research baked into this and you've probably crossed a lot of different studies and things that have kind of jumped out at you. And to me, that's always one of the things that's the most interesting when I dive into a topic like this and go really, you know, kind of knee deep into it. what, was there any kind of research that you stumbled upon as you were preparing for this or, you know, creating this book? that really kind of surprised you or that you found extremely interesting? Any studies out there around the effects of stress that kind of shocked you even maybe? Marcus Lagre (09:18) I wouldn't say shocked, but one thing that surprised me was that there was this study that showed, because I talk in the book about complexity, and I mentioned earlier that if you need to change the information in your working memory a lot, that leads to mental strain. But there were actually studies that showed that interruptions in work does not lower the quality of the work. It does, however, increase the sense of stress. But it doesn't necessarily lower the quality of work, which was something that I was absolutely convinced it would. However, there was a correlation between how far if you got interrupted, if it was on topic, so to speak, so that you didn't have to throw everything out of your working memory, then the quality level was still on par with what you would have seen if you weren't interrupted. However, Brian Milner (09:48) Yeah. Marcus Lagre (10:06) if it was something that was diametrically different to what you were actually doing, then yes, the quality would also drop. But I actually thought there would be like a clear correlation between interruptions and lower quality of work. And it wasn't. Brian Milner (10:20) Yeah. So it's not, I mean, what I'm hearing is it's not necessarily the interruption itself. It's the content of the interruption. And if the interruption is, you know, taking you wildly off track from your thought process, that's higher stress kind of a reaction to it. And that leads to more problems. But if it's, if it's an interruption that's near in the same area of what it is you're working on and thinking about, then it's not as hard to get back to it. Less stress, less, let's kind of end result effect, right? Marcus Lagre (10:52) Yeah, there's less mental strain in that scenario. However, you do often feel like you're less efficient, that you get less joy out of what you're doing if you get constantly interrupted, and that the workload is heavier than it actually is. So there's negative sides to getting interrupted a lot, but as long as it's sort of on topic, as you say, it's not really that harmful. Brian Milner (10:54) Okay. Yeah. Well, I know you do a lot of work with organizations and with leaders and organizations. And I know one of the difficult things, difficult kind of parts of having these conversations with leadership is trying to help them to understand the importance and kind of the impact and why this is important in a business sense to them. Not just that, you know, the way I phrase it in classes, it's not just that it makes you a better person, right? which there's value in that. not negating that being a good person is bad. I'm just saying from a business sense, oftentimes leaders want more than just saying, yeah, I'm a better human by doing that, but is it better for the business? So how do you have that conversation with leaders, with organizations to say, this is actually an important thing to focus on. This makes an impact on your business. Marcus Lagre (12:07) usually the challenge is to get leaders to understand that they are also affected by this. Because a lot of the challenges I see in organizations is that I come in and I usually do like an analysis of the organizations, ask around, do interviews and analyze everything. And what I come up with is rarely news to the leadership. They have seen the same thing. The problem is that they never had the time to just sit down and figure things out because they're constantly rushing between meetings. They're constantly rushing to do various budgets, updates, stuff like this, just keeping the mill going. So I usually say that they're too operationally occupied to take a look at the strategic goals and the strategic direction that they need to be going in for the business to run smoothly over a period of time. And so I usually tell them that the most important thing that you can get yourself is like an hour, at least every week that you just sit on your rear end and just contemplate things. I usually use a different word than rear end when I tell them this, just to drive the point home. But yeah, they need to find time. where they can just like no phone, no computer, just sit down for an hour and let whatever enters your head, enter your head because otherwise you will never figure this out. And you don't have to pay people like me premium to come in and tell you things that you are actually clever enough to figure out yourself. Brian Milner (13:41) Right, right. Yeah, so that's so interesting. So it's hard to convince them that stress plays a big impact on their work. I hadn't really thought of it from that perspective, but that's a great point to make. If you can help them understand the impact it has on their work, maybe it's an easier conversation than to say the impact it has on your teams or on your employees' work. Yeah. Marcus Lagre (14:06) I have never, mean, stress is contagious and it ripples down. If you have a really stressed out management, you're gonna have stress in the rest of the organization as well, like on the floor and in your teams. That's just a given, I would say. Brian Milner (14:11) Yeah. Yeah. All right. Well, so I'm following along. I think this is good. So we're talking about how you kind of explain this a little bit more to leaders and help them understand the impact. What about when you get one of those leaders who's just, and I know I've had these before where they're kind of more old school and they look at things and think, you know, you... Well, on your graph of pressure, right? They're much more leaning towards the higher pressure side to place on employees because they take that attitude of, you know, the old phrase that we all hate, work expands to fill the time allowed or whatever that thing is, right? How do you convince that person that, you know, there's an okay amount, but you're kind of really skewing it to the high end and this is now going to have an adverse effect? Marcus Lagre (15:00) yeah, yeah, Brian Milner (15:12) on what you're ultimately trying to do. Marcus Lagre (15:14) My usual angle of attack is to address the complexity of the part of the equation. I probably can't get them to understand or accept that they're applying too much pressure, but what they're actually trying to achieve is to get more output. I mean, that's the goal of their actions. And so I try to get them to understand the complexity that their teams are working under and try to get them to understand that you need to reduce this in order to free up more time and mental bandwidth for output. And that's usually a better way forward than trying to get them to accept that you only get so far with a whip. Once you've whipped one time too many, people are going to just stop caring. Brian Milner (16:02) Yeah. Yeah, you can't come back and use that tool over and over again. It's going to have kind of the opposite effect that you're hoping it will have eventually, right? Marcus Lagre (16:14) People are going to start telling you about problems, for example, because these people are usually the same people who don't want to hear about problems. Don't tell me about problems, tell me your solutions kind of attitude. And I usually get them to understand that you have absolutely no idea what the problems of this organization is, because people are afraid to tell you. Brian Milner (16:22) Yeah. Right. Yeah, that's such a huge point, I think, for leaders to kind of soak in and understand. If you have that culture, if you are generating that culture of fear in the organization of, don't come to me with problems, only come to me with solutions, then you're right. You're absolutely right. You're closing yourself off. And you're kind of establishing the norm that if there is an issue, The last thing to do is to raise it, to let people know about it, live with it, right? Just kind of exist with a status quo. If there's a problem, then you just have to learn to live with the problem. Marcus Lagre (17:09) Live with the problem or game the system so the problem isn't apparent. Brian Milner (17:13) Right, right. So back to the equation then. So your equation here, pressure times complexity over security. I don't know what we've talked much about security so far. So how does that come into play when you calculate this kind of pressure equation, stress equation? Marcus Lagre (17:25) Bye! Yeah, well, we kind of touched on it now, like with leaders who act in a way that lowers the security or the sense of security. So I define security as the freedom from fear at work. And psychological safety is one part of that. But it's also that you feel that you have... I'm sort of reluctant to use the words servant leadership anymore because there's sort of... sort of become a tainted word in some ways. People see it as a passive leadership style, which is not really, I don't quite agree with that, but security is in essence that you are able to take high pressure and high complexity if you feel that you have the management in your back, that you're taking it on as a team, that you're not alone with all of that pressure and all of that complexity, but you have people around you who you can rely on and ask for help. If you have that, then your security is higher and then you can take more pressure, you can take more complexity without burning out. Brian Milner (18:32) Yeah, yeah, that makes complete sense because if I have the kind of that sense of security that I'm not at risk, I don't feel like I'm being put in a position to fail so that I'm now in danger, but I've been given difficult problems because I have been trusted to conquer them. I've been trusted and empowered to kind of overcome them. That's such a different approach and mindset from an employee standpoint than, my gosh, I got to do this or I'm going to get fired. Marcus Lagre (19:05) Exactly, there's probably, management has probably let me know that we understand, we're handing you like a really tough thing to solve. if you need anything, if you need any resources, if you need any extra help, just ask us for it and we'll solve it. And in that situation, you're a lot more likely to... be able to get into that without burning out simply because you know that I have the management backing me up. Brian Milner (19:37) if I'm one of those employees who's under a high pressure environment, and I don't really feel like I have the power or authority to make that change, what can I do about it? Marcus Lagre (19:50) I mean, the thing that you can do is to change what I usually, one of the reasons why I wrote this book is that stress is one of the leading causes of mental illness and sick leave in our line of work, which is software. So if something is the leading cause of a problem, it's probably systemic, it's not individual. So one of the most important thing, that you can do is to identify what in the system is causing the stress in me, because ultimately stress is a subjective feeling. it manifests itself in people, but you can get the tools to identify what in the system is causing the stress in me. that can be quite a relief to not put that... I mean, put additional pressure on yourself by thinking that you're the one who's bad at your job or you're the one who don't have the correct coping mechanisms for the situation. The situation might actually be insane. Brian Milner (20:51) Yeah. Yeah, it's that subjective nature, I think, that is kind of a variable that I would throw into this equation. It's sort of like, I know one of the things I found really fascinating in kind of the earlier history of Agile and the idea of a sustainable pace was originally there was kind of talk about saying, using words like, no one should work more than 40 hours a week. But then that got changed to sustainable pace because of the realization that for some people 40 hours was too much and for other people 40 hours was not enough. And so that idea of sustainable pace was, it's individual, it's different to different people and that's part of what we got to do is know ourselves enough to know, hey, I'm kind of slipping beyond that point where I can sustain this indefinitely. Marcus Lagre (21:37) Yeah, and I think that's one of the myths that I want to bust a little bit is that, you know, it's not about 40 hours. It's not about the hours. I mean, there are some people who can work 60, 80 hours without burning out. So it's not the hours. It's something else. You know, so it's the end of the... Maybe it's the pressure that we have too much pressure. Maybe it's that we have too high complexity in combination with pressure. Maybe it's that we are in a toxic environment. So it's like how much mental energy do I need to handle the context that I'm in? That's. Brian Milner (22:13) It's almost like there needs to be kind of this balance between those three things that you've got to, one thing might go a little higher, but the others then have to drop a little bit so that it kind of equals out, right? Marcus Lagre (22:22) Yeah. That's what I, like, I always say that if you want to put high pressure on your teams, on your organization, you have to reduce the complexity because you can't do both at the same time. Those are the two variables that increases the stress. But then as we mentioned, like feeling of security is the lowering factor. So you always do well working with Brian Milner (22:38) Yeah. Marcus Lagre (22:46) the sense of security within your teams and working with your culture and making sure that toxic behavior is simply not acceptable in this organization, for example. And so that's always, you always get a reduced level of stress from that kind of work. But as I said, if you have high complexity and you put too high pressure on something, it's gonna break sooner or later. You're either gonna break your people or you're gonna break your product. because you're going to reduce the quality of the work because you have to stress through everything. And quite frankly, I don't care about your product. You're free to break it if you want to, but breaking people, that's just not okay. Brian Milner (23:18) Ha ha. Yeah, now we're back to being a good human, right? mean, these are humans. They're not AI programs, at least not yet. And they have lives. the more that you, like you're talking about, the more that you increase that pressure on them or decrease their sense of security, the less complexity they can handle. And you know, You have diminishing returns on your employees, on their productivity. Marcus Lagre (23:48) It is unsound business. Brian Milner (23:50) Yeah, yeah, absolutely. Well, this is fascinating. I really appreciate you coming on and talking about this. Again, for anyone listening, if this topic is interesting to you, highly recommend you check out the book, The Stress Equation by Marcus Le Gray, even though that's not actually the way to say the name. it's L-A-G-R-E, just so everyone knows. I don't want you to struggle searching for it if you're looking for it. We will put the links to it in the show notes for this episode so that you don't miss out if you're trying to contact Marcus or you want to know more about the book. We'll make sure you find a way to do it. So Marcus, I really appreciate you coming on. This has been a fascinating topic and I appreciate you sharing your wisdom, your research and your knowledge on this with us. Marcus Lagre (24:31) The pleasure was all mine, Brian.

Scott Ambler helps people and teams adopt new ways of working (WoW) and evolve their ways of thinking (WoT), particularly around data warehousing and data quality. He is the creator of the Agile Modeling (AM) (AgileModeling.com) method and Agile Data (AD) (AgileData.org) methods. With Mark Lines, he co-created PMI's Disciplined Agile (DA) toolkit. As a conference keynote speaker, he speaks about continuous data warehousing (DW)/business intelligence (BI), how to address enterprise data debt, how to succeed at corporate AI, and agile architecture. He has also (co-)authored several books, including Choose Your WoW!, An Executive's Guide to Disciplined Agile, Refactoring Databases, and Agile Modeling. For a full list of his books, visit Scottambler.com/my-books/.   Topics of Discussion: [4:29] Scott talks about his career journey. [6:53] Scott's early involvement in Agile. [8:34] Needing to up our game in the Agile space. [8:55] Agile2025 Conference this summer in Denver, CO. [11:20] Challenges and evolution within the Agile community. [20:01] Are we going to have a new Agile gold rush? [21:47] Keeping an eye out for inappropriate processes. [25:38] How we can do better. [28:17] The Agile Manifesto. [35:03] Importance of database refactoring and continuous data operations. [36:46] What best practices does Scott recommend?   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! Scott Ambler Scott Ambler LinkedIn The Future of Agile Isn't Shit   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Does the Agile Manifesto still guide us? The Manifesto has been an integral part of our professional lives. Organizations and teams seem to be tired of values and principles. Is the Manifesto still relevant? Our panel today features: Daniel Doiron - https://www.linkedin.com/in/danieldoiron/ Jeremy Willets - https://www.linkedin.com/in/jeremywillets/ Jon M Quigley - https://www.linkedin.com/in/jonmquigley/ Freddie Clark - https://www.linkedin.com/in/freddie-clark/ Jeremy Berriault- berriaultandassociates.com Me

Xmas Special: Investing in Software: Alternatives To Project Management For Software Businesses With Vasco Duarte In the grand finale of the “5 Wishes for 2025” series, Vasco Duarte tackles the chaotic nature of software development and why traditional project management just doesn't cut it. Drawing on lessons from weather models, butterflies, and Agile practices, Vasco presents a bold manifesto for how we can thrive in uncertainty. Chaos Theory and Software Development “Project management is like trying to predict where a butterfly will land after flying through a hurricane – good luck with that!” Vasco begins with the story of Edward Lorenz, the MIT meteorologist who discovered what was later called the “butterfly effect.” This concept illuminates and explains the unpredictability of software development, where tiny changes can lead to massive, unexpected consequences – like a simple tweak spiraling into a full system refactor. Why Traditional Project Management Falls Short “Planning your year's meals in January? That's about as realistic as predicting October's sushi cravings!” Vasco humorously dismantles the premise of project management, which assumes stability, predictability, and complete information upfront. While Agile provides a more flexible approach, it's often misused as “project management in disguise,” failing to unlock the true potential of adaptability. The 2025 Manifesto: A New Way to Invest in Software “Loving Gantt charts is like loving fax machines – there's a better way!” Vasco outlines his four-point manifesto for how organizations can thrive in uncertainty: Fund Software Incrementally: Treat funding like stock market investing – small, regular investments over time. Think Like an Investor: Focus on maximizing returns, not rigidly executing plans. Experiment by Default: Acknowledge that the best ideas come from testing and iterating. Give Teams End-to-End Ownership: Empower teams to own their work from idea to delivery, eliminating micromanagement. The Need for Agility at All Levels “Scrum teams in a project management organization are like race car drivers stuck in traffic jams – all that potential, nowhere to go!” Vasco emphasizes that agility must extend beyond individual teams. Organizations need to embrace Agile principles at every level to avoid stifling innovation and potential. And his approach to funding and managing software investments does exactly that: bring agility to the decision making forums in the organization, instead of keeping it at the team level. A Wish for 2025: Embrace the Chaos “Butterflies don't follow project plans, and neither does software development!” Vasco's final wish for 2025 is for organizations to stop forcing software into rigid project management frameworks. Instead, they should embrace the unpredictable nature of development, leveraging incremental funding, iterative experimentation, and team empowerment to thrive in uncertainty. See It in Action: Global Agile Summit 2025 “Want to see how real organizations are thriving in chaos? Join us in Tallinn!” Vasco invites listeners to the Global Agile Summit 2025 in Tallinn, Estonia, where forward-thinking organizations will share their stories of breaking free from traditional project management. Holiday listeners can grab a 75% discounted Super Early Bird ticket at GlobalAgileSummit.com. About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

Agile has become a cornerstone of modern development, yet the essence of its value often gets overshadowed by procedural or tool-based interpretations. In the recent Building Better Developers podcast, Rob Broadhead and Michael Meloche delve into the foundational principles of Agile and its relevance to building better developer habits, emphasizing adaptability and continuous improvement. Here's a summary of their key insights and practical takeaways for cultivating an Agile mindset. Understanding Agile: A Framework, Not a Formula Agile isn't a fixed set of tools or methodologies but a mindset underpinned by the Agile Manifesto's four core values: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. These values encourage focusing on people and outcomes, not rigid structures. Agile allows flexibility in navigating challenges, fostering collaboration, and driving solutions that truly matter. Key Takeaways from the Episode 1. Pivoting Is a Strength, Not a Weakness The hosts highlighted the importance of pivoting when a project encounters hurdles. Unlike the waterfall model, Agile embraces flexibility. For example, Michael shared a 16-hour development detour that required re-evaluating the approach when the original solution proved untenable. This adaptability, while frustrating in the moment, prevented further wasted effort and allowed the team to refocus. 2. Breaking Down Goals: The Ruler vs. Yardstick Approach Agile replaces the traditional “yardstick” of fixed, linear progress with “six-inch rulers” of iterative development. This analogy underscores the value of short-term planning and regular evaluation to ensure the project remains aligned with goals, even if adjustments are needed. 3. Tools Are Helpers, Not the Rulebook While tools like Jira and Trello are helpful for visualizing progress, Rob emphasized that developers should avoid becoming slaves to their tools. Instead, use them to enhance collaboration and accountability, ensuring they serve the project rather than dictate it. 4. Collaboration Over Negotiation A major Agile tenet discussed was fostering collaboration with customers rather than fixating on rigid contract details. The hosts illustrated this with scenarios where understanding the “why” behind a customer's request—like insisting on a purple button—can reveal insights that shape better solutions. Instead of challenging requests outright, developers should explore the reasoning, aligning efforts with true business needs. Practical Agile Developer Habits 1. Revisit the Agile Manifesto Regularly Even seasoned developers benefit from revisiting Agile's principles to maintain focus on its core values. The manifesto and its 12 principles can serve as a moral compass, helping developers navigate project complexities. 2. Leverage Daily Sanity Checks Inspired by tools like the Pomodoro technique, developers should periodically assess whether they are being productive or merely busy. This could involve reflecting on progress mid-day or after completing a sprint. 3. Plan Weekly and Adapt Daily Rob proposed an excellent challenge: set weekly goals and adjust daily plans as needed. This builds the habit of agility while maintaining forward momentum. 4. Simplify Where Possible Michael recommended automating repetitive tasks, such as server setups, to save time and reduce cognitive load. Iteration and simplicity go hand-in-hand with Agile values. Agile Developer Habits in Action Agile isn't just for project managers or scrum masters—it's a way of thinking that benefits individual developers and entire teams. By focusing on collaboration, adaptability, and meaningful progress, Agile fosters an environment where everyone can thrive. If you're new to Agile, start small. Explore tools like Trello or Jira to organize tasks, or dive into the Agile Manifesto for inspiration. Remember, building better habits begins with understanding the principles that drive meaningful change. As the podcast hosts reminded listeners, Agile is about progress, not perfection. Whether you're automating workflows, tackling blockers in a sprint, or refining your daily routine, embracing Agile values can elevate your development practice and help you build not just better software, but a better version of yourself. Listener Challenge: Weekly Planning, Daily Adapting 1. Set Weekly Goals At the start of the week, identify a few larger goals or tasks that you aim to complete within seven days. These should be substantial enough that they cannot be completed in a single day, requiring consistent progress. 2. Plan Daily Tasks Each day, determine smaller tasks or steps that contribute to those larger goals. These tasks should be adaptable, meaning they can evolve based on progress or changing priorities. 3. Monitor Your Process Pay attention to whether sticking to a fixed schedule (working on the same task at the same time daily) or adapting your workflow dynamically works better for you. Evaluate if adjustments improve productivity and align with the Agile principle of responding to change over following a rigid plan. The goal of this challenge was to instill habits of flexibility and iterative progress, mimicking Agile's core values while fostering personal and professional growth. Stay Connected: Join the Develpreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Agile Principles Summary – Our Next Steps Patterns For Agile – Templates for Success Scrum Ceremonies – Running An Effective Sprint VIDEO: Coaching Tips to Stop Teams Equating Points to Hours Building Better Habits Videos – With Bonus Content

What does it take to be an effective Scrum Master? In this episode, Brian Milner and Gary K. Evans, author of The Effective Scrum Master, explore the nuanced role of Scrum Masters, the importance of people skills, and the shift from efficiency to effectiveness. Overview Join Brian Milner as he chats with Agile coach and author Gary K. Evans about the essential qualities of an effective Scrum Master. From fostering self-organizing teams to balancing proactive leadership with people-centered strategies, this conversation unpacks the skills and mindsets needed to thrive in the role. Whether you’re new to Scrum or a seasoned pro, this episode offers fresh perspectives and practical advice for taking your Agile expertise to the next level. References and resources mentioned in the show: Gary K. Evans The Effective Scrum Master: Advancing Your Craft by Gary K Evans Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Certified ScrumMaster® Training and Scrum Certification Advanced Certified ScrumMaster® 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. Gary K. Evans is a seasoned Agile Coach and author of The Effective Scrum Master, with over 30 years of experience transforming Fortune 100 and 500 companies through Lean-Agile practices. Known for his expertise in building high-performing teams and training over 15,000 professionals, Gary brings a unique focus on people-centered solutions to complex organizational challenges. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are back and it's another episode of the Agile Mentors podcast. We're getting towards the end of the year. I am here with you, as always, Brian Milner. And today I have a very special guest with me, Mr. Gary K. Evans is with us. Welcome in, Gary. Gary (00:17) Thank you, Brian. It's great to be here. Brian (00:19) Very glad to have Gary with us. Gary is an agile coach. He's a lean consultant. He owns his own company called Evanetics, but he is also the author of a newly published book that came out this summer. It's called The Effective Scrum Master. And it really is a comprehensive guide. It's a really interesting read. So I thought we'd have him on to talk to us about. what that means, an effective scrum master. So scrum master is this episode, I think it's gonna be really a special one for you. So Gary, let's start with that question. When you say an effective scrum master, what is an effective scrum master? Gary (00:56) In my experience, I've worked with a lot of Scrum Masters who go through the motions, they understand the events, they focus on how to run these Scrum events. But the teams flounder and they struggle with what should I do next? How do I anticipate things? And the Scrum Masters themselves often get very frustrated. One of the complaints that I hear, especially from early to mid-career Scrum Masters is I have this anxiety. How do I know that my team is operating as efficient, as efficiently and effectively as they can because they focus so much on efficiency. So this idea of effectiveness really is much more important. In fact, John Kern, one of the co-authors of the Agile Manifesto, who wrote the foreword for my book, he focused in on that word effective because we spend so much of our energies trying to be efficient. that we aren't accomplishing what we need to do, which is to build self-organizing, mature teams. And that's really the focus of my book. Brian (02:01) That's an awesome distinction, I think, because I like that a lot. There's a conversation that I will have sometimes in class about how that drive or search for trying to be not effective, sorry, what was the other word that you used? Efficient, sorry, sorry, just slipped my mind, ADHD. But the efficient kind of quotient there I think is... Gary (02:18) Efficient. Brian (02:27) something that in business in the business world today is a highly visible term. It's something that everyone seems to think is needed. But, you know, that really dates back to sort of the assembly line and efficiency experts that would stand behind you with a stop clock and try to get you to do something, you know, point two seconds faster so that it would total up to, you know, more productivity over the course of the day. But that's not the kind of work we do. Gary (02:56) I love the fact that you've mentioned that that was really the Frederick Winslow Taylor scientific management approach. And it was very much based on this idea of efficiency. But I have seen so many teams and as an agile coach, I've had multiple experiences of teams that are very, very efficient at going in the wrong direction entirely. They've lost their focus on true north. They don't understand what it is they're actually supposed to do. They think that the Scrum Guide, 14 pages in the Scrum Guide, is their Bible. And that's all that they need to know. And nothing could be further from the truth. Brian (03:37) Yeah. Yeah. And to me that, you're talking about efficiency versus effectiveness. You know, if we were a company that was trying to create a new drug to cure some disease, you know, I want effective. I don't want efficient. I don't want someone, I don't want to produce a million pills that don't work. I want to produce, you I'd rather produce one that works, you know. Gary (03:59) Exactly. Brian (04:05) And that seems to be kind of something that I think a lot of teams are missing today. Gary (04:09) It does indeed. Brian (04:10) Well, good. I like that distinction. I think that's a good distinction and that's a good place for us to start to think about this role as being kind of more effective. I think that they're sort of, I don't know, I'm kind of curious what your take is on this. Is it a marketing problem? Is it an education problem? Why is there so much confusion, I think, about what a scrum master, what a good scrum master is? Gary (04:41) That's a really deep and broad question. Part of it is that in the beginning, when Scrum was introduced into the community and was just beginning to become known, there were two attributes of Scrum Masters that were repeated again and again and again. That was you became a servant leader for the team and you removed impediments. Brian (04:44) Just a light casual one here. Gary (05:09) Unfortunately, most people stopped at that point. And they didn't realize that this, the Scrum Master role, and I'll admit, I take a very expansive view of the Scrum Master role because I've been doing this since 1993, basically, 1994. And I've learned through making lots and lots of mistakes. And the idea that All we have to do is be a servant. Well, what does that mean to be a servant leader? Nobody ever really defined it. I actually wrote an essay a number of years ago on what it meant to not be a servant leader so that I could understand by contradiction what it was that I should be doing. I called it the top 10 scrum master crimes. And really, a lot of them really had to do with crimes because it's very easy for a scrum master to start to merge into making decisions for the team that the scrum master should not be making. Now, there are times when a scrum master should direct the team, should make decisions for the team if the team is not qualified to make certain decisions because they're just too new. But this idea of being a certain leader There's so much more to that. In my expansive view of the Scrum Master role, it is not a process role first. It's a people role. And to be an effective Scrum Master, you have to be an effective people person. I've worked with so many teams and coached Scrum Masters. Scrum Masters just did not like people. They weren't people persons. And the teams responded accordingly. So. A lot of the coaching that I do with my Scrum Masters is you've got to reach deep. You've got to be able to get into people's lives rather than hold them off, you know. And so a lot of it has to do with that. Brian (07:10) I love that. I wholeheartedly concur with that. I've talked on this podcast a little bit about how it seems like we've lost the focus of that first line of the Agile Manifesto, individuals and interactions over process and tools. And I mentioned when I go to Agile conferences sometimes, I feel like the majority of the talks that I see and hear are process and tools talks rather than know, individuals and interactions talks. And I can't agree more. I think that's really a focus for us as Scrum Masters is the individuals and interactions portion, the people portion. You know, our teams are made up of people and if we're not good with helping understand how people work together, we're kind of really missing the value of what it is we deliver to the teams, I think. Gary (08:04) And Brian, the people are all different. And to have a one size fits all because the scrum guy says do X, and Z. Well, that'll work for some people, but it will not work for others. And it may even build resentment within the team because they feel that they're being treated unfairly. The focus, the theme of my book and the reason I wrote the book. Brian (08:06) Right, exactly. Gary (08:30) is that I had seen so many teams that were floundering under Scrum Masters who really didn't understand their own role. And I came up from my experience, I defined four different categories that helped to elaborate what the Scrum Master should be if they want to be effective. And I labeled those as Sherpa, Shepherd, Sheepdog, and Diagnostician. I couldn't really think of a word. I started with an S for diagnosticians. But I have a strong medical background, so diagnostician really helped because the sherpa is the expert. And to be an effective scrum master, you have to be an expert, not at scrum, but at agile. We really want, I want my scrum masters to be agile masters. And as a coach, I'm constantly pushing them. How are you improving your craft? And what is involved in that craft? So you've got to be an expert. Brian (08:58) Hahaha. Gary (09:26) Now for a new scrum master, that's a contradiction in terms. You can't be an expert if you are just at the beginning of the journey. But there are things that you can do. And I discussed this. In order to from exposure, you can gain experience. And from experience, you can generate expertise. And so that's the first one. If ultimately you need to be a master of Agile. Secondly, a Sherpa and then a... a Sherpa and then a Shepherd, you have to be able to guide the team. And you can't guide somebody if you haven't been through that path before. So this is where the issue of longevity, education, and just exposure and experience with different teams on different projects. This is where the maturity comes and you start to develop a depth of understanding. But then there's the hardest part, the hardest persona of the scrum master is the sheepdog. This is where you are the protector of the team. And so many scrum masters fold in this area because a threat will come either from management or from within the team or somebody outside the team like a product owner. And the scrum master doesn't understand how to protect his or her own team. I'll share a little war story with you that is in the book. I had a product owner who one morning came in and just started ripping through several of my team members. I don't know what happened at that point. I stepped between him and the team and I said, do not take another step forward. I was ready to defend my team physically. It didn't come to that. And later I learned the reason for why he was so upset. But if you're going to be a sheepdog and protect your team, it may require personal sacrifice. It may require professional sacrifice. And this is the area where so many scrum masters, they can't deal with that part because they don't have that confidence. So you've got the Sherpa who's the expert, the shepherd who is the guide. The sheepdog who's the protector and finally the diagnostician who is the healer. Things are going to go awry and you have to have a way of diagnosing what the root cause of the problem is. And this is where the issue of metrics and understanding your team members, building a rapport with your team members that quite often is extremely intimate. I have had team members, I have a series of questions I ask all my team members so that I understand their background and such and also things that I need to be aware of. And I will ask them, do you have any medical issues or other accommodations that we might need to consider for you? This is an issue of respect so that we don't put somebody in an uncomfortable situation. It's a strictly private conversation. I've had people share with me that they have a drug problem. that they're caring for an ailing parent, that they're going through a divorce, all kinds of different issues that come out. And we work out special signals so that if they're having an episode someday, they just give me that signal. And I know that I need to either give them space or give them some special consideration. This is what I mean by the people issue. You've got to get to the point where you allow people's lives to splash onto you and you get wet with their issues. And yet you still have to maintain your autonomy and separation in order to work with the whole team together. The Scrum Master role is extremely complex from my perspective because it involves people, as you say, individuals and their interactions. That's where we have to start. Brian (13:33) I agree. And that's a great call out to say, to talk about there, just the idea that, you these are, these are individuals, not, they're not robots, you know, like they're not AIs yet. These are human beings and they have lives outside of work. They have things that affect them. And if they're going through a divorce, like you said, then you think that might affect their work life? Well, of course it will. Cause they're a human, right? And that's gonna... Gary (13:43) Right. Yes. Brian (13:57) that's going to affect their, their mood that day. That's going to affect, you know, how productive they are. It's going to affect lots of things. And, and, you know, we, we've talked here on the podcast a little bit about making accommodations for people with different, neurodivergent traits like ADHD or, autism or other things like that. And, know, I've always loved the idea of, know, putting people in the best position to be successful, you know, trying to understand what is. unique about them, strengths and weaknesses, so that you can help them to be put in a position that they can shine, right? They can really contribute in their own unique way. And we have to allow for both those strengths and weaknesses. We have to help them with the weaknesses. We have to put them in a position to share their strengths. Gary (14:49) And this leads to a slightly different topic if I can move up a little bit. The scrum master role is an endangered species right now. And there's a reason for that. There's several reasons for that. One of which is what we've been talking about. So many scrum masters are not people persons. And as a result, the teams are not accomplishing what the organization needs. And therefore the scrum master is regarded as overhead. Brian (14:52) Yeah, please, please, please. Hmm, yeah. Gary (15:19) as ineffective. And frankly, that's correct. There are currently, if you look at the Scrum Alliance and Scrum.org, I got the figures from these companies as of the beginning of this year, there are about two million Scrum Masters in the world right They're not all equally effective, Many of them are PSN1s from Scrum.org and there are like 625,000 of those, that type of thing. And then you get 39,000 PSN2s and then you get a thousand or so PSN3s. You can see the drop off there, just huge drop off. And the certification issues lead people to think that they're a Scrum master. Scrum two days or? An online examination doesn't prepare you. It simply doesn't. We've not done a good job of helping people understand through these major certification roles. that this is a starting point, but it's not going to make you effective. And part of it is it's become commoditized. And so we have this issue of lots and lots of scrummasters, most of whom really are not people persons and most of whom don't understand how to deal with a team and build a team rather than just an assembly of individuals. I've taken over teams that have been floundering. I've done this multiple times. And on day one, it's a series of isolated individuals. That's the best that they could have. Because there was no cohesion that could be found. And that always takes me a lot of effort and a lot of time to figure out how can I find cohesion within the team. So it's exhausting. The Scrum Master rule is really exhausting at times. And if someone's not tired at the end of the day, they're not doing it right. Brian (17:22) Yeah, I really am in alignment with what you're saying here. And I've thought about this issue a lot as well, and just the idea that we seem to find ourselves in a situation where, as you said, there's a lot of people who have that certification. And as someone who gives people certifications, I have to take my own part in that. I have to accept my own role and what that plays in it. But I think that you're right to... The training is necessary, right? You have to understand the basics. You have to understand these things before you can do anything else. However, I think that the disservice that the industry has done is to make this proclamation that if someone is certified, that they are ready to lead. And that really is what a Scrum Master is, is a leader in the organization. They're a leader for the Scrum process in the organization. And that's just... Gary (17:55) Yes. Yes. Brian (18:23) not true, right? It just takes more ongoing mentoring and coaching for that person to get to a place where they are really a, you know, what we would call a change agent, right? They are there to, you I always like to use the term infect the organization. They're there to spread and infect this mindset, this philosophy. And if we don't understand it ourselves, if we're not really living that philosophy, If we want our team to be experimentation based and we don't experiment ourself and we don't kind of demonstrate to them what it looks like to experiment, to try things, to fail, to figure out why that didn't work and then apply a new change and say, let's try something different. If we don't demonstrate that, not just tell them, but demonstrate it, they're never going to get that. They're going to stay, as you said, a collection of individuals. And I think that's, to me, that seems to be one of the big issues today with Scrum Masters and with Scrum in general is just that we have, you know, in opposition to your book, ineffective Scrum Masters that aren't really helping people see what Scrum should be. Gary (19:41) Exactly. And you've touched on what I call the four E's, which are exposure, experience, expertise, all built through experimentation. And you use that word to experiment. We need to experiment. But experimentation takes courage. Now that is one of the Scrum values. But when you get a young person or a new Scrum master who's in a role in an organization that may have certain, let's say, unsafe environment and cultural factors. It's very difficult for most people to build that courage to say, we've got to change this and become agents of change. Now, obviously they can, they should be diplomatic. They should be respectful, but they should also be persistent. But being able to see that requires a vision. You have to be able to be able to look around and see where are the big problems that we have? Why should I rearrange the deck chairs on the Titanic if the ship is sinking? Brian (20:41) you Gary (20:45) And so having that vision, again, comes from maturity. And the Scrum Masters that I work with, I push them pretty hard because I want them to grow. And every one of them has thanked me. But they didn't thank me during while it was happening. Brian (21:06) Ha Yeah. Yeah, I can understand that. mean, we, you know, one of the analogies I'll use there is like, we, a lot of us that have gone through the process and become a trainer will say it was hell while we went through it, but we look back on it and think that was necessary. We needed to go through that. now that we've gone through it we're on the other side, that was a necessary component of becoming an effective trainer was really seeing it up close and personal and seeing how other people do it. So I completely get that. Gary (21:31) Exactly. Brian (21:36) I want to ask you a question here that I know this is a loaded question. I get this question all the time. But I thought it might be interesting to hear your perspective on this from the effective Scrum Master perspective. People constantly ask, well, what does a Scrum Master do all day? Because when you look at the Scrum Guide and you look at the things that we have as responsibilities, You know, the two main responsibilities we have that are ongoing is to make sure events happen and make sure that the time boxes are kept according to the Scrum Guide. But I try to tell people there's a lot that goes on between those events. It's not just about the events, right? There's a lot that we do. just help our audience. For those people who are listening and don't really have a clear picture of what a Scrum Master does, just give us some samples of what you see as activity that effective Scrum Masters would take on a regular basis. Gary (22:30) What an interesting qualitative question. Brian (22:33) Ha ha ha. Gary (22:34) And I say qualitative on purpose. What does a scrum master do? What a scrum master should do is listen, listen a lot, observe, even if you're remote and virtual. You should be monitoring the Slack channel. You should be having video sessions. You should be attending team discussions whenever you can, but not only to listen, but to be the last one to speak. This is a big issue. So a scrum master often is considered to be doing nothing. But what the scrum master is doing is listening, watching, being the last to speak so that he or she does not taint the conversation among the team members. And it's very easy for that to happen. They should be compiling. team metrics. And I have a very lengthy section in the book on metrics, not only velocity and burn down charts and that type of thing, but a number of other other metrics that I've developed over the years for my own teams. So that the Scrum Master and the team can understand their own performance. They should be training, obviously, as a Sherpa, as an expert. They should be conveying knowledge to the team and they should be teaching every time they're talking to somebody, they should be teaching someone. So it's not a prescribed set of activities in my estimation of what a scrum master does. And I'm going to I'm going to use an analogy here. And it's going to it's going to offend some people because they're going to say, that's a terrible analogy. Well, it's actually a good analogy if you take it as that. The scrum master is like a parent. and needs to nurture the family. How does a parent, what does a parent do? They listen, they observe, they teach, they guide. Sometimes they have to protect, sometimes they have to discipline. And these are all skills that make for a good effective scrum master. So as I say, it's a qualitative issue. But a person who cannot parent well, I'm not saying the team are children, I'm saying they're your family. You need to parent your family. And you need to, as an experienced person who hopefully has a bit more experience and exposure and wisdom. and has better insight into how the world works, even the world of the organization, the Scrum Master has to be able to convey that on a day-to-day, hour-to-hour basis. It is not a part-time job. It is a full-time, exhausting, boots-on-the-ground position that many people just cannot fill. It's sad, but not everybody can do everything. Coming back to the certifications again, job ads always want to know you need to have a CSM or a PSM. You need to have an ACSM, type of thing, advanced certified Scrum Master. These are proxies that companies use because they don't know what a Scrum Master does. They don't know how to qualify it. So they try to quantify it through a certification. And what they have are two million Scrum Masters. who are certified in the world. How many of those are really good? Not all of Brian (26:06) Right. Gary (26:07) So the reason that I dwell on this a little bit, Brian, is my book is there to help people understand. not only the limits, but the expanse of what they should do. And there are limits to what a scrum master should do, but there's also an expansive view of they need to do more than just be a servant leader and remove impediments. Those are important. That's not the end of it. Brian (26:33) I agree. It's kind of interesting because it's a delicate balance, right? Because it's sort of like, you know, there's not a recipe. There's not a clear, hey, here's the 10 things that you do every day. And just when you come in the morning, check this list off and do these things, right? There's not that. But I think that the other mistake that I see some Scrum Masters make sometimes is that they treat it as being a purely reactive kind of position where I'm going to sit back and wait for things. And then when something happens, then I'll, then I'll jump in and I'll do something based on what someone else has done, which I think is a mistake as well. We we're proactive. We were very proactive to, to make an impact and make a difference. And when we recognize something's needed, we, got to jump in there. We got to get in there and do something about it when it's needed. you wouldn't want to have a coach of a team who set back and just, you know, Gary (27:26) It is. Brian (27:30) waited for someone to come to them and ask them for questions. There's no strategy. There's no paying attention to fundamentals. All those things would kind of go out the window if that coach isn't more proactive with his approach towards his or her approach toward the team. Gary (27:45) Exactly. That's a wonderful analogy because I was a soccer coach as well. I'm a soccer player as well. And when I'm coaching youth or that type of thing, I have to teach them how to use this sideline, the touch line in order as a virtual defender. need to have been on the field to know how to teach them how to operate on the field. And if I can't get involved with them, if I just wait until they make a mistake, they're going to make a lot of mistakes. Brian (27:48) Hmm. Gary (28:14) And you've touched on this idea of the passive scrum master. Scrum master is not a passive role. I had a product owner, one of the best that I've ever worked with in my career. We were having a very heated conversation one day, as we often did. And he said, Evans, you're an activist scrum master. And I had never heard that before. And I reflected on it a little bit and I said, Chuck, you're right, I am. But not everybody has that kind of personality. So each scrimmaster has to identify where they may need to improve, maybe some of their assertiveness, some others need to learn how to hold back. It's a learning curve. It's a learning 24-hour-a-day learning session. We're all different. teams are different, the Scrum Masters are different. And as we get more experience and develop more expertise, we handle things differently as a result of that growth. And my role as a coach is to grow the Scrum Masters, to grow the teams. And I've loved it because I love working with people. So you get to work with people, you get to solve problems and you get to see tangible results in people's careers. What more could you ask? Brian (29:36) Right, right. I'm with you. I'm right there with you. I can't agree more. Well, this has been a great discussion. just want to, you know, we mentioned already your book is called The Effective Scrum Master. We're to put links in our show notes to that if people want to go and find that and just, but you can find it on Amazon. Gary K. Evans, The Effective Scrum Master. Gary, how can people find out if they want to get in touch with you or find out more about your work, how can they get in touch with Gary (29:37) Thank Well, appreciate that. I am currently putting up, there is a, we have a website. It's called effectivescrummaster.com. I'll repeat that. Effectivescrummaster.com. There's a sign up link there. It's the page is just under construction at this point. It's live, but people can go up and they can enter an email to be notified when we start to make changes. There'll be some free information there, some resources that they can download. We've got a plan on how we're going to roll this out, but that's just beginning. And so I hope that people will go and visit that and hopefully we'll be able to develop a relationship and they'll be able to reach out to me through that website. Again, effectivescrummaster.com. Brian (30:51) Awesome. Well, thank you so much, Gary, for making the time. It's been a really great conversation and I really appreciate you making the time to come on the show. Gary (30:59) Brian, this has been my privilege and I really appreciate it. Thank you so much.

In this episode of Book Overflow, Carter and Nathan discuss The Agile Manifesto, a free-to-read document that has greatly defined the modern software engineering landscape. Join them as they discuss its legacy, how it persists in software engineering today, and whether it was ultimately a good or bad development! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Agile Manifesto https://agilemanifesto.org/ ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

Melissa Perri is the founder of Product Institute, author of Escaping the Build Trap, and host of the Product Thinking Podcast. She has worked with startups, Fortune 50 companies, and everything in between to help them build better products and level up their product teams. In our conversation, we discuss:• The history of the product owner role• The differences between product owners and product managers• How to transition from product owner to product manager• The evolution of and problems with the SAFe framework• How large non-tech companies can improve their product practices• Much more—Brought to you by:• Pendo—The only all-in-one product experience platform for any type of application• OneSchema—Import CSV data 10x faster• Coda—The all-in-one collaborative workspace—Find the transcript at: https://www.lennysnewsletter.com/p/product-owners-melissa-perri—Where to find Melissa Perri:• X: https://twitter.com/lissijean• LinkedIn: https://www.linkedin.com/in/melissajeanperri/• Website: https://melissaperri.com/• Product Institute: https://productinstitute.com/• Podcast: https://www.produxlabs.com/product-thinking—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Melissa's background(02:12) The rise of the product owner role(06:37) Understanding Agile and Scrum(08:27) Challenges in Agile transformations(10:41) The history of the product owner role(13:58) The Scrum Guide(15:43) Product owner responsibilities(21:01) Adopting Scrum in organizations(26:21) The origins and implementation of SAFe(35:20) Why Melissa doesn't recommend SAFe(40:33) Advice for implementing a digital transformation(49:12) An example of SAFe adoption(51:27) The value of experienced product leaders(56:53) Career paths for product owners(01:04:14) Transitioning from product owner to product manager(01:06:41) Be careful relying on certifications(01:11:43) Evaluating existing product owners(01:16:55) Final thoughts on Agile and product management—Referenced:• Escaping the Build Trap: How Effective Product Management Creates Real Value: https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X• Lean UX: https://leanuxnyc.co/• Scrum: https://www.scrum.org/• What is Extreme Programming? https://www.agilealliance.org/glossary/xp/• Capital One: https://www.capitalone.com/• The Agile Manifesto: https://www.atlassian.com/agile/manifesto• Ken Schwaber on X: https://x.com/kschwaber• Jeff Sutherland on X: https://x.com/jeffsutherland• Kanban: https://www.atlassian.com/agile/kanban• What is a kanban board?: https://www.atlassian.com/agile/kanban/boards• Ron Jeffries's website: https://www.ronjeffries.com/• Jeff Patton on X: https://x.com/jeffpatton• The Scrum Guide: https://www.scrum.org/resources/scrum-guide• OpenSky: https://www.openskycc.com/• SAFe: https://scaledagileframework.com/• Dean Leffingwell on LinkedIn: https://www.linkedin.com/in/deanleffingwell/• Capital One scraps 1,100 tech positions: https://www.reuters.com/technology/capital-one-scraps-1100-tech-positions-source-2023-01-19/• Product management theater | Marty Cagan (Silicon Valley Product Group): https://www.lennysnewsletter.com/p/product-management-theater-marty• Marty Cagan on LinkedIn: https://www.linkedin.com/in/cagan/• Jeff Gothelf on X: https://x.com/jboogie• Shruti Patel on LinkedIn: https://www.linkedin.com/in/shruti-patel-32bb573a/• Product Thinking Podcast: Mastering Product Focus: Balancing Legacy and Innovation with Shruti Patel: https://www.produxlabs.com/product-thinking-blog/2024/9/25/episode-190-mastering-product-focus-balancing-legacy-and-innovation-with-shruti-patel• Melissa Douros on LinkedIn: https://www.linkedin.com/in/melissadouros/• Mind the Product: https://www.mindtheproduct.com/• Athenahealth: https://www.athenahealth.com/• McKinsey: https://www.mckinsey.com/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Edward Hieatt (@edwardhieatt, Chief Customer Officer @mech_orchard) talks about app modernization and the advancements and developments to increase progress.SHOW: 867Want to go to All Things Open in Raleigh for FREE? (Oct 27th-29th)We are offering 5 Free passes, first come, first serve for the Cloudcast CommunityRegistration Link - www.eventbrite.com/e/916649672847/?discount=Cloudcastfree  Instructions:Click reg linkClick “Get Tickets”Choose ticket optionProceed with registration (discount will automatically be applied, cost will be $0)SHOW TRANSCRIPT: The Cloudcast #867 TranscriptSHOW VIDEO: https://youtube.com/@TheCloudcastNET CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT OUR OTHER PODCAST - "CLOUDCAST BASICS" SHOW NOTES:Mechanical Orchard (homepage)Startup led by ex-Pivotal CEO lands $50M to modernize apps (TechCrunch)Topic 1 - Welcome to the show. Tell us about your background, and then give us a little bit of background on Mechanical Orchard.Topic 2 - Many of the MO team come from Pivotal (especially Pivotal Labs), as well as being involved with the Agile Manifesto, Extreme Programming, etc. How did the mission of the company get focus on modernizing existing applications?Topic 3 - Modernization projects have traditionally been really costly, with a low success rate. Why is now the right time to focus on this area?Topic 4 - I'm really interested in how MO technology works. It seems like a variation of a digital twin, mixed with some AI capabilities. Give us the big picture of how this is a different approach to modernization.Topic 5 - How much culture/process change is needed with MO to be successful? Topic 6 - What do the stages of success look like with your approach to application modernization?FEEDBACK?Email: show at the cloudcast dot netTwitter: @cloudcastpodInstagram: @cloudcastpodTikTok: @cloudcastpod

How Relevant Are The Agile Principles Today? 2001 is the official birth year of Agile. It took the world by storm. Millions of professionals have found new ways of creating software (and other products) using the values and principles of the Manifesto for Agile Software Development (or Agile Manifesto). At the height of Agile, people saw it as a panacea for all software-related, even all product-related problems. Nowadays, Agile is a commodity. “Everyone” works Agile these days. Some proclaim we are in the post-Agile era. Others say Agile is Dead. Is Agile Really Dead? 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/

You can contact Al here: https://www.linkedin.com/in/alshalloway Al on the PMI: https://community.pmi.org/profile/alshaloway#_=_ Al and his company explains Amplio: https://successengineering.works/author/al-shallowayoutlook-com/ Al’s books on Amazon: https://www.amazon.com/stores/author/B001IXPWYW The post 281 Al Shalloway and why he didn't Sign the Agile Manifesto first appeared on Agile Noir.

Jeff is the co-creator of Scrum and a leading expert on how the framework has evolved to meet the needs of today's business. The framework he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world. However, Jeff realized that the benefits of Scrum are not limited to software and product development. He has adapted this successful strategy for several other industries, including finance, healthcare, higher education, and telecom.   As the CEO of Scrum Inc., Jeff sets the vision for success with Scrum. He continues to share best practices with organizations around the globe and has written extensively on Scrum rules and methods. With a deep understanding of business processes — gleaned from years as CTO/CEO of eleven different software companies — Jeff is able to describe the high-level organizational benefits of Scrum and what it takes to create hyperproductive teams.   Topics of Discussion: [:35] Introduction of Jeff Sutherland, co-creator of Scrum. [3:47] Jeff Sutherland's background: His experience at West Point and lessons in making work visible. [5:19] Fighter pilot experiences that influenced the operational side of Scrum. [6:02] Transition to the Air Force Academy and work in AI at Stanford. [7:38] Learning complex adaptive systems and the origin of Agile from complex systems theory. [8:30] How complex systems theory impacts Scrum and Agile teams today. [9:25] Jeff's first experiences applying Scrum in the banking industry. [11:25] The development of Scrum and the 2001 Agile Manifesto. [12:57] Making work visible and organizing teams, from West Point to Toyota to the Agile Manifesto. [13:23] Fast forward to 2024: Issues in Scrum and Agile practices, including sprint lengths and backlog grooming. [14:34] Jeff's new book: First Principles in Scrum and its relation to Scrum technology stacks. [16:23] Building autonomous systems: Lessons from radiation physics, AI, and complex adaptive systems. [19:16] The influence of autonomous robots on the creation of Scrum. [21:14] Discussion of Scrum and AI, leading to “Extreme Agile.” [22:47] Predictions for the future of Scrum and Agile: Teams becoming 30 to 100 times faster by 2030. [23:37] Example of AI in action: Developing a system to handle expense reports using Scrum principles. [29:37] Challenges with AI-generated code and the need for strong software architecture knowledge. [33:24] The importance of following Scrum “by the book” to achieve hyperproductivity. [35:30] Jeff's closing advice on adapting to extreme agile to stay competitive by 2030.   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! How the Agile Manifesto Came To Be   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Join us for Agile coaching for the PMP Exam at: http://agileaficionado.com Join us for an engaging and insightful webinar that brings the Agile Manifesto principles to life in a fresh and creative way. Through vibrant comic-style illustrations, we'll explore how Agile's core values and principles can transform your team's approach to delivering exceptional results. In this session, we'll dive deep into each Agile principle, using humor and dynamic visuals to showcase the practical application of Agile in real-world scenarios. From the importance of face-to-face communication to the art of simplicity, you'll gain valuable insights that will help you foster collaboration, improve efficiency, and enhance team motivation. The Agile values that drive successful teams. How principles like "Working Software is the Primary Measure of Progress" and "Continuous Attention to Technical Excellence" can boost your team's productivity. Why simplicity and self-organizing teams are key to Agile success. Practical tips on implementing Agile in your projects. Whether you're a project manager, developer, or Agile enthusiast, this webinar is perfect for anyone looking to enhance their understanding of Agile principles in a fun, visually engaging way. Don't miss out on this opportunity to see Agile like never before and leave with actionable strategies to improve your team's workflow! --- Support this podcast: https://podcasters.spotify.com/pod/show/pmpradio/support

Is Agile really dead, or are we just doing it wrong? Tune in as Brian and Scott dive deep into the controversies and misconceptions surrounding Agile practices and what it really takes to make Agile work in today’s organizations. Overview In this episode, Brian and Agile Mentors Podcast regular, Scott Dunn, tackle the provocative question: "Is Agile Dead?" sparked by recent claims of Agile's high failure rates. They discuss the validity of these claims, the common pitfalls of bad Agile implementations, and the importance of continuous improvement and experimentation in Agile practices. The conversation explores the shortcomings of current training approaches, the crucial role of effective coaching and leadership support, and how to overcome the widespread misconceptions about Agile. Brian and Scott emphasize the need to focus on outcomes and ongoing learning rather than getting bogged down by methodology debates and rigid terminologies. References and resources mentioned in the show: Scott Dunn #93: The Rise of Human Skills and Agile Acumen with Evan Leybourn Are Agile and Scrum Dead? By Mike Cohn Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. Welcome back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, friend of the show, regular, you know him, you love him, Mr. Scott Dunn is with us. Welcome back, Scott. Scott (00:13) That's my new favorite intro ever. So thank you, Brian. Always glad to be and then glad to talk shop. So I appreciate you making me some space so that I get to work with you again. Brian (00:16) Ha ha ha. Yeah, we need like walkout music for you. know, like when the pitcher comes out to the mound, the relief pitcher or the wrestler comes out, you know, or whatever, they play the walkout music. We need walkout music. We wanted to have Scott back because there's a hot topic and this is your hot take alert because this show I'm sure is gonna be full of personal hot takes here on the subject. Scott (00:30) Yeah yeah, there you go. Brian (00:50) And that is, is Agile dead? There has been a lot of talk recently about this in the past few months. There's been a lot of blog posts written, a lot of armchair quarterbacks chiming in and trying to make sense of this. So before we dive in, Scott, I want to give a little bit of background to our listeners in case you're not aware of something that happened, where this came from, right? Because I think that there was In one sense, there's always an undercurrent. There's always people out there who are ready to say Agile's dead, right? And so they're waiting to pounce on anything that would back them up. And there was someone who was very happy to oblige about that. There was a company called Engprax, E -N -G -P -R -A -X. I couldn't find much out about them except they're a consulting company. And they put out an article that was announcing research they had done that said that 260 % higher failure rates for Agile software projects. That's what their study revealed. Yeah, 268%. So let's just start there, right? But the article is very thinly veiled in support. of another competing process, believe it or not, called Impact Engineering that is authored with a book that's just out, believe it or not, by a gentleman named Junade Ali. Now I have no idea, I have never crossed paths with this gentleman. I don't know his philosophy or his, much more about him. I did look him up on LinkedIn. He's been in the business for about 11 years. If I trace back to his first thing, it's about 11 years ago. He currently lists himself as the chief executive officer of a stealth startup. Well, I think I can remove the mask of what that stealth startup is because it is Ingeprax. So he is the head of that company. I found another article that did the research in support of his book. Scott (03:03) Hahaha Brian (03:12) announcing his new process that is a competitor, of course, to Agile. Now, there's been a lot of back and forth. He's tried to defend this and say, you know, the research is solid, but here's the thing I always say, without data, it didn't happen. If you're not showing me the actual methodology, if you're not showing me the scientific research paper behind it that says, here's the methodology of the research, here's how we conducted it, here's the... There are some details that are in the article, one of which is that the research was done over a period of about five days. So it was research over about five days. was interviewing a set of, I'm trying to scroll through and find the numbers. I think it was like 250 or so engineers from the UK and 350 from the US. It's something around those numbers. But it was interviews with engineers over a period of about five days. Scott (03:50) Wow. Brian (04:11) And so the numbers are based on these engineers' recall of what their idea of success was in projects, whether it was an Agile project or not an Agile project, by their definition of whether it was an Agile project or not. He doesn't really describe in the article what success is. So saying that it's 268 % failure, what is a failure? It doesn't really state that plainly. So again, where's the data, right? I'm not going to go on and on about the research and the fact, but I just want to give the background before we dive into it because that article is what now you will see quite a few blog posts and things crossing your desk on LinkedIn that say, wow, look, this new study says 268 % failure rate for agile projects. Well, anytime you see something like that, check the source. You have to check the source. I try to do this in any conference talk I do. I put the links to the sources. And I try to only list data that comes from scientific studies, where you can find the actual research paper and dive into it and get into the nitty gritty of it if you really want to. Otherwise, as I said, it didn't happen. He says in the article, hey, we had PhD people that looked over our work, unnamed PhD people. So you can't even question whether that person was someone legitimate who did it. Just trust him that they were legitimate. So I set that up because I don't mean to take so much time here at start of the episode, but I just wanted to set the foundation. If you weren't aware of that kind of thing or where that came from, you may not even been aware of the background of where that study came from. Scott (05:46) You Brian (06:04) And the fact that the person who kind of sponsored it is got an ulterior motive, right? They're trying to push their own methodology and they're publishing research that they collected, they are publishing, that just so happens to support their foregone conclusion that Agile's bad and their methodology is better. So, but Scott. Scott (06:31) I'm just trying. Brian (06:32) So let's get into the topic because what I really want to get into is, I'm sure you've seen people post things like this and there's been sort of this wave of things in the past year or so of people who are so quick and anxious to say Agile is dead. So what's your general impression there? What have you seen? What have you experienced and how do you respond if someone in class says, hey, is Agile dead? Scott (06:43) Mm Mm I great, great question. So for those listening, I want to just want to affirm that probably a lot of you had experiences like, well, certainly wasn't going great or we're not seeing what we thought and all those things. So part of this, Brian, is I think the ethos of why those things take off like that is I do think there's a general feeling of is this really working for us or not? That's that's fair. So I'm not going to pretend like, it's always goes great. It's, you know, be Pollyanna about that. I remember actually this year. of a CEO, a company saying, Agile absolutely does not work. We're going to go all the way back to just full waterfall. Right. That to me is kind of that harbinger of like, wow, it's built up enough for someone to say that. So a couple of thoughts I have, and I'm going to be pragmatic like you for my friends that are hearing this or maybe thinking this or people at your company are pushing back a bit, is I'm to go back and say, well, okay, let's just say that Agile is dead. So what are you going to do? Are you really going to go back to waterfall? Well, we already know that story. whole reason, for those listening, consider this, whole reason Agile took off was the option A wasn't working and very clearly wasn't working for complex projects like software. Now for this person to come and recommend XYZ, of course, not surprising for all the listeners out there. Obviously, there's a marketplace, there's business. I get it that people are going to pitch and recommend what they do my classic one in our space Brian would be because obviously you I Mike within Mountain Goat are teaching the CSM CSPO and I'll see like 350 page books of get ready for the CSM exam like right the scrum guide itself is I mean how many pages so come on Brian (08:38) You Scott (08:47) And they'll even be like, you know, misrepresentation. So clearly people are doing things in their own self interest. get that. as you as people out there, hear information, I love what you're saying is to just like look into it and really be mindful of what's their angle for some of that. But back to your question, is Agile dead? I would argue that Agile partly done or halfway is dead in the sense that that doesn't work or what I would kind of call Agile theater. Agile hand waving, spread the agile pace. So I've been doing this 18 years, I think, since becoming a Scrum Master. And I was on project delivery before that and managing IT people. So I've seen all the things that weren't working well as a developer, et cetera. And I saw the results of what I got. And I've seen plenty of stories beyond that. But what I see more and more is people who are further away from the beginnings and what they're kind of doing is implementing what's comfortable. And I would agree that doesn't work. in that sense, that Agile is dead. In a follow on the idea of and really kind of putting together realizing is for those out there that your company is the one implementing Agile, who usually gets that? Well, it's probably going to be the PMO. And I'm going to poke a little bit here, certainly for my PMO friends, but as a former PMP working within the PMO, what's the PMO responsible for? So if I go to your typical company, say, hey, we're going to go Agile. That's under the purview of who it's a, it's a, there's going to be a group that's responsible for watching over execution delivery. Who is that? It's a PMO. Think about this. The PMO is not responsible for like learning continuous improvement innovation. They're responsible primarily for, for status reporting, managing to a given date, managing resources, escalating issues, but not necessarily for improving. So they bring in Agile sense of, what do we need to do without maybe understanding it fully and really. How do we just manage this process and not, hey, we're starting off from point A, but we're going to learn and get better as we go across. It's going to stop where they feel like, I think we have a new process that implemented. Does it get the results? You know, I don't know and I don't understand how it works to fix that. So they may not be getting results is what I commonly see. I'm seeing a slew. I can tell you the last several companies just in these last few months we've worked with. We've got to fix our process is not working. Are you agile? Yes. But you look at it and they'd miss a lot of fundamentals. And so now we're kind of resetting a lot of people that are struggling with the same issues everyone's talking about. Visibility, predictability, can we deliver this by the date we gave senior management? And they're not by and large. For those who say agile is dead, one of the other options, people have put together agile manifesto had lots of ideas, lots of other approaches besides scrum, but even if just take scrum. Look, scrum is based on lean. Is lean dead? And scrum is an empirical process. Is empiricism dead? Does that not work? So I kind of come back like, what are your options? Just think about the results you're getting. Whose fault is that? And what are we even basing what we're looking at? The roots of it are all very solid. So yeah, I'm going to push back quite a bit on that, what I've seen. And maybe see some of those same. Results or lack of results for organizations Brian because I know that it doesn't always go great out there and in the marketplace is coming. Try to roll this out. Brian (12:07) Yeah, yeah, there's a, so I have a couple thoughts here. One is just in general, I think you're absolutely right that there's, know, well, just listeners, ask yourself, what percentage of Agile practices out there do you think are doing Agile the right way? Right? And I don't mean like a hundred percent. I just mean they are, they're all in on it. They're trying to do it the right way. I don't know what number you have in your head, I would say, don't know, Scott, what would you say? Scott (12:43) They're doing it right? Brian (12:45) Yeah, they're not perfect, right? But they're committed to doing it right. They're committed to doing it according to what the Agile Manifesto says, that sort of stuff. Scott (12:55) Fairly Fairly smart, right? I'm guessing, my first number that came to mind, you asked, I'd say 10%. That's my, maybe less than that. Brian (13:02) Okay. Yeah, I would bet it's a small thing, right? Now that right there, I think is something that we can talk about. Why is it that small? Right? Why is it that small? And I think that there's a discussion that's a legitimate discussion to be had about, well, maybe the structure that was put in place to spread this and train people up and get them, you know, situated to do this well. has failed. And if that's the case, that's the problem. It's not really that the methodology is bad. It's that we didn't do a good job of explaining it or training people for it. that's a separate discussion. But I think that there's a lot of bad agile out there. And I'll just put it to you this way. If you like to hike or camp or anything like that. If you are an aficionado of that stuff, right? If you occasionally go hiking or camping, I'm fairly certain that you've had some hikes or some camping trips that weren't that great, right? And you can probably recall them and think, wow, that was horrible. Well, imagine if that was your only experience, right? Imagine if that hike or that camping trip was your only experience. And you came back from that and someone said, you tried hiking or you tried camping. What did you think of hiking or camping? That sucked, it was horrible. I never wanna do that again. I don't know why these people are crazy, that do that stuff. I would never do that again. But if you really like it, you know that yeah, there could be some bad experiences, but there's some good experiences too. And if you plan a really nice hike and you've got good weather and everything else, it can be a really great experience. So to base someone's opinion on, well, my experience in one place was that it was terrible. Well, okay, come on, give it another shot, right? I mean, they're not all gonna be perfect. And if you see it in a couple of places, you'll probably understand, now I know what we were doing wrong in that other place because it's clear now, right? So that's one point here. And the other thing I wanted to say is one of the things that they talk about in their Scott (15:17) Right. Brian (15:26) 268 % failure rate article where they announced their research, is they focus a lot on that their methodology does a better job with really clearly documenting requirements before development starts. So Scott already knows where I'm going with this, right? I think there's a fundamental misunderstanding before we even begin this, because what they're saying is, Scott (15:42) boy. Brian (15:55) Yeah, one of the things Agile fails at is clearly documenting all the requirements up front. And my response as an Agile trainer is, duh. Yeah, of course, because we don't try to do that. We actually look at that from a different standpoint and say, you're fooling yourself that you can document all the requirements up front. The example I use in class is, well, We're not manufacturing, right? We don't do manufacturing work. We're not churning out the same thing over and over again. If I was doing that, I could document all the requirements upfront, because I've done it before and I know what it takes to do it. We're closer to research and development. So let me take an extreme research and development situation for you. Imagine I'm inventing the cure to a certain kind of cancer, right? And you come to me before that and say, great. Well, we funded the project to cure that certain kind of cancer. Here's the budget. you know, let's get all the requirements documented upfront before you start inventing that cure to cancer. You'd look at me, I'd look at you like you were crazy because I don't know what all the requirements are going to be before I invent this new way of solving the cancer problem, right? I have to experiment. have to try, I have leads, I have ideas about things I would try and that I think have promise, but I've got to go through trials. I've got to go through tests. And the results of those experiments will then guide where I go next. So I think there's a fundamental fallacy in just the idea of trying to judge whether Agile is successful or not about whether it can capture requirements. Scott (17:34) Yeah, right. And for those who've been around, I'm going to double down on that one, Brian, because I've seen this pushback to, hey, we've got to capture all the requirements up front. But every time I ask a company, things change. company priorities change all the time. If anything, we're suffering from just chaotic, inconsistent, random. I remember an executive once said, I love Agile. I can change my mind all the time now. He meant it. So, and even before Agile, there were statistics that showed that the majority of requirements never see the light of day or are to use. So we already know outside of Agile, it's a fool's game, the customer will know it when they see it. That's why it's complex. I think you're right. We're not doing something like manufacturing. We're trying to experiment and figure those things out. So the idea of bad Agile missing out on requirements, it feels good to say we've captured everything upfront. But I remember my first full Scrum project on my own with the whole company and the CEO saying, you know, I need to see this by October. I'm like, well, you'll see, you'll see something backed over, right? I wouldn't say that now, but this same CEO is so dead set, like, no, it needs to hit the state. He fully changed the look and feel of the whole website application we're building twice during that project. To me, it just tells me like, let's not play the game. Like I can still scope it, but let's accept it's going to change. The other part, when you say about just bad and sense of practices, there's a poll I put on my LinkedIn profile. Somebody might have seen this if you follow me on LinkedIn, but I asked. Brian (18:34) Ha Scott (19:00) You know, is the two day CSM enough to get you the results, your organization you want to see now for those who don't know CSM, obviously the standard, you know, training that people take to understand scrum from the scrum Alliance. there's certainly a lot of other courses, Brian, I know you do the advanced CSM CSP, advanced CSP. And there's more beyond that, but people by and large stop at the CSM. The percentage of it last time I checked was like 99 % of all people trained by the scrum Alliance. taking the CSM and it drops off. The percentage of people when I asked out there in the marketplace, is the CSM enough to get you the results? 95 % said no. So one, for my listeners, I'm to be a little bit of tough love on you. We ourselves might be the ones to blame for this. If we stopped our learning then, if we didn't encourage others at our org to learn and keep pressing in, you don't have the tools you need to be successful. The CSM was not all theirs. There's a slew of Equipping and training out there much less coaching and getting support. So I think there's also some miss on bad Agile. Like we never learned enough. Let's just take the basics of well, we have multiple teams. Well, but yes, the CSM doesn't cover multi team and scaling, so you got to figure that out and you're figuring out based on what you have. done it before you have valid experience and the number of companies who aren't getting coaching anymore. Now they end up just trying to figure out a methodology themselves and that's not their strength. The strength might be in -flight software for airlines. I don't know, it's not methodologies. And they're gonna take their best guess influenced by who? I'm gonna guess the PMO. And now you get this muddy version that yeah, doesn't get results. So I second that on the requirements issue and I second that just the fact that Bad Agile could be our own equipping. I do wanna add on the point about experimentation, encourage those. Brian (20:45) Yeah. Scott (20:48) The metaphor you give about camping is really great. I see a lot of out there in the world for those who are out in the scene, the whole dating scene, and you might be like, these dating apps are terrible. They don't work. Okay. I'm not going to argue they don't work depending on how you use them what's going on out there. But again, what are your options? The world's shifted and here's where we are right now. There's things we can do to do that better, but to simply throw that out, it's like, well, or dieting. Yeah, I tried that diet. It doesn't work. Dieting doesn't work. Well, Brian (20:59) You Scott (21:16) There's a mindset that goes with that. And did you follow up correctly? Did you look into the research underneath that? Even recently, I'm going through my own personal work around like sleep and health. I'm going through Peter Tia's Outlive, which is a fabulous read. But those are both like, here's some data and science, but you need to kind of hack everybody's different. Here's some ideas, try them out, see it works. Same with Scrum. Try these things out. It's not like, I did Scrum and we didn't get amazing results out of the gate. Well, you keep experimenting. It's simply empiricism. So those could be things for those listening, come back to that, look at your education level, look at options and keep learning and growing and try those things out. Cause could be, we didn't do our best to bring that or even on Mountain Good for their friends who listening who've gone through the Mountain Good courses and you have access to agile mentors. There's a community forum, there's a chance to interact, ask questions, there's lean coffee, bring your questions. How many of us actually go and take advantage of those resources? There's tons of knowledge, information, but most of us are just too busy. to get smarter and apply that. So that could be an action for people listening. What's your own next steps to grow and make sure you're doing the best agile out there that you can and you have case studies that you can reference. Could be an opportunity. Brian (22:24) Yeah, such great points. I'll build on your analogy there, or what you talked about with sleep a little bit, and thinking about how, you know, this is one of things I love about Agile, because, you know, if it was, this will maybe highlight the difference between Agile and Scrum a little bit for everyone, if you don't really understand this, right? If I were to say to you, make sure you go to bed at 10, and get up at, you know, six every day, right? You get eight hours, that's eight hours, right? You get hours of sleep, but you gotta be in bed by 10 up at six. Well, some people would hear that go, well, that's ridiculous. That doesn't fit my schedule. I work better at late at night and I'm not an early morning person. And you probably just say that's terrible. That's a terrible idea. But if I said to you, make sure you get enough sleep, right? Then you can apply that and think, okay, well, for me, enough sleep is this. And I know what that means. I know what it means when I get enough sleep. Scott (22:53) Thank you. Brian (23:23) And for me, that means I'm going to bed by 11 or 12 or whatever. Like I know when I need to be in bed and I know when I need to wake up in the morning and that's enough sleep for me. Maybe it's seven hours for me. Maybe it's nine hours for me. Right. That's the difference to me between Agile and Scrum is that Agile, and that's why I take such offense at anything that would say, it's a failure. Well, it's a principle. And if you're going to take exception to it, which one? Which principle or value are you going to call out and say, this is the one I disagree with, this is one I don't think is valid? Because it's not telling you exactly how to do it. It's not telling you what a sustainable pace is, for example. It's not saying only work 40 hours a week. It's saying everyone should work at a sustainable pace, a pace they can maintain indefinitely. And if you disagree with that, if you're going to say, well, that's a failure, Scott (24:05) Right? Mm -hmm. Brian (24:17) I don't think people should be working at a sustainable pace. They should be working at an insustainable pace. Well, I'm going to have an issue with you, right? And I'm going to say, where's your research on that? Like, where would you say that that's, you know, how could you back that up? So that's why I take, I think I'm welcome to people with different ideas, but I want to see the data. I want to see you back it up. And even, you know, something like this project, I want to say, what questions did you ask? You know, if you're just taking a poll of software engineers, how did you phrase the questions? Were they leading in how you phrase them? That kind of stuff can be very, very important and make a big impact on your numbers. So without the data, it didn't happen. Scott (25:01) Absolutely. I think that, well, and to that point, Brian, and I'm going to push a little bit. This word agile might be the most misunderstood word of the last decade or two. I guarantee you. You can ask 10 people and get 10 different versions of the answers. So like, what are we talking about? Let's take a step back and like, it's sense making to have a conversation around that. So for example, I remember this person who supposedly walked in, this is just this year, walked into the Brian (25:14) I agree. Scott (25:31) They're, you know, the head of the PMO, they've been doing agile. came from a large manufacturing company. Everyone recognized the name. Now there's other company that got brought in. Let's do this right. And, you know, has all this agile experience. And I'm actually having a conversation. We're talking about planning and predictability and how to get the teams where we need to. And I mentioned this about Velocity and she said, Velocity has nothing to do with planning. And for those who don't know, one, reach out and talk to us, because we can help you do that. The second thing is, in my mind, I didn't even know how to answer. That is the thing we use for planning is how much does your team get done, and we'll extrapolate what they're going to get done by the certain date. But I remember just feeling like, and you're saying you're walking out with all this Agile experience, and you're heading up the PMO on how we roll out Agile. Thank goodness that CTOs are like, Brian (25:56) Right. Scott (26:16) It has everything to do with planning. And I'm like, thank goodness you straightened that out because I didn't want to say anything. And I'm going to add to that at the leadership level and management level, because management statistically is going to be your biggest inhibitors to continued agility and growth. Management in terms of how we work around here, which is essentially a culture, how we do things around here. That's going to be seven of your 10 reasons you get stuck. When I've polled and asked numerous groups, how much does your leadership understand about Agile on a scale of one to 10? And the numbers I'm constantly getting back are right around 3 .5 to four on a scale of one to 10, right? Which is bad. But here's the flip side is I say, okay, how much does your leadership and management think they understand about Agile? Well, then it basically doubles, right? And even I've people say like on scale of one to 10, they think they're at 12, right? So we have groups who are large influences of how this is going and the stakeholders and what they're asking who. Brian (26:53) Yeah. Scott (27:13) not only don't understand it, but think that they do. So if you're listening to this out there and you're kind of like, yeah, I agree. Yeah, so what do we need to do about this? And again, you have a lot of options, but if you let that hang over us in terms of that's gonna be your constraints, the true agility here, what we're trying out. And we just kind of accept that, yeah, they don't know anymore. It's almost like this gallows humor, ha ha, they don't get it. Yeah, but they're the ones who are like. asking for fixed scope, fixed date, don't understand about iterating, don't understand MVP, don't understand, like show up to the demos and see what we've done to give us feedback. So those are things that undergird this problem that that lack of understanding can be pervasive and yet people think that they do. And I'll go back to another leader who said they understood Agile, but when we went through the survey feedback to help them and work through that, his comment was, I'm tired of this deadline optional culture. Deadline optional. I guarantee that people don't feel like it's optional. If anything, they're feeling a lot of pressure. But when we miss dates, how they interpret it several layers above is like, they just don't care. This is all deadline optional. So I think there's a disconnect from leadership and management side and the knowledge and even those heading up the project management office that we need to kind of check ourselves. Have they gone to training? Do they know? You'd be amazed what that can do when they get on board and really support this. It clears up a lot of stuff at the team level. Brian (28:26) Yeah. Scott (28:36) But back to what said earlier, if all you did was send a few people to the two day course and that's it, yeah, you're probably gonna struggle. Brian (28:44) Yeah, and I support what you were saying about, need to take responsibility as trainers and as the Agile community that maybe this way was not the right way of doing this. And if there's one thing I might take a little bit of exception to now from how it's described in Scrum is, we talk about Scrum Masters being change agents. And I think that may have gotten a little overblown, right? Because I think in a lot of organizations, people look at it as these people who take a two day class are ready to lead our whole company in how we're doing this. And that was never the intention, right? I think the two day class is actually okay for someone to get kicked off and plugged in and being a scrum master on a team with support, right? If that's the only person, you only have two or three scrum masters that have all taken just a two day course and... no one has really a lot of experience, then it's probably not going to do very well. But if you have some base layer scrum masters who are new, and they have some coach layers that are more experienced, even if it's just one, even if you have that one senior person who hasn't just, you wouldn't do that with anything else. There's nowhere else in your company where you'd say, let's just hire a bunch of people who have never done this before and hope that it works. Scott (30:07) you Brian (30:09) You wouldn't do that with programmers, you wouldn't do with testers. You would have some, you want to have some senior people that can help guide and mentor and make sure that it's done the right way. But for some reason, you know, companies just kind of look at it as saying, no, I'll just hire a couple of scrum masters that are brand new and that'll solve it. Scott (30:27) Woo, I mean, can you imagine getting on a plane like, by the way, everyone, welcome on board. Our pilot's never flown before. I could do that, course. And not only that, we're trying to save money around here. So he's actually going to be concurrently helping fly three other planes at the same time, like while they're doing this work. Brian (30:32) But I passed the two day class. Yeah, because most of the flight, you're not doing anything, right? You're just sitting there. So we want to make sure they're still productive so he can fly three planes at once. Scott (30:50) That's a hard one be, exactly. That's yeah, which it's, it's, people might be laughing, but it's similar. Like we're trying to get pointy to point people, things change on that flight. And I see these teams, know, scrum master spread around. I remember a company scrum master on seven teams. Nevermind organizational change agent. This poor soul can't even have the meetings run. and someone bested me like, no, I know someone's on 12 teams as the scrum master. So if management doesn't understand the value of this person, and I like what you're saying. It's a tall order organization changes. And I like the idea of like lead improvement, but we kind of cut it at the knees. had one company this year and sadly we'd helped them get started. When we came back, kind of had some back -channel conversations with people that were disgruntled on the team. So thank goodness they had a safe place to come and ask questions. But the person rolling out Agile, it was kind of knighted to help do this. And she had been through the two day training, I think, but literally as they're giving feedback on what's working, not working, she basically said like, Stop complaining. This is the way we're doing things around here. I'm here to just kind of write the playbook. I think you're the person that should be spearheading how to improve every single sprint. And you're saying, we're done talking. We're complaining. I'm trying to formalize our process here. But basically, booted them out of the working group committee that was how we implement Agile. Now, those are two of the key Agilists there. So think we missed some of that when those examples happened. So my friends are listening. expect that people don't get it, expect that they're optimizing for their own concerns. And that's fine, but we don't stop there. We have to kind of work top down bottoms up on that. And there's lots of options and case studies and stories you can see. And certainly I'll just point again to a resource. If you look at Agile Mentors, there's plenty of experts who gonna, they've been on the interviews, been recorded, take a listen to those and hear some stories, help champion this. As a side note, Brian, just gonna add this in real quick. When we talk about Agile being dead or not, I think if we lead this company, like, I totally agree with Brian Scott, especially Scott. He really is very articulate and well -spoken. I think he's probably one of the best podcast interviewees ever. And they might say something like that, but they might come back and say, I agree with Brian Scott. Agile's not dead. We're just not doing it right. So what can we do about that? We'll look back and say, how are we implementing it? Is there a plan? Are we nudging people along? Expect them to kind of play these things out, but keep in mind, It's most of this company's is a multi -year journey to get those kinds of results, but I'm not going to go back as a takeaway from listeners podcasts and tell my management or leadership, we're not doing Agile right. We should do Agile right. For those who don't already know, they don't care. They don't care that we're doing Agile right. They don't even know what it is. We already talked about their scores. They don't know anyways. I'm not going to pitch any kind of change to what we're doing in terms of Agile being right or wrong. That misses. almost every single time for me. What I will pitch is, hey, leadership, you're frustrated that we're not delivering predictably. You're frustrated we're not getting more innovation. You're frustrated our quality is not where it needs to be. Yes, and here's some things we can do to get it there. Under the covers, what we're doing is improving the way we're doing Agile for more visibility, more clarity, better tracking, all that stuff. Your Scrum Master, whoever's leading this, doggone it, they cannot be just glorified JIRA admins. That's not gonna get you there. So take it back as a thing and think about how you're taking it back to them in terms of what matters for them, what's in it for them in business value. Pitch it that way. And you'd be surprised when you're like, if that's tied to the results, I'm listening. But not this we're doing as a right or wrong. So that could be part of reason it falls on its face when we do try to address the agile being dead is how you're presenting and working with your stakeholders and leadership. Brian (34:37) Yeah, and quite frankly, I don't care what you call it. If we need to make up a new name and your company has had such a bad experience with Agile, make up a new name for it. I mean, say, no, it's this new project. It's the, I don't know, tangerine process. And it's, yeah, you haven't heard of it? Well, boy, it's great. It's this tangerine thing. Right, it's the latest thing. Tomorrow there will be a book on it. Scott (34:59) That's the way you were saying. Yes. Brian (35:07) Amazon, the tangerine process as invented by. And here's my research study showing how it's better than Agile. Right, right, exactly. But you know, it's oftentimes there is kind of a problem with a name. And so like I said, I don't care what it's called. You know, I'll give a shout out here because I had some conversations at the know, couple of conferences that took place over this year. And I was talking with one of my friends, Michael Sahota. Scott (35:14) We interviewed three people and yes, we got the data. Brian (35:37) So shout out Michael if you, if anyone kind of points out, I he's listening, but if he's listening, shout out to you for this. But we were talking about kind of the problem with the training courses and you know, how we fixed that and everything. And, one of the things we were talking about is, you know, if we could, if we could distill it down, if we could just have people lead with one thing, if they could walk away from those courses really embedded with the concept of I'm going to inspect and adapt. I'm going to inspect what I did. and adapt and when something doesn't go well, I'm not just gonna say, nah, I'll just keep doing it the wrong way. No, if it doesn't go the way it needs to, stop, figure out why and then change and try something new. If I could just get a team to do that without knowing all the practices, all the other, right, I don't care if you call each other, know, Scrum Masters or whatever, if you can just get that, then I think you will. naturally evolve into what you need to be for that company. But you got to have that underlying mentality, culture of it's not acceptable when something goes wrong. We have to figure out why and change. Scott (36:36) Mm Absolutely, and I'm with you. I don't care what's called anyways. My reference is a colleague in Southern California, Ben Rodolitz, and he's very big. I just don't use those words anymore. to be honest, it could be actually confusing for people. If they don't know what Agile means and you're using words from Agile, they're going to think they're mapping to what reality is. They're misunderstanding. So maybe we do start with terminology. I'm with you. I'll see my friends. I don't care if you use agile scrum, whatever. I would just say, Hey, we're to try to do something, see how that goes. Well, we're visiting two weeks and take a look at what we got and get, we'd love some feedback. I mean, it's all the same stuff, but we're expecting to not do things right. And learn along the way and not stop. That's the whole process of it. So for some of you that are doing this and feeling like, I think agile's X, we're not seeing results. would, I would take a look and are you breaking any of those fundamentals to begin with? And I think we are quick to say, yeah, but we can't do X, Y, Z Scott. can't have dedicated teams. Brian (37:37) Yeah, yeah. Scott (37:38) We can't actually get the stakeholders into the sprint review. We don't got time for the retro. Well, then we're one, you're not doing that stuff right. But even if you just call it something else in the end, do something, inspect and adapt, right? Learn by experience, try something out. I hear too much of, I don't think that'll work here. Well, do some, find out, do something and see what you get from that. Worst case, you're going to learn. But a lot of people are like, you know, we can't do that. They won't go for that. And we never actually even tried. But I love what you're saying. Maybe. for those out there listening, try a refreshing thing of different words and then, or move away from the language that they think they know and don't fight that fight. Pick the fights you think you can win in advanced stuff to get results and get noticed. And Brian, you might've seen this too. I've seen company after company, when they actually see results, the stakeholders see results, business are real, they don't care what you're doing, do more of that. I've watched them just pivot and like rush in. So maybe we do step away from all these. Brian (38:28) Yeah. Scott (38:34) methodology wars and language issues and just get back to what gets results. Do more of that. Learn as you go and keep them learning, right? Like the brass tax. Brian (38:44) Yeah, absolutely. Well, I'm not surprised we went a little over, but I appreciate everyone. I hope we didn't eat into anyone's, know, screw up your walking schedule or anything if you're listening to this while you're walking. But, you know, when Scott and I get on a soapbox, you can just guarantee we're gonna be a little bit over. That's just how it goes. Scott (38:49) Next. You would love it. Brian (39:09) Well, Scott, I really appreciate you coming on, because I think this is a great episode. I really appreciate your views on this, and thank you for making the time. Scott (39:17) Yeah, you bet. And for those listening, honestly, put some feedback. We'd love to see what you think in terms of Agile is dead and continue that conversation. I do think it's gonna be an ongoing conversation. But again, thank you, Brian. My pleasure. Always happy to jump on here. Great to work with you guys.

This week, we discuss Google possibly buying Wiz, why "meta work" leads to too many meetings, and why it took forty years to get spell check in Notepad. Plus, we share some thoughts on enjoying your vacation. Watch the YouTube Live Recording of Episode 476 (https://www.youtube.com/watch?v=xsf8ZV0y2cI) Runner-up Titles Enjoy the time Everyone can get a beef rib at this year's club. We also need to go over your summariztion prompt, because mine is dog shit right now. Make your own happiness Grand unified theory of food - every culture has a tortilla and an empanada. “Platform” is the new “Suite.” A robust NO Answer Writing a book report Failure by lack of airport ads. What is you five dollar chicken I write to figure out what I am thinking Rundown There's a lot of private cloud out there (https://newsletter.cote.io/p/theres-a-lot-of-private-cloud-out?utm_source=post-email-title&publication_id=50&post_id=146459324&utm_campaign=email-post-title&isFreemail=true&r=2l9&triedRedirect=true&utm_medium=email) Google near deal to acquire cybersecurity startup Wiz for $23 billion (https://www.investing.com/news/stock-market-news/google-near-deal-to-acquire-cybersecurity-startup-wiz-for-23-billion--wsj-3518269) Meta Work White-Collar Work Is Just Meetings Now (https://www.theatlantic.com/ideas/archive/2024/07/white-collar-meetings-more-frequent/678941/?gift=kZAb-CYAytdK21NICp8tcksr3ftg7NNiIjAvQD0GxRo&utm_source=copy-link&utm_medium=social&utm_campaign=share) Bullshit Jobs (https://web.archive.org/web/20180807024932/http://strikemag.org/bullshit-jobs/) Far Left Take (https://web.archive.org/web/20180807024932/http://strikemag.org/bullshit-jobs/) Vanguard's Die-Hard Customers Have a Message for New CEO: ‘The Service Is Abysmal' (https://www.wsj.com/personal-finance/vanguards-die-hard-customers-have-a-message-for-new-ceo-the-service-is-abysmal-c2da0491) Measuring the impact of Developer Relations on Revenue (https://jmeiss.me/posts/measuring-devrel-impact-on-revenue/) DevRel's Death as Zero Interest Rate Phenomenon (https://dx.tips/zirp) Microsoft's Notepad gets spellcheck and autocorrect 40 years after launch (https://www.theverge.com/2024/7/8/24194047/microsoft-notepad-spellcheck-autocorrect-features-available) Agile Manifesto co-author on making process 'beacon of hope' (https://www.theregister.com/2024/07/16/jon_kern/) Relevant to your Interests The Silent Crisis in Open Source: When Maintainers Walk Away (https://dev.to/opensauced/the-silent-crisis-in-open-source-when-maintainers-walk-away-1m81) Google's dark web monitoring service will soon be free for all users (https://www.theverge.com/2024/7/9/24194970/google-one-free-dark-web-monitoring) Software Development Job Postings on Indeed (https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE) Samsung unveils its new Galaxy Ring, an AI-backed competitor to the Oura Ring (https://www.businessinsider.com/guides/tech/samsung-galaxy-ring-release-date-price-features-specs) Does Social Media Cause Anything? (https://crookedtimber.org/2024/07/03/does-social-media-cause-anything/) Redbox Owner to Shut Down Kiosk Business in Bankruptcy (https://www.wsj.com/articles/redbox-owner-to-shut-down-kiosk-business-in-bankruptcy-f0cada8d) Intuit to cut about 1,800 jobs as it looks to increase AI investments (https://www.cnbc.com/2024/07/10/intuit-to-cut-about-1800-jobs-plans-to-rehire-in-key-areas.html) Microsoft Exec Althoff: VMware Pricing Gave ‘The World The Greatest Gift Of All' (https://www.crn.com/news/ai/2024/microsoft-exec-althoff-vmware-pricing-gave-the-world-the-greatest-gift-of-all) Nearly all AT&T subscribers' call records stolen in Snowflake cloud hack (https://arstechnica.com/tech-policy/2024/07/nearly-all-att-subscribers-call-records-stolen-in-snowflake-cloud-hack/) OpenAI illegally barred staff from airing safety risks, whistleblowers say (https://www.washingtonpost.com/technology/2024/07/13/openai-safety-risks-whistleblower-sec/) I've Switched to Apple's Password Manager, and I'm Never Going Back (https://www.makeuseof.com/switch-to-apple-password-manager/) Ten years of Overcast: A new foundation (https://marco.org/2024/07/16/overcast-rewrite) Nonsense Costco hikes membership fee for the first time since 2017 (https://www.cnbc.com/2024/07/10/costco-hikes-membership-fee-for-the-first-time-since-2017.html) Costco plans to build 800-unit apartment complex in bid to ease housing crisis (https://nypost.com/2024/06/28/business/costco-teaming-up-with-developers-to-build-an-800-unit-apartment-complex-in-bid-to-ease-housing-crisis/) Here's why the original Buc-ee's went up in flames in Luling (https://www.expressnews.com/news/article/luling-bucees-fire-cause-19567134.php) If you miss defragmenting your C drive, there's a website that lets you recreate the experience complete with hard-drive chunking sounds (https://www.yahoo.com/tech/miss-defragmenting-c-drive-theres-002734202.html) The Morning After: Dune-inspired spacesuit recycles astronauts' urine into drinkable water (https://www.engadget.com/the-morning-after-dune-inspired-spacesuit-recycles-astronauts-urine-into-drinkable-water-111540921.html) OldMapsOnline (https://www.oldmapsonline.org/en) Sponsor Check out www.apilayer.com (https://apilayer.com/?utm_source=SoftwareDefinedTalkPodcast&utm_medium=Leads%20Acquisition&utm_campaign=PodcastDescription)! From scraping, finance to weather data, apilayer offers reliable and easy-to-integrate APIs for all your needs. Trusted by developers at companies worldwide. Use the code SDT2024 for an exclusive discount - 50% for 3 months on 100 API plans. Code is valid until Sep 30, 2024 Conferences Webinar on State of Cloud Native Survey (https://tanzu.vmware.com/content/webinars/jul-24-exploring-the-state-of-cloud-native-application-platforms-and-tanzu), July 24th, 2024, Coté speaking. DevOpsDays Birmingham (https://devopsdays.org/events/2024-birmingham-al/welcome/), August 19–21, 2024 DevOpsDays Antwerp (https://devopsdays.org/events/2024-antwerp/welcome/), 15th anniversary, Sep 4th–5th, 2024 SpringOne (https://springone.io/?utm_source=cote&utm_campaign=devrel&utm_medium=newsletter&utm_content=newsletterUpcoming)/VMware Explore US (https://blogs.vmware.com/explore/2024/04/23/want-to-attend-vmware-explore-convince-your-manager-with-these/?utm_source=cote&utm_campaign=devrel&utm_medium=newsletter&utm_content=newsletterUpcoming), August 26–29, 2024 SREday London 2024 (https://sreday.com/2024-london/), September 19th–20th, Coté speaking. 20% off with the code SRE20DAY (https://sreday.com/2024-london/#tickets) SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Buy Coté's Book: (https://leanpub.com/digitalwtf/c/sdt)Digital WTF (https://leanpub.com/digitalwtf/c/sdt) Sponsorship opportunities available (https://www.softwaredefinedtalk.com/ads) Recommendations Brandon: COTA Bike Night (https://circuitoftheamericas.com/bike-night/?gad_source=1&gbraid=0AAAAABXF-geXk7FxOT844q2nAxFPRq2W-&gclid=CjwKCAjw1920BhA3EiwAJT3lSeeD4WQEfQVJokUXc_KFhuoBpl1SgZzNoGluN4Rm5pPUNKdgI5dvshoC6TYQAvD_BwE) The Mid Year (2024) Mailbag (https://www.thecloudcast.net/2024/07/the-mid-year-2024-mailbag.html) Sharp Tech answers Brandon's question about F1 (https://overcast.fm/+8V7cdzZs0/58:52) Coté: Soulver (https://soulver.app). Photo Credits Header (https://unsplash.com/photos/people-on-sand-7_ZDmcq8x6A) Artwork (https://unsplash.com/photos/person-standing-near-the-stairs-MYbhN8KaaEc)

Are Scrum & Agile Dead? - Mike Cohn I've always said I wanted Scrum and agile to go away.Is that happening? I don't think a week passes without some article about their deaths appearing in my browser or email.Within a few years of the Agile Manifesto being written, I began to say I wanted agile to go away. I didn't mean I wanted us to stop using them. Rather, I want them to win.I want agile to become so much the accepted approach to product development, or to teamwork in general, that we could stop talking about it.Instead of saying “agile software development,” for example, I could just say “software development” and the assumption would be that, of course, that meant agile software development.To some extent, we're there.Changes Accelerated by AgileWhen Scrum emerged as the original agile framework in the mid-1990s, cross-functional teams were not common. They are now.Software development back then was done in phases—typically an analysis phase followed by design, coding, and testing phases.Heavy duty, pixel-perfect prototypes were common back then due to the high cost of iterating over a design. While prototypes are still used today, multiple quick prototypes are now common to help product owners and managers choose between options.Before the advent of agile, organizations thought they could add quality to a product by testing quality in at the end. Agile has helped us see that isn't true.Barry Boehm's spiral model (1986) and Tom Gilb's evolutionary delivery (1988) had started a shift to iterative, incremental development. But that shift accelerated dramatically after the Manifesto in 2001.(Did you know I named Mountain Goat Software after a sentence in Tom Gilb's book?)What I Hear about Agile TodayRecent articles and podcasts saying agile is dead are not saying we need to reverse the improvements agile initiated or accelerated.I haven't read anything advocating a return to waterfall development or, more accurately, the ad hoc development practices that were more common before agile.Instead, the “agile is dead” articles more closely mimic my long-held view that we can eventually stop talking about agile teams, agile development, agile frameworks and more. They'll just become teams, development, and frameworks.So are agile and Scrum dead?I don't think so.I think there's still plenty of work ahead. It's why we're focusing more attention toward whole-team training.Some of the agile and Scrum fatigue I sense today is analogous to what happens in the music industry. Fans who love an artist's first few albums often sour on that artist when they're discovered by the masses. The artist is no longer the hip, new thing and many early fans move on because of that.I will be happy when agile wins, when we can drop it as an adjective in front of so many terms. Until then I will remain dedicated to helping teams succeed with agile, 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/

Mike Lyons: When Technical Knowledge is an Impediment to Great Product Ownership in Scrum Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Visionary Product Ownership, Leading with Passion and Purpose In this segment, Mike celebrates a Product Owner who exemplifies vision and passion, bringing humanity and customer focus into the product development process. He also shares how this approach enhances team empathy and product quality, and what lessons can other Product Owners take from this exemplary behavior. The Bad Product Owner: The Pitfalls of Technical Product Ownership In this segment, Mike discusses the challenges and pitfalls when technical expertise overshadows the true role of a Product Owner. What can go wrong when a former developer becomes a Product Owner, and how does disengagement from the role affect team dynamics? Unpack the essential qualities of vision, passion, and advocacy that every Product Owner should embody.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: Guiding Agile Teams to Independence, Tips For Scrum Masters Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this segment, Mike shares practical tips on measuring and fostering team independence using the five events of Scrum. Key strategies include ensuring teams have seen work before planning, encouraging team-defined goals, limiting the scrum master's role in daily scrums, optimizing sprint lengths for quicker feedback, and focusing on product showcasing and feedback during sprint reviews. Mike challenges teams to push boundaries and continuously improve. Featured Retrospective Format for the Week: Commitment-Driven Retrospectives Mike shares his favorite retrospective format—commitment-driven retrospectives. Mike emphasizes the importance of starting retrospectives with the question, "Did we make the improvement we committed to last time?" He argues that without this initial focus, the format of retrospectives becomes irrelevant and could lead to disengagement. Mike discusses creating an environment that empowers team members to bring and own their improvements, highlighting the scrum master's role in modeling effective approaches to continual enhancement.   [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: Agile Beyond Teams, Leading Organizational Change Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Mike discusses the broader implications of Agile beyond just team dynamics, highlighting the need for coaching and influence at the organizational level. Why does Mike believe that Agile is not just a mindset but a substantial practice that requires change in behaviors before culture can shift? Explore how understanding business language and aligning with organizational outcomes can expand and strengthen the role of Scrum Masters.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: Slipping Back, When Agile Teams Drift Back Toward Waterfall Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mike shares a story from his time with a team that inadvertently started adopting waterfall practices despite beginning with Agile intentions. How did the introduction of a business analyst role lead to a disconnect between the team and their product owner, and what does this signify about the delicate balance of roles within Agile teams? Learn from Mike's retrospective insights on maintaining Agile principles and the importance of quick feedback cycles. Featured Book of the Week: The Phoenix Project by Gene Kim In this segment, Mike describes why the "The Phoenix Project," a business novel resonates so much with scrum masters and Agile practitioners. Why does Mike find himself returning to this book time and again, and how does it mirror the realities of DevOps and Agile environments? Explore how the narrative's emphasis on improving daily work over performing it can revolutionize your approach to Agile project management.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: The Humility to Listen, A Sprint Planning Turnaround Story Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When Mike took on one of his early projects, a seemingly small requirement during sprint planning sparked an epiphany about Agile workflows. Mike's story unfolds as he learns that dictating tasks isn't always the best approach, and he realized the importance of listening and empowering those who do the work. What crucial lessons did Mike learn about intellectual humility and creating space for his team to excel? Discover how these insights transformed his approach to sprint planning and why the Toyota Production System might hold secrets to doing your best work.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Tom Baldwin: Agile Team Champion, The Product Owner Who Gave the Stage Away Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Agile Team Champion, The PO Who Gave the Stage Away This segment spotlights an exemplary Product Owner who, through openness and experimentation, fosters a strong bond between stakeholders, developers, and the Scrum team. Tom emphasizes the importance of backlog management, team involvement in decision-making, and the PO's non-technical, yet impactful, leadership style, illustrating how an effective PO can be a linchpin for team success and stakeholder satisfaction. The Bad Product Owner: The Proxy PO As A Strategy To Overcome PO Anti-Patterns Tom shares some critical anti-patterns often seen in the role of the Product Owner, like distance, dictatorship, and the toxicity surrounding the PO role. By proposing solutions such as empowering subject matter experts and adopting the Proxy PO pattern, Tom provides a blueprint for transforming the PO role into a catalyst for effective Scrum practices, ensuring a balanced and productive team dynamic.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: Beyond The Process Ceremonies, The Necessary Evolution Of Scrum Master Success Over Time Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Tom talks about how we need to, over time, evolve our signs and metrics of success for Scrum Masters, from mastering ceremonies to measuring lead times and value delivery. Emphasizing the importance of team engagement with users and customers, Tom offers insights into fostering a culture of responsiveness and continuous improvement, ensuring that the team's journey towards autonomy and efficiency is both measurable and meaningful. Featured Retrospective Format for the Week: 5 Why's Tom explores the essence of effective Agile retrospectives, focusing on the 5 Why's technique to address root causes of team challenges. He advocates for personalized approaches, ensuring the right stakeholders are present, and fostering an environment where the team can own the process and outcomes. Through strategic documentation and visualization, Tom illustrates how to guide teams towards self-improvement and a focus on collaboration. [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: Agile Under Pressure, Strategies for Effective Organizational Change Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Tom shares a story about leading organizational change under a tight deadline, leveraging Agile principles to dismantle complexity and align teams with corporate goals. Through collaboration with an organizational design consultant, Tom emphasizes practical steps like optimizing team structures, engaging support functions, and applying throughput accounting to facilitate a transformation focused on simplicity, efficiency, and problem-solving, inspired by insights from Taiichi Ohno on eliminating waste.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: From Centralized to Collaborative, Cultivating Independent Agile Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. As Tom steps into a team entangled with centralized communication and decision-making issues, he shares his strategic approach to fostering team independence and effective communication, especially during a managerial hiatus. Key strategies include direct dialogue among team members, engaging leadership in problem-solving discussions, and advocating for managerial coaching, drawing upon a real-life transformation where team autonomy and progress shine despite initial resistance. Featured Book of the Week: The Scrum Field Guide by Mitch Lacey Tom sheds light on the pivotal role The Scrum Field Guide by Mitch Lacey played in his Scrum Master journey, emphasizing its approachability and practical insights into role expectations, task decomposition, and work management. With anecdotes and tips like fitting work to time and embracing various work breakdown strategies. In this episode, we also refer to the episode with Anton Skornikov on slicing User Stories. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: When the Stand-Up Turns Into Chaos, Conflict, Care, and Change for Agile Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In a gripping episode with Tom, we talk about the chaos of a stand-up gone wrong, spotlighting how personal tensions can reflect deeper process issues. Tom recounts a fiery disagreement between developers, stemming from a pressured environment, and how it led to a transformative shift in team dynamics and location. We talk about how Scrum Masters can navigate through conflicts, focusing on psychological insights and team unity. Key takeaways include the importance of 1-on-1 chats, understanding triggers, and collective decision-making, all while referencing seminal works like Deming's 14 principles for management and Lencioni's "The Five Dysfunctions of a Team."   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.