Podcasts about agile manifesto

Someone just told you AI made roadmaps obsolete... and they're about to sell you the replacement!Product Manager Brian and Enterprise Business Agility Leader Om put "the Last Roadmap" pitch next to the Agile Manifesto and find a 25-year-old argument wearing new labels. In reality, the roadmap that 'died' is really a Gantt chart; the 'durable convictions' your company will be sold on will be the same tired top-down contracts you are handed today; and the AI-native team is the 2001 agile team word-for-word that gets pushed-and-then-pulled everytime the numbers or deadlines slip. Listen or watch as Brian and Om discuss and debate:Why the roadmap that 'died' was a Gantt chart wearing a product badgeThe 'funeral funnel' behind the pitch: declare it dead, sell the fixWhy 'durable convictions' set without customer collaboration are contracts with extra stepsThe AI-native team pitch (aka. the Agile Manifesto's empowered team from 2001)Why AI can't fix your empowerment problemsThis podcast is for product managers working at real companies, managers trapped in the messy middle, and anyone whose 'roadmap' has dates, swim lanes, and/or looking for a man in finance.#AgileManifesto #ProductRoadmap #AIAgile Manifesto (2001), Marty Cagan, Henry Gantt, Jira, W. Edwards Deming, L. David Marquet, Kumar Dattatreyan, Dario Amodei (Anthropic), Arguing Agile 249 (Disagree and Commit), Arguing Agile 113 (Outcome vs Output Roadmaps)LINKSYouTube: https://www.youtube.com/@arguingagileSpotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596INTRO MUSICToronto Is My BeatBy Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Last time it was the WHO: customers, businesspeople, face to face.  This time it is the HOW.  @Kate Megaw, @Anu Smalley and @Ryan Smith finish the Back-to-Basics run through the 12 Agile Principles with numbers 7 through 12, asking the same question of each: what wording would keep someone in legal, marketing, or finance reading?  Working software becomes delivered value in about ninety seconds, no notes.  Sustainable development turns out to be the most ignored principle of the twelve, partly because it says development and partly because people think sustainable means 40+ hours a week.  Technical excellence loses the C-suite at the word technical, and then the three hosts split on whether design has to go too.  Simplicity and the retrospective principle survive untouched, which raises the obvious question of why the retrospective is the first event teams drop. 

The 12 principles behind the Agile Manifesto are the most skipped page in agile. Plenty of people can quote the four values.  Far fewer know there are 12 principles sitting underneath, and fewer still could name one. Kate Megaw, Anu Smalley and Ryan Smith continue the Back-to-Basics series by working through the first six, one at a time, asking the same question of each: what wording would make this land for someone in marketing, finance, or HR?  Software becomes value, then the three of them discuss whether value is too vague.  Business people and developers becomes stakeholders and teams, because “I am not a developer” is a very easy way to leave a conversation.  The word project shows up twice and nobody minds anymore, which is a shift from five years ago. And face to face gets a defense from Alistair Cockburn that is worth quoting the next time someone tells you a remote team cannot do it.  The point is not a new set of principles. It is that people shut down when the words do not fit their world, so hand them words that do.

Many Scrum Masters and Agile Coaches have been cut loose, organizations are changing how they deliver products and services, and AI has landed on top of both. Kate Megaw, Anu Smalley and Ryan Smith open a new Back to Basics series with the document that started all of it, the Manifesto for Agile Software Development. They start with the obvious question. If it was written for software, what word belongs there now? Ryan says iterative development. Anu says iterative fill in the blank, because coaching a leader is iterative too. Then they go to the four values and pick favorites, and pretty much land on the same pair. Individuals and interactions, and responding to change, come out as the bookends that give the middle two somewhere to stand. Meanwhile AI is quietly pulling attention back toward the tools on the right and working software and customer collaboration are where teams are slipping.  The close is the useful part. This is not a rulebook to recite at people. It is a short piece of text that gives a team permission to work better.

