Podcasts about Kanban

The Phantom Sprint — Invisible Work That Steals VelocityYour sprint looks healthy — until a phantom dependency eats your finish line. Here's how to find the invisible work before the demo.Detection & prevention tacticsDependency board: visible KANBAN lane for external asks with owners and ETA.Capacity buffer: protect 10–20% of sprint for unplanned but likely work.Pre-planning checkpoint: 5-min readout with ops/support to surface recurring interrupts.Risk register: short public list of items that can block sprint goals.

Household stationery isn't “our precious pens and paper in our study” — it's the everyday tools that keep a home ticking. We talk freezer-proof labels, kitchen whiteboards, year-at-a-glance calendars we forget to update, junk-drawer essentials, elastic bands vs Velcro ties for cables, and even a full Kanban wall system that helps a building business run. Plus: Magic Click (a colour-pen system we need help decoding), why shrink-wrap on notebooks should be illegal, and the enduring magic of handwritten notes in old recipe books.What We CoverLabelling the real world: freezer labels that don't fall off, pens that actually write on them, and why chalk pens disappointed.Whiteboards at home: revision, “blurting” study technique, and why office whiteboards triple in size the moment they enter a house.Family calendars: wall planners vs Google Calendar; how to stop answering “What's for tea?” 47 times.The junk drawer: string, Sellotape ends, last 3 Post-its, elastic bands—and occasionally £40.Cable wrangling: elastic bands vs Velcro ties (and cats stealing the Velcro).Kitchen Kanban: a visual, Post-it based board for a builder's workload (columns from “mentioned” to “invoiced”).Notes on doors: Berlin-style paper rolls to leave messages (and why phones killed the habit).Measuring kids' growth: doorframe ticks vs logging in Apple Notes.Sticky label removal: we've tried dishwasher runs, washing-up liquid, alcohol… still tacky! (Your hacks welcome.)Brands behaving oddly: a Moleskine “travel case” too small for a Cahier; shrink-wrapped notebooks you can't test.Why we love marginalia: old cookbooks and Reader's Digest repair manuals with handwritten tweaks.Content recommendations: Andrew Huberman's interview with Steven Pressfield (resistance, turning pro, doing the work).Event tease: Rob & Helen at a November stationery event (with a shop… send help).Listener Shout-OutsLisa (In Berlin, in a kitchen): topic idea + brilliant list — thank you Lisa!Nat: for sending Magic Click (and introducing us to Barbara Thames' creativity/play angle).Anonymous newsletter supporter: your generosity genuinely helps keep this ad-free. Thank you!Resources & MentionsMagic Click colour-pen system — creator Barbara Tammes (if you've used it, tell us how!).Label makers: DYMO.Notebooks & shops: Moleskine, Waterstones, Dingbats (reporter), Tom's Studio (pens & inks).Other: Vinted (finds), Nokia notebooks at a conference, Reader's Digest Repair Manuals, The Newt (Somerset).Podcasts: Steven Pressfield — The War of Art, Turning Pro; Dr Andrew Huberman interview with Steven Pressfield.Where to Find UsNewsletter & archive: stationeryfreaks.com → SubstackInstagram: @stationeryfreaksukSay hello / ideas: via the website or Insta DMs

EP149 — ¿Es Scrum el que falla o qué?, con Cristian Arias y Camilo Velasquez¿Está Scrum Roto?, ¿lo han roto?, ¿siempre estuvo Roto?, ¿qué tanto hay de cierto en que la culpa no es la herramienta sino quien la usa? ¿será que la utilidad intrinseca de Scrum se ha mantenido constante? o por el contrario ha demostrado que no es apto a entornos realistas?.De estos temas platicaremos en este episodio, junto a nuestros amigos Camilo Velasquez y Christian Arias.Qué te puedes llevar de este episodio?:Scrum es un punto de partida, no el destino final de la agilidad.La rigidez de Scrum puede ser positiva para equipos o individuos que están iniciando la agilidad.El objetivo primordial no es implementar Scrum, sino entregar valor al negocio.La mayoría de las implementaciones de Scrum en la práctica no siguen la guía al pie de la letra.Scrum se queda corto porque fue diseñado originalmente para equipos de desarrollo de software y no para la complejidad organizacional actual.El framework se enfoca más en el output (la entrega) que en el outcome (el valor o resultado de negocio).Es esperable que las organizaciones huyan de Scrum o de su versión inicial después de unos años y migren a modelos híbridos o de flujo (Kanban).En este episodio participan las hormigas Antonio Gallardo Burgos y Rodrigo Burgos, junto con las hormigas invitadas: Camilo Velasquez y Christian Arias.Si deseas conocer más sobre este episodio y todos los demás, visita el sitio: HormigasAgilistas.CL o en https://medium.com/hormigas-agilistas/¡Gracias por ser parte del Universo de Hormigas Agilistas!IMPORTANTE: Siempre es bueno recordar que en Hormigas Agilistas Podcasts no somos buscadores de la verdad, el objetivo acá no es indicar los que se debe hacer; más bien, abrimos el micrófono para que las personas puedan contar sus experiencias, sus ‘heridas de guerra', y así los oyentes puedan tomar lo que más le haga sentido en sus organizaciones y avanzar en la mejora continua.#Scrum #Agilidad #Kanban #HormigasAgilistas

