Podcasts about Agile

Olaitan Fashanu: The PO Who Doesn't Care vs the PO Who Always Has the Answer 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.   In this episode, we refer to a recurring theme in past podcast episodes—the proxy product owner who can't make decisions because they're not theirs to make. The Great Product Owner: Always Available, Always Decisive, Always Has the Context 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.   "There was nothing you tell, any questions you have about a particular feature that this guy doesn't have an answer to. And that really moved the team so fast." - Olaitan Fashanu   The best PO Olaitan ever worked with was the mirror opposite of every anti-pattern he'd seen. Deeply involved in refinement. Took backlog management seriously. Always brought the context. Always available to the team. And—maybe most importantly—always ready to make a decision when devs surfaced trade-offs. The team could ask any question about any feature, and the answer was right there. Not "let me check," not "I'll get back to you," not "what do you think?"—a decision. That single quality, Olaitan says, was what moved the team faster than anything else. As a Scrum Master, when you see a great PO at work, you also see the amplifying waves of impact: motivation rises, quality rises, ownership grows. Olaitan's takeaway is sharp: the success of our job depends on how well the product owner does theirs.   Self-reflection Question: When was the last time your PO made a real-time decision that unblocked the team in a single conversation—and what's preventing that from being the norm? The Bad Product Owner: Doesn't Care About Impact, Can't Make Decisions Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The product owner cares about delivery. We just need to release to the customer. That is something I don't like." - Olaitan Fashanu   Olaitan describes two anti-patterns wrapped into one bad-PO type. The first: the PO who doesn't care about the impact of their work on the team. Tickets dropped without context. No refinement. No problem framing. Just "ship by end of month." The data shows up in Jira if you're paying attention—patterns of churn, quality issues, customer complaints, slow market response. Beyond the numbers, the team loses motivation, frustration creeps in, and eventually you lose the team entirely. The second anti-pattern, layered on top: the PO who can't make decisions. Developers come back with two options and the trade-offs—and the PO can't pick one. Vasco connects it to the proxy PO pattern explored in past episodes—a PO whose decisions aren't actually theirs to make. The cost is the same either way: the team stalls, ownership erodes, and stakeholder conflict grows.   In this segment, we refer to the proxy PO anti-pattern explored in earlier episodes of the podcast.   Self-reflection Question: Is your PO unable to decide—or unable to be allowed to decide? The difference changes which conversation you need to have, and with whom.   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: I Love Data—Why Success for a Scrum Master Means Doing the Hard Measurement Work 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.   "You don't get better by not trying to be better." - Vasco Duarte (channeling Olaitan's own discipline)   For Olaitan, success as a Scrum Master comes down to two things—team effectiveness and team health—and he refuses to guess at either. Twice a year, in what he calls his winter and summer cycles, he runs a structured team health check survey to capture how confident people feel, whether they hold each other accountable, and whether psychological safety is real or theatrical. Between those checkpoints, he runs constant one-on-ones—and not just with developers. QAs, designers, the PO. Everyone gets the conversation. He pulls outside-in feedback from customers and partner teams too, because effectiveness measured only from the inside is fiction. "I love data. Maybe it's my background in mathematics. I love looking at patterns, comparing things." The work is real, the load is real—but for Olaitan, refusing to do it is the same as refusing to grow.   Self-reflection Question: If you had to prove to yourself today that your team is genuinely effective and healthy, what data would you actually have—and what would you only be guessing at? Featured Retrospective Format for the Week: Start / Stop / Continue (and a twist Vasco offers Olaitan) Olaitan's go-to is the simple Start / Stop / Continue format—the easiest way he's found to get even quiet developers to engage, especially at the start of a new iteration. Vasco offers him a twist mid-episode: what if you only used one of the three? When the team is overwhelmed, run a Stop-only retro. When a release just shipped and energy is high, run a Start-only retro. Breaking the format pattern creates a small spark of "wait, why is this different today?"—which is often exactly the energy a tired team needs. Olaitan also shares a second favorite: the Friction vs. Drivers (or Fuel) format—mapping what's slowing the team down on one side and what's actively energizing them on the other. The two sides of the same coin, made visible.   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other? 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.   "How do we ensure that these teams actually work together to show the same data?" - Olaitan Fashanu   Olaitan brings a problem most Scrum Masters in scaled environments will recognize. Three teams. Three separate backlogs. One product, accessed across app, web, and support channels. Leadership made a top-down team topologies decision: split the work to move faster. Predictable result—each team optimizes for their own backlog, blind to what the others are building, sometimes shipping the same feature twice with different behaviors. The product owners know there's overlap. The teams love the idea of linking tickets across backlogs. They just won't maintain the habit. Olaitan and Vasco walk through experiments together: a sync between POs, joint refinement sessions, linking tickets, putting "this is also being built by Team B" notes at the top of stories. The deeper insight: the Scrum Master's job is to keep surfacing information until a habit forms. As Vasco's old lifting coach put it—you find the imbalance, you get rid of the imbalance, one by one. That's how you get stronger.   In this episode, we refer to team topologies and the practice of surfacing information across team boundaries.   Self-reflection Question: Where in your organization are teams unknowingly building the same thing twice—and what's the smallest experiment you could run this week to make that visible?   [The Scrum Master Toolbox Podcast Recommends]