Faith Forster has spent 15 years in product leadership. She was VP of product at Dex, acquired for approximately $600 million, and went on to serve as CPO at Legal, a payments and compliance platform. She now runs discovery.com, an AI-native platform that helps product leaders and teams make faster, better product decisions by connecting to their tools and synthesising competitor, customer and growth intelligence. She is also the driving force behind the Makers Manifesto — a cross-disciplinary set of values and principles for building great products in the age of AI, developed with 45 contributors from across product, engineering, design, and business leadership.We discuss:The manifesto emerged from 96 conversations with product leaders whose grasp of AI ranged from fully automated pipelines to treating it as a faster way to write PRDs — a gap that revealed an industry in urgent need of a shared reference point.Four values anchor the manifesto: purpose over possibility, value created over effort spent, learning loops over launch plans, and human accountability over full automation."Maker" was chosen over "builder" to signal that designers, engineers, salespeople, customer support staff, and founders all share equal ownership of the creation process — regardless of job title.Feature parity is no longer a defensible moat: when any competitor can replicate a capability within days, durable advantage must come from data, relationships, distribution, and business model.Product market fit can no longer be treated as a static milestone — in a market where products, competitors, and customer expectations shift simultaneously, fit must become a continuous, living part of decision-making."Done" now means adopted, not shipped. AI removes every excuse for clunky, one-size-fits-all experiences, and teams that still equate production deployment with completion are measuring the wrong thing.Making context explicit — codifying strategy in a form that agents and humans can both act on daily — is the principle teams consistently identify as their most urgent, immediate priority.Chapters00:00 Introduction 01:12 Faith's background 02:28 Origins of the Makers Manifesto 06:18 Makers Manifesto vs the Agile Manifesto 07:23 Why "maker" not "builder" 11:42 Four values and 16 principles 15:01 Purpose over possibility 19:10 Learning loops over launch plans 22:36 Who gets to be a maker 28:55 Durable advantage in the AI era 33:22 Staying close to customers 36:04 What's next for the manifesto 43:59 Wrap-upReferencedMakers Manifesto — https://makersmanifesto.orgdiscovery.com — Faith's AI-native product decision platformOur HostsLily Smith enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She's currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space. She's worked on a diverse range of products – leading the product teams through discovery, prototyping, testing and delivery. Lily also founded ProductTank Bristol and runs ProductCamp in Bristol and Bath.Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury's. He participated in Silicon Valley Product Group's Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities he runs for CPOs (CPO Circles), Product Managers (Product In the {A}ether) and Product Coaches. He's the author of What Do We Do Now? A Product Manager's Guide to Strategy in the Time of COVID-19. A recovering music journalist and editor, Randy also launched Amazon's music stores in the US & UK.

In this episode of Le Podcast on Emerging Leadership, I sat down with Jon Kern, aerospace engineer turned software architect and co-author of the Agile Manifesto.Jon shares his fascinating journey from testing jet engines for the Defense Department to pushing back against heavyweight, bureaucratic software processes. We explore the original intent behind the Agile Manifesto, the misconceptions that led to overly rigid frameworks, and how leaders can embrace the concept of "being lazy" to deliver true business value.Finally, Jon dives into the frontier of "Vibe Coding," sharing how he uses AI to automate rigorous testing, compliance, and architecture without losing the foundational discipline of software engineering.