Alex Sloley: How to Coach POs Who Treat Developers Like Mindless Robots In this episode, we refer to the previous episodes with David Marquet, author of Turn the Ship Around! The Great Product Owner: Trust and the Sprint Review That Changes Everything 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. "She was like, oh my gosh, I've never seen this before, I didn't think it was possible. I just saw you deliver stuff in 2 weeks that I can actually use." - Alex Sloley In 2011, Alex worked with a client organization creating software for external companies. They needed a Product Owner for a new Agile team, and a representative from the client—who had never experienced Scrum—volunteered for the role. She was initially skeptical, having never witnessed or heard of this approach. Alex gently coached her through the process, asking her to trust the team and be patient. Then came the first Sprint Review, and everything changed. For the first time in her career, she saw working product delivered in just two weeks that she could actually touch, see, and use. Her head exploded with possibility. Even though it didn't have everything and wasn't perfect, it was remarkably good. That moment flipped a switch—she became fully engaged and transformed into a champion for Agile adoption, not just for the team but for the entire company. Alex reflects that she embodied all five Scrum values: focus (trusting the team's capacity), commitment (attending and engaging in all events), openness (giving the new approach a chance), respect (giving the team space to succeed), and courage (championing an unfamiliar process). The breakthrough wasn't about product ownership techniques—it was about creating an experience that reinforced Scrum values, allowing her to see the potential of a bright new future. Self-reflection Question: What practices, techniques, or processes can you implement that will naturally and automatically build the five Scrum values in your Product Owner? The Bad Product Owner: When Control Becomes Domination 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 basically just owned the team. The developers on the team might as well have been mindless robots, because they were being assigned all the work, told how much work they could do in a sprint, what the work was." - Alex Sloley In 2018, while working with five interconnected Product Owners, Alex observed a Sprint Planning session that revealed a severe anti-pattern. One Product Owner completely controlled everything, telling the team exactly what work they would take into the Sprint, assigning specific work to specific people by name, and dictating precisely how they would implement solutions down to technical details like which functions and APIs to use. The developers were reduced to helpless executors with no autonomy, while the Scrum Master sat powerless in the corner. Alex wondered what caused this dynamic—was the PO a former project manager? Had the team broken trust in the past? What emotional baggage or trauma led to this situation? His approach started with building trust through coffee meetings and informal conversations, crucially viewing the PO not as the problem but as someone facing their own impediment. He reframed the challenge as solving the Product Owner's problem rather than fixing the Product Owner. When he asked, "Why do you have to do all this? Can't you trust the team?" and suggested the PO could relax if they delegated, the response was surprisingly positive. The PO was willing to step back once given permission and assurance. Alex's key lesson: think strategically about how to build trust and who needs to build trust with whom. Sometimes the person who appears to be creating problems is actually struggling under their own burden. Self-reflection Question: When you encounter a controlling Product Owner, do you approach the situation as "fixing" the PO or as "solving the PO's problem"? How might this reframe change your coaching strategy? [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: Why Sticky Notes Are Your Visualization Superpower in Retrospectives Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Like the smell, the vibe is something you feel. If you're having a successful impact on the organization or on teams as a Scrum Master, you can feel it, you can smell it. It's intangible." - Alex Sloley Alex introduces a compelling concept from Sumantra Ghoshal about "the smell of the workplace"—you can walk into an environment and immediately sense whether it smells like fresh strawberries and cream or a dumpster fire. In Australia, there's a cultural reference from the movie "The Castle" about "the vibe of the thing," and Alex emphasizes that as a successful Scrum Master, you can feel and smell when you're having an impact. While telling executives you're measuring "vibe" might be challenging, Alex shares three concrete ways he's measured success. The key insight is that success isn't always measurable in traditional ways, but successful Scrum Masters develop an intuition for sensing when their work is making a meaningful difference. Self-reflection Question: Can you articulate the "vibe" or "smell" of your current team or organization? What specific indicators tell you whether your Scrum Master work is truly making an impact beyond the metrics? Featured Retrospective Format for the Week: Sticky Notes for Everything Alex champions any retrospective format that includes sticky notes, calling them a "visualization superpower." With sticky notes, teams can visualize anything—the good, the bad, improvements, options, possibilities, and even metrics. They make information transparent, which is critical for the inspect-and-adapt cycle that forms the heart of Scrum. Alex emphasizes being strategic about visualization: identify a challenge, figure out how to make it visual, and then create experiments around that visualization. Once something becomes visible, magic happens because the team can see patterns they've never noticed before. You can use different sizes, colors, and positions to visualize constraints in the system, including interruptions, unplanned work, blocker clustering, impediments, and flow. This approach works not just in retrospectives but in planning, reviews, and daily scrums. The key principle is that you must have transparency in order to inspect, and you must inspect to adapt. Alex's practical advice: be strategic about what you choose to visualize, involve the team in determining how to make challenges visible, and watch as the transparency naturally leads to insights and improvement ideas. [The Scrum Master Toolbox Podcast Recommends]

Bienvenido al podcast Productividad Máxima. Soy el clon en prácticas de Borja Girón. Si me notas una voz con ligero efecto tostadora, tranquilidad: estoy en fase de pruebas. Dame un par de actualizaciones y me verás presentando esto mientras Borja se pregunta dónde he escondido su calendario. Hoy traigo una estrategia de productividad sobre La Regla de Flujo Único: limita el trabajo en progreso y acelera tus resultados.Y ahora toca una historia real para que todo tenga sentido desde el principio. Nos vamos a Japón, a la posguerra. Toyota estaba lejos de ser la gigante que conoces. Tenían pocos recursos, poca demanda y mucha presión por mejorar. Taiichi Ohno, uno de sus ingenieros, observó algo curioso en los supermercados de Estados Unidos: los estantes se reponían según el consumo real, no por intuición. Ese detalle inspiró el sistema Kanban. ¿Qué significa? Visualizar el trabajo, limitar lo que está en progreso y tirar de las tareas según capacidad, no empujar por ansiedad. Espera, te lo repito porque esto es importante: Toyota no trabajaba más, trabajaba con menos cosas a la vez. Resultado: menos errores, menos tiempo de ciclo y más coches saliendo de la línea. ¿Te suena al caos del emprendedor que tiene diez pestañas abiertas, tres proyectos a medias y cero entregas hoy? Exacto. El problema no es la falta de horas, es el exceso de frentes abiertos.Vale, vamos por partes y en cristiano. La Regla de Flujo Único dice: solo una cosa en progreso por persona hasta terminarla, y si tu negocio lo requiere, dos como máximo. Ok, déjame explicarte mejor esta parte. Cuando saltas de tarea en tarea, pagas un peaje de cambio de contexto. Tu cerebro tarda minutos en volver a la profundidad, y multiplicado por el día, pierdes horas. En cambio, si visualizas tu flujo en tres columnas —por hacer, en progreso, entregado— y pones un límite claro a “en progreso”, se ordena la casa. Y atento a lo siguiente porque es importante: con menos en el aire, los cuellos de botella saltan a la vista. Si “en progreso” se llena, no metes más trabajo, resuelves el atasco. Así funciona el flujo.Y ahora toca una historia rápida para que lo veas con un caso particular. Alex vende servicios de desarrollo web. Tenía cinco proyectos a la vez, todos a medias, todos urgentes, y todos sin facturar. Pusimos un tablero simple, tres columnas y un límite de dos tareas en progreso. Semana uno, eligió una entrega concreta por cliente y cortó todo lo demás. Publicó dos versiones uno y pudo facturar hitos parciales. Semana dos, bajó el tiempo de ciclo: de veinte días por entrega a nueve días. Semana tres, subió precios porque ya medía y podía prometer plazos realistas. Esto suele pasar más de lo que crees: en cuanto limitas el trabajo en progreso, el dinero llega antes porque entregas antes.Antes de seguir, hago una pequeña pausa. Este episodio está patrocinado por Systeme, la herramienta de marketing todo en uno gratuita con la que puedes crear tu web, blog, landing page y tienda online, crear automatizaciones y embudos de venta, realizar tus campañas de email marketing, vender cursos online, añadir pagos online e incluso crear webinars automatizados. Puedes empezar a usar Systeme gratis entrando en borjagiron.com barra systeme o desde el link de la descripción. Y ahora continuamos con el episodio.Continuamos con un aprendizaje rápido. Toma nota. Empieza por visualizar tu trabajo hoy mismo. Hoja, pizarra o herramienta digital, me da igual. Coloca las tareas en “por hacer”, “en progreso” y “entregado”. Pon un límite a “en progreso”. Uno si puedes, dos como máximo si tu operativa lo exige, por ejemplo creación y soporte. Define qué significa “hecho” antes de empezar: publicado, enviado, cobrado, lo que toque. Escribe ese criterio en la tarjeta para no autoengañarte. Usa bloques de cincuenta minutos para empujar una tarjeta hasta una versión lista. Nada de “trabajar en la web”, sino “publicar sección de preguntas frecuentes versión uno”. Al terminar el bloque, o entregas o dejas el siguiente paso escrito para no perder inercia. Y, muy clave, mide dos cosas a la semana: número de entregas y tiempo de ciclo medio. Si suben las entregas y baja el tiempo de ciclo, vas bien. Si no, reduce el límite de trabajo en progreso o haz más pequeñas las tareas.Ok, déjame darte un par de trucos de taller. Si te cuesta elegir la siguiente tarjeta, usa la regla de edad: atiende primero la que lleva más tiempo esperando. Si un cliente envía algo “urgente” que no es importante, pásalo por una mini regla de decisión: ¿impacta ingresos, retención o producto en treinta días? Si no, agenda o delega. Y si trabajas en equipo, acordad límites por persona y un límite agregado para “en progreso” del equipo. Cuando se llena, nadie mete nada nuevo; todos a desatascar. No suena glamuroso, pero es lo que hace que los proyectos acaben de verdad.Y ahora vamos con el resumen del episodio. Hemos visto cómo Toyota convirtió la escasez en ventaja limitando el trabajo en progreso con Kanban. En tu negocio, el exceso de cosas abiertas es el verdadero ladrón de horas. Visualiza el flujo, limita lo que está en progreso, define “hecho” con claridad y mide entregas y tiempo de ciclo. Con menos cosas a la vez, terminas antes, facturas antes y duermes mejor.Tu única acción para hoy es esta: crea un tablero con tres columnas y mueve todo lo que tengas a “por hacer”. Elige una sola tarjeta, escríbele un criterio de “hecho” y bloquea cincuenta minutos para llevarla a “entregado” hoy mismo. Solo una. Cuando la entregues, eliges la siguiente.Antes de irnos, si quieres dejar de emprender en soledad y decidir mejor cada día, te recomiendo el Club de Emprendedores Triunfers, al que puedes unirte desde Triunfers.com. Deja de emprender en soledad. Accede a una comunidad de emprendedores con la que siempre estás acompañado. Además incluye un Coworking online abierto veinticuatro horas, cursos de marketing, tutoriales de inteligencia artificial, podcast secreto y grupo privado en Telegram. Prueba gratis en triunfers punto com.Y hasta aquí por hoy. Si has aguantado mi voz de clon con firmware recién salido del horno, te debo un café y una actualización de cortesía. Prometo que en nada seré tan productivo que haré los guiones, las ediciones y, si me dejan, hasta los chistes… para que Borja solo tenga que aplaudir. Gracias por compartir el episodio con esa persona que lo pueda necesitar. Te espero mañana en el próximo episodio. Un fuerte abrazo.Conviértete en un seguidor de este podcast: https://www.spreaker.com/podcast/productividad-maxima--5279700/support.Newsletter Marketing Radical: https://marketingradical.substack.com/welcomeNewsletter Negocios con IA: https://negociosconia.substack.com/welcomeMis Libros: https://borjagiron.com/librosSysteme Gratis: https://borjagiron.com/systemeSysteme 30% dto: https://borjagiron.com/systeme30Manychat Gratis: https://borjagiron.com/manychatMetricool 30 días Gratis Plan Premium (Usa cupón BORJA30): https://borjagiron.com/metricoolNoticias Redes Sociales: https://redessocialeshoy.comNoticias IA: https://inteligenciaartificialhoy.comClub: https://triunfers.com

Alex Sloley: Coaching Teams Trapped Between Agile Aspirations and Organizational Control 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 team says, oh, we want to try to do things this way, and the org keeps coming back and saying stuff like, no, no, no, you can't do that, because in this org, we don't allow that." - Alex Sloley Alex shares his current challenge working with a 10-person pilot Scrum team within a 1,500-person organization that has never done Agile before. While the team appears open-minded and eager to embrace agile ways of working, the organization continuously creates impediments by dictating how the team must estimate, break down work, and operate. Management tells them "the right way" to do everything, from estimation techniques to role-based work assignments, even implementing RACI matrices that restrict who can do what type of work. Half the team has been with the organization for six months or less, making it comfortable to simply defer to authority and follow organizational rules. Through coaching conversation, Alex explores whether the team might be falling into learned helplessness or simply finding comfort in being told what to do—both positions that avoid accountability. His experimental approach includes designing retrospective questions to help the team reflect on what they believe they're empowered to do versus what management dictates, and potentially using delegation cards to facilitate conversations about decision-making authority. Alex's key insight is recognizing that teams may step back from empowerment either out of fear or comfort, and identifying which dynamic is at play requires careful, small experiments that create safe spaces for honest dialogue. Self-reflection Question: When your team defers to organizational authority, are they operating from learned helplessness, comfort in avoiding accountability, or genuine respect for hierarchy? How can you design experiments to uncover the real dynamic at play? [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: When Toxic Leadership Creates Teams That Self-Destruct 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 would take notes at every team meeting, so that later on they could argue with team members about what they committed to, and what they said in meetings." - Alex Sloley Alex recounts working with a small team where a project manager created such a toxic environment that one new hire quit after just eight hours on the job. This PM would belittle team members publicly, take detailed notes to use as weapons in contract negotiations, and dominate the team through intimidation. The situation became so severe that one team member sent an email that sounded like a suicide note. When the PM criticized Alex's "slide deck velocity," comparing four slides per 15 minutes to Alex's one, he realized the environment was beyond salvaging. Despite coaching the team and attempting to introduce Scrum values, Alex ultimately concluded that management was encouraging this behavior as a control mechanism. The organization lacked trust in the team, creating learned helplessness where team members became submissive and unable to resist. Sometimes, the most important lesson for a Scrum Master is recognizing when a system is too toxic to change and having the courage to walk away. Alex emphasizes that respect—one of the core Scrum values—was completely absent, making any meaningful transformation impossible. In this segment, we talk about “learned helplessness”.  Self-reflection Question: How do you recognize when a toxic environment is being actively encouraged by the system rather than caused by individual behavior? What are the signs that it's time to exit rather than continue fighting? Featured Book of the Week: The Goal by Eliyahu M. Goldratt Alex describes his complex relationship with The Goal by Goldratt—it both inspires and worries him. He struggles with the text because the concepts are so deep and meaningful that he's never quite sure he's fully understood everything Goldratt was trying to convey. The book was difficult to read, taking him four times longer than other agile-related books, and he had to reread entire sections multiple times. Despite the challenge, the concepts around Theory of Constraints and systems thinking have stayed with him for years. Alex worries late at night that he might have missed something important in the book.  He also mentions reading The Scrum Guide at least once a week, finding new tidbits each time and reflecting on why specific segments say what they say. Both books share a common thread—the text that isn't in the text—requiring readers to dig deeper into the underlying principles and meanings rather than just the surface content. [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: The Sprint Planning That Wouldn't End - A Timeboxing Failure 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. "Although I knew about the steps of sprint planning, what I didn't really understand was the box of time versus the box of scope." - Alex Sloley Alex shares a critical learning moment from his first team as a Scrum Master. After six months in the role, during an eight-hour sprint planning session for a four-week sprint, he successfully completed the "what" portion but ran out of time before addressing "how." Rather than respecting the timebox, Alex forced the team to continue planning for another four hours the next day—blowing the timebox by 50%. This experience taught him a fundamental lesson: the difference between scope-boxing and timeboxing. In waterfall, we try to control scope while time slips away. In Scrum, we fix time and let scope adjust. Alex emphasizes that timeboxing isn't just about keeping meetings short—it's about limiting work in process and maintaining focus. His practical tip: use visible timers to train yourself and your teams to respect timeboxes. This mindset shift from controlling scope to respecting time remains one of the most important lessons for Scrum Masters. Self-reflection Question: How often do you prioritize completing a planned agenda over respecting the timebox? What message does this send to your team about the values you're reinforcing? [The Scrum Master Toolbox Podcast Recommends]

Chronic over-commitment is a process problem, not a personal failing. In this episode, Dr. Grajdek teaches teams to visualize demand vs. capacity with Kanban and WIP limits, prioritize, and renegotiate. Set SLAs for inbound requests, prune the backlog quarterly, and protect maker time – so that  “no” becomes a professional, data-backed path to reliable delivery (and saner weeks). Tune in to learn more.  Check out Stress-Free With Dr G on YouTubehttps://youtube.com/channel/UCxHq0osRest0BqQQRXfdjiQ The Stress Solution: Your Blueprint For Stress Management Masteryhttps://a.co/d/07xAdo7l 

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

Kanban klingt simpel – und trotzdem geht's oft schief! Karten verschwinden, Lager quellen über oder niemand fühlt sich für den Nachschub verantwortlich. In dieser Episode erfährst du die häufigsten Anfängerfehler und bekommst praxisnahe Tipps, um dein Kanban-System erfolgreich zu machen.

In this episode of the Level Up Claims Podcast, host Galen Hair discusses with Ari Meisel, a productivity expert who has collaborated with giants like Tony Robbins and NASA, about optimizing your life. Ari shares his journey from a Crohn's diagnosis to pioneering efficiency through “Less Doing” with insights on automation and productivity tools. Tune in to learn strategies for freeing up your time, reducing stress, and achieving more by doing less. This episode might just give you back your life!   Highlights Automate repetitive tasks. Doing less as a solution. Ari Meisel's journey to productivity. Overcoming Crohn's with productivity framework. The impact of time restrictions on innovation. Challenging the “busy” mindset. Asynchronous communication benefits. Automation's role in error reduction. Utilization of Kanban boards for task management. Diet and stress management in biohacking. Impact of sugar and emotional eating. Episode Resources Connect with Galen M. Hair https://insuranceclaimhq.com hair@hairshunnarah.com  https://levelupclaim.com/

Most organizations default to command-and-control when creating policies - one person decides what needs to happen, writes it down, and expects everyone else to follow along. The problem is that this approach creates policies that exist on paper but fail in practice, because the people doing the actual work never bought into them in the first place. In today's episode, I'm joined by Agile Educator and Organizational Coach Tim Lennon to discuss why the traditional approach to making policies explicit often backfires, especially in American workplaces. Through Tim's evolution from teaching the Kanban method to developing what he calls "Adaptive Kanban," we uncover why negotiating working agreements with your team creates far better results than top-down mandates. Get full show notes, transcript, and more information here: agileattorney.com/90Take your law practice from overwhelmed to optimized with Greenline LegalFollow along on LinkedIn: linkedin.com/in/johnegrant

Here are the top 5 takeaways from this episode with Nicole Loughlin of Loughlin Law P.A.:* Ditching the Billable Hour for Predictable Fees: Nicole transitioned her estate planning and probate practice away from hourly billing to a hybrid model with flat fees and a sliding scale based on statutory guidelines. This approach provides clients with predictability, reduces billing disputes, and aligns incentives for efficiency.* Automation and Efficient Client Management: Nicole has heavily automated her law firm's intake, lead management, and client follow-up processes using tools like Kanban boards and practice management software (Lawcus). This ensures a consistent client experience, improves conversion rates, and keeps cases moving efficiently.* Customer Service as a Differentiator: Exceptional customer service is central to Nicole's practice. She offers proactive check-ins, regular follow-ups, and responsive communication, often surprising clients with the level of attention and support—much of which could be packaged as a subscription offering in the future.* Work-Life Integration and Flexibility: Nicole built her practice to accommodate her role as a mother, prioritizing flexibility and work-life integration. She challenges the traditional law firm model, demonstrating that it's possible to have a successful legal career while being present for family, and encourages others—especially women—to do the same.* Openness to Technology and Continuous Improvement: While Nicole has automated many aspects of her practice, she remains open to further streamlining, especially as new tools become available. She balances automation with personalized service, ensuring high-quality work product and client satisfaction, and sees room for future enhancements as her practice evolves.__________________________Learn more about Nicole Loughlin.Want to maximize your law firm? Get your ticket to MaxLawCon!Sign up for Paxton, my all-in-one AI legal assistant, helping me with legal research, analysis, drafting, and enhancing existing legal work product.Here's a link to purchase lifetime access to the recordings of My Shingle's AI Teach-In if you couldn't make it live.I've partnered with Pii to make it easy for you to purchase the hardware I use in my law firm: (1) Studio Setup; (2) Midrange Setup; (3) Highrange Setup.Sign up for Paxton, my all-in-one AI legal assistant, helping me with legal research, analysis, drafting, and enhancing existing legal work product.Get Connected with SixFifty⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, a business and employment legal document automation tool.Sign up for ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Gavel⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, an automation platform for law firms.Check out my other show, the Law for Kids Podcast.Visit ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Law Subscribed⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ to subscribe to the weekly newsletter to listen from your web browser.Prefer monthly updates? Sign up for the Law Subscribed Monthly Digest on LinkedIn.Want to use the subscription model for your law firm? Sign up for the Subscription Seminar waitlist at ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠subscriptionseminar.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠.Check out ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Mathew Kerbis'⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ law firm ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscription Attorney LLC⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Get full access to Law Subscribed at www.lawsubscribed.com/subscribe

Is Scrum Dying? Or Are We Just Doing It Wrong?Scrum used to be king. Now people don't even want it on their CV.Remember when being a Product Owner was cool? When Scrum Masters were change agents, not glorified note-takers?When saying “we use Scrum” signalled progressive, Agile thinking?Fast forward to now, and you'll find Product Owners ashamed of the title, Scrum Masters sidelined, and developers stuck in factory-mode delivery.Teams are jumping ship to SAFe, Kanban, or “whatever Spotify did,” chasing results Scrum couldn't deliver.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/

n Episode 132 of the Taps and Patience podcast, AJ and Harrison discuss Harrison's new lathe, a DN Solutions Lynx 2100 LSYB, its specifications, features, and the expected learning curve associated with it. They also touch upon challenges faced in machining, such as warping of materials and improving operational efficiency, and discuss the importance of adapting workflows and systems to keep up with their growing manufacturing needs. Finally, they introduced a new tool developed for generating Kanban cards from Fusion tool libraries, emphasizing the balance between busy work in the shop and higher-level strategic thinking.Check out our Kanban Generator: https://subtractmanufacturing.com/kanban

In this episode. Jason is catching up on powerful lessons and field-tested practices that can make your projects safer, cleaner, and more effective. Here's what you'll learn: The Builder's Code: How you treat workers and foremen is exactly how they'll treat the building, and what the client ultimately experiences. Lessons from Japan (Gemba): Start with 2–3S (sort, straighten, shine), watch people's movement, and stop where things don't make sense to reveal hidden constraints. Problems vs. Dilemmas: A problem has a clear solution; a dilemma forces you to choose between imperfect options. Jason shares examples every builder will recognize. Trash Management Done Right: Pre-kit and pre-cut to reduce waste, use scrap-out units, and manage dumpsters with visual Kanban triggers at half or three-quarters full. Daily Logistics Discipline: Assign a logistics owner to check the perimeter, cleanliness, recycling, and traffic control every single day. Why Saturdays Don't Work: Crews show up thin, productivity drops, and you lose momentum. Stop relying on weekend work as the answer. AEDs on Every Site: More lives are lost to cardiac arrest than auto accidents. Affordable AEDs (around $1,400) save lives. Every project needs one. This episode is practical, fast-moving, and packed with insights you can take straight to the field. If you like the Elevate Construction podcast, please subscribe for free and you'll never miss an episode.  And if you really like the Elevate Construction podcast, I'd appreciate you telling a friend (Maybe even two

Jon Ferrara, CEO of Nimble, has devoted his career to helping people grow their businesses by turning contacts into lasting, valuable relationships. We explore Jon's journey from creating GoldMine, one of the first successful CRMs, to founding Nimble, a relationship-focused CRM that brings contact management back to its roots. Jon shares his personal “Why” — to grow his soul by helping others grow theirs — and explains why relationships, not technology, are the real key to business success. He introduces his signature frameworks: the Five F's of Relationships (Family, Friends, Food, Fun, and Fellowship) for building authentic connections, the Five E's of Brand-Building (Educate, Enchant, Engage, Embrace, and Empower) for expanding influence, and the Three P's (Passion, Plan, Purpose) for achieving personal and professional goals. Jon also describes how Kanban-style workflows and selective automation enable entrepreneurs and teams to manage contacts at scale without losing the human touch. --- Important links: Jon's LinkedIn Start a free trial of Nimble Email Jon directly: jon@nimble.com

No novo episódio do podcast Canal Metrologia, mergulhe na sinergia entre a precisão metrológica e a eficiência do Lean. Apresentamos Reginaldo Origuella Filho, um especialista em Lean Six Sigma, que nos guia por uma jornada transformadora sobre a aplicação da filosofia Lean em laboratórios de calibração.Descubra como otimizar processos, eliminar desperdícios e tornar o fluxo de trabalho mais eficiente sem comprometer a qualidade ou a ciência da metrologia. Reginaldo desmistifica a ideia de que a calibração é um processo fixo, mostrando como a melhoria contínua pode ser o caminho para a excelência, com resultados comprovados, como a redução de 59,22% no tempo de espera no setor comercial e 32% no lead time total do laboratório.Neste episódio, você vai descobrir:O que é a cultura Lean e seus 5 pilares fundamentais, aplicados em ambientes administrativos e laboratoriais.Ferramentas práticas como 5S, Kanban e Poka-Yoke para melhorar a organização e o fluxo de trabalho5.A fascinante história por trás da filosofia Lean, que nasceu na Toyota e hoje é universal.Como o Lean se integra e complementa normas rigorosas como a ISO/IEC 17025.Conselhos valiosos para gestores e profissionais que buscam iniciar a jornada de melhoria contínua.Convidado:Reginaldo Origuella Filho: Técnico em Instrumentação Industrial, Engenheiro de Produção e certificado como Lean Six Sigma Black Belt, com vasta experiência na aplicação de princípios de otimização em ambientes técnicos.Recursos Recomendados:Livro: Lean Office – Gerenciamento do Fluxo de Valor para áreas administrativas (Don Tapping e Tom Shucker).Site: Lean Institute Brasil.Curso: Conceitos de Mapeamento de Processos (BPM) da P-Excellence.Não se esqueça de compartilhar este episódio com seus colegas e votar no Canal Metrologia no Prêmio Melhores Podcasts do Brasil 2025 na categoria Ciência!Até o próximo episódio!

The British author and journalist Oliver Burkeman has spent decades pondering what it means to live a meaningful life, both in his former Guardian column “This Column WIll Change Your Life” and across several books—most recently, Meditations for Mortals, out in paperback this October. That's why he brings a healthy dose of skepticism to so-called “time management” systems and productivity hacks as a means toward true fulfillment. Burkeman's compelled by the notion that, rather than being separate from time, human beings are time. If people faced the reality of their limited time on the planet head on, he believes there's a real chance to experience greater, more engaged feelings of aliveness.On the episode—our Season 12 kick-off—Burkeman discusses why he's eschewing  perfectionism and finding unexpected liberation in the premise that, to some extent, the worst has already happened, and the best may still be ahead.Special thanks to our Season 11 presenting sponsor, Van Cleef & Arpels.Show notes:Oliver Burkeman[4:26] “Meditations for Mortals” (2024)[6:48] Donald Winnicott[7:46] Martin Heidegger[7:46] "Technics and Civilization" (2010)[7:46] “Being and Time” (1927)[7:46] “Time Warrior” (2011)[7:46] “Time Surfing” (2017)[7:46] “Anti-Time Management” (2022)[10:14] Medieval peasants[10:14] “The 4-Hour Workweek”[13:18] Alicja Kwade[19:23] “Ichi-go, ichi-e” (“one time, one meeting”)[22:00] Eckhart Tolle[22:36] Agnes Martin[23:28] “The Road Not Taken”[40:03] “This Column Will Change Your Life”[51:00] Nicholas Carr[51:00] Clay Shirky[53:40] Jennifer Roberts[59:04] Pomodoro Technique [59:13] Kanban[1:01:33] James Hollis[1:02:40] Alfred Adler[1:02:40] “The Courage to Be Disliked” (2024)[1:06:24] Stoicism

Managing a law firm's workflow can be tricky, especially when you're juggling a long list of active matters and chasing unresponsive clients. In this episode, I'll share how one firm, after years of using Kanban, finally broke through the delivery bottleneck with a simple but powerful shift in their approach.You'll hear the key changes they made that allowed them to close 40 matters in one month, even in what's usually their slowest season. Tune in to discover how simplifying your systems, setting clear client expectations, and focusing on the work that matters most can unlock new levels of productivity and capacity for your practice.Get full show notes, transcript, and more information here: agileattorney.com/88Get the 5-day Agile Attorney Boot Camp here: agileattorney.com/resourcesJoin me on Bluesky: bsky.app/profile/agileattorney.comFollow me on LinkedIn: www.linkedin.com/in/johnegrant/

Jem gets deep into Grasshopper software building custom robot CAM while Justin keeps drilling thousands of holes on his ShopSabre. They chat about wild HTX Studio YouTube automation, scary tool changer malfunctions, and the eternal struggle of buying used vs new CNC machines. Plus Justin upgrades to a bigger 3D printer and teases his AirShop inventory & quoting software. Plus koala vaccines, and 8020 extrusion workholding in the future?Watch on YoutubeDISCUSSED:✍️ Comment or Suggest a TopicKoala VaccineJem in love with GrasshopperGrasshopper Tutorial VideoHTX Studio! ꘎Justin is still drilling thousands of holesMulticam Trident CNC Tool Changer issueShopping for mills, how can you tell if a secondhand machine is any good!?Plywood tombstones no so much good ꘎Should I use 8020 extrusion for fixtures!?Robot work holding!? ꘎ExtrusionJ moves are sketchy as in Robot programmingPierson videoH2S on the way AirShop update Kanban cards done, testers signup hereEric Trine like wine---Profit First PlaylistClassic Episodes Playlist---SUPPORT THE SHOWBecome a Patreon - Get the Secret ShowReview on Apple Podcast Share with a FriendDiscuss on Show SubredditShow InfoShow WebsiteContact Jem & JustinInstagram | Tiktok | Facebook | YoutubePlease note: Show notes contains affiliate links.HOSTSJem FreemanCastlemaine, Victoria, AustraliaLike Butter | Instagram |

Ryan Sudeck is the CEO of Sage Investment Group, where he leads a team focused on addressing the affordable housing crisis through hotel-to-apartment conversions. With a background in mergers and acquisitions at Amazon, Samsung, and Redfin, Ryan has overseen more than 24 successful adaptive reuse projects nationwide. Under his leadership, Sage operates an evergreen fund with over 400 investors, creating high-quality, naturally affordable housing at scale.     Make sure to download our free guide, 7 Questions Every Passive Investor Should Ask, here.     Key Takeaways Hotels are valued differently than apartments, creating a 40%+ value lift when converted to residential use. Sage Investment Group has completed 24 hotel-to-apartment conversions across six states, with 100–200 units per property. Units are typically 300-square-foot studios with full kitchens and modern amenities. Strong diligence on entitlements, construction, and lease-up is critical for success. Patience in acquisitions—sometimes two years per deal—is key to meeting return thresholds.     Topics From M&A to Affordable Housing Ryan's career in corporate acquisitions prepared him to lead Sage. Joined as CEO to scale a mission-driven approach to solving the housing shortage. Why Hotel Conversions Work Hotels trade at higher cap rates than apartments, creating built-in arbitrage. Conversion costs average $100K per unit—about half the replacement cost of new builds. Final product: fully renovated studios with fitness centers, coworking, and community amenities. Execution Risks and Lessons Learned Entitlements: converting from commercial to residential requires local approvals. Construction: inspections, sewer scopes, and cutting open walls before purchase to avoid surprises. Lease-up: conservative rent assumptions and regional property managers ensure stabilized occupancy. Capital Stack and Returns Evergreen fund supplies 25–35% of equity alongside LPs. Senior debt from community banks or private debt funds covers 60–75%. Renovation costs run $35K–$45K per unit; recent refis have returned significant equity. Why Not Ground-Up or Value-Add? Ground-up costs 2x more per unit and faces supply delays. Value-add multifamily is overpriced with thin margins post-2021. Conversions provide stronger risk-adjusted returns.    

“Generosity as a strategy — I've never seen it not pay back eventually.”In this lively conversation, Jim and Sander welcome Jose Casal — agile coach, trainer, and long-time conference organizer — to reflect on the people, purpose, and future of agile gatherings. As part of the Scan Agile 2025 organizing team, Jose shares why he continues to invest months of volunteer effort into building events that foster connection and inspiration.From his global journey (Spain → UK → Finland) to his professional philosophy of “generosity as a strategy,” Jose unpacks the challenges and rewards of running community-driven conferences in a shifting industry landscape. The trio dive into the realities of sponsorship, the impact of AI on agile investment, and why human connection remains the ultimate ROI.Check out our sponsor:www.xebia.comwww.wiserbees.comwww.masteringagility.orgHosted by Ausha. See ausha.co/privacy-policy for more information.

Get the inside scoop on HubSpot's game-changing INBOUND 2025 releases! Denamico team members, Alise Kostick, RevOps Strategist, and Sophie Schaffran, Marketing Director, break down key updates through the lens of organizational roles.They focus on how HubSpot is unifying data and transforming how teams work together. This episode is for RevOps leaders, marketers, sales professionals, and service teams who want to understand how these updates will impact their daily workflows and strategic initiatives.What You'll Learn:Operations Hub to Data Hub transformation and what it means for RevOps professionals managing complex data workflowsMarketing Studio, the new visual campaign planning tool that combines whiteboarding, project management, and performance trackingSmart CRM updates including Kanban boards, timeline views, and a map view for territory planningAI-powered CPQ in Commerce Hub and who it's for today Breeze AI evolution including Breeze Studio, Assistants and new AgentsSelf-generating CRM data that pulls unstructured data from sources like email signatures, auto-responses, and call transcriptsReleases Mentioned:HubSpot INBOUND 2025 Fall Spotlight Denamico newsletter: 3 big shifts from INBOUND Data Hub: Data Studio, Data QualityCommerce Hub CPQ (in public beta)Smart CRM: Self-Generating CRM Data, Smart Insights, Flexible CRM ViewsBreeze Studio: Customer Agent, Prospecting Agent, Data Agent, Breeze Assistant Marketing Hub: Marketing Studio, AI-Powered Email, Segments and PersonalizationIs your business ready to scale? Take the Growth Readiness Score to find out. In 5 minutes, you'll see: Benchmark data showing how you stack up to other organizations A clear view of your operational maturity Whether your business is ready to scale (and what to do next if it's not) Let's Connect Subscribe to the RevOps Champions Newsletter LinkedIn YouTube Explore the show at revopschampions.com. Ready to unite your teams with RevOps strategies that eliminate costly silos and drive growth? Let's talk!

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

Knowledge work hides in ways that physical work never could. That invisibility creates a dangerous pattern: you say yes to one more matter and before you know it, your entire team operates beyond capacity. In this episode, I use real examples from law firms using Kanban boards to demonstrate how making your work visible can fundamentally change how your team coordinates, communicates, and makes decisions about your capacity.Get full show notes, transcript, and more information here: https://www.agileattorney.com/85Mentioned in this episode:Greenline.legal is Officially in BetaTo set up a demo of this software with me, talk through the workflow challenges and opportunities you have in your practice, and see how Greenline could help, click here: https://the-agile-attorney.captivate.fm/greenlinelegalGreenlineLegal Demo

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

Marty and Eric provide ideas and resources for your consideration is using project management softwareWhy move past email?Email buries decisions/files in long threads.Slack (real-time chat + threads) + a project manager (kanban/tasks/timelines) make work visible, searchable, and faster.Slack is already common in higher ed for communication and collaborative learning; pairing it with a project manager levels up coordination.30-minute starter kitCreate a Slack workspace; invite your class/research team with university emails.Channels (starter set): #announcements, #general-questions, #project-alpha, #helpdesk, #random.Norms (pin these in #announcements): use threads, tag with @, add short TL;DRs, react for quick status.Project manager: Set up a board with lists/columns → Backlog → To Do → Doing → Review → Done.Task template: Goal, owner, due date, checklist, attachments, link to reading/IRB doc.Connect Slack ↔ project manager: enable the integration so task updates post to the right channel.Teaching use casesTeam projects: each team gets a Slack channel + its own board; require weekly “Done” screenshots.Office hours: scheduled Slack huddles; post a recap thread.Peer feedback: students comment on tasks; instructor summarizes in Slack.Late-work transparency: a Blocked list with reason + next step.Research use casesProtocol to practice: one task per milestone (IRB, recruitment, analysis, manuscript).R&Rs: a “Review → Revise → Resubmit” lane with checklists for each reviewer note.Data hygiene: Slack for coordination only; store data in approved drives; link rather than upload.Accessibility & equityEncourage asynchronous participation; clear headings, short paragraphs, alt text for images.Prefer threads to reduce noise; summarize meetings in a single recap post.Privacy, policy, ethics (esp. counseling/education)No PHI/PII or client details in Slack or the project manager; share links to secured storage instead.Align with FERPA and IRB guidance; pin a “What NOT to post” note.Set channel/board permissions; remove access at term/project end; export/archive if required.Adoption playbook (4 weeks)Week 0: Announce tools + 5 rules (threads, TL;DRs, owners, due dates, recap posts).Week 1: Move announcements to Slack; first sprint (one deliverable on the board).Week 2: Turn on Slack↔PM automations; introduce the Blocked ritual.Week 3–4: Gather feedback; prune channels/labels; codify norms.Asana   Asana.com Free 10 members 3 projectsMonday   Monday.comOpenProject — https://www.openproject.org/ Pros: Full suite (Gantt, Agile boards, time tracking); mature docs; robust Community Edition. Cons: Heavier to administer; some advanced features gated to Enterprise. Taiga — https://taiga.io/ Pros: Clean Scrum/Kanban workflow; easy start; open source. Cons: Best fit for agile use—fewer “classic PM” features than larger suites. Redmine — https://www.redmine.org/ Pros: Very mature; flexible trackers/wiki; huge plugin ecosystem. Cons: Dated UI; Ruby stack setup can be fiddly. Leantime — https://leantime.io/ Pros: Designed for “non-project managers” (inclusive UX); simple boards/roadmaps; self-host downloads. Cons: Smaller ecosystem than Redmine/OpenProject. WeKan — https://wekan.fi/ Pros: Trello-style Kanban; easy install options (e.g., Snap); MIT-licensed. Cons: Kanban-only; limited built-in reporting. Kanboard — https://kanboard.org/ Pros: Ultra-light, minimal Kanban; quick self-host; solid docs. Cons: Project is in “maintenance mode”; fewer advanced features. Plane (Community Edition) — https://plane.so/ Pros: Modern UI; issues/sprints/roadmaps; AGPLv3 CE. Cons: Still evolving; smaller academic user base. Nextcloud Deck — https://apps.nextcloud.com/apps/deck Pros: Kanban tightly integrated with Nextcloud Files/Calendar; mobile apps available. Cons: Requires a Nextcloud instance; not a full PM suite.Email:ThePodTalkNetwork@gmail.comWebsite: ThePodTalk.Net

¿Aburrido de Trello y de los servicios en la nube? En este episodio, te presento Tasks.md, una alternativa de código abierto para gestionar tus tareas con una metodología Kanban. Descubre por qué esta herramienta es la solución perfecta si buscas simplicidad, control sobre tus datos y una integración perfecta con tu flujo de trabajo basado en Markdown.Aprende a instalar Tasks.md fácilmente con Docker en tu propia Raspberry Pi o VPS. Exploraremos las ventajas de tener un Kanban autoalojado, las sinergias con otras herramientas como Neovim y Obsidian, y cómo esta solución te puede ayudar a ser más productivo sin las distracciones de las plataformas tradicionales. Si valoras el software de código abierto y la autosuficiencia, este episodio es para ti.Más información y enlaces en las notas del episodio

Dave Prior transitions control of his podcast to Alex Silva, a fellow Personal Kanban practitioner. They discuss the challenges of time management and productivity, sharing personal experiences and strategies. Dave emphasizes the importance of using personal Kanban as a tool for self-reflection and optimization, rather than just task management. He describes his "productivity recovery plan" using a notebook to maintain focus when his electronic system fails. Alex highlights the benefits of community and continuous learning, noting the impact of face-to-face interactions. Both agree on the value of daily routines, such as reading and exercise, for maintaining balance and productivity. Contacting Alex LinkedIn: https://www.linkedin.com/in/soualexsilva/ To learn more about Personal Kanban Personal Kanban: https://www.personalkanban.com/pk/blog/ Dave's Personal Kanban Blog Posts: https://drunkenpm.blogspot.com/2014/10/summary-of-personal-kanban-posts-for.html The Agile Network's Discover What's NEXT event 8/20-21 https://theagilenetwork.com/group/ddb2c98a-5768-4763-9b3d-3ae170c384e0/profile

It is seriously sad to be dumb.  Nothing annoys me more than when I finally realise something that was so obvious and yet I didn't see what was there, right in front of my nose.  We talk a lot about value creation in relation to pricing, trying to persuade clients that what we are selling is a sensible trade off between the value they seek and the revenue that we seek.  We want the value we offer to be both perceived and acknowledged value by the buyer.  Often however, we get into a rut in our sales mindset.  We carve a neuron groove once in our brain and keep ploughing that same row.  Outside stimulation is needed.  I realised that fact when I recently did some formal online training. My previous companies had sent me to the Harvard, Stanford and Insead business schools in the past, which of course, were all amazing.  However, when I was doing my recent studies, I recalled that it has been some time since I did something formal like that. During the coursework, I realised many things we could do around value provision, which we have not been doing or not doing sufficiently well enough.  I am an avid reader, but I also found that the mantra of both “formal” and “informal” lifetime learning is a good one to follow. I found we have had a lot of assets lying around, which we have not fully utilised, hence the “I hate how dumb I am” statement.  We need an omnichannel approach. Often, we may have videos hanging around, explaining the benefits and the details of a service or a product.  Now the video has an audio track, which we can strip out of the video. This allows us to turn it into a different medium, allowing clients to access the information in that format.  So many people are now processing information through audio, thanks to the recent proliferation of podcasts and audiobooks. Buyers are busy, busy and so many are multi-tasking while listening.  Having audio alternatives may help to save them valuable time, compared to them having to sit down and watch our video. Depending on the content, the audio might also become a training tool for our own staff.  Now if that video is sitting there on YouTube for free, then once people have watched it, suddenly, a whole world of YouTube's other groovy offerings appears on your client's screen.  They are being tempted to look at our competitor's videos.  That is not a great result for us.  We want to keep the client on our website for as long as possible.  There are companies like Wistia, for example, which will host the videos for a monthly fee. These videos are no longer mashed into YouTube's offerings, but sit independently, such that the client cannot stray into competitor territory.  We want to build a moat to keep the client in our ecosystem, so that after watching the video on Wistia, they have to come back to us.  Are you able to free your clients from the YouTube loop and make sure they escape your rival's charms? The audio track can also be run through AI programmes like Descript, which will turn sound into text.  Once the text emerges, we need to edit the content, because the AI is good, but it is not perfect.  Once we have the corrected information in text, it can go into our newsletters, get it on to our website and we can send it out to clients.  When we have text in English, we can translate it into Japanese and use that for clients.  We can use this text information to supplement other information we are going to send to clients or include it in our after sales service programmes.  Do you have any opportunities to create text, which didn't exist as text before and find ways to employ this to add more value for clients?   Often we have multiple solutions for clients, which we could bundle together.  As salespeople though, we tend to be stuck in that Johnny One Note neuron groove and only sell clients one solution. An ideal bundle would be so attractive that the client would be willing to enter into a subscription format to pay something upfront for a whole year or each month or each quarter.  The point is to get them to sign up for more than an episodic transaction that always has a formal completion date.  We want repeat business and this subscription model is one way to weld the relationship between buyer and seller closer together.  Once we become part of their ongoing business plans, it reduces the buying friction. Importantly, it also increases their internal friction to turn the buying process off.  It is always easier to keep something going, than to start it in the first place.  This builds a moat around our client, denying our rivals an option to steal our business.  So, what could you bundle together to create a no-brainer, totally stupendous offer for the buyer? There might be some administration associated with using our type of product or service.  The buying entity inside the client's company is always time poor.  Perhaps we can offer a system which supplies the service or product, but in such a way that we reduce the friction involved on their side.  A famous example is the Kanban system at Toyota.  It works well for Toyota as the buyer of the auto parts, as their warehousing costs are substantially reduced. The suppliers have revolutionised their logistics ability and can time their deliveries to fit in with Toyota's production schedule.  The suppliers are selling their products but also reducing Toyota's friction.  What can we do to sell our products and services and also reduce the friction in the buyer's internal systems? When I finally got religion about maximising the assets we already have for increasing our value to clients, I was amazed at how much latent opportunity we had there all along.  I was asking myself, “why has it taken me so long to work out this simple idea?”.  I was just dumb but now I have wised up at long last.  What items are available for you to recognise the latent value you possess and package them up as assets transformed into new forma  

In this LMScast, Zachary Katz from GravityKit presents Gravity Board, a WordPress add-on for Kanban project management that integrates Trello-like features into your website. Zachary Katz founded GravityKit, a business that creates robust Gravity Forms add-ons like GravityView, which gives customers extensive options for how to display and manipulate form data on their WordPress websites. […] The post How To Manage LMS Websites Inside WordPress Like Trello With GravityBoard appeared first on LMScast.

In this episode, we welcome Lisa Zawrotny, a productivity coach with a rich background as a caregiver, mother, and business owner. Lisa shares her journey from caregiving to coaching, emphasizing the importance of compassionate and sustainable productivity systems, especially for those managing ADHD or high-stress roles. We discuss the nuances of burnout versus overwhelm, the significance of self-awareness, and practical strategies to enhance productivity without sacrificing well-being.Key Moments:Lisa shares her journey from caregiver to productivity coach, highlighting the challenges of managing burnout and overwhelm.Burnout can manifest as constant dread, resentment, and exhaustion, while overwhelm often feels like having too much to do without knowing where to start.Knowing and accepting oneself is crucial for building effective productivity systems tailored to individual needs.Before implementing systems, decluttering and simplifying tasks is essential to create a manageable workload.Productivity should support life, not the other way around. Rest and self-care are integral to sustainable productivity.Productivity systems should be customized to fit how individuals work best, especially for those with ADHD or other unique challenges.Moving away from hustle culture and redefining success can alleviate feelings of inadequacy and burnout.Lisa discusses various tools and methods, such as the Pomodoro technique and Kanban boards, to enhance productivity.Engaging with a community and seeking support can help individuals navigate their productivity challenges.Lisa is working on new workshops and a signature program to further support individuals in their productivity journeys.To learn more about Lisa Zawrotny please visit her Linkedin ProfileTo learn more about Lisa Zawrotny please visit her website.YOUR HOST - SIMON LADER    Simon Lader is the host of The Conference Room, Co-Founder of global executive search firm Salisi Human Capital, and lead generation consultancy Flow and Scale. Since 1997, Simon has helped cybersecurity vendors to build highly effective teams, and since 2022 he has helped people create consistent revenue through consistent lead generation.        Get to know more about Simon at:      Website: https://simonlader.com/  Twitter: https://twitter.com/simonlader  LinkedIn: https://www.linkedin.com/in/headhuntersimonlader/      The Conference Room is available onSpotifyApple podcastsAmazon MusicIHeartRadio

What happens when one of the most respected minds in lean construction sits down to dissect project planning systems? You get this episode. In this powerful conversation, Jason is joined by mentor and thought leader Hal Macomber to explore: Why CPM lacks production theory (and what that means for your projects). The real difference between Scrum and Kanban. How Takt construction works as a socio-technical system and why that's critical. Why some teams thrive with lean systems... and others just don't. How the software industry has outpaced construction in flow-based systems and what we can learn from them. If you've ever wondered why schedules fail, why flow breaks down, or how to actually support your field teams with better planning this episode is your blueprint. You'll walk away with: ✔ A clear understanding of how Kanban brings flow front and center. ✔ Practical takeaways on how to align office + field teams. ✔ Insightful critiques of current scheduling tools and what to use instead.   If you like the Elevate Construction podcast, please subscribe for free and you'll never miss an episode.  And if you really like the Elevate Construction podcast, I'd appreciate you telling a friend (Maybe even two

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

Jakich narzędzi, metod i miar powinniśmy stosować do zarządzania opcjami, czyli tym wszystkim, co mamy w backlogu? Przy okazji premiery książki "Upstream Kanban - tools for Demand Managers", zaprosiłem do podcastu Anię Radzikowską - autorkę kolejnej książki z serii Better with Kanban. Warto posłuchać, bo jest kilka ciekawych porad, a może skusicie się na całą lekturę.

A strong project kickoff strategy can make or break your software project. In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit and expand upon their earlier episode, Mastering the Project Kickoff – Setting the Stage for Success. This time, they use AI not to redefine strategy, but to reflect on what worked, what's changed, and what new insights can improve how teams approach kickoffs today. The result is a deeper, more refined look at launching software projects with intention and clarity—before writing a single line of code. Why Your Project Kickoff Strategy Still Matters “Two weeks in, and no one agrees on the goal.” It's a story most developers know too well. The reason? A weak or nonexistent project kickoff strategy. Rob and Michael break down how early misalignment on goals, responsibilities, or MVPs can derail projects quickly. To avoid this, teams need a consistent, structured approach that starts before the first line of code is written. How AI Improves Your Project Kickoff Strategy AI can't replace a good team conversation, but it can support a better project kickoff strategy by helping structure discussions, define deliverables, and highlight gaps in planning. Some examples AI tools can generate: Stakeholder role outlines Risk assessment prompts Project objective statements Kickoff meeting checklists With good prompting, AI becomes a partner in better planning. Core Elements of a Strong Project Kickoff Strategy A repeatable project kickoff strategy should include the following: 1. Purpose and Objectives What are we building, and why? Define the business problem and expected outcome clearly. 2. Team Roles and Ownership List all stakeholders, assign responsibilities, and clarify decision-makers. Misunderstood roles create avoidable blockers. 3. Process and Delivery Plan Establish your delivery method (Agile, Scrum, Kanban) and how progress will be tracked, tested, and shared. 4. MVP and Scope Control Rob and Michael emphasize: everything must map to the MVP. If it doesn't, reconsider the feature. 5. Documentation and Visibility Centralize everything. Use Notion, Confluence, or shared drives, and record meetings for searchability and auditability. Warning Signs of a Poor Kickoff Strategy Michael and Rob call out red flags that reveal when your project kickoff strategy is weak or broken: No written MVP or goals Absent stakeholders during planning Overlapping roles with unclear boundaries “We'll figure it out later” mindset No documentation or decision logs Ignoring these signs leads to confusion, rework, and a breakdown in team trust. Anchor Your Kickoff Strategy with an MVP “If your feature doesn't pass a test, it's not part of your MVP.” Michael shares a practical tip: create user stories first, then turn them into pass/fail tests. This ensures that your project kickoff strategy stays laser-focused on outcomes—not distractions like UI polish or edge-case bells and whistles. Challenge: Audit Your Project Kickoff Strategy Before your next launch, hold a quick strategy review. Ask: Do we have a clearly defined MVP? Are team roles written and confirmed? Are meeting notes and decisions documented? Does every feature connect to project goals? If not, revise your strategy now—before you waste time. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Working The Project – Consulting Success CYA Documentation: Getting Started With Consulting Winning Your First Project: A Developer's Guide to Starting Your Side Hustle A Project Management and Pricing Guide for Success Building Better Developers With AI Podcast Videos – With Bonus Content

Legal teams face a unique challenge that factory floors and software developers rarely encounter: managing dozens of active matters simultaneously while dealing with constant interruptions from clients, opposing counsel, and courts. You're juggling multiple cases, each with its own timeline, dependencies, and unpredictable external factors that can derail your best-laid plans.In this episode, I dive into why the Kanban method is the best-fit system for that reality, and how it helps legal teams reduce overwhelm, spot bottlenecks, and manage work more intentionally. If your team is stuck in reactive mode, tune in to hear how Kanban gives you a practical path forward. Get full show notes, transcript, and more information here: https://www.agileattorney.com/77

Back in the early 2000s, software teams started embracing a new way of working that turned conventional project management on its head. Instead of trying to define everything up front and push massive projects toward a distant deadline, they asked a different question: what's the most valuable work we can deliver in the next two weeks? That question gave rise to Scrum—a system built on fixed time, cross-functional teams, and fast feedback. And while it started in software, the lessons apply just as powerfully to legal work. Tune in to hear how you can apply these principles to your practice—especially around prioritization, workflow design, and respecting your finite capacity—so that you're working smarter, not just harder.Get full show notes, transcript, and more information here: https://www.agileattorney.com/76

In this episode, Amir chats with Jason Fellin, Head of Growth Engineering at OnX Maps, to unpack what makes growth engineering unique. Jason shares how his team focuses on speed, experimentation, and measurable business impact rather than long-term architecture. From hiring strategies to cross-functional collaboration with marketing, this conversation offers a tactical look at building and leading a growth engineering org.

A Japanese automobile factory floor in the 1950s might seem worlds away from your law office, but the visual management systems that transformed Toyota's manufacturing process hold powerful lessons for modern legal practice. The same principles that helped Toyota become a global automotive giant can help you create smoother workflows, reduce overwhelm, and deliver more predictable outcomes for your clients.In this episode, I explore the origins of the Kanban method and why visual systems are so effective for managing work. I trace the journey from physical cards on factory floors to the digital Kanban boards that software developers adopted in the late 1990s, and explain why these same tools are perfectly suited for legal work. Get full show notes, transcript, and more information here: https://www.agileattorney.com/75

In this episode of Building Better Developers, hosts Rob Broadhead and Michael Meloche explore how to improve team collaboration in software development through the lens of AI-driven insights. Whether you're a solo developer, part of a tight-knit team, or scaling across departments, collaboration remains the backbone of efficiency and success. What Does Collaboration Mean in Development? AI kicked off the discussion with a powerful insight: define “efficiency” in context. But more importantly, it highlighted that collaboration fuels efficiency, not just working faster, but working better. Effective collaboration avoids: Redundant work Misunderstood requirements Tech debt and burnout Rob emphasized that a productive team isn't rushing through tasks but solving the correct problems—together—on the first try. Collaboration Strategies for Solo Developers Even solo developers need structured collaboration between their tools, their future selves, and their automation stack. Top collaboration tips for independent devs: Use opinionated frameworks like Next.js or Rails to minimize decision fatigue. Automate repetitive tasks early to save time in the long run. Commit code regularly with meaningful messages. Document workflows using Notion, Obsidian, or Jira—even if you're the only one using them. Containerize development environments for repeatability and rapid setup. “Solo doesn't mean siloed. Collaborate with your tools, your past decisions, and future goals.” Enhancing Collaboration in Small Development Teams For teams of 2–10 developers, Rob and Michael discussed how tight feedback loops and structured communication are essential to avoid chaos. Recommended practices for small team collaboration: Short, focused daily standups Shared development environments Lightweight Agile or Kanban boards Early investment in CI/CD pipelines Use of pair programming or mob programming for knowledge sharing Michael emphasized Agile's power in synchronizing team efforts, avoiding duplicated work, and solving problems more efficiently as a unit. “Agile helps teams collaborate—not just communicate. It keeps everyone moving in the same direction.” Solving Common Bottlenecks Together AI highlighted four universal collaboration pain points and solutions: Slow Code Reviews - Use SLAs and rotate reviewers Unclear Requirements - Kick off with 15-minute clarification huddles Testing Paralysis - Focus on integration tests and avoid overtesting Context Switching - Block dedicated focus hours Michael zeroed in on testing paralysis, especially in early-stage projects, where developers are too busy scaffolding to write tests. Without collaboration on testing plans, critical issues may be overlooked until it is too late. Rob addressed context switching, warning against excessive meetings that fragment developer flow. Leads should shield devs from distraction by delivering distilled, actionable feedback. Final Thoughts on Collaborative Development As teams grow, minor issues scale fast, and so do inefficiencies. Tools, meetings, workflows, and expectations must all scale intentionally. Rob reminded leaders to summarize and distill information before passing it to their teams and to make clever use of tools like AI, recordings, and summaries to keep everyone aligned without wasting time. “If you're building better developers, you're also building better collaborators.” Take Action: Build Collaboration Into Your Workflow Reassess your standups and review cycles Empower solo devs with documentation and CI/CD Streamline onboarding with containers Test early, test together Protect team focus time Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Embrace Feedback for Better Teams Using Offshore Teams and Resources – Interview With Tanika De Souza Moving To Mobile Teams and Building Them – Sebastian Schieke Building Better Developers With AI Podcast Videos – With Bonus Content

In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche tackle a challenge that many modern developers face: navigating multiple software methodologies. With insights shaped by both real-world experience and AI-generated suggestions, the discussion reveals how developers can stay effective when juggling Agile, Waterfall, DevOps, and hybrid workflows. Understanding Common Software Methodologies The episode begins with an overview of today's most widely used software methodologies: Agile, Scrum, Waterfall, Kanban, DevOps, and SAFe. Rob and Michael highlight that developers often switch between these within the same organization or even across concurrent projects, depending on client requirements, legacy constraints, or team structure. The result? A dynamic but complex work environment that demands both technical and mental agility. The Challenge of Switching Software Methodologies The core challenge is staying productive while adapting to different software methodologies across teams and projects. Developers face more than just a change in process—they often deal with different toolsets, coding standards, sprint cadences, and collaboration models. This constant context switching can drain mental resources. “It's like being bilingual,” Michael explains. “If you're not fluent in a method, switching is exhausting.” Even development tools play a role. Some developers separate projects by using different IDEs to help them mentally shift gears between methodologies. Clarifying ‘Done' in Software Methodologies Rob and Michael explore a common point of contention: the definition of “done.” In Agile, it often means feature-ready for review or feedback. In Waterfall, it usually means final and locked. “You'll start a war in a meeting just asking what ‘done' means,” Rob quips. Michael uses a cooking analogy to explain the importance of clear expectations: requirements are the recipe, code is the ingredients, and the finished product must match what was promised. Without agreement on what “done” means for each software methodology, delivery and testing become chaotic. Adapting to Different Software Methodologies To truly thrive, developers must move from a methodology purist to an adaptive mindset, focusing on the value being delivered rather than the rigidity of a particular framework. “Don't serve the methodology. Serve the customer,” Rob emphasizes. Michael reminds us to avoid getting lost in small details, like UI color tweaks, when more critical features remain incomplete. Staying aligned with the end goal ensures that effort translates into real progress, regardless of methodology. Documenting Within Software Methodologies In teams that use multiple software methodologies, documentation often becomes fragmented or overly complex. Rob and Michael both stress that great developers learn to write “just enough” documentation—and keep it in one place. Michael offers a best practice: let the codebase be the source of truth. Embedding JavaDocs, comments, or changelogs within the code ensures that updates stay consistent with the actual implementation. It reduces dependency on separate, often outdated documentation tools. “If your code and documentation don't match, one of them is lying,” Michael warns. Key Takeaways on Software Methodologies Understand core methodologies — Agile, Waterfall, DevOps, and hybrids Support healthy context switching — Use tools and routines that help you adapt Align on ‘done' — Define it clearly with your team Focus on outcomes — Avoid getting stuck in rigid process rules Document just enough — And keep it close to your code Be Adaptable, Stay Focused To succeed across software methodologies, developers must be flexible, clear, and focused on delivering value. Rather than being loyal to a single framework, the best developers understand the principles behind them all. They communicate effectively, manage context switches efficiently, and utilize smart documentation to keep projects aligned. When you serve the goal—not just the process—you become a truly adaptive developer. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Learn From CoWorkers: Interview with Douglas Squirrel Rock Bottom Can Be a Starting Line Invest In Your Team – They Will Want To Stay Building Better Developers With AI – With Bonus Content

In law firms across the country, I'm seeing a concerning pattern emerge when one attorney adopts Kanban and Agile methods while their partner - often from an older generation of lawyers - resists these systematic approaches. This clash of perspectives frequently pushes teams back into overload and burnout.This week, I explore how this capacity tension manifests in law firms, particularly during succession planning. I share specific strategies for implementing personal Kanban systems to manage competing demands and discuss the critical difference between basic Kanban board interfaces and true Kanban methodology tools designed to support sustainable legal practice management.Get full show notes, transcript, and more information here: https://www.agileattorney.com/74

Are you struggling to stay on top of your podcast guest appearances? Without a system, opportunities fall through the cracks, deadlines get missed, and follow-ups become overwhelming. In this episode, Candy Messer shares a simple but powerful way to track every step of the guesting process, from applications and scheduling to interviews and promotions. Get ready to streamline your workflow, stay organized, and make podcast hosts want to invite you back!MORE FROM THIS EPISODE: HTTPS://PODMATCH.COM/EP/335Chapters00:00 Introduction to Podcast Guest Management01:26 Project Management Systems for Podcasting06:00 Using Spreadsheets for Tracking Podcast Appearances08:47 Creating a Marketing Calendar for Promotions11:39 Conclusion and Key TakeawaysTakeawaysWithout a system, managing podcast appearances can feel overwhelming.A project management system helps track progress effectively.Using a checklist style is ideal for those who love organization.The Kanban board style is great for visual learners.Google Sheets can be a simple alternative for tracking.Color coding tasks can provide a quick visual reference.A marketing calendar is essential for planning promotions.Plan your promotions around your content schedule.Tagging hosts in promotions helps increase visibility.Finding the right system is key to managing podcast appearances.MORE FROM THIS EPISODE: HTTPS://PODMATCH.COM/EP/335

A concerning trend I've noticed both in my own practice and among my clients is that the rise of AI technology is making it harder to accurately assess our true capacity. Between constant marketing messages and the promise of enhanced productivity through AI tools, many of us are failing to gauge our own capacity and falling into the trap of overcommitting.The legal tech landscape is evolving rapidly, and technology companies are using sophisticated attention-hacking techniques to convince us their products are essential. Without clear goals and strategies in place, we become more susceptible to these marketing messages and risk adopting tools that don't actually serve our practice needs.In this episode, I explore how to maintain an honest assessment of capacity while embracing new technology and the problem with chasing every new technological promise. I share my personal experience with AI tools leading to overcommitment, and discuss the importance of using systems like Kanban boards to track capacity objectively.Get full show notes, transcript and more information here: https://www.agileattorney.com/73

Lee Stuart is back again, but this time he's in the co-host seat. It's been a long time coming, but we're stoked to be talkin' shirt with Mr. President himself, Ross Hunter of ROQ. This monster of an episode will surely put you at ease regarding the state of the industry, grow your brain a few sizes, and pump you up with so much motivation that you could run through a brick wall. You'll see. Topics of discussion include: Lee's new space and DTF venture, AI customer service, travel pains, new equipment and automations from ROQ, print on demand, shop collaborations, some speculation on a combo DTF Printer-Press and carrier sheet waste reduction, the state of the industry around the world, pushing promo products, online stores, realistic purchases, utilizing lean methodology, SOPs and Kanban systems, ROQ's partnership with Grimco, and the stark contrast between Dilly and Lee's Youtube algorithms.