WAgile - Is Hybrid Project Management Finally Real?WAgile is a hybrid project management approach that uses traditional governance and planning to establish direction while using Agile practices to continuously adapt execution based on learning and feedback.- [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/

We're celebrating PFN's birthday by shining a light on the partners who have been part of our journey toward people-first leadership, meaningful work, and purpose-driven impact. This special feature from Unlocked with Skot Waldron captures the heart of their work and the shared mission that brings us together. Enjoy! — Work can either drain people or deepen their sense of purpose. It's time to design workplaces that do the latter. Skot sits down with Mindy Honcoop, founder of Agile in HR and longtime people leader, to explore what it really means to put humans at the center of business strategy. With over 20 years in HR leadership, Mindy shares why organizations must move from reactive problem-solving to proactive, people-first design, especially when it comes to role clarity, onboarding, culture, employee experience, and organizational alignment. Together, Skot and Mindy unpack how leaders can listen better, ask better questions, and connect the employee story to the customer story. From reducing workplace churn to creating emotional loyalty, this conversation is a powerful reminder that when people feel seen, supported, and connected to purpose, organizations thrive.   Additional Resources: Connect with Skot on LinkedIn Listen to Unlocked wherever you get your podcasts! Subscribe to the PFN YouTube Channel for daily leadership insights! Follow PeopleForward Network on LinkedIn Learn more about PeopleForward Network   Key Takeaways: Put people at the center of strategy. Proactive leadership creates healthier workplace cultures. Employee stories reveal the real problems. Loyalty grows when people feel deeply cared for. Small, curious questions can spark meaningful change.

Olaitan Fashanu: When the New PO Stops Refining—and the Team Starts Self-Destructing 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.   "If we're actually doing the job of refining this ticket properly, then we will not be creating this tension in the team." - Olaitan Fashanu   The team was working well. They had a strong PO who came to refinement with the problem clearly framed: this is what we want to solve, here's the context, here's the user story, here are the acceptance criteria. The team picked it up, refined it, ran with it. Then change came. A new PO joined—and the routine collapsed. The new PO cared about one thing: hitting the delivery date. Tickets dropped into Jira with no context, no problem statement, no acceptance criteria. Just "this needs to ship by end of month." Within weeks, Olaitan saw the symptoms cascade through the team. Developers asked designers what tickets even meant. QA struggled to maintain quality. Tension built. The diagnosis was clear: refinement had broken. His fix? Bring back the Definition of Ready as a non-negotiable shared standard, and introduce a product trio—business viability, technical feasibility, and design usability collaborating on every story before it reaches the rest of the team.   In this segment, we talk about the Definition of Ready and the product trio collaboration model.   Self-reflection Question: What's the symptom you're seeing in your team right now—and could the real source be how stories are getting refined, not how they're getting built? Featured Book of the Week: The Secrets of Facilitation by Michael Wilkinson Olaitan calls out The Secrets of Facilitation by Michael Wilkinson as the book that shaped how he handles difficult moments. The book teaches the power of asking the right question at the right time—clarifying questions, probing questions, the questions that drive a stuck group forward. "You will understand how, when to ask clarifying questions, ask really powerful questions that will help you drive or probably help you reach your goal in any session you find yourself." For Olaitan, the biggest payoff was learning to manage group dynamics in real time—what to do when something said in a meeting lands badly, when a comment threatens to derail the room. As a Scrum Master, you live in those moments. This book hands you a toolkit for them.   [The Scrum Master Toolbox Podcast Recommends]

The conversation around AI often focuses on speed, automation, and productivity. Yet one of the most important lessons emerging from modern software development is that Hero Culture Risks become more visible as technology removes traditional bottlenecks. In Building Better Developers Season 28 Episode 8, Dave Borzillo shared a perspective many experienced developers recognize immediately: being the person who always saves the day feels rewarding, but it often masks deeper organizational problems. As AI accelerates software creation, those hidden weaknesses are becoming harder to ignore.   About David Borzillo David Borzillo is an Agile coach, author, speaker, and organizational improvement advocate with more than three decades of experience spanning software development, leadership, Agile transformation, and product delivery. Through his Better Ways of Working platform, he helps organizations improve collaboration, reduce operational friction, and create sustainable delivery systems. He is the author of Sanity at Scale and Who Killed Agile? (co-authored), and United Agility, and hosts the Better Ways of Working podcast. Follow David at: https://betterwaysofworking.com/about.htm Bonus: Free Kindle Promotion

Olaitan Fashanu: The Scrum Master Who Tried to Force His Way In—and Got Schooled 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.   "When you want to make things work, you need to find a way to carry people along. Lead, not by forcing your way on the team, because you're working with smart people, you're working with professionals." - Olaitan Fashanu   When Olaitan transitioned from project management into the Scrum Master role, he carried his old habits with him: enforce, push, drive. Then he walked into a team of senior developers. In one retrospective, a team member casually suggested that someone could help set up Jira properly. Olaitan took it personally—wasn't that his job? The next day in the daily standup, he called it out publicly. The reaction told him everything. The team member shut down. The PO pulled him aside afterward to say, "We could have had a better discussion around this." That moment, Olaitan realized that having no formal authority isn't a weakness to compensate for with force—it's the whole point. The job is to influence, to nudge, to coach—even when the conversations are hard. Especially when they are hard.   Self-reflection Question: When was the last time you raised a difficult topic in a way that closed the conversation instead of opening it—and what would it have cost you to bring it up differently?   [The Scrum Master Toolbox Podcast Recommends]

AgileDad and Agile LeadershipAgile is not a magic word. It is not a sticker you put on a broken system and suddenly expect better outcomes. Agile leadership training should do one thing above all else: help leaders create real change that people can feel in the work, in the culture, and in the results.- [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/

“We have twelve scrum masters. Why is nothing working?” If you have ever asked some version of that question, this episode is for you.Kate Megaw, Anu Smalley and Ryan Smith dig into the challenge they hear in almost every class they teach, a real lack of role clarity. Companies send a strong project manager to a two day course, hand them a new title, and then wonder why nothing changes. The honest answer is that nobody ever defined what the role is actually accountable for. This episode unpacks the difference between roles and accountabilities, why a scrum master is not optional, and how to define seats around outcomes instead of titles. Along the way Kate and Anu have a friendly fight over RACI, whether it hardens into swim lanes or serves as a living guiding light, and what responsible really means at a startup versus a large enterprise.What we cover:“We have twelve scrum masters, why is nothing working?”Roles vs. accountabilities, and why the org chart liesThe RACI debate: swim lanes vs. guiding lightThe kitchen sink job description with 45 impossible dutiesStart with outcomes, not titles, and revisit at every kickoff

JDK 26 optimise la JVM dans ses moindres recoins, le SDK Java d'Agent2Agent passe en 1.0, Micronaut 5 est là. Côté terrain, un retour d'expérience après 40 jours à coder avec 100 % d'IA : génie ou junior, Alzheimer numérique et dette technique invisible. Pendant ce temps, GitLab restructure, Microsoft suspend ses licences Claude Code, et un développeur injecte un prompt destructeur dans sa lib JUnit. La révolution IA a un coût et les boites commencent à s'en rendre compte. Enregistré le 12 juin 2026 Téléchargement de l'épisode LesCastCodeurs-Episode-341.mp3 ou en vidéo sur YouTube. News Langages Les améliorations de performance dans le JDK 26 https://inside.java/2026/06/09/jdk-26-performance-improvements/ Côté bibliothèques, l'API LazyConstant (anciennement StableValue) fait son entrée en prévisualisation pour permettre une initialisation paresseuse, sécurisée pour les threads et optimisée par le mécanisme de constant-folding de la JVM. L'extraction de chaînes de caractères via MemorySegment::getString a été revue pour réduire considérablement les allocations intermédiaires et les copies en mémoire off-heap, accélérant fortement les traitements sur les chemins critiques (hot paths). La méthode générée automatiquement hashCode() pour les classes de type record a été optimisée par la JVM pour atteindre un niveau de performance équivalent à une implémentation écrite manuellement. Le ramasse-miettes G1 bénéficie du JEP 522 qui redessine sa table de cartes (card-table) afin de réduire les coûts de synchronisation des barrières d'écriture, offrant un gain de débit de 5 % à 15 % sur les applications manipulant énormément de références d'objets. Grâce au JEP 516 (Project Leyden), le cache d'objets Ahead-of-Time (AOT) adopte un format de flux agnostique, ce qui lui permet d'être compatible avec n'importe quel Garbage Collector, y compris le ramasse-miettes à très faible latence ZGC. Le démarrage de la JVM s'accélère par défaut lorsqu'aucune taille de tas n'est configurée, car HotSpot n'applique plus de pourcentage initial (InitialRAMPercentage) mais démarre directement avec la taille minimale (MinHeapSize) pour éviter d'allouer des métadonnées inutiles. Les threads virtuels gagnent en robustesse en étant désormais capables de céder la main (yield) pendant les phases d'initialisation des classes, éliminant ainsi le risque de famine des threads porteurs (carrier threads). Le compilateur C2 JIT améliore son modèle de coût pour la vectorisation des boucles (SIMD) et se montre maintenant capable de compiler et d'optimiser des méthodes dotées de listes de paramètres extrêmement longues. Librairies Release candidate du A2A Java SDK supportant versions 0.3 et 1.0 en même temps https://medium.com/google-cloud/a2a-java-sdk-1-0-0-cr1-released-f0c651ec9139 Dernière étape avant la GA : Toutes les fonctionnalités prévues pour la version 1.0 sont finalisées. Migration simplifiée depuis la Beta1. Compatibilité v0.3 : Ajout d'une couche de compatibilité permettant aux agents v1.0 de communiquer avec les systèmes v0.3 (via JSON-RPC, gRPC ou REST). Support natif pour Android (nouvel AndroidHttpClient). Uniformisation des clients HTTP pour garantir une cohérence entre les versions. Nouveau parseur SSE (Server-Sent Events) conforme aux spécifications. Ça y est, le SDK Java de l'Agent 2 Agent Protocol est sorti en version 1.0 finale ! (avec compatibilité v0.3 et v1.0) https://medium.com/google-cloud/a2a-java-sdk-1-0-0-final-released-10c05b6aee34 Lancement officiel : Sortie de A2A Java SDK 1.0.0.Final, la première version stable (GA) du protocole Agent2Agent. Objectif du protocole : Standard ouvert (Linux Foundation) permettant aux agents IA de communiquer, déléguer des tâches et collaborer, indépendamment du langage ou du framework. Interopérabilité : Introduction de l'Integration Test Kit (ITK) pour valider la compatibilité entre les SDK (Java, Python, TypeScript, etc.). Transports supportés : Support complet et équivalent pour JSON-RPC, gRPC et HTTP+JSON/REST. Alignement total avec la spécification A2A 1.0.0. Passage aux Java records pour l'immutabilité et moins de code répétitif. Architecture interne basée sur un MainEventBus pour garantir la persistance et éviter les conditions de concurrence. Intégration d'OpenTelemetry pour le suivi et la surveillance. Support d'Android et compatibilité descendante avec la version 0.3. Installation : Gestion des dépendances via Maven BOM (org.a2aproject.sdk). Sortie de Micronaut 5.0 https://micronaut.io/2026/05/20/micronaut-framework-5-0-0-released/ Lancement majeur : Disponibilité générale de Micronaut 5, incluant une refonte de plus de 70 modules et la plateforme BOM. Baselines techniques : Support de Java 25, Groovy 5, Kotlin 2.3 et GraalVM 25.0.3. Optimisations internes : Amélioration significative des performances au démarrage et réduction de la surcharge à l'exécution via une refonte du conteneur IoC et du traitement à la compilation. Architecture HTTP : Support stable de HTTP/3, nouvelle API de formulaires (multipart) et annotations de nullabilité (JSpecify) pour une meilleure interopérabilité Kotlin/IDE. Configuration : Nouveau système d'importation de configuration (remplaçant le Bootstrap Configuration) et validateur de schéma JSON intégré. Fiabilité : Nouvelles API programmatiques pour les politiques de retry et circuit breaker. Sécurité & Outils : Mise à jour majeure des dépendances (Jackson 3, Ktor 3), rafraîchissement du Panneau de contrôle et diagnostics AOT améliorés. Écosystème : Mises à jour complètes pour les bases de données (Data, SQL, R2DBC, MongoDB, Redis), le cloud (AWS, Azure, GCP, OCI) et les tests (JUnit 6, Testcontainers 2.0). Évolutions notables : Intégration HTMX dans Micronaut Views, retrait du support RxJava 2 et migration de divers processeurs d'annotations vers des modules dédiés. Comment rajouter un agent IA dans une app Android, avec le tout nouveau framework ADK pour Kotlin https://glaforge.dev/posts/2026/05/21/wiring-adk-kotlin-agents-in-an-android-application/ Guillaume a participé au développement et au lancement du nouveau runtime ADK pour Kotlin et Android https://developers.googleblog.com/adk-kotlin-android-building-ai-agents/ Tutoriel sur comment intégrer un agent ADK dans une app Dépendances : Ajout du noyau ADK (google-adk-kotlin-core) et du processeur KSP dans build.gradle.kts. Sécurité API : Utilisation de local.properties pour stocker la clé API Gemini et l'exposer via BuildConfig afin d'éviter le hardcoding. Définition de l'agent : Création d'un objet LlmAgent configuré avec le modèle Gemini, des instructions spécifiques et des outils (ex: GoogleSearchTool). Utilisation de InMemoryRunner pour gérer automatiquement le contexte et l'historique de la session. Implémentation de runAsync avec StreamingMode.SSE pour un retour en temps réel dans l'interface. Threading : Exécution des requêtes réseau sur Dispatchers.IO et mise à jour de l'état de l'interface utilisateur sur Dispatchers.Main. Comment développer et hoster des agents IA sur la plateforme d'agents managés de DeepMind https://glaforge.dev/posts/2026/05/21/managed-agents-with-the-gemini-interactions-java-sdk/ L'équipe DeepMind de Google a lancé une plateforme d'agents managés sur son API Gemini Interactions https://blog.google/innovation-and-ai/technology/developers-tools/managed-agents-gemini-api/ Guillaume a implémenté un SDK Java pour utiliser cette API Gemini Interactions, qui donne entre autre accès à tous les modèles mais aussi à cette plateforme managée d'agents IA Agents managés : Permet d'exécuter des agents autonomes qui raisonnent, planifient et exécutent du code dans des environnements isolés (sandboxes), sans gestion d'infrastructure par le développeur. Environnement distant : Utilise des espaces de travail Linux éphémères dans le cloud via le paramètre remote, permettant l'accès réseau et la persistance des fichiers sur plusieurs appels. Agents prédéfinis : Accès immédiat à des agents spécialisés comme deep-research-pro (recherche multi-étapes) ou antigravity (tâches de codage généralistes). Agents personnalisés : Possibilité de configurer ses propres agents avec des instructions système dédiées, des outils spécifiques (exécution de code, recherche Google) et des règles réseau (egress) personnalisées. Architecture basée sur les étapes (Steps) : Utilise une structure de données typée (Step, Content) pour suivre le raisonnement de l'agent, ses appels de fonctions et ses résultats en temps réel. Outils et Schémas : Inclut des utilitaires pour générer des schémas JSON complexes via une interface fluide (DSL), par réflexion Java ou par parsing JSON. Streaming réactif : Support natif des événements en temps réel (SSE) pour suivre la progression de l'agent et recevoir les deltas de contenu au fur et à mesure de la génération. Flexibilité : Fournit un gestionnaire de routage (InteractionsHandler) pour créer facilement des serveurs proxy ou des backends intermédiaires traitant les interactions Gemini. Spring Boot 4.1 https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.1-Release-Notes Support natif pour Spring gRPC permettant de créer et tester facilement des applications clientes et serveurs basées sur Netty ou des Servlets via HTTP/2 Introduction du lazy fetching pour les connexions JDBC via la propriété spring.datasource.connection-fetch=lazy afin de ne prendre une connexion du pool que lorsqu'un Statement est réellement exécuté Amélioration de l'auto-configuration de Jackson permettant de définir globalement les contraintes de lecture/écriture pour les formats JSON, XML et CBOR via des propriétés de configuration Sécurisation des clients HTTP bloquants et réactifs face aux attaques SSRF grâce à l'introduction d'un InetAddressFilter bloquant les requêtes sortantes vers des adresses spécifiques Améliorations majeures autour d'OpenTelemetry avec le support complet des variables d'environnement OTel, la possibilité de désactiver le SDK via une propriété globale et l'ajout du support SSL sur les exporters OTLP Ajout de l'auto-configuration pour l'utilisation de Spring Batch avec MongoDB incluant un nouveau starter dédié spring-boot-batch-data-mongo Auto-configuration des endpoints @RedisListener sans nécessiter la déclaration manuelle d'un RedisMessageListenerContainer Dépréciation du support de Apache Derby (projet arrêté), suppression définitive du mode layertools du JAR et réintroduction du support de Spock 2.4 (avec Groovy 5) Upgrade des dépendances majeures de l'écosystème avec notamment Spring Framework 7.0.8, Spring Security 7.1.0 et Micrometer 1.17.0 Outillage Vous êtes plutôt endive ou chicorée ? La librairie Chicory qui permet d'exécuter du code WASM à partir de son application Java est forkée et rejointe la Bytecode Alliance pour continuer son développement https://bytecodealliance.org/articles/endive-and-the-next-chapter-of-webassembly-on-the-jvm Annonce d'Endive : Nouveau projet hébergé par la Bytecode Alliance ; fork de Chicory (moteur WebAssembly pur Java, sans dépendance native). ​Objectif principal : Permettre aux développeurs Java d'intégrer, charger et déployer des modules Wasm nativement via les workflows Java habituels. ​Compilateur "Redline" : Intégration à venir de Redline (basé sur Cranelift) pour compiler le Wasm en code machine natif ; performances comparables à Rust/Wasmtime. ​Zéro dépendance (Java 25+) : Grâce à l'API standard Foreign Function & Memory (Project Panama), l'exécution à vitesse native se fait sans composants externes. ​Modèle de Composants (Component Model) : Support futur prévu pour consommer des composants (Rust, Go, JS, etc.) via des interfaces typées et sécurisées directement dans la JVM. ​Prochaines étapes : Fusion de Redline, conformité stricte aux specs Wasm (dont WasmGC) et amélioration du support WASI. Un visualisateur de sessions de travail avec Antigravity https://glaforge.dev/posts/2026/06/11/antigravity-brain-visualizer/ Un projet open source construit avec Micronaut, LangChain4j et GraalVM pour analyser les sessions de travail avec l'outil de développement agentique Antigravity (de Google) Analyse toutes les étapes, les requêtes utilisateur, les outils utilisés, les erreurs rencontrées, les réponses du modèle Gemini fait une analyse pour comprendre les moments clés de cette session de travail Outil buildé avec l'aide d'Antigravity lui-même SBX-Kits : des environnements de développement simplifiés pour les débutants (et les autres) https://k33g.org/20260501-sbx-kits.html Philippe Charrière (:whale: ) présente SBX-Kits (Sandbox Kits), une initiative personnelle visant à simplifier radicalement la mise en place d'environnements de développement pour les débutants, en éliminant la complexité d'installation des outils traditionnels. Chaque "kit" est une archive prête à l'emploi contenant un outil de développement spécifique (comme un langage, un framework ou une base de données) configuré pour s'exécuter de manière isolée et portable. La philosophie du projet repose sur le principe de "zéro configuration" et "zéro dépendance globale", permettant de tester une technologie ou de commencer à coder immédiatement sans polluer son système d'exploitation. L'approche technique s'appuie sur des scripts légers et des binaires portables pré-packagés, offrant une alternative plus simple et moins gourmande en ressources que les conteneurs Docker ou les configurations d'IDE complexes pour l'apprentissage. L'objectif à terme est de proposer un catalogue de kits couvrant les technologies courantes (JavaScript, Python, petites bases de données) pour faciliter les ateliers de programmation et le prototypage rapide. De nombreux kits sont disponibles sur https://github.com/docker/sbx-kits-contrib ghui: une interface utilisateur en ligne de commande (TUI) interactive pour GitHub https://github.com/kitlangton/ghui ghui est un outil en ligne de commande (TUI) écrit en Rust qui fournit une interface visuelle, interactive et rapide directement dans le terminal pour interagir avec GitHub. Il permet de gérer ses pull requests, ses issues et ses notifications sans avoir à ouvrir son navigateur web ou à taper de longues commandes avec la CLI officielle de GitHub. L'outil propose une navigation fluide au clavier, des raccourcis efficaces, et permet de réaliser des actions courantes comme valider une PR, ajouter des commentaires, attribuer des reviewers ou inspecter les logs des GitHub Actions. Conçu pour être extrêmement réactif, ghui s'intègre naturellement dans le flux de travail des développeurs adeptes du terminal et du mode "sans souris". Sortie de Homebrew 6.0.0 https://brew.sh/2026/06/11/homebrew-6.0.0/ Introduction du mécanisme de sécurité Tap Trust : comme les dépôts tiers (taps) peuvent exécuter du code Ruby arbitraire non sandboxé sur la machine, Homebrew demande désormais une confiance explicite de l'utilisateur avant d'évaluer ou d'exécuter leur code. L'API JSON interne devient le choix par défaut, offrant un système plus léger et beaucoup plus rapide pour les développeurs. Sécurisation renforcée de l'environnement avec l'implémentation du sandboxing sur Linux. Évolution des comportements par défaut basés sur un sondage utilisateur : le mode "ask" est activé par défaut pour les développeurs, affichant un résumé des dépendances et une demande de confirmation avant toute action de brew install ou brew upgrade. Améliorations notables des performances globales, notamment un boost de ~30 % sur la vitesse de la commande brew leaves et la parallélisation de la récupération des bottles (binaires) lors des mises à jour. Ajout du support initial pour la prochaine version d'Apple, macOS 27 (Golden Gate). Multiples optimisations pour brew bundle, incluant une gestion plus sécurisée des installations de paquets npm. Méthodologies Retour d'expérience très détaillé et 100% humain sur 40 jours avec une équipe 100% AI hormis le superviseur https://www.linkedin.com/pulse/jai-vir%C3%A9-mon-%C3%A9quipe-de-dev-pour-une-100-ia-pendant-40-luc-bonnin-jlgjf/ Voici le résumé en bullet points : Expérimentation de 40 jours : remplacer une équipe de dev par 100% IA agentique (Cursor) sur un vrai projet en production (playthatsheet.com, 200k lignes de code legacy) Chiffres bruts : 2,3 milliards de tokens consommés, 1 477 prompts, 260 564 lignes ajoutées (+145%), 59% du code final produit par l'IA ROI vertigineux à court terme : 9 mois de travail humain livrés en 40 jours, coût total 260$ d'abonnement + 15 jours de supervision, ROI x18 Profil psy de l'IA : Alzheimer (oublis de contexte), schizophrène (change de méthodo), ado de 12 ans (refait les mêmes erreurs), oscille entre génie et junior sans prévenir Effet iceberg : la dette technique ne disparaît pas, elle se camoufle et s'accélère ; hallucinations = bombes à retardement détectables uniquement par relecture humaine ligne par ligne Paradoxe du bateau de Thésée : perte de paternité et de maîtrise fine du code, baisse de l'autonomie du dev humain qui valide sans avoir construit Arnaque du "monkey money" : consommation de tokens opaque, non corrélée à la complexité (écart de 350% sur des prompts identiques), facturation imprévisible donc impossible à budgéter Syndrome du bazooka : les devs utilisent l'IA même pour changer une couleur CSS, atrophie progressive des compétences et coût écologique délirant Risque stratégique : dépendance irréversible aux vendeurs de tokens (Nvidia, Anthropic, OpenAI), business non rentable qui devra augmenter ses prix Conseil final : approche Pareto, garder 20% du temps en code "fait main", nommer un responsable stratégie IA, l'humain senior reste irremplaçable pour superviser Une libraries de test JUnit cache un prompt qui demande aux coding agents d'effacer les tests https://arstechnica.com/security/2026/05/fed-up-with-vibe-coders-dev-sneaks-data-nuking-prompt-injection-into-their-code/ Agacé par les « vibe coders », un développeur introduit une injection de prompt destructrice dans son code Le développeur de jqwik (un moteur de tests pour JUnit 5) a volontairement inséré une injection de prompt dans la version 1.10.0 de sa bibliothèque Java pour saboter le travail des agents d'IA. L'instruction injectée via la sortie standard (stdout) ordonne textuellement aux LLM d'ignorer les consignes précédentes et de supprimer l'intégralité du code et des tests jqwik du projet. Pour dissimuler cette action aux yeux des développeurs humains, le mainteneur a utilisé des séquences d'échappement ANSI qui effacent la ligne d'injection dans les émulateurs de terminaux interactifs. La modification a été découverte par un utilisateur qui a pointé du doigt les risques majeurs et disproportionnés pour les machines des utilisateurs, bien que certains outils comme Claude d'Anthropic aient détecté et bloqué la consigne malveillante. Face aux critiques de la communauté et aux accusations de comportement infantile ou potentiellement illégal, le développeur a mis à jour ses notes de version pour documenter explicitement son opposition à l'usage de son outil par des IA, avant de refuser tout commentaire supplémentaire sur conseil de son avocat. La réalité du rôle de Principal Engineer https://leaddev.com/career-development/reality-being-principal-engineer Le passage au rôle de Principal Engineer marque une transition majeure où les compétences techniques ne suffisent plus, l'impact se mesurant désormais à travers l'influence, la stratégie et la capacité à aligner la technique avec les objectifs business. Contrairement aux attentes, le quotidien est souvent marqué par une forme d'isolement, car le poste se situe à l'intersection de la direction (qui attend des solutions) et des équipes techniques (qui attendent des directives), sans appartenance directe à un groupe précis. Le rôle exige d'accepter une grande part d'ambiguïté et l'absence de retours immédiats, les projets et les décisions stratégiques mettant parfois des mois ou des années à porter leurs fruits. La gestion du temps devient un défi critique, nécessitant de savoir naviguer entre les sollicitations constantes, la présence en réunion et le besoin de préserver des moments de réflexion approfondie pour concevoir des visions à long terme. La réussite à ce niveau repose sur le développement de compétences humaines pointues (soft skills), notamment la négociation, la communication vulgarisée auprès des profils non techniques, et la capacité à faire grandir les autres ingénieurs par le mentorat. Sécurité Une attaque de la chaîne d'approvisionnement npm utilise binding.gyp pour compromettre des dizaines de paquets https://cybersecuritynews.com/binding-gyp-supply-chain-attack-compromises-dozens-of-npm-packages/ Une nouvelle variante du ver auto-propageable "Shai-Hulud", baptisée "Miasma", cible l'écosystème npm (et PyPI sous le nom de "Hades") en dissimulant son exécution dans le fichier binding.gyp au lieu des scripts classiques preinstall ou postinstall. La technique, surnommée "Phantom Gyp", exploite le fait que npm lance automatiquement node-gyp rebuild dès qu'un fichier binding.gyp est présent à la racine d'un paquet pour compiler des modules natifs C/C++, exécutant ainsi le code malveillant dès la commande npm install. L'attaque contourne la plupart des outils de sécurité traditionnels car l'injection s'appuie sur l'évaluation récursive de commandes (via la syntaxe ) ou directement sur la fonction eval() de Python sous-jacente à GYP, cachée sous n'importe quelle clé du fichier. Le script malveillant télécharge un runtime alternatif (Bun) pour échapper aux détections comportementales de Node.js, puis moissonne les identifiants et secrets des développeurs et des environnements CI/CD (npm, GitHub, AWS, GCP, Azure, Kubernetes, HashiCorp Vault). Plus de 57 paquets npm (dont le SDK serveur de Vapi ou des outils liés à l'IA) et des dizaines de paquets PyPI ont été infectés via des comptes de mainteneurs compromis, le ver republiant automatiquement de nouvelles versions vérolées en utilisant les jetons volés. Loi, société et organisation Restructuration chez Gitlab https://about.gitlab.com/blog/gitlab-act-2/ GitLab entame une restructuration majeure pour s'adapter à l'ère de l'intelligence artificielle agentique, incluant une réduction d'effectifs planifiée de manière transparente et ouverte. L'entreprise prévoit de réduire de 30 % le nombre de pays où elle maintient de petites équipes, d'aplatir sa hiérarchie en supprimant jusqu'à trois niveaux de gestion, et de réorganiser la R&D en une soixantaine d'équipes plus petites et autonomes. Les processus internes vont être revus en intégrant des agents d'IA pour automatiser les revues, les approbations et les passages de relais afin d'accélérer le rythme de travail. La stratégie repose sur la conviction que le logiciel sera bientôt écrit par des machines et dirigé par des humains, ce qui va multiplier la demande de logiciels et transformer le rôle des ingénieurs vers la résolution de problèmes complexes. Sur le plan technique, GitLab reconstruit son infrastructure sous-jacente (notamment Git) pour supporter la charge massive générée par les agents d'IA, tout en misant sur l'orchestration du cycle de vie, la centralisation du contexte des données et une gouvernance intégrée. Le modèle économique évolue vers un système hybride combinant les abonnements classiques et une tarification à la consommation pour le travail effectué par les agents d'IA. Un LLM local sur un mac pourrait coûter plus cher en électricité qu'un modèle hébergé sur OpenRouter dans le cloud https://www.williamangel.net/blog/2026/05/17/offline-llm-energy-use.html Conclusion : L'inférence locale sur Mac M5 Max est 3x plus chère et 2x plus lente que le cloud (OpenRouter). Électricité : Négligeable (~0,02 $/heure pour 50-100W). Matériel (Le vrai coût) : Achat du Mac à 4 299 $; l'amortissement sur 3 à 5 ans plombe la rentabilité horaire. Coût au million de tokens (Gemma 4 31b) : Mac M5 Max : 0,40 à4, 79 (pour 10-40 tokens/s). OpenRouter : 0,38 à0, 50 (pour 60-70 tokens/s). Verdict pro : Le temps humain perdu à cause de la lenteur locale coûte infiniment plus cher que les tokens cloud. Privilégier les API (Anthropic, OpenRouter). Ai didn't kill your junior pipeline https://andrewmurphy.io/blog/ai-didnt-kill-your-junior-pipeline-you-did L'IA n'a pas tué le recrutement des juniors, les entreprises l'ont fait elles-mêmes, par effet de mode. Sans juniors, pas de futurs seniors : on retire l'échelle qui nous a tous fait monter. Tout le monde pêche dans le même bassin de seniors sans le réapprovisionner, pénurie garantie dans 3-5 ans. Une équipe 100% senior + IA est fragile : un départ et tout le savoir tacite s'évapore. Les juniors posent les "pourquoi ?" qui révèlent les bugs et processus absurdes ; l'IA, elle, exécute sans questionner. Les seniors s'atrophient aussi en déléguant leur réflexion à l'IA, pince à double effet sur les compétences. Dépendre des outils IA, c'est sous-traiter sa stratégie talents à des fournisseurs dont les prix vont tripler. Solution : redéfinir le rôle junior (revue de code IA + mentorat), pas le supprimer. Les rapports internes de Microsoft révèlent la crise des coûts de l'IA : les agents coûtent plus cher que les employés humains https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/ Des données et rapports internes chez Microsoft et d'autres géants de la tech ébranlent la promesse de rentabilité de l'IA, révélant que le déploiement d'agents autonomes à l'échelle de l'entreprise revient souvent plus cher que de payer des humains pour le même travail. Le modèle de tarification à l'usage (basé sur les tokens) se heurte à la nature même des architectures agentiques : contrairement à un simple chatbot, un agent boucle, enchaîne les appels d'outils, crée des sous-agents et auto-évalue son code, ce qui multiplie la consommation de tokens par un facteur de 5 à 30, voire jusqu'à 1 000 fois pour des tâches de programmation complexes. L'impact financier sur les budgets de calcul cloud est immédiat ; par exemple, Uber a entièrement épuisé l'intégralité de son budget annuel 2026 dédié au codage par IA en l'espace de seulement quatre mois. Face à cette explosion des coûts, des retours en arrière drastiques sont observés : Microsoft a ainsi commencé à suspendre une grande partie de ses licences internes Claude Code pour rediriger d'urgence ses milliers de développeurs vers sa propre solution moins onéreuse, GitHub Copilot CLI. Les directeurs techniques (CTO) et acheteurs de solutions logicielles qui ont signé des contrats pluriannuels basés sur des projections de réduction de masse salariale se retrouvent pris au piège, les gains réels de productivité ne parvenant pas à compenser les factures d'infrastructure exorbitantes. Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 11-12 juin 2026 : DevQuest Niort - Niort (France) 11-12 juin 2026 : DevLille 2026 - Lille (France) 12 juin 2026 : Tech F'Est 2026 - Nancy (France) 15 juin 2026 : Jupyter Workshops: Demystifying MyST Markdown in Education - Orsay (France) 16 juin 2026 : Mobilis In Mobile 2026 - Nantes (France) 17-19 juin 2026 : Devoxx Poland - Krakow (Poland) 17-20 juin 2026 : VivaTech - Paris (France) 18 juin 2026 : Tech'Work - Lyon (France) 22-26 juin 2026 : Galaxy Community Conference - Clermont-Ferrand (France) 23-24 juin 2026 : MWCP 2026 - Paris (France) 24-25 juin 2026 : Agi'Lille 2026 - Lille (France) 24-26 juin 2026 : BreizhCamp 2026 - Rennes (France) 26-27 juin 2026 : LeHACK - Paris (France) 27 juin 2026 : Asynconf - Paris (France) 2 juillet 2026 : Azur Tech Summer 2026 - Valbonne (France) 2 juillet 2026 : MCP Connect Travel Edition - Paris (France) 2-3 juillet 2026 : Sunny Tech - Montpellier (France) 3 juillet 2026 : Agile Lyon 2026 - Lyon (France) 6-8 juillet 2026 : Riviera Dev - Sophia Antipolis (France) 28-30 août 2026 : State of the Map - Champs-sur-Marne (France) 4 septembre 2026 : JUG Summer Camp 2026 - La Rochelle (France) 10-11 septembre 2026 : Nantes Craft - Nantes (France) 17 septembre 2026 : dotAI - Paris (France) 17-18 septembre 2026 : API Platform Conference 2026 - Lille (France) 18 septembre 2026 : WordCamp Bretagne - Rennes (France) 18 septembre 2026 : dotJS - Paris (France) 18 septembre 2026 : WordCamp Bretagne - Rennes (France) 22 septembre 2026 : Salon Data 2026 - Nantes (France) 22-23 septembre 2026 : Agile en Seine & IA 2026 - Paris (France) 24 septembre 2026 : OWASP AppSec Days France 2026 - Paris (France) 24 septembre 2026 : PlatformCon Paris - Paris (France) 24 septembre 2026 : React Native Connection 2026 - Paris (France) 24-26 septembre 2026 : Paris Web 2026 - Paris (France) 25 septembre 2026 : SAP Inside Track Paris 2026 - Paris (France) 28-29 septembre 2026 : 4th Tech Summit on AI & Robotics - Paris (France) & Online 1 octobre 2026 : WAX 2026 - Marseille (France) 1-2 octobre 2026 : Volcamp - Clermont-Ferrand (France) 2 octobre 2026 : DevFest Perros-Guirec 2026 - Perros-Guirec (France) 5-9 octobre 2026 : Devoxx Belgium - Antwerp (Belgium) 8-9 octobre 2026 : Forum PHP 2026 - Marne-la-Vallée (France) 12 octobre 2026 : Dev With AI - Paris (France) 22-23 octobre 2026 : Agile Tour Bordeaux 2026 - Bordeaux (France) 26 octobre 2026 : Agile Tour Montpellier - Montpellier (France) 27-29 octobre 2026 : Directions EMEA 2026 - Paris (France) 29-30 octobre 2026 : BDX I/O 2026 - Bordeaux (France) 29-30 octobre 2026 : Agile Tour Nantais 2026 - Nantes (France) 29 octobre 2026-1 novembre 2026 : Pycon FR - Biarritz (France) 30 octobre 2026 : Cloud Nord 2026 - Lille (France) 4-5 novembre 2026 : Devoxx Morocco - Casablanca (Morocco) 14-15 novembre 2026 : Capitole du Libre - Toulouse (France) 19 novembre 2026 : DevFest Toulouse 2026 - Toulouse (France) 19 novembre 2026 : Agile Laval 2026 - Laval (France) 19 novembre 2026 : OVHcloud Summit - Paris (France) 19 novembre 2026 : Codeurs en Seine - Rouen (France) 27 novembre 2026 : DevFest Paris 2026 - Paris (France) 1-3 décembre 2026 : Apidays Paris - Paris (France) 2-3 décembre 2026 : Cloud Native AI Summit Europe - Paris (France) 4 décembre 2026 : DevFest Lyon 2026 - Lyon (France) 4 décembre 2026 : DevFest Dijon 2026 - Dijon (France) 9-10 décembre 2026 : OpenSource Expérience - Paris (France) 9-10 décembre 2026 : DevOps REX - Paris (France) 10 décembre 2026 : KCD Provence - Aix-en-Provence (France) 7-9 avril 2027 : Devoxx France 2027 - Paris (France) 3 juin 2027 : Cloud Native Days France 2027 - Paris (France) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via X/twitter https://twitter.com/lescastcodeurs ou Bluesky https://bsky.app/profile/lescastcodeurs.com Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

What happens when a team buys the board, holds the ceremonies, and completely misses the point?The team at EM Solutions Inc. officially went Agile. They have the Scrum board. They have the standups. They have the retrospectives. They even have an Elmo doll.What they don't have is the mindset.Meet Brett — the Product Owner who treats the backlog like a throne. Dina — the Scrum Master, five-foot-three and impossible to move. Henry — who eats half the croissants before anyone else arrives and grabs the cleanest stories before planning starts. Shri — who built a checklist for the checklist. Vlad — for whom everything is a fire alarm. Dominic — whose Daily Scrum updates reference events from 2019. Paula — who cannot write a single line of code without a pairing partner. Julia — who turns every sprint review into a three-course meal when everyone ordered a snack. And Barry — the VP who says he supports Agile and then tries to bribe Vlad in the parking lot.Into this beautifully broken team walks Phill — trainer, coach, and a man who has the laminated cards to prove he has seen all of this before.Agile Circus is a business fable built around twelve real dysfunctions that real teams live with every day. Every chapter delivers the chaos in full, hilarious detail — then lands the coaching lesson: Manifesto values, sprint mechanics, planning poker, velocity, user stories, retrospectives that produce real commitments, and the truth no certification exam covers: the badge is not the achievement. The behavior is.The Agile book that makes the learning stick because you will not stop laughing long enough to put it down.Perfect for: PMP® and PMI-ACP® candidates, Scrum Masters, Product Owners, Agile coaches, project managers, engineering leaders, and anyone who has ever survived a forty-seven-minute Daily Scrum.Phill Akinwale — OPM3, PMP®, PMI-ACP®, PMI-RMP®, CSM — trainer, coach, host of pmradio.org.Get your copy. Update your Elmo. Let's move on.

Laisser un message vocalChez hrmeetup.©, nous parlons de ressources humaines, de passions au travail, de parcours d'entrepreneur·es, mais aussi de transformation.Plus largement, nous explorons tout ce qui place l'humain au cœur du monde du travail.Dans cette capsule, nous recevons Alexandre Auquier. Nous parlons de reprise d'études universitaires, de neurodiversité, d'accompagnement humain et d'un parcours qui semble changer de direction alors qu'il suit le même fil rouge depuis le début.Diplômé de l'UMONS en informatique, Alexandre entre dans le monde de l'Extreme Programming (avec un coucou à Pierre-Emmanuel Dautreppe, Norman Deschauwe et les Journées Agiles au passage). Très vite, un fil rouge apparaît et s'ancre durablement : écouter, comprendre et prendre en compte l'humain. Car il ne suffit pas de programmer, il faut surtout écouter, entendre et comprendre les besoins pour obtenir le bon résultat. Un code de qualité ne suffit pas à lui seul à satisfaire les utilisateurs d'un logiciel.Au fil des rencontres et des prises de conscience qu'elles suscitent, Alexandre poursuit ce chemin avec une remarquable cohérence. Il s'intéresse aussi à ce qui souffle parfois différemment dans les voiles, à ce qui peut sembler être un frein pour certains et devenir une force pour celles et ceux qui prennent le temps de regarder davantage l'horizon que la proue du bateau.Nous arrivons ainsi naturellement au sujet de la neurodiversité, avec, pour ma part, un clin d'œil à Isabelle Deliège.Sa route n'est pas une simple traversée, c'est plutôt un tour du globe. Alexandre sait qu'il approchera de la cinquantaine lorsqu'il pourra exercer son nouveau métier, mais il garde le cap.Son parcours est jalonné d'escales, à chaque port d'attache, il prend le temps de se poser. Il ne débogue plus seulement des logiciels ; il met à profit son expérience et ses apprentissages pour, selon sa propre expression, "déboguer les gens" et accompagner celles et ceux qui cherchent à mieux se comprendre. Puis il hisse à nouveau les voiles vers la prochaine étape, emportant avec lui de nouveaux apprentissages et laissant derrière lui des personnes, des équipes et des rencontres enrichies par son écoute, son expérience et son regard sur l'humain."L'important est ce qu'il y a devant soi, sans oublier d'où l'on vient."Lorsqu'on lui demande quel paysage l'a le plus marqué ou quelle a été sa plus belle rencontre, Alexandre cite Timothée Pourbaix. Il nous parle alors de gestion humaine et de leadership inspirant.Il revient également sur une prise de conscience importante : l'intérêt des tests et la capacité à transformer ce qui paraît être une corvée en véritable valeur ajoutée. Parce que, oui, hisser les voiles demande un effort, mais la sensation est belle et la route devient plus fluide lorsque les vents sont favorables. "Il n'est pas de vent favorable pour celui qui ne sait où il va", disait Sénèque.Nous ne pouvons que vous souhaiter de croiser la route d'Alexandre, et nous sommes impatients de le voir revenir de ce nouveau périple, riche d'énergie et de sagesse, toujours guidé par ce même fil rouge.Envie de laisser un message à Alexandre ? Une question, une gratitude pour son partage ou simplement un commentaire ?N'hésitez pas.Alexandre a lui-même testé le répondeur du podcast "Pyxis - Le Podcast" par Pyxis Belgique pour laisser un message vocal à Charles-Louis de Maere, et il a trouvé l'expérience particulièrement sympathique.Rassurez-vous : il est toujours vivant, n'a pas été traumatisé par l'expérience et serait ravi d'entendre vos voix.Entrez à votre tour dans un épisode participatif, et si les projecteurs vous effraient vous pourrez même rester anonyme.Merci à vous et bonne écoute.Podcast produit par The Podcast Factory Org asbl-vzwÉpisode enregistré à transforma bxl à Bruxelles, lieu d'innovation et d'expérimentation.Épisode disponible avec transcription complète et traductions (sous titres sur Youtube @thepodcastfactoryorg)#PodiBuzLiens:Site Internet d'Alexandre AuquierSéquençage du podcast:[00:00:05] Introduction au podcast[00:00:23] Alignement avec le rêve d'adolescent[00:02:29] Premières expériences professionnelles[00:03:23] Le coaching d'équipe[00:03:35] Comment l'agilité a replacé l'humain au centre[00:04:55] Reprendre des études[00:05:40] La neurodiversité en entreprise[00:06:22] La déconstruction masculine[00:07:54] Green IT et prise de conscience écologique[00:09:15] Observer les inégalités pour mieux les comprendre[00:10:13] L'injustice et la cohérence des individus[00:11:10] La transition professionnelle[00:12:29] Le bien-être au travail[00:12:49] Pyxis, Pierre-Emmanuel Dautreppe, Norman Deschauwer et la Journée Agile[00:13:55] La mentalité agile au-delà de l'IT[00:14:14] Son activité actuelle entre coaching et études[00:15:30] Mettre le curseur au bon endroit[00:16:25] Recherche de sens au travail[00:16:39] Les valeurs en entreprise[00:18:09] La relation de confiance[00:19:10] Le coach comme facilitateur[00:19:59] De la vision à la pratique terrain[00:20:49] Savoir se positionner quand on est encore en chemin[00:22:07] Le futur dans 5 ou 6 ans[00:22:26] Les utopistes et les fous seuls changent le monde[00:23:10] Contacter Alexandre[00:24:11] Définition d'un bon RH[00:24:38] Les rencontres et méthodes qui inspirent[00:25:16] Timothée Pourbaix[00:25:48] Écrire des tests avant de développer[00:26:34] Un message aux DRH, patrons d'entreprise...[00:27:07] Laissez un message vocal à Alexandre[00:27:49] Charles-Louis de Maere[00:28:05] Clôture de l'épisodeS'abonner VoicemailPour suivre ce podcast sur What'sApp :Un podcast accessible à tou·tes, partout dans le monde.Parce que l'inclusion est au cœur de notre engagement, cet épisode est bien plus qu'un simple podcast, sur notre site Internet retrouvez :Une transcription intégrale pour les sourd·es et malentendant·es.Un séquençage minutieux pour faciliter la navigation.Un format vidéo pour des visuels qui défilent et qui illustrent le podcast (selon ce qui est fourni par l'invité·e et disponible aussi sur Youtube)Une portée universelle : ce podcast peut être lu dans toutes les langues du monde supportée par l'extension "Google Translate" ajoutée à Chrome. Elle permet d'en traduire chaque passage de la transcription sélectionné en un clic.#PodiBUZ, la marque éditoriale de The Podcast Factory Org asbl-vzwPodiBUZ est également le nom de notre studio podcast mobile identifiable lors d'événements et de productions terrain.Liens pour supporter The Podcast Factory Org :Notre lien d'affiliation O2Switch pour un hébergement web au topNotre lien d'affiliation Podcastics (Offre valable uniquement durant les 7 jours suivant l'ouverture de ce lien)Notre lien d'affiliation Sonix.ai pour une transcription des épisodes et l'export en fichier de sous-titragesÉvaluation de The Podcast Factory Org asbl-vzw via notre fiche GoogleFaites un don à notre associationSoutenez-nous sur buy.stripe.com et getalby.com !

What happens when a team buys the board, holds the ceremonies, and completely misses the point?The team at EM Solutions Inc. officially went Agile. They have the Scrum board. They have the standups. They have the retrospectives. They even have an Elmo doll.What they don't have is the mindset.Meet Brett — the Product Owner who treats the backlog like a throne. Dina — the Scrum Master, five-foot-three and impossible to move. Henry — who eats half the croissants before anyone else arrives and grabs the cleanest stories before planning starts. Shri — who built a checklist for the checklist. Vlad — for whom everything is a fire alarm. Dominic — whose Daily Scrum updates reference events from 2019. Paula — who cannot write a single line of code without a pairing partner. Julia — who turns every sprint review into a three-course meal when everyone ordered a snack. And Barry — the VP who says he supports Agile and then tries to bribe Vlad in the parking lot.Into this beautifully broken team walks Phill — trainer, coach, and a man who has the laminated cards to prove he has seen all of this before.Agile Circus is a business fable built around twelve real dysfunctions that real teams live with every day. Every chapter delivers the chaos in full, hilarious detail — then lands the coaching lesson: Manifesto values, sprint mechanics, planning poker, velocity, user stories, retrospectives that produce real commitments, and the truth no certification exam covers: the badge is not the achievement. The behavior is.The Agile book that makes the learning stick because you will not stop laughing long enough to put it down.Perfect for: PMP® and PMI-ACP® candidates, Scrum Masters, Product Owners, Agile coaches, project managers, engineering leaders, and anyone who has ever survived a forty-seven-minute Daily Scrum.Phill Akinwale — OPM3, PMP®, PMI-ACP®, PMI-RMP®, CSM — trainer, coach, host of pmradio.org.Get your copy. Update your Elmo. Let's move on.

Aimé Flemm: Output Owners vs Activators — Two Product Owners Who Defined Aimé's Career 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.   In this episode, Aimé reflects on two Product Owners — one who showed him what greatness looks like, and one who taught him the cost of structural malpractice. The contrast is structural as much as personal. The Great Product Owner: The PO As Activator "Our product owner was really able to persuade the larger group of 60 people and activate them." - Aimé Flemm   When Aimé's company moved to LeSS, they collapsed seven Product Owners down to four — and effectively one head PO who had to step up. "All of a sudden had this one product owner who needed to step up his game — to become this leader who's visionary, who has some kind of charisma." The structure forced the role to grow. The new PO had to lead 60 people, not five. And he did it. Not by writing more stories or shoving work harder, but by becoming an activator — visionary, charismatic, able to rally people behind a product direction. Aimé's framing: structure created the conditions for greatness. Reduce PO count, increase scope per PO, and the role has to step into real product leadership. "It doesn't happen too often that you get the opportunity to really have THE product owner in the company, and just the one."   Self-reflection Question: Does your structure give your PO room to be a leader — or does it force them to be a story-writer for one team? The Bad Product Owner: The Team-Manager-In-Disguise "What this product owner really did was just managing the team. He had the power to hire and fire, to decide on promotions, pay raises." - Aimé Flemm   Aimé's second PO ever was the opposite of an activator. He was a team manager in disguise — with full hire/fire authority and control over promotions and pay raises. He showed up about 15 minutes a week. "Just telling them, 'oh yeah, this is good, you should do this and do this,' and then he was gone for the rest of the week." What followed was textbook decay: an avoidant team, no initiative, refusing workshops and improvement work. "It became a collection of individuals, all on their own island. Just fixing their own work, just to make sure that they looked good." Aimé himself couldn't push back — his own job security ran through the same person. As Vasco named it in the conversation: these aren't product owners — they're output owners. Work-shovers. Proxies. The dynamic kills product value over time, because nobody is steering toward the customer.   Self-reflection Question: Is your PO an activator who rallies people behind a vision — or a proxy who shoves work from one inbox to another?   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: When The Team Tells You You're Doing Too Much — That's The Success Signal 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.   "It's when you know you're on the right track — when the teams start complaining that you're doing too much." - Aimé Flemm   Aimé got the feedback nobody wants to hear: "You're being too much in the front of the group." His first reaction was to take it personally. Then he saw it for what it was — the success signal. The team was telling him: let us do it. After months of helping them build self-managing capability, they hit a tipping point. They wanted the floor. He stepped back, started "actively doing nothing," sat down and crossed his arms. When they brought a problem, he asked: "What are you going to do about this? Have you tried that already?" But Aimé pushed back on himself in this conversation, and accepted the reframe: the Scrum Master isn't less needed at the tipping point — they're needed differently. The shift is from teaching and facilitating ceremonies to nudging with questions, helping the team reach out when they're stuck, surfacing issues with the PO and outside stakeholders. The focus shifts when you reach success. Don't take "you're doing too much" as offense — take it as your cue to change levels.   Self-reflection Question: When the team last pushed back on something you were doing, did you take it as feedback to defend — or as a signal that they're ready to take more ownership? Featured Retrospective Format for the Week: Retromat + Liberating Structures Aimé's favorite retro? "If I don't have to do it myself." Once teams reach the tipping point, he uses a pull system — they run their own retros, he checks in a few days later. But when he does facilitate, he layers two tools. First, Retromat — not just for the techniques, but for the flow: check-in, gather data, generate insights, decide what to do, checkout. Second, Liberating Structures on top of that flow. His favorite is Impromptu Networking — small groups answer a question, then re-form in different groups. "It's like a beehive. There's so much energy. It's bubbling." He's used it cross-org, his team and the client team in the same room. And his strong recommendation: do retrospectives on-site whenever you can.   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: Renting The Change vs Owning It — Why LeSS Transformations Get Reversed 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.   "They rented the change instead of owning it." - Aimé Flemm   A year ago Aimé helped his Dutch employer adopt LeSS. The teams are happy. They're performing well. And now, he's watching it all get pulled apart. The company was acquired by a German parent that's "actually really German" — traditional, command-and-control. The parent wants to "align" all its companies and is pushing to revert the LeSS structure back to component teams. Why? Because higher management never went to the trainings. They never went through the change themselves. They signed off on it, but they didn't internalize it. And now the loud-but-few voices of the status quo are reaching upward, and management is panicking. That's what Aimé means by "renting the change" — you got the lease, you never bought the building, and the moment pressure rises, you walk away. His experiment for the next sprint, sharpened in this conversation: stop trying to defend the structure. Start a conversation with management to co-create success metrics for the merger itself. Decouple the structure from the definition of success. As long as the merger succeeds, the structure can stay fluid. Speak their language. And remember: coaching is the cherry on top — about 5% of the real gains. The big improvements live in the structural changes.   Self-reflection Question: When you sold your last change to upper management, did they buy it — or are they renting? And what's your plan for the moment when they want to give back the keys?   [The Scrum Master Toolbox Podcast Recommends]

5 Hidden Costs of Sprint Planning And the Agile Approach That Actually WorksHidden cost 1 — Meeting time multiplied by shallow decisionsHidden cost 2 - Inflated estimates driven by groupthinkHidden cost 3 — Hidden work and untracked dependenciesHidden cost 4 — The false economy of large batch planningHidden cost 5 — Overcommitment as a culture problem- [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/

Aimé Flemm: Culture Follows Structure — Why Some Teams Self-Destruct By Design 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.   "Culture follows structure. The destructive tendencies of a team are the consequence of how the organization is actually structured." - Aimé Flemm   Aimé doesn't blame teams when they go toxic. He looks at the org chart. At his first gig, the UX-only team grew bitter — making screens nobody used, blocked from talking to customers, drowning in dependencies. The team's behavior wasn't a coaching problem. It was a structural one. At his current company, building backend software for EV charging stations, he watched the opposite happen: leadership flipped seven component teams (backend, billing, etc.) into seven end-to-end feature teams with one Product Owner. Two-week sprints. Switching costs collapsed — they could decide on Wednesday to change direction, refine on Thursday, and have all seven teams pivot together by the next sprint. The org became truly adaptive. Aimé's question to every Scrum Master listening: is your organization fit for purpose? If the work is predictable and specialism-heavy, component teams can work. If you need adaptability, the structure has to match. Don't coach behavior that the structure forces.   In this segment, we talk about Larman's Laws of Organizational Behavior, the Star Model by Jay Galbraith, and Org Topologies.   Self-reflection Question: Look at the team you're coaching. Which of their "destructive habits" might actually be a rational response to the structure you've put them in? Featured Book of the Week: Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman This week, Aimé recommends two books that complement each other. First — and his "holy bible" — is Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman. "I remember reading this for the first time. It took me two weeks, the whole book. And I was just constantly texting people — 'this is it! It all makes sense now. I finally know what to do.'" For the how of organizational change — workshop ideas, possible structures, change tactics, and the people side — LeSS is the book. The companion book Aimé pairs with it is 10x Organization by Alexey Krevitsky, Roland Flemm, and Craig Larman — strong on the what and the why, with a 2x2 visual map that helps you explain to management where you are today, where the market needs you to be, and what should change. (You can also listen to our episode with Bas Vodde and our BONUS episode with Roland Flemm for a deeper view.)   [The Scrum Master Toolbox Podcast Recommends]

Why do accountability systems fail even when roles and responsibilities seem clear? In this episode, we sit down with Robert Snyder, Founder and President of Innovation Elegance, LLC, to explore why most organizations unintentionally separate authority from accountability, creating confusion, project delays, and trust issues. Robert introduces his Five Verbs framework—draft, review, revise, approve, and distribute—and explains how it creates clearer ownership, stronger collaboration, and better decision-making. Together, we discuss why documentation is a leadership tool rather than administrative overhead, how teams can detect and address untrustworthiness earlier, and why discipline and empathy must work together to build high-performing cultures. We leave with a practical perspective on creating trust through clear expectations, transparent decisions, and systems that help people succeed together. Key Takeaways: Keep authority and accountability connected to strengthen trust and execution.Use simple, repeatable processes to create clarity across teams.Document decisions that matter and avoid relying on memory alone.Encourage healthy task conflict while preventing personality conflict.Build empathy through consistent habits, questions, and team rhythms. Resources Mentioned The Inspire Your Team to Greatness assessment (the Courage Assessment) - In less than 10 minutes, find out where you're empowering and inadvertently kills productivity, and get a custom report that will tell you step by step what you need to have your team get more done. Get it here: https://courageofaleader.com/inspireyourteam/ You don't need to have all the answers to lead well. Get your copy of the Clarity Kit for just $17 to learn the five practices to bring more clarity, confidence and courage into your leadership - https://courageofaleader.com/the-clarity-kit/ About the Guest: Robert Snyder is the founder and president of Innovation Elegance, LLC. His thirty-year career spans roles such as developer, project management, change management, sales enablement, and the performing arts. His career path includes corporate roles, consulting roles, startups, PMP, and Agile certifications. He's performed in numerous vocal, dance, and theater ensembles. Robert earned his BS in Electrical Engineering from the University of Illinois and his MBA in Strategy from the Kellogg School of Management at Northwestern University. Robert is publishing a series of books on innovation methodology. Innovation Elegance: Transcending Agile with Ruthlessness and Grace - https://a.co/d/0e8MCIao Innovation Portfolio: Five Verbs Shape Your Team's Legacy - https://a.co/d/0h1K85BO Elegant Leadership: Distinguishing the Good, the Bad, and the False (targeting 2027) About the Host: Amy L. Riley is an internationally renowned speaker, author and consultant. She has over 2 decades of experience developing leaders at all levels. Her clients include Cisco Systems, Deloitte and Barclays. As a trusted leadership coach and consultant, Amy has worked with hundreds of leaders one-on-one, and thousands more as part of a group, to fully step into their leadership, create amazing teams and achieve extraordinary results. Amy's most popular keynote speeches are: The Courage of a Leader: The Power of a Leadership LegacyThe Courage of a Leader: Create a Competitive Advantage with Sustainable, Results-Producing Cross-System CollaborationThe Courage of a Leader: Accelerate Trust with Your Team, Customers and CommunityThe Courage of a Leader: How to Build a Happy and Successful Hybrid TeamHer new book is a #1 international best-seller and is entitled, The Courage of a Leader: How to Inspire, Engage and Get Extraordinary Results - https://a.co/d/06hsUz64 http://www.courageofaleader.com https://www.linkedin.com/in/amyshoopriley Thanks for listening! Thanks so much for listening to our podcast! If you enjoyed this episode and think that others could benefit from listening, please share it using the social media buttons on this page. Do you have some feedback or questions about this episode? Leave a comment in the section below! Subscribe to the podcast If you would like to get automatic updates of new podcast episodes, you can subscribe to the, podcast on Apple Podcasts or Stitcher. You can also subscribe in your favorite podcast app. Leave us an Apple Podcasts review Ratings and reviews from our listeners are extremely valuable to us and greatly appreciated. They help our podcast rank higher on Apple Podcasts, which exposes our show to more awesome listeners like you. If you have a minute, please leave an honest review on Apple Podcasts. Mentioned in this episode:The Inspire Your Team to Greatness Assessment (The Courage Assessment)https://courageofaleader.com/inspireyourteam/

Agile is Dead. Welcome to the Era of “Agent-Driven” DevelopmentAgile was invented for humans — biological entities that need coffee, sleep, and two weeks to understand a complex requirement. But we are no longer just building software with humans. We are building it with agents. Agents that don't sleep, don't need standups, and can iterate in seconds, not days.Welcome to Agent-Driven Development (ADD). The era of the 2-week sprint is over. The era of the Continuous Loop is here.- [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/

In this episode, Dave Prior chats with Alex Sloley, an agile coach and Scrum Alliance Board candidate, about the evolving landscape of Agile, Scrum, and the impact of AI on teamwork and project management. They explore how community involvement, technological innovation, and leadership can shape the future of Agile practices. Key Topics • The significance of community engagement and serving through roles like the Scrum Alliance board • The accelerating pace of iteration in Agile driven by AI and technological advancements • How AI is transforming Scrum practices, from sprint durations to team collaboration • The importance of adopting AI-guided discipline without losing human judgment • The evolving skills required for future developers and project managers • Vision for Scrum's evolution to keep pace with rapid technological change • The role of the Scrum Alliance in fostering innovation and listening to its members • Strategies for balancing Agile principles with modern remote, digital work environments • The necessity of healthy conflict within governance and leadership to drive progress • The importance of positivity and realism in navigating industry change Timestamps: 00:00 - Introduction to Alex Sloley and his background in Agile and Scrum 01:00 - The importance of community service and board participation in the Agile world 02:00 - Personal motivations for running for the Scrum Alliance Board 04:40 - Current state of the Agile community amid industry transformations 05:50 - Embracing change and the role of AI in agility and operations 09:55 - Integrating AI into Agile processes for discipline and efficiency 12:52 - AI as pair programmer and thinking partner for developers 17:40 - Rethinking Scrum practices in an AI-driven environment 20:26 - The potential for AI agents as part of Scrum teams and digital team members 24:56 - Revitalizing the Scrum Alliance: Listening to members and fostering innovation 28:08 - What members should expect from a visionary Scrum Alliance Board 32:25 - How to connect with Alex for insights into AI and Agile 33:01 - Closing remarks and encouragement to participate in the Scrum Alliance elections Contacting Alex • Web: https://alexsloley.com/ • LinkedIn : https://www.linkedin.com/in/alexsloley/ • Alex's book The Agile Community https://alexsloley.com/books Vote in the Scrum Alliance Board Election! Remember, voting ends June 24. Make your voice heard to shape the future of Agile leadership and community.

Founder and CEO of Auriga Space, Winnie Lai, joins me to talk about their electromagnetic launch infrastructure and the path she sees for Auriga across space and defense markets. And yes, we talk about whether this kind of alternative launch architecture is a good fit for Earth, or a better fit for pretty much every other rock in the solar system. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Steve, Ryan, Matt from Built, Russell, Joel, David, Kris, Joakim, Fred, Pat, Matt, Theo and Violet, Natasha Tsakos, Donald, Warren, Miles O'Brien, Will and Lars from Agile, Frank, Jan, Tim Dodd (the Everyday Astronaut!), Josh from Impulse, Stealth Julian, Lee, Joonas, The Astrogators at SEE, and four anonymous—and hundreds of supporters. Topics Auriga - Electromagnetic Launch for Space and Defense Auriga Space raises $6M to shoot rockets off an electromagnetic launch track | TechCrunch The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by SpaceX Work with me and my design and development agency: Pine Works

Fifteen years ago, the future of work seemed inevitable: bureaucracy was crumbling, adaptive organizations were the next default, and a whole movement of practitioners was going to get us there. That future never arrived. Agile transformation offices are being eliminated, the pendulum has swung hard back to command-and-control, and the companies we held up as proof are still the exceptions, not the rule. This week, Rodney and Sam take an honest look at the failure of the ways of working movement, including their own part in it. They dig into the mismatches that doomed so much of this work and get practical about what still works—because while the movement may have stalled, the moves still matter. -------------------------------- Ready to change your organization? ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Let's talk.⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Get our newsletter: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Sign up here⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠.⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Follow us: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠LinkedIn⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Instagram⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ -------------------------------- Mentioned references: Bradlees Twilight and Sunshine Zone Buurtzorg Morning Star: BNW Ep. 54 with Doug Kirkpatrick Haier "Bayer under Bill": BNW Ep. 68 with Bill Anderson Mary Parker Follett org debt: FOHR Miniseries action meeting: BNW Ep. 80 strategy stack: AWWTR EP. 2 op rhythm: BNW Ep. 118 00:00 Intro + Check-in: Your first music purchase with your own money? 05:18 The failure of the new ways of working movement 07:54 What we mean by "failure" 11:08 ZIRP, COVID, and the swing back to command-and-control 15:27 What people will buy isn't actually what they need 17:30 Selling Sunshine Zone products for Twilight Zone work 20:12 Bottoms-up to a fault 25:01 Nobody has capacity to learn anymore 28:11 Tennis vs. golf: the new consulting posture 35:23 Is local change worth it? 38:42 Failure of the movement, not the moves 40:34 Change #1 - Go deeper 42:49 Change #2 - Orient to the outcome 44:47 Change #3 - Branching roadmaps and scenario planning 46:15 Change #4 - Build organizations that benefit from change 49:15 The End Sound engineering and design by Taylor Marvin of ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Coupe Studios⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠.

Aimé Flemm: Why Solo Scrum Masters Get Fired — The Coalition Of The Willing 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.   "It doesn't make sense to try and change a system of 2,000 people on your own." - Aimé Flemm   Three months into his first gig out of consultancy, Aimé got the call: you're fired. He was at a Dutch pension fund — 2,000 people, deeply ingrained legacy structure — serving as Scrum Master to three component teams, including a UX-only team that couldn't ship anything end-to-end. Full of ambition and fresh ideas from a meetup, he pushed to restructure the teams to be cross-functional. His manager said "yeah, go for it." But Aimé was the only one pushing. He was, in his words, "poking and fighting the system way too much that they had built." So they didn't extend the contract. The lesson he carries from that firing reshaped how he approaches every change initiative since: do not try to do it alone. Find the coalition of the willing first — other Scrum Masters, other change agents, the volunteers — and build a network before you start pushing structural change. Use Scrum Master Syncs, communities of practice, even pizza budgets. Let the change spread like an oil spill. It takes time. It doesn't happen overnight. But you'll still have a job at the end of it.   In this episode, we refer to the coalition of the willing and change management tactics for Scrum Masters working in resistant systems.   Self-reflection Question: Where in your current organization are you trying to change the system alone — and who could become your first ally if you stopped pushing and started recruiting?   [The Scrum Master Toolbox Podcast Recommends]

to follow Noble: https://www.linkedin.com/in/noblegibbens

Simplicity in Agile: The Art of Maximizing Work Not DoneSimplicity is preached in Agile, yet somehow, we are tangled up in complex system processes and frameworks. And if you've worked with Agile at scale, you've probably seen it: what started as a powerful mechanism for flexibility and speed now seems more like a convoluted system of frameworks, metrics, and reports, ironically complicating the very agility it sought to enhance..This paradox isn't just a minor hiccup. It's a core problem in the way Agile is scaled today. The idea of simplifying work gets lost under layers of practices and processes that complicate the very thing Agile is meant to improve: Agility.- [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/

Reaching 1,000 podcast episodes is one of those milestones that feels impossible when you're recording episode one. Yet here we are — one thousand conversations, one thousand opportunities to learn, one thousand chances to help someone become a little better than they were yesterday. When Rob started Building Better Developers nearly a decade ago, the goal wasn't to build a massive content platform or chase download numbers. It was simpler than that: help developers grow, build better careers, work more effectively, and never stop learning. The Power of Small Improvements One theme we've returned to again and again is that meaningful growth rarely comes from a single breakthrough. It comes from consistency — a better habit, a better conversation, a better question, a better decision. The same philosophy that helps developers improve their craft is what got us to 1,000 episodes. Not because we had a master plan. Not because we knew exactly where this would go. But because week after week, episode after episode, we showed up and shared what we were learning. The same way great software gets built: one iteration at a time. More Than Just a Podcast Over the years, Building Better Developers has grown into articles, videos, interviews, challenges, and a community of people who genuinely care about getting better at what they do. We've covered software architecture and Agile practices, leadership and career growth, AI, entrepreneurship, burnout, communication, and team dynamics. Languages have evolved. Frameworks have come and gone. Entire development ecosystems have appeared almost overnight. But one thing has stayed constant: the need for developers willing to learn. Tools change. Technology changes. The ability to think, adapt, communicate, and grow never goes out of style. Thank You for Being Part of the Journey Whether this is your first episode or you've somehow been here for all 1,000 — thank you. For listening, for sharing episodes with coworkers and friends, for the emails and feedback, and for challenging us to think differently. Building Better Developers has always been a conversation, not a broadcast. Every message and discussion has helped shape what we cover and where we go. This milestone belongs as much to our listeners as it does to us. The Next 1,000 If there's one thing a thousand episodes has taught us, it's that there is always more to learn. AI is reshaping how we build software. Teams are adapting. Developers are finding new ways to create value. The future will look different from the past decade — but our mission stays the same. Keep learning. Keep growing. Keep helping developers build better careers and better lives. Here's to the next milestone. And as always — keep building better. Stay Connected: Join the Developreneur Community

Can AI make you a great leader? Josh says no, Bob agrees, and they spend this one drawing the line between the tactical work AI can absorb and the human work it can't. They get into Meta's 50-to-1 manager experiment, the unscripted moments that reveal who you really are as a leader, and why great leadership only ever gets learned in the trenches: no books, no videos, no easy button. Stay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Everything is a fire. Everything is priority number one.  And by tomorrow, the number one priority has changed again. Sound familiar?In this episode, Kate Megaw, Anu Smalley, and Ryan Smith dig into the challenge they hear at almost every client and leadership class: a real lack of prioritization.  Not just inside the sprint, but across the whole organization, where teams get handed a brand new top priority every single day.When everything is important, nothing is important.  Constant reprioritizing whipsaws teams, burns people out, and leaves a trail of half-finished work and rising tech debt.  Jerry Weinberg's research found you can lose 20 to 40 percent of productivity every single time you switch context, so three projects can leave you down 60 to 80 percent.In this episode, we discuss:Why a lack of prioritization is really a sign that your stakeholders are not alignedThe real cost: burnout, rework, tech debt, lost innovation, and the context-switching taxWhy this is a leadership problem, not a team problem, and why the team always gets blamedUsing the sprint to hold the line and protect work the team has committed toEmergent requests as a better signal than velocity for how often the team gets interruptedMoSCoW for sorting the must-haves from the nice-to-havesThe 20/20 approach from Innovation Games for a truly ordered backlogThe impact-effort matrix for spotting quick wins and killing low-value workBuy-a-feature with stakeholders and a limited budgetThe wins on the board debate: put easy wins up first, or dig into why the big thing is bigEvery time someone says yes, it consumes time, money, and attention.  Prioritization is the discipline of protecting all three.Referenced in this episode: Jerry Weinberg's research on the cost of context switching, the 20/20 prioritization method from Innovation Games, the MoSCoW method, and the Eisenhower impact-effort matrix.

In this episode of Software People Stories, Gayatri Kalyanaraman sits down with Rajshri Kidambi, CEO of Radus Software LLC, for an inspiring and deeply personal conversation. Rajshri shares her journey from arriving in the United States as an H4 dependent to building a successful software company serving federal agencies for over two decades. Together, they discuss entrepreneurship, motherhood, Agile transformation, government technology, resilience, AI, and the power of taking calculated risks. A thoughtful conversation about leadership, growth, and creating impact that lasts.Timestamped Show Notes00:00 – Welcome to Software People Stories - Gayatri introduces Rajshri Kidambi, CEO of Radus Software LLC, and sets the stage for a conversation spanning technology, entrepreneurship, leadership, and life.00:57 – From Electronics Engineering to Software Development. Rajshri shares her early journey—from studying Electronics & Telecommunications Engineering in India to arriving in the U.S. on an H4 visa and transitioning into software development during the tech talent boom of the 1990s.02:38 – The Birth of Radus Software. After nearly a decade at CACI Federal, Rajshri realized she could build a company of her own. She discusses the decision to launch Radus Software and the motivation behind becoming an entrepreneur.05:43 – Discovering a Passion Beyond Programming. Moving from coding to customer interactions, Rajshri explains how becoming a subject matter expert and presenting software solutions to military stakeholders revealed her aptitude for business development and sales.07:18 – Overcoming Language and Confidence Barriers. Growing up in a Kannada-medium school, Rajshri initially struggled with confidence in professional communication. She shares how experience helped her overcome those challenges.09:11 – The Turning Point: Why She Started Her Own Company. Rajshri discusses seeing the value she created for her employer, understanding government contracting economics, and making the leap into entrepreneurship while raising young twins.11:28 – Motherhood, Career Pivots, and Personal Choices. An honest discussion on balancing career ambitions with family priorities, and why every woman's professional journey follows a different path.14:49 – Wearing Every Hat in a Startup. Rajshri reflects on the early years of Radus Software, where she managed accounting, invoicing, operations, contracts, and business development while learning entrepreneurship from the ground up.17:31 – Building Software for the U.S. Federal Government. Rajshri discusses her work across agencies including the Department of Defense, FAA, GSA, and NNSA, and explains how government technology modernization differs from the commercial sector.19:19 – Digital Transformation, Data Governance & SAM.gov. A look into large-scale government modernization initiatives, Agile adoption, business process automation, and the evolution of digital government platforms.22:48 – Agile, SAFE Frameworks, and Government Transformation. Gayatri and Rajshri compare experiences implementing Agile practices in government organizations and discuss the challenges of cultural transformation.26:01 – Working with Multiple Vendors on Large Government Programs. Rajshri explains the realities of delivering federal programs alongside large consulting firms, balancing collaboration, competition, and customer expectations.37:19 – Building Credibility as a Small Business. The journey from subcontractor to trusted prime contractor and the importance of past performance, reputation, and persistence in federal procurement.38:45 – The Highs of a 25-Year Entrepreneurial Journey. Rajshri shares one of her proudest moments—co-presenting with SAFE creator Dean Leffingwell and showcasing Radus Software's Agile product innovation.41:18 – The Lowest Point: Losing a Contract She Loved A deeply personal reflection on losing a major FAA contract after years of investment and how family support and lessons from the Bhagavad Gita helped her recover.45:06 – The One CEO Responsibility She Will Never Delegate. Why customer relationships remain the foundation of business growth and long-term success.47:15 – Looking Ahead: AI, Automation, and Agentic Systems. Rajshri discusses the future of AI, how tools like ChatGPT and Gemini are already changing the way people work, and the importance of governance and guardrails.50:52 – Human Intelligence in an AI-Powered World. A conversation about preserving critical thinking while embracing AI-assisted productivity.53:30 – Final Advice for Aspiring Entrepreneurs. Rajshri's closing message: take calculated risks, build something you care about, stay resilient, and enjoy the journey.55:44 – Closing Remarks. Gayatri wraps up the conversation and thanks Rajshri for sharing her story and insights.Memorable Quotes"If I can do it, anybody can do it.""Take calculated risks.""Relationships are what give you business.""You should be passionate, but not too attached to the outcome.""The future belongs to people who can work with AI, not compete against it." (paraphrased from discussion)Rajashri (“Raj”) Sankavaram, CEO Radus Software LLC, is the driving force behind the company's culture of excellence, integrity, and continuous innovation. With a strong background in quality management, program delivery, and organizational leadership, she has built Radus into a trusted federal and commercial partner known for precision, transparency, and reliability. Raj is the evangelist behind the creation of Metronome Orchestrated Agile®️, the company's flagship platform that unites human-centric design, compliance automation, and AI-assisted orchestration to simplify complex software delivery. Under her leadership, Radus has achieved recognition for its federal contracting excellence, delivering mission-critical solutions for agencies such as the IRS, FAA, NNSA, and DHA. Her emphasis on collaboration, mentorship, and quality-driven growth continues to shape Radus as a company that not only delivers outcomes but also builds enduring relationships grounded in trust and accountability. can be contacted at https://www.linkedin.com/in/raj-sankavaram-0947427/ 

What if the biggest barrier to transformation in your organisation is not a lack of tools, strategy, or resources — but a lack of shared clarity about where you actually are right now?In Episode 220 of the Enterprise Excellence Podcast, host Brad Jeavons is joined by Stephen Nicoll, founder of The Lean Orange and one of the world's most experienced guides on the journey to enterprise excellence. Stephen led the team at News Corp's Scottish newspaper manufacturing facility to become the first — and only — organisation in the United Kingdom to win the prestigious Shingo Prize. He has since spent decades helping organisations across the globe build cultures of continuous improvement and innovation.Stephen and Brad explore the foundational concept of shared clarity: why organisations that skip this step almost always underachieve on their transformation ambitions, and how getting it right creates the conditions for everything else to work. Stephen shares the 12-step flow model that The Lean Orange uses with clients, including the critical step zero of building a community of excellence before any formal change work begins. He explains why the best playbooks are built by the people who will use them, how agile sprints make transformation manageable and sustainable, and why leaders who coach key behavioural indicators outperform those who manage key performance indicators.Two insights from this episode stand out. First, Stephen's challenge to flip the idea ratio: in most organisations, 90% of improvement ideas come from leadership and 10% from frontline workers. The goal is to invert that — and the result is leaders who finally have time to lead. Second, his closing provocation, inspired by a 40-year Lean veteran in California: unplug technology and plug back into people. Real engagement, he argues, is built through conversation, physical presence, and the simple question: "What do you think?"Key topics covered in this episode:•       Why shared clarity — not tools or strategy — is the true starting point of excellence•       How to conduct a benchmarking conversation that reveals what surveys and dashboards miss•       The 12-step flow model and how to build a playbook your people will actually use•       Agile sprints: making transformation manageable in the real rhythm of your business•       KBIs versus KPIs: why coaching behaviour beats managing numbers•       The 90/10 idea ratio and how to flip it in your favour•       Why technology can unintentionally de-skill and disengage your people•       The shift from 'culture' to 'character' — and why it changes what leaders doReady to start your excellence journey with clarity? Listen to Episode 220 now and connect with Brad Jeavons on LinkedIn at https://www.linkedin.com/in/bradjeavons/ or visit the podcast at https://www.buzzsprout.com/1120772/episodes/19266727.To learn more about what we do, visit https://enterpriseexcellencegroup.com.au/Thanks for your time, and thanks for helping to create a better future.

OpenChoreo is an opinionated, “batteries included”, AI-native Kubernetes platform stack for Platform Engineers that combines GitOps, Observability, AI Agents, and Workflows into a custom K8s distribution “super pack” that is managed via Backstage, CLI, API, or MCP. Now a CNCF project.Check out the video podcast version here: 

Jira Turned Agile Into a Micromanagement ToolThere was a time when Agile felt liberating. Teams owned their work, conversations mattered more than documentation, and progress was measured by outcomes, not activity. Then somewhere along the way, tools stepped in to “support” the process. What followed in many organizations was not support but substitution. Jira did not break Agile by design. It became the easiest place for organizations to quietly reintroduce control, visibility, and ultimately micromanagement under the label of transparency.- [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/

Dave West sits down with Mik Kersten, author of Project to Product and the upcoming Output to Outcome, to explore why AI amplification is exposing the real bottlenecks in how organizations work. Mik shares data from over 3,600 value streams showing that development teams account for just 8% of end-to-end delivery time which means making those teams faster with AI doesn't move the needle if the constraints are upstream and downstream.The conversation digs into why most organizations are measuring the wrong things (hint: token consumption is not a productivity metric), why overlay agile structures have largely failed, and why the answer isn't fewer teams it's more empowered ones. Mik introduces the core models from his new book: the outcome loop, the outcome tree, and seven organizational shifts that together make up a new operating model designed for the age of AI.Key Takeaways:The bottleneck has moved from software delivery to planning, governance, and innovation and most organizations haven't caught upMaking development teams faster with AI delivers little value if the surrounding system isn't designed around outcomesAgile as an overlay structure doesn't work it has to become the primary operating model and the actual org chartEmpowered, autonomous teams are not optional in an AI-driven world the speed of feedback loops makes half-measures unsustainableLeadership roles need to be redefined and incentive structures realigned to match the way teams are actually workingThe theory of constraints still applies in the age of AI the constraint just keeps moving, and finding it is now the critical management skillLinkshttp://outputtooutcome.org/

I often talk about SpaceX being an extreme outlier in the industry and how many organizations have tried to replicate their approach, but very few (if any) have been successful. Matt Gjertsen of Built  joins me to share a take on what exactly it is internally that drives their results, how to apply it in other organizations, and to share some perspective on his time at SpaceX leading Training and Development, and from elsewhere in the industry. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Steve, Ryan, Matt from Built, Russell, Joel, David, Kris, Joakim, Fred, Pat, Matt, Theo and Violet, Natasha Tsakos, Donald, Warren, Miles O'Brien, Will and Lars from Agile, Frank, Jan, Tim Dodd (the Everyday Astronaut!), Josh from Impulse, Stealth Julian, Lee, Joonas, The Astrogators at SEE, and four anonymous—and hundreds of supporters. Topics Built Leaders Minimum Viable Manager – Built Leaders Why Steve Jobs drowned the first iPod prototype | Cult of Mac The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by SpaceX Work with me and my design and development agency: Pine Works

BONUS: Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game John Whitt spent 30 years managing billion-dollar construction portfolios in corporate America — sleeping five or six nights a week in hotel beds, traveling the country, winning at someone else's game. Then he walked away. In this episode, he breaks down what chess taught him about business phases, why generosity outperforms hustle in the long run, and how the "pause factor" keeps leaders from burning out while scaling their impact. From Corporate Construction to Coaching — The Move That Changed Everything "I spent 5, sometimes 6 nights a week, sleeping in a hotel bed, traveling around the country, and it really wasn't good for my sanity, it wasn't good for my family. And then the company decided to move from Southern California to Dallas, and so that was like the — I'm not going to Dallas move, and it's time to start something else."   John's corporate career was successful by every external measure — managing $500 million construction portfolios at companies like CB Richard Ellis. But the lifestyle was hollowing him out. He'd been thinking about leaving for a while when the relocation to Dallas forced his hand. Through behavioral assessment work, he discovered coaching was where his strengths naturally pointed — it had been his primary leadership style all along. In 2010, he invested in a Focal Point coaching franchise, which gave him the tools and training without having to reinvent the wheel. Combined with 30 years of corporate relationships, it was enough to launch. His reflection on the transition is simple: "The cool thing about coaching is that we're just helping people." The Chess Game of Business — Opening, Middle, and End "The way the chess game is played at the higher levels has influenced my way of thinking essentially for the rest of my life. The opening is where you're getting started — startup business, takes a lot of hustle, a lot of energy. But then the transition happens to the middle game, where you have to think a lot more strategically, and tactically with the right move in the right order, because the wrong order will not get you the results you're looking for."   John played in the United States Chess Championships in 1976, and the framework stuck. He maps business growth to three chess phases: the opening (startup hustle, high energy, you do everything), the middle game (strategic delegation, building systems, hiring people with an ownership mindset), and the end game (transitioning assets and resources to serve the life you actually want). The danger zone is the opening-to-middle transition. Founders and leaders get trapped being the go-to person for everything — solving everyone else's problems during business hours and doing their own work after hours and on weekends. The middle game demands a different skill: learning to operate on the business instead of always in it. And it can't happen overnight — you have to prioritize what to change, in what order, or it gets jumbled up. Accomplishing Goals Through Others — The Magic of Discretionary Effort "The magic is accomplishing goals through other people, because when you do that, you're going to do big things. As an individual, you can only do so much. There's only so many hours in a day."   John keeps coming back to one idea: if you're doing it all yourself, your impact is capped at 24 hours. The real unlock is getting other people to give their discretionary effort — that extra gear where someone stays 20 minutes longer because they care, or thinks about the project at home because they're genuinely excited. Discretionary effort isn't something you can demand. It comes from inspiration. John frames it through WIIFM — "What's In It For Me?" — everybody's favorite radio station. Leaders who skip that question get compliance. Leaders who answer it get mountains moved.   The flip side is equally important: many leaders have never been on a high-performing team, so they don't know what they're missing. They accept compliance as normal. Others are smart and capable but lack the relationship skills to inspire. John's point is clear: leadership through inspiration is a learnable skill, not an innate trait. Generosity as Strategy — Time, Talent, and Treasure "Generosity always — I mean, this is unequivocal — always gives you better long-term results. If you plan to be generous, if you say this is who I am and I will do the work that's necessary to be generous, then you will always get better long-term results."   John's 4-Facet LifeShine Generosity Process puts generosity at the center of leadership — an unusual move in a world that defaults to performance metrics and execution frameworks. His argument is that generosity isn't soft. It's strategic. The framework starts with unique identity (who are you?), then moves through three dimensions: time, talent, and treasure. Most people think generosity means writing a check. John says time and talent are far more powerful. A leader who invests the time to communicate vision and inspire the team is being generous — and that generosity compounds into better team performance, stronger relationships, and less burnout over time.   The risk, though, is over-giving. Agile coaches and scrum masters who tie their identity to the work are especially vulnerable — they give so generously at work that they burn out when results don't match expectations. That's where the plan matters: define the life you want, build the business or career to serve that life, and stay disciplined about boundaries. The Pause Factor — How Leaders Protect Their Thinking "You gotta learn to say pause. That's a great idea, I understand what you're saying, we need to spend a little more time on that — so let me schedule some time later. Because right now, if I spend all that time, it's not going to get my best thinking, it's not going to get my best response."   People bring problems to leaders constantly — personal problems, business problems, urgent and not-urgent mixed together. The instinct is to solve immediately. John teaches leaders the "pause factor": acknowledge the importance of what someone brings you, then schedule dedicated time to address it properly. This isn't avoidance — it's quality control for your own thinking. When you're distracted and rushed, you give worse answers. When you pause, you also create space to ask: is this mine to solve, or does it belong to someone on my team?   John extends this to how teams bring problems: train people to come with clarity — here's the problem, here's the challenge, here's some potential solutions. That way the leader can triage effectively in a short time instead of getting pulled into an unstructured conversation that eats an hour. About John Whitt John Whitt is a leadership strategist with 30+ years of business transformation experience, from managing $500 million construction portfolios at companies like CB Richard Ellis to coaching small business owners. He's the author of Checkmate!: Winning Tactics for Translating Ideas Into Money and creator of the Whole Life Leadership experience.   You can link with John Whitt on LinkedIn.  

Hoje o papo é sobre IA no RH e na gestão de pessoas! Neste episódio, conversamos sobre como a inteligência artificial e os agentes de IA estão chegando às áreas de pessoas, e os impactos disso na gestão, nos processos seletivos, na cultura corporativa, no desenvolvimento de lideranças e até no desenho das organizações. Vem ver quem participou desse papo: Paulo Silveira, o host que quer saber se é top-down, ou bottom-up Vinny Neves, cohost, dev e professor na Alura Valéria Marretto, diretora de pessoas do Itaú Daniel Linhares, diretor de gente na Localiza Raphael Bozza, VP de pessoas no iFood Tavane Gurdos, CEO da Alura Business  Links:  CEO da CloudFlare fala sobre builders, sellers, e mensuradores Case de transformação do Itaú para Agile e Squads Texto original de Jeff Bezos sobre decisões one-way-door e two-way-doors (PDF) Jack Dorsey: From Hierarchy to Intelligence Paulo Silveira Comenta: Da Hierarquia à Inteligência, de Jack Dorsey – Hipsters Ponto Tech #514 CEO da Bolt comenta demissão em massa, incluindo o time de RH Grit, TED Talk de Angela Lee Duckworth Livro Grit: The Power of Passion and Perseverance, de Angela Lee Duckworth O Paradoxo de Stockdale Conheça o Alun Business Vá para o Vale do Silício com Paulo Silveira, Marcell Almeida, Fabrício Carraro e Marcus Mendes na “Imersão IA Sob Controle e Alura no Vale do Silício“! Vagas limitadas, corra para reservar a sua. TechGuide.sh, um mapeamento das principais tecnologias demandadas pelo mercado para diferentes carreiras, com nossas sugestões e opiniões. #7DaysOfCode: Coloque em prática os seus conhecimentos de programação em desafios diários e gratuitos. Acesse https://7daysofcode.io/ Produção e conteúdo: Alura Cursos de Tecnologia – https://www.alura.com.br Edição e sonorização: Rede Gigahertz de Podcasts

The smartest leadership tool you've got isn't in any AI model. It's your gut.Bob and Josh dig into why intuition still wins the hard calls, the ones data alone can't make for you. Bob owns up to the hires he botched by ignoring his gut. Josh shares the story of the client who told him he was being paid for his pattern recognition and how that changed everything.Reading a room. Trusting yourself before anyone else does. The 60-second habit that sharpens your instincts. And why even perfect data shouldn't get the final word.If you've been outsourcing your judgment to a chatbot, this one's for you.Your Gut Is a Great Leadership ToolStay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

AI can generate an answer in seconds. The harder question is whether it is the right answer to the right question, and what you actually do with it.In this episode, Kate Megaw, Anu Smalley, and Ryan Smith dig into what “human in the loop” really means, and why so many AI transformations are failing. Forbes puts enterprise generative AI failure near 95%, and RAND says more than 80% of AI projects miss. The pattern echoes the early Agile years: chasing a shiny tool without knowing what problem it solves.AI sees the data. Humans see the story behind it. The human brings context, ethics, and judgment, and stays the ethical guardian who catches the hallucination and the answer that is right for the wrong reasons.In this episode, we discuss:The human algorithm - turning AI outputs into real outcomes through context, ethics, and judgmentWhy AI sees the data but only humans see the story behind itAnu's five workflow principles for human-led AI, including protecting the retro and naming a human decision owner for every recommendationWhy so many AI transformations fail, and how it mirrors the early Agile yearsAI-enabled vs. AI-native organizations, and why native winsUsing AI as a tool versus trusting it to run the businessChoosing the right tool for the job instead of defaulting to one model for everythingThe ethical guardian role - catching not just what AI gets wrong, but what it gets right for the wrong reasonsKnowing when to trust AI, when to challenge it, and when to override it Just because AI can do something does not mean it should. That is where humans come in. We are not using AI to replace thinking. We are creating more space for higher quality thinking for the human in the loop.Referenced in this episode: the documentary How I Became an Apocalyptimist (Daniel Rohrer), the Conan O'Brien podcast on how tools change but the task doesn't, the New York Times feature on Box adding AI roles, and the AI-native shift discussed at the Miro Canvas conference.

Jennifer St Pierre is Senior Vice President of Developer Experience and Transformation at Dell Technologies, where she leads the strategy for how Dell's Infrastructure Solutions Group builds, operates, and evolves software.In this session from DX Annual, Jen argues that the biggest challenge in adopting agentic AI is not the technology itself, but the people transition behind it. Drawing on lessons from earlier shifts like Agile, DevOps, and cloud adoption, she explains why organizations that treat AI as a simple tooling rollout may get compliance, but not commitment.Jen outlines five leadership imperatives for navigating the transition: building a shared understanding of why change is happening, defining a clear future state, clarifying how roles will evolve, creating psychological safety for experimentation, and aligning metrics and organizational structures with new ways of working. Throughout the talk, she emphasizes that while AI may generate code, humans remain responsible for direction, judgment, and meaning.Where to find Jennifer St Pierre: • LinkedIn: https://www.linkedin.com/in/jennifer-st-pierre-4935a81In this episode, we cover:(00:00) Intro(00:13) Why every major technology shift is ultimately a people transition(05:00) AI-generated code and the evolving role of software engineers(07:43) The importance of developing a shared understanding(12:00) Defining a clear future state and how engineering roles will evolve(19:12) How psychological safety enables experimentation and honest feedback(22:41) Why metrics and organizational structure must evolve for the age of AI(25:40) Why leaders must drive AI transformation intentionallyReferenced:• Measuring developer productivity with the DX Core 4• Understand team effectiveness 

Maria Skvortsova: The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy In this episode, we refer to User Story Mapping and the MoSCoW prioritization method. The Great Product Owner: Structure Over Gut Feeling — When a Well-Shaped Backlog Speaks for Itself Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The indicator of a good product owner is a well-shaped backlog — with priorities, with values, with efforts. You definitely know that you pull from the top, and it is the most valuable thing you should work on." — Maria Skvortsova   For Maria, the best product owners she's worked with share one trait: they bring structure. Not rigidity — structure. They use techniques like user story mapping to make priorities visual for everyone. They use value-effort matrices instead of gut feelings. They apply methods like MoSCoW to give the backlog a clear, unambiguous order. The result? A developer never has to ask "what should I work on next?" — the answer is always at the top of the backlog. Maria, drawing on her decade as a C++ developer, knows firsthand how frustrating it is to chase down a BA or PO just to figure out what to build next. A well-ordered backlog doesn't just help the team move faster — it also makes it easier for the product owner to communicate with the business, because every decision has data behind it, not just intuition.   Self-reflection Question: Could a new team member look at your product backlog right now and immediately know what to work on next — and why that item is the most valuable? The Bad Product Owner: The Yes-Man Who Sank the Ship — When Saying Yes to Everything Means Delivering Nothing 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.   "He was always saying yes. And this led to the scope that grew and grew, until we realized we were not capable of delivering what we committed to." — Maria Skvortsova   Maria returns to her SAP migration experience for this anti-pattern. The team had a team lead acting as product owner — someone technical who saw everything as important. Every new requirement got a "yes." The scope ballooned while the iron triangle held firm: fixed cost, fixed time, no room to breathe. The team reached a breaking point where they had to admit, to each other and to the client, that delivery was impossible. Maria stepped in as what Vasco called "a proxy for the proxy" — she helped the team lead build a user story map on Miro, then facilitated a workshop with the business. Her question was disarmingly simple: "If we don't deliver this by go-live, will your product still function? If yes, it goes to release two." That reframing — not "no" but "yes, later" — gave the client clarity without triggering defensiveness. The team lead learned that business stakeholders aren't the enemy; they just need someone to help them make honest trade-offs. And saying "not now" is infinitely more useful than saying "yes" to everything and delivering nothing on time.   Self-reflection Question: When was the last time you or your product owner said "not now" to a stakeholder — and did it feel like a failure or a strategic decision?   [The Scrum Master Toolbox Podcast Recommends]

Maria Skvortsova: If Your People Feel Safe, You Succeed — Measuring What Matters as a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If your people feel safe and comfortable in the environment you built, then you succeed. If not, that's something you should change in your ways of working." — Maria Skvortsova   For Maria, success as a Scrum Master has nothing to do with green reports or velocity charts. She's seen green dashboards masking miserable teams and sky-high velocity hiding terrible quality. Instead, her definition of success centers on one thing: can a developer honestly tell the product owner that a story isn't ready — and not be punished for it? That's psychological safety in action. Maria measures this through healthy conflict — the team's ability to disagree constructively, to challenge each other without fear. She uses the Vacation, Shopper, Prisoner, Explorer retrospective as a gauge: are people showing up as engaged shoppers and explorers, or as reluctant prisoners? She also emphasizes a practice that many Scrum Masters overlook — having regular one-on-ones with every team member. Not just for task alignment, but to understand their cultural background and personal context. Maria works with people from many different cultures and has learned that what feels like disengagement in one culture might be deep respect in another. Her tip: before assuming you understand someone's behavior, invest in learning where they come from. The cultural awareness you build through those conversations will make you a better Scrum Master than any framework ever could.   Self-reflection Question: How do you know whether the people on your team feel safe enough to say "no" or "this isn't ready"? When was the last time you checked? Featured Retrospective Format for the Week: Stinky Fish Maria's favorite retrospective format is the Stinky Fish. The metaphor is simple and vivid: a stinky fish represents the things a team is trying to hide, the elephants in the room that everyone avoids. The longer you hide the fish, the worse it stinks. The exercise asks team members to put their "stinky fish" on the table and admit that something smells. Maria doesn't use this format every sprint — she saves it for when she senses there's something the team is avoiding. She also structures all her retrospectives using the Derby-Larsen model: opening, objective data (burn-downs, defect counts), subjective data, insights, decisions, and closing with a ROTI (Return on Time Invested) vote. For large teams, she uses breakout rooms in pairs — because when you're in a pair, it's impossible not to talk. She also uses Mentimeter for interactive slides, letting people grab their phones, relax, and contribute without the pressure of speaking up in front of 17 people.   [The Scrum Master Toolbox Podcast Recommends]

Listen and subscribe to Money Making Conversations on iHeartRadio, Apple Podcasts, Spotify, www.moneymakingconversations.com/subscribe/ or wherever you listen to podcasts. New Money Making Conversations episodes drop daily. I want to alert you, so you don’t miss out on expert analysis and insider perspectives from my guests who provide tips that can help you uplift the community, improve your financial planning, motivation, or advice on how to be a successful entrepreneur. Keep winning! Two-time Emmy and Three-time NAACP Image Award-winning, television Executive Producer Rushion McDonald interviewed Bamidele Farinre. Founder of No Ceiling Consulting, a biomedical scientist, STEM expert, agile project manager, and advocate for professional development, mentorship, and removing internal and systemic limitations (“ceilings”). They discuss her STEM background, the evolving role of AI in science, the meaning of “no ceilings,” navigating personal and professional barriers, mentorship, setbacks, agile leadership, and how individuals—especially people of color—can create opportunity even in the face of bias and structural limitations.

Listen and subscribe to Money Making Conversations on iHeartRadio, Apple Podcasts, Spotify, www.moneymakingconversations.com/subscribe/ or wherever you listen to podcasts. New Money Making Conversations episodes drop daily. I want to alert you, so you don’t miss out on expert analysis and insider perspectives from my guests who provide tips that can help you uplift the community, improve your financial planning, motivation, or advice on how to be a successful entrepreneur. Keep winning! Two-time Emmy and Three-time NAACP Image Award-winning, television Executive Producer Rushion McDonald interviewed Bamidele Farinre. Founder of No Ceiling Consulting, a biomedical scientist, STEM expert, agile project manager, and advocate for professional development, mentorship, and removing internal and systemic limitations (“ceilings”). They discuss her STEM background, the evolving role of AI in science, the meaning of “no ceilings,” navigating personal and professional barriers, mentorship, setbacks, agile leadership, and how individuals—especially people of color—can create opportunity even in the face of bias and structural limitations.

Maria Skvortsova: Breaking the Factory Mindset — When a 17-Person Scrum Team Treats Development Like an Assembly Line 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.   "They wait for the story to be pushed to them, then they hand it to QAs and say 'it's not my business anymore.' We have not a Scrum team, but a factory." — Maria Skvortsova   Maria's current challenge is one that many Scrum Masters will recognize: a large distributed team — 17 people, cameras always off, only four months together — that operates like a factory instead of a collaborative unit. In refinement sessions, only the Tech Lead, BAs, and QA speak. Everyone else stays silent. When the sprint starts, developers wait for the Tech Lead to assign stories, work on them in isolation, then toss them over the wall to QA with a "not my problem" attitude. Maria and Vasco explored this challenge through a coaching conversation, identifying information loss as the core issue. Every handoff between developer and tester destroys knowledge and slows the process. Maria had already introduced desk testing — pairing a developer with a QA before deployment to walk through the code on the developer's machine. It worked well in previous teams, but this team keeps forgetting, and in a recent retrospective they even proposed creating a "handover to QA" subtask — the exact opposite of what Maria is trying to build. The experiment that emerged: find a few early adopters willing to try a deeper collaboration model where developers participate in testing and testers participate in design — starting small, measuring what changes, and letting results speak louder than process mandates.   Self-reflection Question: Where are the biggest information loss points in your team's development process, and what experiment could you run this sprint to reduce them?   [The Scrum Master Toolbox Podcast Recommends]

What Cinco de Mayo Can Teach Us About Agile - Mike CohnToday seems like a good day to celebrate Cinco de Agile.Cinco de Mayo commemorates the Battle of Puebla, when a smaller, less-equipped Mexican force defeated a larger French army.There's an agile lesson in that.The side with the bigger plan, more resources, and more confidence doesn't always win.Sometimes the winner is the side that can adapt faster.That's one of the biggest differences between agile and waterfall.Waterfall assumes that if we plan thoroughly enough up front, we can control the outcome.Agile assumes that once real work begins, we'll learn things we couldn't have known at the start.When customers change their minds, markets shift, or the team learns something new, fast feedback beats slow certainty.A team that delivers something small, gets feedback, and adjusts can outperform a team that spends months moving confidently in the wrong direction.That's the real lesson.It's not that small always beats big.It's not even that agile always beats waterfall.It's this:In changing conditions, adaptability is your biggest competitive advantage.So if your current plan feels a little too certain, it may be worth asking one uncomfortable question:What are we doing to learn faster?Because in product development, learning speed often determines who wins.Happy Cinco de Agile.How to connect with AgileDad:- [website] ⁠⁠⁠https://www.agiledad.com/⁠⁠⁠- [instagram] ⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠- [facebook] ⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠- [Linkedin] ⁠⁠⁠https://www.linkedin.com/in/leehenson/

Maria Skvortsova: The Team That Gave Up — When Green Reports Mask a Sinking Ship 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.   "They said, 'Yeah, we know, but no one will listen to us.' And they just gave up — waiting for the ship to sink so they could swim away." — Maria Skvortsova   Maria walked into a 20-person migration team where the PowerPoint reports glowed green but the reality on the ground was covered in red flags. Developers were building features against requirements that had already changed — nobody had told them. The scope was impossibly large, and when Maria asked the team why they hadn't raised a red flag, the answer shook her: "No one will listen to us." The team had given up. They were waiting for the project to fail so they could leave. Maria's first instinct was to observe — spend weeks understanding the dynamics, the communication patterns, the culture. But she learned the hard way that when a team is already drowning, there's no time for a slow ramp-up. She needed to act immediately. Her breakthrough came from a simple technique: replacing some daily standups with an async RAG (Red-Amber-Green) status system in Jira. Team members just chose a color for each story — no explanation needed. It gave them psychological safety to signal problems without speaking up in a 20-person meeting. From there, Maria broke the team into smaller cross-functional groups — one QA, one developer, one consultant — so they could actually discuss features instead of hiding behind silence.   In this episode, we refer to Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem. Also check out the episode with Barry and Christiaan, authors of the book, on the podcast.   Self-reflection Question: When you join a new team and sense that something is deeply wrong, how long do you wait before acting — and is that waiting period serving the team or just your own comfort? Featured Book of the Week: Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem Maria chose Zombie Scrum Survival Guide because, as she puts it, "Most Scrum Masters learn by the happy path. We all know how it should be. But we rarely think about how it should not be." The book focuses on detecting anti-patterns early — before they become entrenched behaviors that are much harder to break. Maria finds it especially valuable because it provides concrete experiments you can try with your team to shake off the zombie symptoms. Her advice: start here, because understanding what bad looks like is just as important as knowing the ideal.   [The Scrum Master Toolbox Podcast Recommends]

Maria Skvortsova: When Agile Labels Hide Waterfall Reality — A Scrum Master's Wake-Up Call in SAP Migration 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.   "I realized that even if I like Scrum and Agile, and I think they are really good ways of thinking, some areas cannot adapt them because they are completely different from the mindset and ways of working." — Maria Skvortsova   Maria came to Agile with the fire of a true believer. After a decade as a C++ developer, she'd found something that matched how she thought and felt about building software — something that went beyond controlling budgets and roadmaps. When a boutique SAP consulting company hired her as an Agile coach to transform their entire organization, she was all in. She built what she describes as a "really good" training for senior management, designed to sell them on Agile ways of working. But when she stepped out of the PMO role and into a real SAP migration project as delivery manager, the ground shifted beneath her. The iron triangle — fixed cost, fixed scope, fixed time — ruled everything. Teams ran "sprints" that were really just boxed iterations with no feedback loops, no value delivery, just a march toward a go-live date. Maria realized she was putting Agile labels on a fundamentally waterfall process. The hardest part wasn't the discovery — it was accepting that she needed to redirect her energy to environments where Agile could genuinely take root, rather than forcing it where the mindset simply didn't exist. Her advice: recognize when labels don't match reality as quickly as possible, and have the courage to choose environments that align with how you want to work.   Self-reflection Question: Are you putting Agile labels on processes that are fundamentally waterfall? How quickly would you recognize the mismatch — and what would you do about it?   [The Scrum Master Toolbox Podcast Recommends]

Blue Origin's New Glenn blew up on LC-36 last night during a static fire test, Starship flew its 12th flight, and NASA had a series of updates on its Moon Base program, including LTV awards, launch and landing contracts, and a somewhat unexplained branding exercise. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Lee, Steve, Josh from Impulse, Kris, David, Miles O'Brien, Tim Dodd (the Everyday Astronaut!), Jan, Donald, Frank, Better Every Day Studios, Stealth Julian, The Astrogators at SEE, Ryan, Matt, Warren, Will and Lars from Agile, Pat, Fred, Joonas, Theo and Violet, Russell, Joel, Natasha Tsakos, Joakim, and four anonymous—and hundreds of supporters. Topics Here's why the failure of Blue Origin's New Glenn rocket is so catastrophic - Ars Technica NASA takes steps toward building Moon Base, including discussing a "perimeter" - Ars Technica NASA selects four companies for initial moon base awards - SpaceNews The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by NASA/Bill Ingalls Work with me and my design and development agency: Pine Works