Aliu Adewale: The New Scrum Master Trap—Being In Everyone's Business to Look Busy 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.   "Sometimes the best architecture and design comes from a self-organizing team." - Aliu Adewale   When Aliu first became a Scrum Master, he wanted to be everywhere. New to the role, new to the organization, with a new team relying on him to deliver, he scheduled extra check-ins, sat in on everything, and made sure his manager could see him working. The result wasn't visibility—it was suffocation. The team felt he was in their business, and the deliveries he was trying to protect got worse, not better. Aliu's wake-up call came from his coach, who told him a sentence he still carries: "Stepping back gives your team the space to take ownership and unlock their true potential." The hardest thing a new Scrum Master can do is let things roll on their own for a Sprint or two and adjust through the retrospective. But once Aliu did it, the team started self-organizing, owning their day-to-day, and delivering beyond his expectations. The lesson he names is Agile principle number 5: build projects around motivated individuals, give them the support they need, and trust them to get the job done. The deeper insight from Vasco in this episode: when we want to be in our team's business, it's usually because we don't trust ourselves to know enough—so we try to know everything.   In this episode, we refer to Turn the Ship Around! by David Marquet, which Vasco recommends for any Scrum Master learning to step back, and to the Agile Manifesto.   Self-reflection Question: What are you doing this week to "be visible" that the team would actually be better off without?   [The Scrum Master Toolbox Podcast Recommends]

Jim Highsmith has been thinking about decision-making for a long time. When he wrote Agile Project Management in 2004, he went looking for practical guidance on decision-making in the project management literature and found very little. That gap matters even more now.In this episode, Jim and I talk about why AI raises the stakes for executive judgment. AI can remove friction, speed up work, and take on repeatable tasks, but it can also make it easier for leaders to stop practicing the very capabilities they are paid to use. Jim brings this to life through John Boyd's OODA loop, the risk of judgment atrophy, mountaineering decisions, Rob Hall's Everest threshold, Phil Knight's pattern recognition at Nike, and a personal story from Jim's own time leading a collaborative project team at Nike.This conversation is really about how leaders build judgment deliberately: by making consequence-bearing decisions, setting thresholds before pressure arrives, creating space for slow thinking, and reflecting honestly on how decisions were made.Key TakeawaysAI can weaken judgment when leaders stop practicing it: Jim compares the risk to driving an autonomous car: the more the system takes over, the less sharp the driver becomes. AI can remove low-value effort, but leaders still need to practice making consequence-bearing decisions.The OODA loop is mostly about orientation: Jim explains that John Boyd's edge was not just speed, but his ability to update his mental model quickly. For leaders, the real work is noticing when old assumptions no longer fit the situation.Capability is knowledge plus experience plus judgment: AI can make knowledge easier to access, but it cannot replace the experience of carrying consequences. Judgment develops when people make real decisions, reflect on the outcome, and adjust how they think.Thresholds only work when enforced under pressure: Jim uses Rob Hall's Everest story to show why decision thresholds matter before emotion, ambition, or sunk cost take over. In business, those thresholds might be cost, risk, customer impact, or reversibility.Leaders need to separate fast decisions from slow judgment: Some repeatable, data-heavy decisions can be automated with guardrails. Higher-context decisions still need human orientation, pattern matching, and time to think.Reflection turns experience into better pattern matching: Barry shares his practice of documenting decisions, what was known at the time, and why the call was made. That kind of review helps leaders improve the decision process, not just judge the outcome.Additional InsightsRole modeling beats mandates: Jim describes how Boyd taught by showing the mechanics of his performance. Barry connects this to AI adoption: leaders create more movement by sharing how they are using the tools in real work.Productivity fatigue is a real AI-era risk: Barry reflects on how AI can increase output while shrinking the space to think. That matters because senior leadership work often depends on judgment, not just throughput.AI transformation is still a people problem: Jim returns to Jerry Weinberg's reminder that “no matter what they tell you, it's a people problem.” Tools help, but organizations still need to redesign the work, behaviors, and decisions around them.Pattern matching is different from gut feel: Jim uses Phil Knight's Nike decisions to show how instinct can come from years of context. What looks intuitive on the surface is often pattern recognition built through experience.Episode Highlights00:00 – Episode Recap – Jim Highsmith frames the core tension of the episode: AI can accelerate work, but it can also expose whether leaders have a real decision-making system or are quietly handing judgment to the machine.01:45 – Guest Introduction – Barry introduces Jim Highsmith, a pioneer of adaptive leadership and original Agile Manifesto signatory whose work has shaped how organizations navigate uncertainty and make high-stakes decisions. (Jim Highsmith)04:27 – Decision-Making Was Missing from the Playbook – Jim explains that when he wrote his first Agile Project Management book in 2004, he found surprisingly little practical guidance on decision-making in standard project management sources.05:47 – The Real Power of the OODA Loop – Jim revisits John Boyd's observe, orient, decide, act model and argues that orientation, the ability to update mental models under pressure, is the part leaders often underdevelop.07:19 – From Process-Centric to Judgment-Centric Management – Jim makes the case that if AI takes over more process improvement work, organizations need decision-making capacity distributed through the system, not concentrated at the top.09:14 – The Judgment Muscle Can Atrophy – Barry and Jim use the autonomous car example to show how useful automation can quietly weaken a capability when people stop practicing it.12:33 – Role Modeling Beats Mandates – Jim explains how Boyd taught fighter pilots by showing the mechanics of superior performance, which Barry connects to leaders demonstrating their own AI experiments instead of simply telling others what to do.15:50 – Capability Is More Than Knowledge – Jim defines capability as knowledge plus experience plus judgment, pointing out that LLMs can provide knowledge but not the consequence-bearing experience that shapes better calls.18:56 – Thresholds Keep Decisions Honest – Jim shares the Rob Hall Everest story to show why thresholds only matter if leaders are willing to honor them when pressure, ambition, or sunk cost pushes the other way.20:58 – Automate the Right Decisions – Jim distinguishes fast, data-dependent System One decisions from slower System Two judgments, giving leaders a practical way to decide what to automate and what to protect.24:31 – From Search Engine to Human-Agent Teams – Jim describes his own progression from using AI as a search engine to working daily with multiple humans and agents, showing that the practice evolves through use.27:06 – Productivity Fatigue and Constant Execution – Barry reflects on how AI can create more throughput while leaving less space for slow thinking, especially for leaders whose real value is making judgment calls.31:05 – Relearning the People Problem – Jim returns to Jerry Weinberg's reminder that “no matter what they tell you, it's a people problem,” and Barry connects that to companies buying AI tools without redesigning how people work.33:21 – Pattern Matching Is Not Gut Feel – Jim uses Phil Knight's early Nike decisions to explain why seasoned executives often seem intuitive because they have built patterns from industry knowledge, relationships, and lived context.36:09 – Decision Journaling Builds Better Judgment – Barry describes documenting decisions, the information available, and the rationale at the time as a way to learn from both strong and weak outcomes.37:22 – A Nike Lesson in Collaborative Judgment – Jim recalls a project decision at Nike where the team agreed with the outcome but challenged the process, giving him a lasting lesson about when people need to be part of the call.38:51 – Closing Reflections – Barry thanks Jim and points listeners toward his writing as these long-standing ideas about judgment, adaptability, and decision-making become even more relevant in the AI era.Useful ResourcesJim Highsmith's website – Jim's home base for his bio, books, articles, podcasts, and current work. (Jim Highsmith)The Adaptive EDGE – Jim's Substack on leadership, adaptability, and AI. (jimhighsmith.substack.com)The Agile Manifesto – The original manifesto and signatories list, including Jim Highsmith. (Agile Manifesto)Adaptive Leadership: Accelerating Enterprise Agility by Jim Highsmith – The book Jim references when discussing his earlier work on adaptive leadership and decision-making. (Google Books)Robot-Proof: When Machines Have All the Answers, Build Better People by Vivienne Ming – The book Jim mentions as influencing his thinking about creative human capability in the AI era. (Google Books)Boyd: The Fighter Pilot Who Changed the Art of War by Robert Coram – A deeper look at John Boyd, the OODA loop, and the “40-second Boyd” story discussed in the episode. (

Chris Lucian and Austin Chadwick discuss all things #agile and product development from a #MobProgramming perspective. What if you could decompose every agile method down to its essential building blocks and recombine them for your own specific context? In this episode, Chris and Austin are joined by Aria Omidvar to explore the HEXI method — a framework-agnostic approach to understanding and applying agile, lean, and software craftsmanship practices through physical hexagon objects and collective sense-making. Aria shares his journey from software craftsmanship and clean code, through Scrum and XP, to discovering Dave Snowden's HEXI method and building his own independent "Hexiverse" — a modular knowledge map that spans Software Teaming, Extreme Programming, Kanban, Modern Synthesis, the Agile Manifesto, and more. He unpacks how breaking methods into reusable hexagonal pieces allows teams (and individuals) to see the connections between ideas, surface what is missing, and navigate the overwhelming landscape of agile methods without falling into method wars. We dig into: What the HEXI method is and how Dave Snowden and Nigel Thurlow introduced it via Scrum.org How Aria independently adapted HEXI to create a Hexiverse for software teaming and mob programming Why decomposing methods into building blocks enables recombination for any specific context The spatial design choices behind the Hexiverse — and why dotted hexagons signal a concept shared across sets How Alistair Cockburn validated the Agile Manifesto hexiset (and why that meant the world to Aria) The learning journey metaphor of islands growing large enough to connect — and how the Hexiverse accelerates that Why "nice" doesn't cut it in high-collaboration environments — and how kindness, consideration, and respect offer a deeper model The "turn up the good" retrospective format and why it flips the traditional improvement lens How the Hexiverse serves both as a personal learning quest and a potential onboarding tool for teams new to agile methods Aria's call to action: check the original HEXI sources, play with the physical kits, and consider building your own Hexiverse Scaling Complex Systems by Building on Agile Frameworks with Dave Snowden and Nigel Thurlow: https://youtu.be/AEf1BCffimA Aria's Hexiverse on Miro: https://miro.com/app/board/uXjVKv84GGU= The Hitchhiker's Guide to Hexiverse on Medium: https://medium.com/@omidvar.aria/list/the-hitchhikers-guide-to-the-independent-hexiverse-fe509a7c46f8 The Hitchhiker's Guide to Hexiverse on LeanPub: https://leanpub.com/HG2H

This conversation was recorded at GOTO Copenhagen 2025.https://gotocph.comMartin Fowler - Pioneer of Various Topics around Object-Oriented Technology & Agile MethodsKent Beck - Software Engineer & Creator of Extreme ProgrammingRESOURCESMartinhttps://x.com/martinfowlerhttps://www.martinfowler.comhttps://toot.thoughtworks.com/@mfowlerhttps://www.linkedin.com/in/martin-fowler-comKenthttps://bsky.app/profile/kentbeck.bsky.socialhttps://www.kentbeck.comhttps://github.com/KentBeckhttps://twitter.com/KentBeckhttps://www.linkedin.com/in/kentbeckhttps://tidyfirst.substack.com/aboutDESCRIPTIONMartin Fowler and Kent Beck — two of the authors of the Agile Manifesto and perhaps the most influential duo in software engineering history — reunite for an unscripted conversation spanning thirty years of friendship, craft, and the relentless pace of change. They discuss how AI ("the Genie") has become a genuine part of both their workflows: Kent uses it as an endlessly patient tutor for exploration between features, while Martin distinguishes between AI as a tool for talking to computers versus the irreplaceable human skill of talking to the people who need software built. Both are optimistic about the future, though Kent's optimism takes characteristically sharp form: he expects the industry to keep making the same mistakes, which means he'll still be employed teaching the same lessons 20 years from now.The conversation also revisits the Agile Manifesto at nearly 25 years old, with both reflecting on what Extreme Programming got right — feedback loops, testability, evolutionary design — and what the broader adoption missed or diluted. Martin is candid that progress in software has been slower than he'd like, though he points to a "forest" of practitioners who have genuinely advanced the craft. On the question of a Manifesto reunion, both gently redirect: it belongs to the next generation now. Their closing advice to a junior developer in the audience is perhaps the most memorable exchange in the whole session — use the gaps between features to learn, and never forget that understanding the domain and the people in it is ultimately what separates good programmers from great ones.Read the full abstract here:https://gotocph.com/2025/sessions/3780RECOMMENDED BOOKSMartin Fowler • Refactoring • https://amzn.to/3EVcHXQMartin Fowler & Pramod Sadalage • NoSQL Distilled • https://amzn.to/3ChIpu7Martin Fowler • Patterns of Enterprise Application Architecture • https://amzn.to/3lp4sIqMartin Fowler • Domain-Specific Languages • https://amzn.to/3nzOIFkMartin Fowler • UML Distilled • https://amzn.to/3kahjyAKent Beck • Tidy First? • https://amzn.to/4gscjjKKent Beck & Cynthia Andres • Extreme Programming Explained • https://amzn.to/3sBASDGKent Beck • Test Driven Development • https://amzn.to/3U4AXLsKent Beck, Fowler, John, William, Don & Gamma • Refactoring • https://amzn.to/3SFBYbNKent Beck • Implementation Patterns • https://amzn.to/3sBlCGLBlueskyInstagramLinkedInFacebookCHANNEL 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!

The doomer YouTubers are working overtime. Shoggoth monsters behind the mask. Models faking alignment. Mythos secrets the AI labs allegedly won't release. Compelling theater — and almost entirely empty under the empirical microscope. Coach AF asks the question your favorite fear influencer won't: who profits from your panic? Episode 73 cuts open three of the loudest AI fear narratives for what they really are. The Shoggoth metaphor — where it came from, what it actually meant, and how content creators hijacked it. The alignment faking paper from Anthropic and Redwood Research — what the protocol actually tested, and what the headlines deliberately bury. The Claude Mythos leak — accident, not conspiracy. This is the same colonization pattern that turned the Agile Manifesto into a certification factory and Bitcoin into a speculation casino. Different costume. Same vendor playbook. Read the source. Trust the craft. Dare real agile, applied to real AI.

Jim talks with Bonnitta Roy, interdisciplinary thinker and founder of the Pop-Up School and the Divinity School, about her worldview, the deep foundations of her work, and an upcoming conference in Cambridge. They discuss the phenomenology of waking up and recomposing, life as a stream of participation, being nested in place through horses, pigeons, bees, and gardens, covariant motions as her process-philosophy term for embeddedness, the limits of computational rationalism, the bench scientist versus the metatheoretical interpreter, Michael Levin's interpretive science and the standards it demands, McGilchrist's left-brain dominance in late-stage Game A, early complexity theory's assumption that enough compute could map all relations, the open future and retrofitted causal explanation, emergence and causality as co-resident trees, Bonnitta's critique that emergence does insufficient explanatory work, continuous gradients beneath emergent thresholds, the traffic jam as a case study in laminar flow breakdown and downward causality, a 55-gallon drum of Jim Rutt chemicals, modularity as a post-hoc feature of development rather than its driver, where the impulse to get a beer actually comes from, the Buddhist thought experiment of cells covarying above and below thresholds, the evolutionary stack from amoeba to eukaryote to bone, white blood cells as ancient life forms living inside the body as habitat, the importance of precise definitions of consciousness, levels of simulation from New Caledonian crows to humans simulating a simulation into other people, the introspective nervous system's first-person and always-running third-person modes, Anil Seth's hallucination framing and Bonnitta's belief that simulation is the better word, why calling biological visual adjustment a hallucination is irresponsible pedagogy, Kant and the grounded approximation of reality, cultural variation in color perception, complex potential states versus the adjacent possible, Elon Musk as an example of seeing past constraints to new potential states, Bonnitta's critique of stage theory as pipeline-shaped rather than genuinely developmental, the Agile Manifesto generation acting their way into results without the formation stage theory assumes, David Bays's mathematics book and culturally bound leaps in simulation capacity, egocentric versus allocentric modes in neurodynamics, the self-generative trap of inner development and parts work where parts have parts, the three-legged stool of self, other, and world, the egregore as a hugely powerful collective agent, the historical arc from Renaissance world-builders to postmodern distributed agency, the Divinity School's question of how to lead free and willing participants, post-formal actor superpower types with powerful action logics but insufficient character, and much more. Episode Transcript Divinity School Conference: Innovations in Biological Intelligence & Machine Agency JRS EP 17: Bonnitta Roy on Process Thinking and Complexity The Pop-Up School (Substack) GSNV (Substack) Bonnitta Roy is founder of Alderlore Insight Center, and academic director of The Divinity School. She describes herself as a gardener, horse whisperer, and insight guide. She has two Substack publications: The POP-UP School where she is currently building out her philosophy of The Global State Naturalized View, and GSNV, where she posts articles generated by her GPT-engine trained on that view.

Stewart Alsop sits down with Ulises Martins on the Crazy Wisdom podcast to explore how artificial intelligence is fundamentally disrupting professional careers, labor markets, and the pace of human adaptation itself. They discuss everything from Dario Amodei's concept of "technological adolescence" to the possibility that we're approaching a point where AI advancement accelerates beyond our ability to keep up, touching on topics ranging from the economics of software development and the future of warfare to generational differences in how people will respond to AI-driven change. Martins emphasizes that while we may not be able to predict exactly what's coming, we need to dramatically increase our efforts to learn and adapt—potentially doubling the time we invest in understanding AI—because this isn't optional change, it's disruption happening at an unprecedented speed. Connect with Ulises on Linkedin to follow his work in AI and generative technology.Timestamps00:00 — Stewart introduces Ulysses Martins, framing the conversation around accelerationism and the future of work.05:00 — Ulises uses the parent-child analogy to argue humans will no longer play the dominant role as AI surpasses us.10:00 — Both agree learning AI is non-negotiable, urging listeners to double their investment in staying current.15:00 — Discussion shifts to software as media, the collapsing cost of building products, and the risk of big players like Anthropic making your idea obsolete overnight.20:00 — Ulises raises ecology vs. cosmic ambition, questioning whether humanity should aim for civilizational-scale goals like the Dyson sphere.25:00 — Stewart's ESP32 hardware project illustrates AI's current blind spots beyond software, while both predict physical-world AI will arrive as a byproduct of bigger industrial goals.30:00 — Tesla's birthplace in Croatia sparks a reflection on human genius as luck versus deliberate investment, invoking the Apollo program as a model.35:00 — The US-China AI race is compared to the Cold War Space Race, with interdependency acting as a brake on outright conflict.40:00 — Drone warfare and AI reframe military power, making troop size irrelevant and potentially reducing total war.45:00 — Agile methodology and generational shifts are linked, asking how Gen Z's values will shape the AI era globally.50:00 — Argentine vs. American Zoomers are contrasted, with millennial expectations versus Gen Z's pragmatism explored.55:00 — Ulises closes urging everyone to enjoy the ride, taking the infinite stream of change one episode at a time.Key Insights1. The Death of Traditional Career Paths: The concept of professional careers as we know them—starting as a junior and progressively advancing—is becoming obsolete due to AI's rapid advancement. This applies far beyond just software and SaaS companies, extending to all industries as robots and AI systems gain capabilities that fundamentally disrupt labor markets. The question isn't whether we'll adapt, but whether humans can adapt fast enough to keep pace with exponential technological change.2. The Acceleration Imperative: People must dramatically increase their investment in learning about AI immediately. Whatever time you were previously dedicating to staying current with technology needs to be doubled or tripled. This isn't optional—it's comparable to the necessity of basic education. Unlike previous technological transitions where you had years to learn new frameworks or tools, the current pace demands immediate, intensive engagement or you risk becoming irrelevant.3. Software as Media and the Collapse of Development Economics: Software has become media—easily reproducible and increasingly commoditized through AI assistance. The fundamental economics of software development are collapsing because if building software requires dramatically fewer development hours, the value and price of that software must necessarily decrease. Entrepreneurs need a new evaluation framework that assesses the risk of their ideas being replicated by AI or absorbed by major players like Anthropic or OpenAI.4. The Parent-Child Analogy for AI Development: Humanity's relationship with AI will inevitably mirror that of parents with increasingly capable children. Initially, we understand and control what AI does, but as it advances, it will surpass human capabilities in most domains. Just as parents cannot control fully grown adult children who exceed their abilities, humans will need to reconcile with creating something superior to ourselves. Attempting to permanently control such systems may be both impossible and potentially pathologic.5. The Kardashev Scale and Civilizational Ambitions: AI represents a civilizational-level technology that should redirect humanity toward grander goals like capturing stellar energy through Dyson spheres and expanding beyond our solar system. The competition between China and the United States over AI mirrors the Apollo program's space race but with higher stakes—potentially making traditional concepts like money less relevant if we successfully crack general intelligence. This requires thinking beyond planetary constraints.6. The Changing Nature of Warfare and Geopolitics: AI and autonomous weapons systems are fundamentally changing warfare by making human soldiers less relevant, similar to how nuclear weapons reduced the importance of conventional military force. This shift may actually reduce bloody civilian casualties in conflicts between major powers, as drone warfare and AI-driven systems create new equilibriums. The geopolitical map may fracture into more sovereign states and city-states as centralized control becomes less effective.7. Generational Adaptation and Unpredictability: Different generations will respond uniquely to AI disruption based on their values and experiences. Generation Z, having grown up during the pandemic without traditional expectations, may adapt differently than millennials who experienced unmet expectations. However, we must remain humble about our predictive abilities—we're not good at forecasting technological change or its timing. The best approach is maintaining openness, trying to understand developments as they unfold, and accepting that we cannot consume all information in an era of unlimited AI-generated content.

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

 Un Café avec Frédéric Épisode 17J’aimerais te parler et échanger sur l’actualités, des commentaires, des stratégies sur l’agilité d'affaire, l’innovation technologique et le leadership ouvert, libre et décentralisé.Un Café avec Frédéric (UCAF) Ça inclue aussi des histoires de succès d'entrepreneur, des fails fast, get up faster. On va aussi se parler du Club des Citoyens Responsables, Nomad digital, AI Craftman, de DeFi, Real Bitcoins, Renaissance de notre vivre ensemble et différents.Joins toi à moi avec un bon café, LIVE le Premier Vendredi du mois enrte 9h ou Midi, heure de l’Est.Ce mois-ci, Un échange lucide, critique et inspirant sur le futur du travail, du logiciel et de la création de valeur.25 ans après le Agile Manifesto, pourquoi tant d'organisations échouent encore à livrer de la vraie valeur ? Cet épisode assume une posture claire : nous vivons une anemoia collective cette nostalgie d'une révolution du code que peu ont réellement incarnée. Pendant que les modèles de gestion de projet classiques continuent d'imposer rigidité, contrôle et illusion de prédictibilité, une nouvelle vague de développeurs et d'entrepreneurs avance autrement.Scrum, intelligence artificielle et craftsmanship deviennent les leviers d'un système vivant, orienté apprentissage, adaptation et résultats concrets. Ici, on ne célèbre pas l'agilité comme un dogme. On questionne ses dérives, on expose ses contradictions et on parle de systèmes plutôt que d'objectifs, de valeur plutôt que de processus, de leadership basé sur les preuves plutôt que l'idéologie. Un épisode sans nostalgie naïve, mais avec une vision lucide du futur du travail et de l'agilité en 2026. Musique dans ce podcast par  Producer, Director & Writer | LeyonsAgile Rhapsody – Bohemian Rhapsody Parody – Scrum Team Building – Agile Manifesto in a fun songBuy my Guests and me a Coffee to Warm us our Hearts ☕️Want to Watch this Episode in Video?

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

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.

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/

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)

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.