Podcasts about Agile

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

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

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

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

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

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

The current moment feels like 'the end'. If you're truly Agile, the opportunities are everywhere. Tech feels like mayhem right now, but that creates MORE opportunity to envision the future, and place a bet on an experiment that could change everything. Isn't that what we're supposed to be good at?

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

Njegos Ilic: The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient In this episode, we refer to the concepts of Scrum Master as facilitator and team empowerment. The Bad Scrum Master: The "Painting by Numbers" Approach That Leaves Product Owners Working Alone Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "You basically feel totally alone because you are trying to deliver value as a team, but if nobody asks anything and nobody challenges anything, you end up defining everything yourself." - Njegos Ilic   Njegos describes the worst Scrum Master anti-pattern he's witnessed: the "painting by numbers" Scrum Master who runs every ceremony by the book — dailies, refinements, plannings, retros, reviews — but without understanding the purpose behind any of them. The meetings become a reporting cycle: "What did you do yesterday?" with no interaction, no challenging, no real engagement. From the product owner's perspective, this is devastating. Njegos describes feeling completely alone — trying to deliver value as a team while nobody engages, nobody asks questions, nobody pushes back on assumptions. The downstream effect is predictable: gaps that could have been caught early with a single conversation only surface during development or after deployment. Worse, the lack of engagement creates doubt and overthinking — the product owner starts over-defining requirements because there's no feedback loop, which reinforces the very passivity that caused the problem.   Self-reflection Question: Are the ceremonies on your team creating genuine engagement and learning — or have they become a reporting cycle that nobody actually needs? The Great Scrum Master: The Quiet, Impactful Leader Who Made the Team Self-Sufficient 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 best Scrum Masters I worked with were invisible — they knew always when to speak, they sensed the pulse of the team, and they weren't afraid to jump in when needed." - Njegos Ilic   The best Scrum Masters Njegos has worked with share a common trait: they were almost invisible. They didn't dominate meetings or insert themselves where they weren't needed. But they were always present — sensing the team's pulse, knowing when to step in, unafraid to say "we're out of time, let's take this offline." They were knowledgeable about the product, which earned them genuine respect from developers. And perhaps most powerfully, they delegated facilitation itself. Njegos shares an example where a Scrum Master introduced a round-robin system: when new developers joined the team, everyone took turns facilitating meetings — planning, retros, dailies. This wasn't just delegation for efficiency; it was empowerment by design. Team members who facilitated a retrospective suddenly understood how hard it is to lead one. That empathy changed how they participated when someone else was facilitating. The Scrum Master remained the guide, but the team grew its own capacity to self-organize.   Self-reflection Question: If your Scrum Master disappeared tomorrow, would your team know how to facilitate its own ceremonies — and if not, what does that say about how the role is being used?   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why Measuring Your Product Bets Is the Key to Product Owner Success Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you cannot measure what you build, you will just be depending on who is screaming the loudest and using your gut feeling — which is not a good thing long term." - Njegos Ilic   Njegos defines product owner success through three pillars: the ability to measure product bets, deep knowledge of the industry and product, and the humility to admit mistakes and be challenged. The measurement piece is central — without it, he argues, you're flying blind, making decisions based on opinions rather than evidence, reacting to whoever screams loudest rather than what the data shows. But Njegos is honest that not every environment makes measurement easy. Some companies lack the tooling, the culture, or the historical infrastructure to set up proper analytics. In those situations, he turns to user interviews as the next best thing — getting direct feedback from users, even though he acknowledges that opinions are still limited without data to fact-check them against. His most powerful suggestion: invite the whole team to user interviews, not just the product trio. When developers hear directly from users, they connect to real-world problems, and conversations during refinements become richer and more grounded.   In this episode, we refer to The Mom Test by Rob Fitzpatrick and Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger.   Self-reflection Question: How do you currently measure whether the features you shipped actually delivered the value you expected — and if you can't measure it, what's your fallback? Featured Retrospective Format for the Week: Start With a Relaxing Exercise Njegos doesn't advocate for a specific retrospective template — and that's the point. From his product owner perspective, he values retrospectives that begin with a relaxing, informal exercise to set the tone. Not everything needs to feel like business as usual. This casual opening allows people to connect as humans first, which opens them up to think differently about what they learned during the sprint. Njegos is candid about the reality: some teams love icebreakers, while others find them childish and just want to get to the point. His advice is to sense the pulse of the team and adapt. The format matters less than whether it creates an environment where people can be honest about what went well, what didn't, and what to improve. A Scrum Master who reads the team's vibe and adjusts accordingly — that's what makes the difference.   [The Scrum Master Toolbox Podcast Recommends]

AI Breaks the Agile Sweet Spot For Team SizeHow big should your Agile taem be? Does Agentic AI change everything? Lets listen and explore how team sizes may EXPLODE! 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/

Njegos Ilic: How a Miro Board Experiment Changed the Way His Team Understood the Big Picture 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.   "Every feature is a product bet. I would call this a process bet — just try to see what works best for you." - Njegos Ilic   Njegos shares a change story from his time working with a tech lead who had previously been a Scrum Master — a partnership that made all the difference. Together, they introduced a simple but powerful change: visualizing the team's work on a Miro board instead of relying on a standard ticket board with cards and status columns. They mapped out concepts, connected ticket numbers to a visual representation of how different pieces of work fit together, and used this board during dailies and refinements to track progress in context. The change wasn't imposed top-down — Njegos and his tech lead simply said, "Give us one sprint to try this. If it doesn't work, we drop it." The result was immediate: dailies became more engaging, the team could see how their individual work connected to the bigger picture, and Njegos found it much easier to track progress as a visual thinker. His advice for Scrum Masters and product owners who want to introduce something similar is refreshingly simple — frame it as a "process bet," just like you'd frame a product bet. Try it, measure what happens, and if it doesn't work, drop it and try something else. The willingness to experiment with your own process is a prerequisite for experimenting with the product itself.   Self-reflection Question: What "process bet" has your team been avoiding — and what would it take to just try it for one sprint?   [The Scrum Master Toolbox Podcast Recommends]

This conversation with Gil Broza goes straight at a question many product leaders are quietly wrestling with: how do you bring AI into product development without breaking everything that already works? Gil, author, coach, and long-time agility expert, returns to talk with Matt and Moshe about “reshaping product development for AI's impact,” focusing not on building AI features, but on how AI is changing the way product and engineering teams work day to day. He argues that while AI massively increases speed and output, it doesn't change the fundamentals of good product development: clear direction, evidence-based judgment, solid technical foundations, and healthy teams. Join Matt and Moshe as they explore with Gil: - Why AI is a “turbo engine in a car with old brakes” if you drop it into a system designed for human speed. - How leaders confuse more output with more value, and why faster code can just mean “legacy code years ahead of schedule”. - The difference between real agility and “performative Agile” (ceremonies, Jira theater) when AI tools are doing more of the work. - How to think in systems: what you're actually optimizing for (predictability, innovation, time-to-value) and how AI changes the constraints and feedback loops in your org. - Practical blind spots leaders miss with AI adoption: - Treating AI as an implementation, not a transformation - Ignoring cognitive load and burnout when people work all day with agents - Shrinking teams for “efficiency” and accidentally increasing isolation - The three main ways to use AI in product development, and why you should be explicit about each: - As a pairing partner (thinking, coding, design) - As an autonomous agent - As “just” automation (summaries, note-taking, etc.) - Why skipping prototyping and experiments is now “less excusable” when AI can create testable prototypes in hours instead of weeks. - What changes (and doesn't) in roles like PM, engineer, and scrum master when AI becomes a real team member. - Concrete steps leaders can take: apply systems thinking, revisit mindset and values, redesign ways of working for AI-speed conditions, and invest in continuous improvement again. - How Gil's new courses (“Reshaping Product Development for AI's Impact” and “Leading AI-Enabled Product Teams”) help product and engineering leaders do this work intentionally. Want to go deeper or work with Gil? - Website & courses: https://3pvantage.com/  - Newsletter & articles: https://3pvantage.com/subscrib.../  - LinkedIn: https://www.linkedin.com/in/gi.../  You can also connect with us and find more episodes: - Product for Product Podcast: http://linkedin.com/company/pr...-podcast  - Matt Green: https://www.linkedin.com/in/ma... - Moshe Mikanovsky: http://www.linkedin.com/in/mikanovsky  Note: Any views mentioned in the podcast are the sole views of our hosts and guests, and do not represent the products mentioned in any way. Please leave us a review and feedback ⭐️⭐️⭐️⭐️⭐️

Former NASA Administrator Jim Bridenstine has joined Quantum Space as CEO. We talk about what the company is working on, the Ranger spacecraft, how they fit into the industry, where he sees their market going, and what it's like to be a former NASA Administrator running a company in the industry. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Fred, Frank, Better Every Day Studios, Tim Dodd (the Everyday Astronaut!), David, Steve, Kris, Stealth Julian, Will and Lars from Agile, The Astrogators at SEE, Pat, Warren, Josh from Impulse, Miles O'Brien, Russell, Matt, Natasha Tsakos, Joakim, Lee, Theo and Violet, Joonas, Joel, Jan, Donald, Ryan, and four anonymous—and hundreds of supporters. Topics Quantum Space hires Bridenstine as CEO - SpaceNews Quantum Space to build spacecraft in Tulsa - SpaceNews Quantum Space acquires Phase Four propulsion assets - SpaceNews Quantum Space raises $40 million - SpaceNews The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by NASA/Bill Ingalls Work with me and my design and development agency: Pine Works

Njegos Ilic: Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I can't change people, but I can definitely involve them." - Njegos Ilic   Njegos describes a pattern he's encountered multiple times as a product owner: teams where engagement is almost nonexistent. He walks into a refinement session, presents ideas, asks for feedback — and gets crickets. Nobody pushes back, nobody asks questions, nobody challenges the assumptions. The result is a product owner working in isolation, defining everything alone, only to discover gaps during development that could have been caught early with a single conversation. Njegos is honest about the limits of what any one person can do — you can't change people's personalities, and expecting a Scrum Master to do so is unrealistic. But what you can do is involve people. His approach when joining a new team: don't come in announcing how things will work. Instead, learn how the team already works, meet them where they are, and then find ways to fit new concepts into their existing rhythm. For the non-negotiable things — the red lines — he's precise, open, and always provides an alternative rather than just pushing his way.   In this segment, we talk about Discovery and Delivery and the Product Trio concept.   Self-reflection Question: When you join a team meeting and get silence instead of feedback, do you assume agreement — or do you treat it as a signal that something deeper needs to change? Featured Book of the Week: Inspired by Marty Cagan Njegos recommends Inspired by Marty Cagan as the book that most shaped his approach to product ownership. He highlights the entire SVPG series — including Empowered and Transformed (available as the Product is Hard SVPG Box Set) — but points to the Product Trio concept as especially powerful. As Njegos puts it, the Product Trio — bringing together a product manager, a tech lead, and a designer — removes the hand-off mentality where each discipline works in isolation. Instead of the product owner defining everything alone and handing it to the team, the trio shapes problems together during discovery, so that by the time work reaches the team, there's shared understanding of why they're building something, not just what to build.   [The Scrum Master Toolbox Podcast Recommends]

Law firms are constantly being introduced to new tools, frameworks, and operational philosophies that promise better efficiency and better results. But the challenge is not simply adopting a popular methodology; it's understanding which approaches actually fit the type of work your team is doing and the problems you're trying to solve within your law firm operations.In this episode, I sit down with business consultant and Agile practitioner Robin Sims-Allen to explore what law firms can learn from other heavily regulated industries about process improvement, project management, and organizational change. We discuss the strengths and limitations of frameworks like Scrum, SAFe, Kanban, and Waterfall, and why choosing the right tool depends on the nature of the work, the structure of the team, and the realities of the environment you're operating in.Get full show notes, transcript, and more information here: agileattorney.com/121Take your law practice from overwhelmed to optimized with GreenLine LegalFollow along on LinkedIn: linkedin.com/in/johnegrantFollow Robin on LinkedIn: linkedin.com/in/robinsimsallen

Njegos Ilic: Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner 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 game is rigged because they are strong personalities, they want to get things done, but you don't have a magic stick — it's really hard to deliver results if you cannot say no." - Njegos Ilic   Njegos shares a failure from early in his career as a product owner in startup environments, where he found himself saying yes to every stakeholder request. Working with strong-willed founders who expected things done their way, Njegos fell into the trap of trying to please everyone — building everything that was asked without pushing back. The result was predictable: scattered priorities, no room to pivot, and a product backlog driven by the loudest voice in the room rather than real user needs. But Njegos frames this failure with a perspective that product owners at any stage can learn from. He compares the learning process to watching children learn to walk — stumbling and falling is not a sign of weakness, it's a necessary step in the process of growing. His advice to product owners currently stuck in this pattern: don't try to avoid failures too hard, because you might prevent yourself from learning the most important lessons. Instead, treat failure as a feedback loop — something happened, you can measure it, and you can change your approach. The key is doing the actual work of reflection: What did I do? What should have been different? What wasn't possible to change, and why?   Self-reflection Question: When was the last time you said yes to a stakeholder request even though your gut told you it wasn't the right call — and what would it take for you to say no next time?   [The Scrum Master Toolbox Podcast Recommends]

https://clearmeasure.com/developers/forums/ Ryan Riley is a Senior Lead Software Engineer at Quorum Software in Houston, TX, with deep expertise in functional programming, software architecture, and web API design across the .NET ecosystem. He is a Microsoft Visual F# MVP and longtime open-source contributor, best known for his work on projects such as Frank, WebApiContrib, and the Open Web Interface for .NET (OWIN) specification. Ryan leads the Community for F# virtual user group and is an active blogger, having recently published a thought-provoking piece in March 2026 examining AI-assisted spec-driven development and its relationship to Agile and historical software practices. He brings a thoughtful, systems-level perspective to software engineering leadership, mentoring, and team-building that spans front-end UX through back-end distributed applications. LinkedIn: https://www.linkedin.com/in/ryanriley/ GitHub: https://github.com/panesofglass Twitter/X: https://twitter.com/panesofglass Previous Appearances on the Azure & DevOps Podcast: Ryan Riley: Leading a Software Engineering Team - Episode 316 (September 23, 2024)  The Power of 10 Wiki: https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_CodeDevelopment Process using AI Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Christian Thordal: The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership The Great Product Owner: Clarity, Accountability, and a Partnership That Fills in the Blanks 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.   "We kind of filled in the blanks for each other, and it felt very natural — it's grown organically into this partnership where we're extremely aligned on how we see and do things." - Christian Thordal   Christian describes his best Product Owner as someone he currently works with — a person who combines deep product clarity with genuine leadership. This PO is fully accountable for the backlog, sets clear expectations toward the teams, and isn't afraid to push them. What makes this PO stand out is how they use reporting as a communication tool: alongside the backlog, they proactively communicate to the product leader whether things are within or outside scope, always with a plan ready. Christian and this PO hold weekly follow-ups to discuss the team, the backlog, and the product direction. Over time, their alignment has become so strong that during facilitation sessions they naturally fill in blanks for each other — one picks up where the other leaves off. Vasco compared it to a jazz duo, where each musician picks up on the other's leads in real time. This kind of organic partnership in leadership direction reflects positively on the entire team, creating a sense of coherence and momentum that everyone can feel.   Self-reflection Question: How aligned are you with your Product Owner on leadership direction, and what would it take to build the kind of partnership where you naturally fill in the blanks for each other? The Bad Product Owner: When the PO Disappears and the Scrum Master Becomes the Glue Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "You can inspire, you can motivate, but you can't really do the work for them." - Christian Thordal   Christian shares an experience from a larger logistics company in Denmark where the Product Owner was a great, likable person — but didn't understand the role. The backlog was high-level, consisting primarily of Epics with no acceptance criteria. Then the warning signs started: the PO became increasingly hard to get a hold of, started canceling refinement meetings (sometimes on the same day), began working more from home, and became physically more distant from the team. Christian and the team were left to navigate on their own, breaking down epics into stories and tasks without knowing if they were building the right product. Christian tried setting up weekly one-hour sessions to help the PO work through the backlog, but the fundamental problem remained — you cannot do the PO's work for them. Eventually, Christian found himself filling in for the PO, which is itself an anti-pattern: the Scrum Master becoming the glue that holds the product together. The symptoms to watch for are clear: a PO who starts missing meetings, backlog items that remain unrefined, a PO who becomes physically or remotely distant, and — the biggest red flag — a Scrum Master who feels compelled to step in and do the PO's job.   Self-reflection Question: Are there signs that your Product Owner is drifting away from the team, and have you caught yourself filling in gaps that aren't yours to fill?   [The Scrum Master Toolbox Podcast Recommends]

Your people strategy shouldn't be a support function. It should be a competitive advantage. In this episode, Dr. Shari Simpson sits down with James Terry, Head of US Revenue at IndeedFlex, to talk about what it really means to build an agile, flexible workforce in today's labor market. James brings a frontline revenue perspective on how companies can stop treating staffing as a headache and start treating it as a growth lever. Here's what you'll take away: Why workforce flexibility isn't a perk but an untapped labor pool waiting to be activated How AI screening tools are helping recruiters review 80 interviews a day instead of 13, without losing the human element The data-first playbook HR leaders use to run pilots that actually change how operations teams think about shift patterns Timestamps 00:02 Intro — What HR Mixtape is all about 00:15 James Terry introduction and his role at IndeedFlex 01:07 Why staffing is a business survival issue, not just an HR problem 03:02 Hiring for the business vs. hiring for the role 04:05 How AI is reshaping recruiting when applications flood the funnel 08:11 Candidate perspectives on AI screening (and why 60-70% prefer it) 12:37 Removing interview bias and focusing on real skills 13:46 What an agile workforce actually looks like and who gets unlocked 17:53 The pilot program strategy that wins over skeptical operations teams 22:05 James's top takeaways: fall forward and dare to lead Guest Bio: James Terry is the Head of US Revenue at IndeedFlex, the contingent labor arm of Indeed. He specializes in helping businesses build more agile, flexible workforces, particularly in high-velocity industries like logistics, hospitality, and customer service. James brings a data-driven perspective to workforce strategy, championing the idea that HR professionals who speak the language of operations, and back it up with numbers, become some of the most valuable people in any organization. Brought to you by Paylocity Paylocity is the fasted growing unified platform for HR, Finance, and IT. Paylocity brings your people, processes, and data together in one place so HR leaders can spend less time managing systems and more time doing the work that actually moves their organizations forward. Learn more at paylocity.com Keywords: agile workforce, flexible staffing, contingent labor, AI recruiting, talent acquisition, workforce flexibility, HR strategy, IndeedFlex, pilot programs, shift patterns, Gen Z workforce, implicit bias, AI screening, turnover rate, data-driven HR, profit center HR

Christian Thordal: Structure Creates Freedom, How an Agile Coach Measures Success by Becoming Less Needed 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 less I shine and the more the team shines, the better I perform." - Christian Thordal   Christian shares how his definition of success has fundamentally shifted over the years. Early in his career, the question was "How can I shine?" Today, it is the opposite — success means becoming invisible. For Christian, a high-performing Scrum Master builds teams that no longer depend on them, much like raising a child to become a functional adult by eighteen. They can always call dad for coaching or to borrow money, but they can stand on their own. He illustrates this with a team he moved from what he calls "cowboy loose Kanban" to an adapted Scrum framework. The structure gave the team freedom: he can now miss dailies and planning sessions, and the team still produces a solid plan, sprint backlog, and sprint goal. He drops by to give pointers and encourage good behaviors. Christian also highlights the importance of the Scrum Master and Product Owner partnership — "the mom and dad of the team" — and how building predictability and flow matters more than heroics. A key tactical insight: he created a one-pager roadmap for his domain leader showing issues, plans, milestones, and metrics. This simple artifact gave leadership the comfort that things were under control, buying Christian the autonomy to do his best work. This proved critical when his team was decimated by departures in late 2025 — he hired new people, stabilized the group, and got them delivering again.   Self-reflection Question: What would it look like if your team could run a full sprint cycle without you present — and what is stopping that from happening today? Featured Retrospective Format for the Week: The Four-Box Retrospective Christian shares a retrospective format he calls the Four-Box Retrospective — a structured, pragmatic approach that resonates especially well with engineer-minded teams. The session begins with a team check-in to get the vibe in the room. Next, the team reviews last week's agreements: who was accountable, and are those items still alive or handled? Anything still alive moves forward automatically, ensuring nothing falls through the cracks. Then comes the core mechanic: topic creation divided into four boxes — Tech (tools and tech stacks), Team (issues within the team), Outside (external dependencies and blockers), and Parking Lot (everything else). Presenters explain their topics briefly to give context, and the group uses dot voting to surface the most pressing issues. Discussion follows, with clear accountability assignments and action items written down. The pre-grouping into four boxes saves significant time by giving topics a natural home before discussion begins. Named owners for every action item create real progress between retrospectives. Christian values this format because it is grounded in actual operational problems — people can see the direct application of every conversation, which keeps engagement high and outcomes tangible.   [The Scrum Master Toolbox Podcast Recommends]

What Does a Delivery Manager Do and Do I Even Need One? A Delivery Manager is a client-facing, Agile project manager who acts as a servant-leader to ensure high-quality products are delivered in a predictable way. As the main point of contact between founders and Developers, the Delivery Manager keeps everyone connected and informed. They own the plan, align the product strategy and scope with founders and the team, and work closely with founders on priorities as well as future requirements and team changes.Delivery Managers lead all Agile ceremonies (such as meetings and workshops) and ensure teams can be productive and organized by unblocking issues, planning sprints, organising the backlog, driving efficiency, ensuring tasks are ready to be worked on and keeping the team motivated and empowered.Does someone actually believe this?

Agile Basics for Predictive Project Managers

Christian Thordal: Managing Cross-Team Dependencies in Scaled Agile, From Planning to Real-Time Coordination Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When one team's plan failed, the rest collapsed — deliveries and outcomes were delayed across the entire domain." - Christian Thordal   In this episode, Christian Thordal shares the biggest challenge he faced as an Agile Coach working within a large Danish broadcast company's technology division, where 32 teams operate across multiple domains. Within his domain of 10 teams, they plan in three-month cycles using OKRs, but a critical blind spot kept undermining their results: nobody had a clear grasp of the dependencies between teams and sister domains. When one team's delivery slipped in a previous cycle, it triggered a cascade of failures across the organization. Christian and the agile coaching community escalated the issue to the portfolio and delivery department, pushing to synchronize cycle timing across domains. He introduced a "big room planning" approach within his domain to map out which teams they impact and who impacts them, structured around a three-week cadence: define OKRs, align, then commit. A key coaching insight reshaped his thinking: dependencies are not facts — they are decisions. By naming the specific people involved (the person who needs resolution and the person who provides it), teams can manage dependencies in real-time rather than waiting for a program management layer that only addresses problems after escalation. Christian now plans to establish dedicated coordination days during each cycle where teams actively collaborate and resolve dependency issues together.   Self-reflection Question: When dependencies between your teams cause delivery failures, do you treat them as coordination problems to solve in real-time, or do you wait for escalation through a management layer?   [The Scrum Master Toolbox Podcast Recommends]

Would you like access to our advanced agency training for FREE? https://www.agencymastery360.com/training Are you charging for execution when clients are about to stop paying for it? Are you building your sales process around your offer instead of around your prospect's trust? Today's featured guest built a growth workshop that converts 78% of buyers into long-term retainer clients. In this episode, she'll get into what that workshop actually contains, why the entry offer might be the thing keeping it from scaling, how to stop your CEO from chasing shiny quarters mid-engagement, and what happens when you position strategy as the product instead of execution. Jen Jurgens is the founder of 1 Bold Step, a revenue operations agency based in Michigan. Her background is in supply chain management, which is where she developed the belief she will die on: sales and marketing is a process, and processes can be measured, improved, and optimized. One Bold Step is a HubSpot partner and works primarily with B2B clients on pipeline growth, campaign optimization, and revenue systems. In this episode, we'll discuss: Focusing on pipeline growth as a primary metric Creating a foot in the door for Jen's growth workshop Selling the process, not the deliverable Subscribe Apple | Spotify | iHeart Radio Sponsors and Resources E2M Solutions: Today's episode of the Smart Agency Masterclass is sponsored by E2M Solutions, a web design and development agency that has provided white-label services for the past 10 years to agencies all over the world. Check out e2msolutions.com/smartagency and get 10% off for the first three months of service. Toggl: Most agencies are losing 15–30% of their profit every year: lack of time tracking, messy manual timesheets, scope creep, untracked revisions, and all those "quick" client requests that never get billed. Toggl has created a fast, interactive way to uncover exactly where your margins are leaking. Start your investigation now at toggl.com/smartagency and use the code SMARTAGENCY10 at checkout for a 10% off annual plans. The Case for Charging for Strategy Before Execution Jen comes at pricing from a supply chain logic: if you can measure the outcome, you can defend the price. Her agency focuses on pipeline growth as its primary client metric because it is the number most directly connected to revenue and the one she can credibly influence within a defined timeframe. Monthly reports go out, and every quarter there is a two-hour retrospective with the client covering what was committed to, what actually happened, what worked, what did not, and what the next 90 days look like. The reason this cadence holds is that it makes the strategic layer of the engagement visible. Most agencies send reports that clients stop reading after the first month because the data is wrapped in jargon and disconnected from business outcomes. Jen's approach is the opposite: tie everything to pipeline, show up in person or on screen quarterly, and use an Agile sprint structure to keep the client's attention from jumping to whatever crossed their desk that morning. That level of structure is the thing clients are actually paying for, and most of them do not know it until it is explained to them directly. Why Your Entry Offer Might Be the Reason Deals Stall Jen's growth workshop has a 78% conversion rate from buyer to long-term retainer. That is a strong number. The problem is on the other side of the funnel: getting prospects to say yes to the workshop in the first place. The workshop is currently priced between $10,000 and $15,000, takes 100 to 120 hours of agency time to deliver, and goes deep enough that Jen describes it as showing clients not just what they want but what they actually need. It is comprehensive. It is also a significant ask before any trust has been established. The Foot-in-the-Door principle exists precisely for this situation. A $10,000 to $15,000 entry requires founder-level credibility to close and has no on-ramp for prospects who are not yet convinced. What it needs is a smaller version that a prospect can say yes to at low risk, that delivers a real insight in a short window, and that makes the full workshop the obvious next step rather than a leap of faith. The mechanics are straightforward: charge $1,000 to $2,000 for a focused diagnostic session, frame it as a mutual qualifier, and let the output do the selling. The trust the mini-session builds is what removes the friction from the larger close. Selling the Process, Not the Deliverable Jen describes what she actually does in the growth workshop as taking the client's assumptions about what is blocking their growth and replacing them with what is actually blocking their growth. Nine times out of ten, a CEO who says they need more leads is sitting on an unconverted database, a sales team sitting on two-year-old proposals, or five product lines with no prioritization. More leads into a leaky bucket is not a solution. The reason this framing is powerful is not just diagnostic accuracy. It is positioning. When Jen walks into a growth workshop, she is not selling marketing services. She is functioning as a strategic operator who knows how revenue systems work and is willing to tell the client something they did not ask to hear. That is a fundamentally different position than an agency responding to an RFP. The clients who pay $10,000 to $15,000 for that workshop are not buying a deliverable. They are buying the read, and the confidence that what comes next will be built on something real. Pricing for Strategy When AI Is Changing What Execution Costs The conversation landed on a reality every agency is navigating right now. Execution is getting cheaper and faster. Four websites in three hours is not hypothetical anymore. Clients who used to pay for time spent are starting to ask why the price has not moved if the time has. The answer is not to lower prices. The answer is to make the case clearly that what they are paying for was never the hours. It was the 20 or 30 years of judgment that knows which inputs to use, which levers to pull, and what not to build. Jen's framing for clients who push back on process costs is direct: you can manage this yourself and be the general contractor on your own build. But you will not, because you do not have the time, and if you did, you would not need us. Agencies that can hold that position without flinching are the ones that will not have their margins compressed by AI. The ones that cannot articulate what strategy is worth beyond hours delivered are already in trouble. Do You Want to Transform Your Agency from a Liability to an Asset? Looking to dig deeper into your agency's potential? Check out our Agency Blueprint. Designed for agency owners like you, our Agency Blueprint helps you uncover growth opportunities, tackle obstacles, and craft a customized blueprint for your agency's success.

Neel Kunjur, Co-Founder and CTO of K2 Space, joins me to talk about their hardware in space today, how their vision and plans have evolved over the past few years, and how industry changes like the push for orbital data centers have impacted their future. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Lee, Steve, Josh from Impulse, Kris, David, Miles O'Brien, Tim Dodd (the Everyday Astronaut!), Jan, Donald, Frank, Better Every Day Studios, Stealth Julian, The Astrogators at SEE, Ryan, Matt, Warren, Will and Lars from Agile, Pat, Fred, Joonas, Theo and Violet, Russell, Joel, Natasha Tsakos, Joakim, and four anonymous—and hundreds of supporters. Topics High-Power Satellite Platforms | K2 Space | Build Bigger T+270: K2 Space (with Neel Kunjur, Co-Founder and CTO) - Main Engine Cut Off Investors commit quarter-billion dollars to startup designing “Giga” satellites - Ars Technica Episode 241 - Maybe the Denver Airport (with Andrew Rush) - Off-Nominal Anduril teams with commercial space firms, Sandia lab on Golden Dome interceptor program - SpaceNews Space Force taps K2 satellites to test laser communications for missile-defense - SpaceNews The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by NASA/Bill Ingalls Work with me and my design and development agency: Pine Works

Christian Thordal: How "Fake Kanban" Fooled the Metrics, And What This Agile Coach Did to Fix It 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 was like birds in a nest waiting to get fed — completely dependent on the PO for every piece of work." - Christian Thordal   Christian tells us about a team that always appeared busy but was hiding serious dysfunction behind a single healthy metric. When he rated the system across his domain, he found the team scored low in process maturity, effectiveness, and learning — yet their cycle time looked good. The team claimed to practice Kanban, but in reality it meant "we can do whatever we want." Daily standups had become social check-ins. The backlog held over 100 items to do and 50+ in progress, most of them just headlines with no descriptions. Real work assignments happened through 30-minute Slack huddles between the PO and individual developers — pure push, no prioritization. Despite having OKRs, the team could only plan a week ahead. Christian's fix was radical: he restarted the backlog entirely, cutting 150 items down to roughly 30, established WIP limits to create a pull-based system, and brought the team into the process as active participants rather than passive recipients.   In this segment, we refer to Kanban and OKRs.   Self-reflection Question: When was the last time you looked beyond a single "green" metric to understand what was really happening in your team's workflow? Featured Book of the Week: Turn the Ship Around by David Marquet Christian recommends Turn the Ship Around by David Marquet, a former U.S. Navy submarine commander who transformed his crew's performance by replacing permission-seeking with intent-based leadership. Instead of waiting for orders, crew members were expected to say "I intend to..." — transferring ownership and making people accountable for their decisions. Christian says this deeply resonated with his own military background in the Danish Army, where leadership operated on similar principles. The book's core message — stop creating dependency and start building leaders at every level — connects directly to the team story in this episode, where passive dependency on the PO was the root of the dysfunction. You can also listen to previous episodes with David Marquet and explore more on intent-based leadership.   [The Scrum Master Toolbox Podcast Recommends]

We continue our episodes of the Auto Remarketing Podcast originating from the Live Stage, which was sponsored by SYCN Auto Logistics, during the Used Car Industry Summit in Miami this spring. Agile Auto founder and CEO John Ellis acknowledged inventory management might be the most difficult part of dealership operation nowadays. So, Ellis cherry-picked some of his best recommendations to share

Christian Thordal: When Applying Scrum By The Book Fails, Understanding Context Before Changing The System Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I treated Scrum like a military SOP — follow the book, execute the steps. But I failed to see that the context was really the tipping point. What looked like a problem was actually their solution." - Christian Thordal   Christian shares a hard-won lesson from his time coaching three RPA teams at one of Denmark's largest banks during the pandemic. He inherited teams running six-week sprints with half-hour planning sessions that amounted to little more than putting items on a calendar. As a former Danish Army officer, Christian's instinct was to fix the obvious deviation from the Scrum Guide — the sprint length. He advocated for shorter feedback loops and eventually convinced the Product Owner, who also served as the director, to try two-week sprints. The first planning session was a disaster. There was yelling and scolding, and it became clear that the real problem had nothing to do with sprint length. The teams had no proper backlog. The six-week sprints actually worked because they gave teams enough time to go out to the business, discover work, and deliver it within a single cycle. Christian realized he had been applying Scrum mechanically without understanding how work entered the system. He started attending business analyst and PO meetings, uncovered the backlog gap, and helped the teams build a proper one. His key insight: what looks like a symptom can actually be a pragmatic solution to real constraints. Understand the system before you change it.   In this episode, we refer to the book Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland.   Self-reflection Question: When was the last time you assumed a team's practice was wrong, only to discover it was a reasonable adaptation to their context? How might you investigate the "why" behind existing processes before proposing changes?   [The Scrum Master Toolbox Podcast Recommends]

Josh and Bob dig into the courage problem that runs through every layer of tech leadership right now. The courage to push back on your team. The courage to be honest with peers. And the hardest one, the courage to tell the people above you that the thing they want is the wrong thing.They get into why most leaders are courageous downward but cave upward. Why fear of losing a job often costs you the job anyway. The "blinds" metaphor for how much truth you actually let out in the room. And the moment Josh told his boss "no" for the first time and watched the conversation turn into something better than he expected.Then they bring it back to the current reality. Boards with youthful enthusiasm about cutting 50% of the workforce with AI. The agile-is-dead chorus. Senior leaders want fast answers to questions that deserve careful ones. And the leaders in the middle who quietly comply instead of saying what they actually think.This is a challenge episode. If you've been swallowing what you really believe in leadership conversations, this one is going to sit with you. Stay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Mukhtar Kadiri: The Three Qualities That Separate Great Product Owners From Those Who Just Drop Tickets The Great Product Owner: Decisive, Versatile, and Credible at Every Level 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.   "This person could hold his own at any level of the organization — with executives, with engineering leadership, and with the team." - Mukhtar Kadiri   Mukhtar describes the best product owner he ever worked with through three distinct qualities. First, this person could operate at any level — equally comfortable in a strategic conversation with executives and in a tactical session with the engineering team. Second, they had vast cross-functional knowledge. They weren't a specialist in any one domain, but they could hold intelligent, credible conversations with marketing, go-to-market, customer success, and engineering alike. And third — perhaps most critically — they were decisive. In ambiguous environments where nobody has done this before, teams need someone who will pick a direction and say "let's find out," even if the decision might be wrong. That decisiveness, combined with the ability to course-correct early, is what separates great product owners from those who leave teams waiting for direction that never comes.   Self-reflection Question: Which of these three qualities — operating at any level, cross-functional credibility, or decisiveness — is strongest in your product owner, and which one needs the most development? The Bad Product Owner: Not Owning the Backlog Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you don't have a strong product person, engineering just takes over the backlog. And that is dangerous, because it's product that is the representative of the customers." - Mukhtar Kadiri   Mukhtar has seen it happen repeatedly: when a product owner doesn't truly own the backlog, a strong engineering lead steps in and takes over prioritization by default. Things still get built — often beautiful, technically elegant solutions — but they don't produce business value because engineering lacks the customer intimacy that product should bring. The fix isn't simple, but Mukhtar identifies three levers. First, mentorship — pairing a junior product person with a more senior one to build confidence and skills. Second, building technical literacy — a product owner who can't meet engineering halfway will always be seen as an outsider dropping tickets. And third, closing the relationship gap between product and engineering. As Mukhtar points out, a product owner is technically a part of the team, but if the team doesn't feel like they're a part of the team, that gap becomes a chasm. There needs to be real overlap between engineering and product — not just shared meetings, but shared understanding.   Self-reflection Question: Is your product owner truly a member of the team — or are they just someone who shows up to drop tickets and disappear until the next sprint planning?   [The Scrum Master Toolbox Podcast Recommends]

Do you find yourself covering the same agile lessons over and over again? Back in CITCON 2021, a special guest brought up how he's been talking about the same problems for 20 years. And five years later, we imagine not much has changed! Listen to this re-run episode for our thoughts on this topic with Squirrel's analogy on how teaching long division turns out to be surprisingly helpful. LINKS: - CITCON:AI Helsinki: https://citconf.com/helsinki2026/ - Moore, Crossing the Chasm: https://en.wikipedia.org/wiki/Crossing_the_Chasm - Chris Matts, community of needs: https://snowbirdcollaboratory.org/community-of-needs/ - Alistair Cockburn: https://alistair.cockburn.us/ -------------------------------------------------- You'll find free videos and practice material, plus our book Agile Conversations, at agileconversations.com And we'd love to hear any thoughts, ideas, or feedback you have about the show: email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick joined forces at TIM Group in 2013, where they studied and practised the art of management through difficult conversations. Over a decade later, they remain united in their passion for growing profitable organisations through better communication. Squirrel is an advisor, author, keynote speaker, coach, and consultant, and he's helped over 300 companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, and is an accomplished author and speaker. You can connect with him here: www.linkedin.com/in/jfredrick/

Mukhtar Kadiri: Why Success Means Nothing If the Project Doesn't Move the Business Forward — And How Public Commitments Keep You Honest Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you're not careful with success, you can deliver a project, but the project will really not do much for the business." - Mukhtar Kadiri   For Mukhtar, success is personal — he's the kind of project leader who gets emotionally invested, who thinks about the project after hours, who needs recovery time between engagements. And that emotional investment shapes how he defines success: not as hitting deadlines or completing tasks, but as delivering real business value. He breaks success metrics into three buckets using his signature rule of three: business and product metrics (NPS, revenue, market penetration), project management metrics (velocity, burn-down, risk scores), and software and system metrics (availability, transactions per second, platform health). But the real insight is in how he holds himself accountable. Mukhtar makes public commitments at the start of every project — "Expect status updates from me every week" — because he knows that the discipline of narrating the project's story every week forces him to truly understand what's happening. A status report isn't bureaucratic busywork when you approach it as storytelling: you have to make sense of the data, surface what's relevant, and articulate where the project actually stands. If you can't tell the story, something's missing from your understanding. That weekly narrative becomes both an accountability mechanism and an early warning system.   Self-reflection Question: Can you tell the story of your project right now — not just the tasks completed, but the narrative of where it stands, why, and what that means for the business? Featured Retrospective Format for the Week: What Worked / What Didn't Work / Next Steps Mukhtar is a firm believer in simplicity, and his favorite retrospective format reflects that — the classic "What worked, what didn't work, and next steps." He applies his rule of three here as well: three categories are easy for humans to hold in their heads, removing cognitive overhead so the team can focus on the conversation itself. But Mukhtar is quick to point out that a simple structure can still produce terrible retrospectives. What matters more is the facilitation: making sure people feel safe at the very start, level-setting so participants can "land" into the retrospective after jumping from another meeting, giving everyone a moment of quiet introspection to write things down before discussion begins — ensuring both quiet and loud voices are heard. He prepares for every retrospective because, as he puts it, "if you run a bad retro, you could do damage to your team morale and your project." Active facilitation — watching for who isn't speaking, encouraging quieter voices, managing tone — is what transforms a simple format into a powerful conversation.   [The Scrum Master Toolbox Podcast Recommends]

Project World | Business Analyst World - Day 3-4 ReviewDay 3 - Agile Fundamentals - One of the most common points of Agile adoption failure comes with the incremental on-boarding of Agile teams throughout an organization while not having everyone starting with the same foundational Agile knowledge. This workshop session is designed to help everyone on the team learn the fundamental principles behind what makes Agile work, and allows them to participate in several real world exercises. This structure allows everyone on the team to learn the ‘Why' behind the ‘How', and gives everyone a chance to leave with the tools needed to effectively do their job better. This session is designed for both new Agile / Kanban teams learning the ropes and experienced Agile teams who are trying to re-align or get started on the same Agile footing while establishing an internal Agile Center of Excellence. This workshop is often coupled with Agile Coaching in order to increase the effectiveness and impact. The Three Keys - Seeking & Embracing Success: Success can be defined by each of us in many different ways. The truth is there are three keys to a successful personal and professional career. Once we discover these keys and learn to use them, we are gifted the ability of a lifetime of success. This personal journey will teach you the importance of making dreams come true and give you the tools to make that happen.Day 4 - C-Suite Engagement - Too many transformation efforts stall not because the work is hard, but because the right people weren't invited to the table — or they were, and nobody spoke their language. This session gives leaders a pragmatic, no-fluff playbook for turning executives from passive approvers into active sponsors. We'll strip away the jargon and replace it with three things executives actually pay attention to: clear outcomes, short bets, and repeatable governance. Expect real templates (one-page decision memos, sponsor cadence scripts), live translation exercises to turn team metrics into executive value, and role-play scenarios you can use the moment you return to the office. If you want predictable, funded change — not theater — this workshop will help you get it. Attendees will leave with: • A one-page executive brief template that gets decisions — fast. • A sponsor-activation cadence that prevents “ghost sponsorship.” • Three scripts to convert technical/operational language into strategic outcomes.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/

Time left estimation may be one of the simplest ideas in software delivery, but it directly challenges decades of traditional Agile estimation practices. Instead of treating estimates as fixed promises, the concept focuses on continuously updated delivery confidence. During the discussion with Alex Polyakov, this idea became one of the strongest execution-focused themes of the conversation. The goal is not perfect prediction. The goal is operational awareness. That distinction changes how teams communicate, coordinate, and deliver software. About Alex Polyakov Alex Polyakov is the founder of Project Simple AI, a platform designed to improve software delivery visibility and operational discipline for engineering organizations. His background spans engineering, architecture, product leadership, startup operations, and entrepreneurship across more than two decades in software development. He has led teams as a developer, architect, technical leader, product manager, and founder, giving him firsthand experience with the communication gaps and operational inefficiencies that slow modern software teams. Alex also hosts the "Let's Talk Agile" podcast on YouTube, where he explores software delivery, Agile practices, and modern engineering workflows. LinkedIn: https://www.linkedin.com/in/alexpolyakov/ Why Traditional Estimation Breaks Down Software teams have experimented with estimation models for years. Story points. Velocity scoring. Capacity planning. No-estimate methodologies. Hybrid systems. Each approach attempts to solve uncertainty while preserving predictability. The problem is that software development is inherently dynamic. Teams uncover unknown dependencies. Requirements evolve. Technical assumptions change. AI accelerates some implementation paths while introducing entirely new verification requirements. Static estimates fail because the work itself evolves. Alex described how many organizations accidentally treat estimates as guarantees. Once a developer says "four hours," stakeholders mentally convert that into a contractual promise. That mindset creates tension immediately. Developers become defensive about estimates. Managers become frustrated when timelines shift. Teams avoid updating reality because changing estimates feels like admitting failure. An estimate should communicate current understanding, not create artificial certainty. Time Left Estimation Creates Operational Awareness The core principle behind time left estimation is remarkably simple. Instead of asking: "How long did you think this would take?" Teams ask: "How much time remains?" That shift sounds small, but it fundamentally changes communication quality. Alex used a driving analogy during the interview. If someone asks where you are and you answer, "I'm in the car," that provides almost no operational value. That resembles many software status updates. "In progress" rarely tells leadership anything meaningful. A better response would be: "GPS says I'm five minutes away." Now stakeholders understand delivery confidence, remaining uncertainty, and expected timing. That is the real value of time left estimation. Why Time Left Estimation Improves Team Coordination One of the strongest operational arguments for this approach is coordination visibility. Modern software delivery is collaborative. Backend engineers hand work to frontend developers. QA teams validate implementation. Architects review integrations. Product teams prepare releases. DevOps engineers manage deployments. Software delivery depends heavily on sequencing. Time Left Estimation Helps Teams Predict Handoffs A continuously updated remaining-time estimate acts like a coordination beacon. It signals: Who is next When dependencies become active Whether blockers are emerging Whether downstream teams should prepare This creates significantly better operational flow than static task ownership systems. Instead of discovering delays during sprint reviews, teams identify delivery movement in real time. Static estimates often hide risk until delivery windows are already compromised. Time Left Estimation Aligns Better with AI Development AI-assisted development makes estimation harder and easier simultaneously. Some implementation tasks collapse from days into hours. Others become harder because AI-generated code requires stronger validation, testing, and architectural review. The conversation highlighted a major shift happening inside engineering organizations today. Developers are increasingly becoming reviewers, validators, and coordinators rather than pure code producers. That changes where uncertainty exists. The coding itself may accelerate dramatically. The verification process becomes more important. Traditional Agile estimation models were not designed for this environment. Time left estimation adapts more naturally because it reflects current conditions instead of relying entirely on original assumptions. The Real Goal Is Confidence, Not Precision One of the most practical ideas from the interview was that software organizations do not necessarily need perfect prediction. They need confidence. Leadership teams can make strong decisions when they understand: Current progress Remaining uncertainty Emerging risks Coordination readiness The problem is not changing estimates. The problem is discovering reality too late. Time Left Estimation Encourages Honest Communication Because remaining-time estimates are expected to evolve, teams become more comfortable updating status honestly. An estimate can decrease when work becomes easier. It can increase when new complexity appears. That flexibility reduces the emotional pressure attached to traditional software estimation. Healthy engineering communication depends more on transparency than forecasting perfection. Why Simpler Estimation Models Matter The transcript repeatedly returned to one consistent theme: software organizations have overcomplicated operational management. Heavy process structures often attempt to create predictability by adding more layers: More ticket fields More ceremonies More reporting More workflows More estimation rituals But complexity itself creates operational drag. Simple systems scale better because teams actually use them consistently. That may be the most important takeaway from Alex's philosophy. Software delivery is already difficult. The management layer should reduce friction, not multiply it. Audit your current estimation process and identify which activities improve delivery versus which only create reporting overhead. Conclusion Time left estimation is not just a different planning technique. It represents a different philosophy about software delivery communication. Instead of pretending uncertainty does not exist, the model embraces changing information and operational transparency. As AI reshapes implementation speed and software organizations continue evolving, delivery systems must become more adaptive, more collaborative, and more visibility-oriented. Teams that improve coordination awareness will outperform teams that optimize only for reporting structure. The future of engineering execution will likely depend less on rigid estimation frameworks and more on dynamic operational visibility. Stay Connected: Join the Developreneur Community

Mukhtar Kadiri: Merging Three Companies Into One Platform — When Founders Can't Let Go and Leaders Won't Decide 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.   "A lot of times, conflict arises because people don't understand each other. The first thing you need to do is make sure they understand each other." - Mukhtar Kadiri   Mukhtar brings us a challenge from a merger and acquisition program where a dominant software company acquired two competitors simultaneously — both solving the same market gap, each with their own platform, their own founders still in place, and their own fierce loyalties. The mission: merge three platforms into one. But the technical challenge was the easy part. The real complexity was human — founders who'd built their companies from scratch watching their babies potentially get retired, teams losing people to low morale and uncertainty, and leadership paralyzed by the knowledge that every decision would make somebody unhappy. Together, Mukhtar and Vasco explore a four-step approach to navigating these high-stakes disagreements: first, create a feeling of time abundance — never rush a decision that requires buy-in. Second, get each side to present their perspective with only clarifying questions, no judgment. Third, name the disagreement explicitly — turn emotions into concrete, debatable statements. And fourth, co-create an alternative solution that doesn't come from either original position, because co-creation builds commitment. Mukhtar adds a critical fifth element: steel-manning — having each side articulate the other's argument as if defending it. When people feel genuinely understood, even "disagree and commit" becomes possible.   In this episode, we refer to steel-manning and the concept of disagree and commit.   Self-reflection Question: When you're facilitating a disagreement between two strong positions, do you rush toward a decision — or do you invest the time to make sure both sides can articulate each other's argument before you even think about next steps?   [The Scrum Master Toolbox Podcast Recommends]

Project World | Business Analyst World - Day 2 ReviewBeyond Delivery - Project success is too often measured at delivery. On time, on scope, on budget, yet real value is frequently lost after the work is “done.” In today's evolving project and product environments, leaders are being asked to think beyond execution and focus on outcomes, adoption, and lasting impact. This session reframes project leadership through four enduring phases of successful work: Initiate (clarity and alignment), Discover (learning and risk reduction), Deliver (execution with feedback), and Release (adoption and value realization). While often associated with Agile thinking, these phases represent leadership behaviors that have always driven meaningful results when practiced well. Participants will explore how to manage stakeholder perceptions of value, make better decisions across the lifecycle, and ensure success is defined by outcomes, not just outputs. The session also introduces practical ways AI can support insight and decision-making, allowing leaders to focus more on judgment, communication, and impact. Key Takeaways Differentiate delivery success from value realization and explain why projects often fail after go-live. Apply the four phases (Initiate, Discovery, Delivery, Release) as a leadership lens across any delivery approach. Manage stakeholder perceptions of value throughout the lifecycle, not just at project close. Identify where value is commonly lost and take corrective action earlier. Use AI responsibly as a decision-support tool to improve insight, reduce risk, and strengthen outcomes.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/

Adam Creeger is the CTO of Slate and creator of iLoom (pronounced “il-LOOM”). His leadership experience at Meta, Greenhouse, and Frame.io not only informs Slate's transformation into an AI-native organization, but also shapes the way AI influences product strategy, engineering workflows, and operational models. Throughout his conversation with Sean and Dan, Adam argues that becoming AI native is not about layering AI features onto existing products. Instead, it requires companies to rethink how software is designed, built, and operated – from the ground up. His perspective offers a practical framework for product leaders navigating AI-driven transformation. Here's what else we learned: ‘AI Native' Requires Organizational Reinvention AI native organizations are willing to rethink every layer of their business, Adam says. Rather than adding AI features superficially, AI native organizations redesign workflows, team structures, and customer experiences around AI capabilities. He emphasized that AI transformation changes not only products, but also how people contribute inside organizations. “To be AI native requires this deep exercise in re-imagination and not just imagination,” Adam continues. “In an AI native company – from the day-to-day operations to the ‘who does what' – the roles and the owners of things are going to look very different.” AI is expanding participation across teams, enabling designers, support teams, and non-engineers to contribute directly to product delivery. That shift signals a major change for modern software organizations. AI and the Future of the Software Development Life Cycle (SDLC) Our conversation then turned to an exploration of how AI is already changing the traditional software development lifecycle. Years ago, Agile development emerged because humans had historically struggled to fully reason through complex systems before implementation. “I've realized that Agile was really a mitigation of a few things, mostly that we humans are limited in our abilities to reason through abstract concepts,” Adam says. “So when we thought about a software project, we didn't have the ability to see around corners and understand the problems we'd face – until it was real, until you really started playing with it. Turns out that many of those challenges are very solvable by AI, allowing us to go much deeper into the problem space without ever writing a line of code. In addition, AI-assisted planning allows teams to revisit some waterfall-style thinking, but with dramatically faster iteration and validation cycles. Product Managers’ New Role: Communicate Context Importantly, AI is actually elevating the role of product managers, Adam offers. Rather than acting primarily as tactical decision-makers, product leaders can (and should) focus on providing context that enables teams to make informed decisions independently. “More than ever, the product manager has become a role about providing context,” he adds. “PMs should be elevated to a much more strategic role, understanding the long-term vision and helping to translate that to engineers.” Adam also feels that PMs should be using AI to communicate ideas about the product vision much more effectively. That evolution creates a faster and more collaborative product environment. Teams can evaluate real implementations earlier, gather customer feedback sooner, and align around outcomes instead of specifications alone. [05:54] What it means to be ‘AI native’. Conceptually, it’s same as digital native from when the internet was born many years ago. In the abstract sense, I see AI native being about the folks and the companies that are either just starting in the age of AI where everything they do is shaped by the existence of AI and their ability to use AI. [15:08] Is waterfall making a comeback? Oh man, this is one of my favorite topics. Growing up in the industry, waterfall was always like the evil thing. But with AI-assisted coding or agentic coding, you can go really deep, create a much bigger scope, and deliver it much more quickly…and it resembles more of a waterfall mentality. [21:51] The PM’s primary role: providing context. The product manager more than ever has become a role about providing context. The most powerful thing PMs can do in an organization is provide context to other people. [25:49] Exploring Adam’s iloom tool, and how it can help. Hear a quick story from Adam about how he used his iloom tool to create — and demo — a new product feature during a call with his customer success team. [28:47] Swarms. What are they, and how do they work? A swarm is a number of AI agents working together in a very collaborative way with the potential of real-time communication between them. [35:03] Avoiding ‘AI slop’ to defend and elevate a brand’s quality bar. Slate is creating a tool that makes it very difficult to create AI slop. This is a valuable proposition to brands that care deeply about what gets produced in their name. The post 187 / AI Native: Reimagining Product Roles and Development Cycles, with Adam Creeger appeared first on ITX Corp..

Want to improve team communication, build a stronger work culture, and lead with more confidence? In this episode, Nicole Greer sits down with organizational psychologist and author Yadi Caro to unpack why soft skills are actually the hardest and most important skills in business today. Yadi Caro is the author of Hardcore Soft Skills: A Guide to Work with Humans.  In it, she explores the communication, collaboration, conflict management, and leadership skills that make organizations truly effective.Yadi shares practical strategies for building high-performing teams, improving workplace communication, handling conflict productively, giving effective feedback, leading through change, and creating meetings that “suck less.” The conversation also dives into emotional intelligence, empathy, networking, problem-solving, and why AI will never replace genuine human connection.If you want to improve your leadership skills, strengthen your organizational culture, and become better at working with humans, this episode is packed with actionable insights.In this episode:Why “soft skills” are actually hardcore skillsThe role of self-awareness in leadershipHow empathy improves team performanceWhy listening is a competitive advantageHow to prevent workplace misunderstandingsBetter ways to give and receive feedbackConflict management strategies that build stronger teamsWhy productive meetings matterLeadership skills AI can't replaceHow to create a more vibrant workplace cultureGet Yadi's book: Hardcore Soft Skills: A Guide to Work with HumansYadi Caro is an organizational psychology practitioner, certified Agile coach, and Harvard-trained expert who has worked with developer teams, engineers, and US military organizations for over 15 years. Her book, Hardcore Soft Skills: A Guide to Working with Humans, is a hands-on workbook packed with frameworks, assessments, and exercises you can use immediately. Learn more about Yadi: Yadi Caro Official Website: https://www.yadicaro.com/The Build a Vibrant Culture Podcast helps leaders improve work culture, communication, and business performance through real-world leadership strategies and practical insights. Click here to view the episode transcript. Learn more about training, coaching, and courses at https://vibrantculture.comConnect on LinkedIn: https://www.linkedin.com/in/build-a-vibrant-culture-nicole-greer/For speaking inquiries: https://vibrantculture.com/speaker-kit-request/Download our training catalog: https://vibrantculture.com/catalog-request/Want to be a guest? Send your request to podcast@vibrantculture.com

Is AI actually helping us escape the build trap, or just helping us build the wrong things faster?In this episode of Arguing Agile, hosts Brian Orlando and Om Patel discuss the new AI4Agile Practitioners Report 2026 from Scrum.org. The data reveals a startling trend: while 83% of practitioners have access to AI tools, the primary fear isn't job replacement, it's that AI is becoming a "supercharged way into the feature factory."Listen or watch as we examine the report's key findings, including the gap between AI access (83%) and actual competence (only 15% received formal training). We discuss why the reported productivity gains (73.7%) might be masking the erosion of agile values like reflection and collaboration. Citing Melissa Perri's "Escaping the Build Trap," we explore how organizations are using AI to accelerate output without redesigning workflows to improve outcomes.Key topics include:Why "speed of delivery" was never the real bottleneckWhat practitioners really fearThe lack of workflow redesign in the AI eraFive actionable questions to test if your team is escaping or acceleratingTune in to learn how to ensure your AI adoption drives value, not just volume.#Agile #ProductManagement #AIEscaping the Build Trap by Melissa Perri, The Goal by Eliyahu M. Goldratt, AI4Agile Practitioners Report 2026 by Scrum.org, Crossing the Chasm by Geoffrey MooreLINKSYouTube: https://www.youtube.com/@arguingagileSpotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596INTRO MUSICToronto Is My BeatBy Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Mukhtar Kadiri: When the Smartest Person on the Team Becomes the Biggest Bottleneck — And Explodes in a Meeting 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.   "A lot of times, the problem is not necessarily technical. It's a human problem. Just figuring out the human dynamics removes the obstacles and makes the project flow." - Mukhtar Kadiri   Mukhtar was brought into a healthcare software project where the team couldn't hit any of their milestones. The product manager, engineering team, and head of engineering were supposed to be self-sustaining, but chaos reigned. What Mukhtar found through his one-on-ones was a pattern of finger-pointing — product blaming engineering, engineering blaming product. Then, in one meeting, the head of engineering exploded. He burst out yelling in front of the entire team. In a private conversation afterward, Mukhtar discovered the root cause: this brilliant architect was a bottleneck. Everyone depended on him, he was stretched across multiple projects, and the frustration had been building with no outlet. Mukhtar's approach was direct — "Your name is on this project. Yelling is not going to help." But the real insight came from what happened next. Once the head of engineering started controlling his outbursts, team morale improved almost immediately. Combined with basic structure — regular meetings, low-hanging-fruit milestones — the team built momentum and eventually became self-sufficient. The lesson? No matter how technical the challenge looks, it's always a people problem. And one-on-ones aren't just status updates — they're pressure valves that prevent public explosions that can cause irreparable damage to team morale.   Self-reflection Question: Is there someone on your team who's carrying too much load in silence — and what would it take for you to create a safe space where they can express that frustration before it boils over? Featured Book of the Week: HBR Project Management Handbook by Antonio Nieto-Rodriguez Mukhtar recommends the HBR Project Management Handbook because, as he puts it, "A lot of project management books, I can read them and it's almost like I'm not really learning anything new. But this one had substance." After stumbling into project management and leading projects for seven years before even pursuing his PMP, Mukhtar found that most PM books simply codified what he already knew from experience. The HBR handbook was different — it offered breadth, depth, and fresh approaches to common project management challenges. He also recommends the Rita Mulcahy PMP Exam Prep for those preparing for PMP certification, noting that studying for the exam crystallized frameworks around things he had been doing instinctively.   [The Scrum Master Toolbox Podcast Recommends]

Software delivery clarity has become one of the most important competitive advantages for engineering organizations. Teams are shipping faster, AI-assisted development is compressing implementation timelines, and traditional project management systems are struggling to keep pace with modern software delivery realities. During the conversation with Alex Polyakov, one idea surfaced repeatedly: most project management systems promise visibility but fail to provide actual operational clarity. Teams still discover delays too late. Executives still receive bad news at the last possible moment. Developers still spend excessive time updating systems rather than building software. That disconnect is exactly what inspired Alex to rethink how engineering organizations manage software delivery. About Alex Polyakov Alex Polyakov is the founder of Project Simple AI, a platform focused on improving transparency and discipline across software delivery workflows. With more than 25 years of experience spanning software engineering, architecture, product management, entrepreneurship, and startup leadership, Alex brings a deeply practical perspective to modern development operations. He has worked as an Application Developer, Senior Engineer, Tech Lead, Software Architect, Solutions Architect, Product Manager, Entrepreneur, and Startup Founder. Today, his focus is helping engineering teams gain visibility and operational discipline without adding unnecessary complexity. Alex also hosts the "Let's Talk Agile" podcast on YouTube, where he discusses modern software development challenges and Agile transformation realities. LinkedIn: https://www.linkedin.com/in/alexpolyakov/ Why Software Delivery Clarity Still Doesn't Exist Most organizations believe they have visibility because they use Jira, Azure DevOps, or similar tools. In reality, they have tracking systems, not visibility systems. Alex described modern project management tools as "glorified Excel sheets." That description lands because many engineering teams recognize the pattern immediately. Endless ticket hierarchies, fields, statuses, and sprint rituals often create administrative complexity without improving confidence. The core issue is simple: status updates depend on human behavior. Developers forget to update tickets. Teams delay reporting problems. Managers discover schedule risks only when deadlines are already compromised. The tooling creates an illusion of control while actual delivery risk remains hidden. That creates a dangerous operating environment for leadership. A founder or executive can solve a delivery problem early. They can reduce scope, renegotiate timelines, allocate additional staff, or re-sequence priorities. But once a team waits until the final week to communicate delays, most strategic options disappear. Visibility is not the same thing as documentation. Visibility means understanding delivery risk early enough to respond. Software Delivery Clarity Requires Behavioral Design One of the most interesting concepts from the discussion was the idea that project management is partly behavioral science. Most tools allow teams to skip critical disciplines. Teams can start work before decomposition. They can mark tasks complete without validating outcomes. They can carry partially defined requirements into implementation. Alex's approach flips that model entirely. Instead of giving teams unlimited flexibility, the system enforces operational readiness. Work cannot begin without decomposition. Timelines cannot exist without estimates. Completion cannot happen without verifying a definition of done. This is important because software organizations often assume process problems are communication problems. In reality, many are workflow design problems. If a system permits ambiguity, ambiguity becomes normalized. If a system requires clarity, clarity becomes operational behavior. Why AI Makes Software Delivery Clarity More Important AI-assisted development changes the economics of software delivery. Implementation cycles are shrinking dramatically. Tasks that previously required days may now take hours. Boilerplate code generation, scaffolding, testing support, and architectural suggestions accelerate execution speed. That acceleration creates a new challenge. If implementation becomes faster, bottlenecks move upstream and downstream. Requirements gathering, coordination, prioritization, testing, and validation suddenly become the limiting factors. This means organizations can no longer rely on heavyweight process management structures built for slower delivery cycles. When implementation speeds increase but operational visibility stays static, delivery chaos accelerates instead of improving. The transcript discussion highlighted a critical reality many organizations are only beginning to recognize: AI amplifies existing operational weaknesses. A disorganized engineering team using AI becomes a faster disorganized engineering team. That is why delivery clarity matters more now than it did during earlier Agile transformations. The Simplicity Principle Behind Better Delivery Alex outlined several operational principles that simplify software execution dramatically. Software Delivery Clarity Starts with Prioritization Teams should know exactly what matters most. Priority order should not be vague or political. If only one item can ship, teams must know which item wins. That sounds obvious, but many organizations operate with dozens of simultaneous "critical" initiatives. Clear sequencing eliminates organizational confusion. Software Delivery Clarity Depends on Finishable Work Teams should not start work that they cannot complete. This principle directly attacks excessive work in progress — one of the most common hidden inefficiencies in software organizations. Partially completed work creates coordination overhead, testing delays, context switching, and reporting confusion. Smaller, decomposed work creates measurable progress. Software Delivery Clarity Improves Team Accountability Alex also challenged pre-assigned work structures. When work is individually distributed too early, collaboration weakens. Teams lose shared ownership. Visibility becomes fragmented across individuals instead of remaining centralized around delivery goals. That perspective aligns closely with modern product-oriented engineering cultures where collaboration and flow matter more than rigid task ownership. Before adding new process layers, evaluate whether your current workflow already contains unnecessary coordination overhead. Why Simpler Engineering Systems Scale Better Many organizations assume maturity means adding process. The conversation suggested the opposite. Mature engineering organizations often remove unnecessary friction instead of introducing more operational complexity. Simplicity improves adoption, consistency, and decision-making speed. This becomes especially important in high-growth environments. As teams scale, communication overhead compounds rapidly. Every unnecessary workflow step multiplies across developers, product managers, QA engineers, architects, and leadership stakeholders. Simple systems reduce cognitive load. That reduction creates operational focus. The goal of project management is not to track work forever. The goal is to deliver valuable software predictably. Conclusion Software delivery clarity is not about more dashboards, more ceremonies, or more ticket customization. It is about creating operational confidence. Alex Polyakov's perspective challenges many assumptions that modern engineering organizations accept as normal. Teams do not necessarily need more process. They need better behavioral systems, clearer visibility, stronger prioritization, and simpler operational structures. As AI continues accelerating implementation speed, organizations that simplify coordination and improve transparency will gain a meaningful competitive advantage. The future of software delivery may not belong to the teams with the most process sophistication. It may belong to the teams with the clearest operational discipline. Stay Connected: Join the Developreneur Community

Jamie Sullivan, TLIS, joins the podcast to share her veteran perspective on shifting from rigid software platforms to agile, user-centric systems. She discusses the power of regional collaboration through her year-long AI leadership cohort and explains why technology departments must prioritize "academic teching" to keep the focus on student learning.Castilleja SchoolToddle LMSVeracrossRuvna Safety SolutionsEric Hudson (Facilitator)Coachella Music Festival (Mentioned)SeniorNet (Mentioned)TLIS Certification

Mukhtar Kadiri: The Invisible Stakeholder Who Almost Derailed His First Big Project 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.   "Nobody really told me, okay, this is what success looks like. And that's a very dangerous thing, because you can just go in there and be busy and be executing." - Mukhtar Kadiri   Early in his career, Mukhtar was sitting on the bench with nothing to do — and his days felt numbered. When a low-priority project came along, he jumped at it, eager to prove himself. He met the contract holder, understood the terrain, laid out a plan, and started executing. Then a stakeholder he hadn't even mapped called him into her office and blasted him. The project wasn't aligned with her vision — and it turned out she was more powerful than the contract holder, even though she appeared nowhere on the org chart. That moment forced Mukhtar to rethink everything. He started scheduling one-on-ones with every stakeholder he could find, asking each one what success looked like from their perspective, and then asking them to point him to the next person he should talk to. What emerged was a comprehensive success criteria that no single person had articulated before — because even the leaders hadn't sat down to define it. Mukhtar learned that in complex, ambiguous environments, success isn't handed to you. It's your job to surface it, articulate it, and get everyone aligned. As he puts it, don't be fooled by org charts — the real stakeholder map is one you have to build yourself through one-on-one conversations.   Self-reflection Question: When was the last time you validated your stakeholder map beyond the org chart — and could there be an invisible stakeholder whose definition of success you haven't yet discovered?   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: From Desk-Pounding to Harmony — How the Game of Go Transformed a Violent Product Owner, and Why Every Employee Should Think Like an Owner In this episode, we refer to The Agile Way by Peter Merel and The Great Game of Business by Jack Stack. The Great Product Owner: The Real Estate Visionary Who Built Channels of Learning Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When a product owner brings an attitude of learning together, it doesn't just create psychological safety — it creates an active experimental mindset and a network of trust relationships that support each other in the learning process." - Peter Merel   The best product owner Peter has worked with is Ben White, one of three brothers and partners in Ray White — Australia's largest property management business, started by Ben's great-grandfather. Ben had a vision for transforming how property management works across the entire Australian industry. To realize this vision, he tried to bring an app to market — and failed. Not once, but twice, before succeeding on the third attempt. What made Ben exceptional wasn't his persistence alone, but that each failure became an opportunity to learn how to approach the problem differently. The product he finally brought to market was informed by all of that learning. Ben's real genius, Peter explains, is his ability to establish channels of learning — trust relationships that flow not just through the technical team, but throughout the entire business and back into product development. Without those trust relationships, psychological safety alone isn't enough. Peter also emphasizes that the product owner should be a servant leader, and points to Jack Stack's open book management model where every employee is motivated to think and act as a business owner. When everyone understands that the future of the business is their future, they all collaborate as product owners — and the need for desk-pounding disappears entirely.   Self-reflection Question: How many channels of learning does your product owner currently have — and are there trust relationships in the organization that could become active channels but haven't been tapped yet? The Bad Product Owner: The Violent Visionary Who Didn't Understand Collaboration 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 problem isn't the role of product owner. The problem is the relationship between product owner and everybody else." - Peter Merel   At Commonwealth Bank of Australia, Peter worked with a business executive who drove the development of a digital product that generated $2 billion in business for the bank. By any business measure, this person was extraordinarily successful. But as a product owner, he was terrible. He pounded desks, went red in the face, insisted that everything the team was doing was wrong, didn't trust anyone, and couldn't be trusted either. The core anti-pattern wasn't the shouting itself — it was that this person didn't understand what a collaborative relationship needed to be. Peter found a creative solution: he taught the executive the game of Go. Go rewards harmony — you lose by being too passive, and you lose by being too aggressive. Through Go, Peter taught the executive to create prompting questions, to work through others so they would carry concerns into meetings, and to provide answers rather than demands. Once the executive saw that collaboration was a more effective way to realize his own vision — faster, better, and more reliably — the behavior changed completely. The insight Peter shares is that before coaching behavior, you sometimes have to prove the business case for collaboration itself.   In this segment, we refer to The Agile Way by Peter Merel, which Peter now gives to product owners as a framework for understanding collaborative relationships.   Self-reflection Question: When you encounter a product owner who leads through demands rather than collaboration, have you considered showing them that collaboration is actually a faster path to getting what they want?   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: Leadership as a Service — Why Scrum Masters Should Work Themselves Out of a Job and How Quality Circles Make Learning Flow 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.   "A Scrum Master is a self-defeating role. If you have worked yourself out of a job, then you've succeeded." - Peter Merel   Peter Merel challenges the very notion of the Scrum Master as a permanent organizational role. He argues that calling someone a "master" makes everyone else a servant — the opposite of what agile teams need. Instead, Peter advocates for leadership as a service, where every team member provides leadership to their team and every member of a swarm provides leadership to their swarm. He points to the Haudenosaunee Confederacy — the successful direct democratic republic that existed in North America before the USA, and which influenced the American founding fathers — as a model for distributed leadership. The protocol is simple enough to apply universally, regardless of organizational structure. Peter's practical approach to success measurement is equally compelling: build a thin steel thread of alignment, prove it works in 8 to 12 weeks, then split it and backfill with the most progressive people in the organization. He describes growing a group of 300 in just 9 months using this approach. The key insight is that coaches should not think of themselves as change agents, but rather as people who transform change participants into change leaders. Once a team can self-organize without you, your job is to move on to the next challenge — and that's what success looks like.   In this episode, we refer to the concept of leadership as a service and the XScale Alliance.   Self-reflection Question: If you stepped away from your team tomorrow, could they self-organize effectively — and if not, what's the one thing you could teach them this week that would bring them closer to not needing you? Featured Retrospective Format for the Week: Quality Circles Peter Merel recommends quality circles as a cross-team retrospective format drawn from the Toyota Production System. The concept is simple but powerful: take three teams of six people and break them into six quality circles of three — one person from each team in each circle. These circles meet regularly for 10 to 30 minutes, ideally before team planning sessions, to share problems, ideas, and ways they can help each other. The magic of three people is that while one person explains, another listens, and the third is already thinking about where the conversation goes next — creating what Peter calls "a beautiful hum." Each circle brings two kinds of ideas back to their team: proposals for work that would benefit the teams as a whole, and treaties — working agreements between teams. The teams remain autonomous and can decide how to respond. Peter emphasizes that this approach scales naturally — representatives from groups of teams can form quality circles at higher levels, keeping face-to-face communication alive across entire organizations. As Peter puts it, "Learnings flow across the organization — and that's more valuable than anything you can come up with in a retrospective by yourself."   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: AI Alignment Is the Agile Coach's Next Frontier — Using Throughput Accounting and Pull-Based Transformation to Prove Value 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.   "Our jobs ARE about alignment. Alignment is how do we get all of the people and all of the tools to work together for mutual benefit." - Peter Merel   Peter Merel brings a provocative perspective on the biggest challenge facing agile professionals today: AI and agile alignment. With AI rapidly advancing, Peter observes that everyone in the agile community is afraid for their jobs — but argues this fear is misplaced. The real challenge isn't replacement; it's alignment. How do we get biological and electronic entities to work together for mutual benefit? Peter's answer begins with pull-based transformation — building a thin steel thread from business through to DevOps, proving it works with a small group, then growing it. He connects this to Goldratt's throughput accounting, arguing that throughput (operating expense plus net profit) is the only metric immune to Goodhart's Law. From throughput, Peter derives three flows: value flow (throughput itself), workflow (the first derivative — what increases value flow), and learning flow (the second derivative — what improves workflow). He then introduces the pirate metrics (AARRR) — acquisition, activation, retention, referral, and revenue — as market constraints that can be analyzed through Theory of Constraints. Peter's frustration is that 25 years after Agile began, most business stakeholders still can't identify their market bottleneck. Without that knowledge, he argues, priorities are meaningless. The path forward for agile coaches? Bring scientific rigor to transformation, measure what matters, and prove value before scaling.   In this episode, we refer to FAST Agile, Joe Justice's work with Tesla and WikiSpeed, and the connection between throughput accounting and agile transformation metrics.   Self-reflection Question: Can you identify the single biggest market constraint limiting your organization's throughput right now — and if not, how confident are you that your current priorities are the right ones?   [The Scrum Master Toolbox Podcast Recommends]

Ever wondered why one song can instantly give you chills… while another makes you feel nothing at all?In this episode, Selina Meere, COO of Trevanna Tracks, pulls back the curtain on the invisible system behind the music you feel in films, ads, and media. From navigating complex rights and scaling music operations for global brands to leading without a playbook, this conversation dives deep into what it really takes to operate at the intersection of creativity, technology, and leadership.They explore the realities of being a COO, managing elite teams, making high-stakes decisions, and building trust in environments where there are no clear answers.If you want to understand how world-class operators think, lead, and execute under pressure, don't wait. The cost of staying reactive instead of strategic is too high. Hit play now for insights you won't hear anywhere else.Timestamped Highlights[00:00] – The hidden force behind why certain songs instantly trigger emotion in movies and ads[02:14] – Why music licensing became exponentially more complex, and what most people don't realize[04:21] – The “Excel breaking point” that led to building a completely new category in media[06:37] – From book publishing to COO, the unexpected career pivot that changed everything[11:00] – The moment she had to learn DevOps, Agile, and engineering… from scratch[13:40] – The leadership mistake most companies make during major internal transformations[17:11] – How top teams actually prioritize when every client thinks their request is urgent[19:01] – The hardest part of being a COO, and why there's no such thing as a playbook[28:12] – The real way to build confidence when making big, high-risk decisions[31:54] – Why asking questions can quietly destroy trust, and how to fix itAbout the GuestSelina Meere is the COO of Trevanna Tracks, a pioneering music rights and workflow platform serving some of the largest media and entertainment companies in the world. With a background in publishing and PR, she has built a career partnering closely with founders to scale businesses, optimize operations, and drive growth across industries. Known for her adaptability and strategic thinking, Selina specializes in leading high-performance teams in complex, fast-evolving environments.

What if your most visible, most exciting product wasn't your real product at all, but was actually a Trojan horse for building a much deeper, stickier customer relationship? Agility requires more than just a willingness to change; it demands a deep understanding of what truly motivates your customer, allowing you to evolve your model in service of their emotional outcomes, not just their transactional needs. Today, we're going to talk about how a brand can embody the very principle it sells, turning a core service into a flywheel for customer retention, emotional engagement, and scalable business growth. To help me discuss this topic, I'd like to welcome, Mark Van Wye, CEO at Zoom Room. About Mark Van Wye Mark Van Wye is the CEO of Zoom Room, the nation's premier dog training franchise, and the author of the #1 bestselling Puppy Training in 7 Easy Steps. He's a systems architect who saw white space in the $100 billion pet industry and positioned dog training as behavioral infrastructure for modern life. A lifelong builder of scalable learning environments, he taught adults to code at eleven, developed a national learning platform for the Boys & Girls Clubs of America, and has spent his career designing environments – physical and digital – that scale without losing their human edge. Mark Van Wye on LinkedIn: https://www.linkedin.com/in/zoomroom/ Resources Zoom Room: https://www.zoomroom.com The Agile Brand podcast is brought to you by TEKsystems. Learn more here: https://aglbrnd.co/r/2868abd8085a9703 Drive your customers to new horizons at the premier retail event of the year for Retail and Brand marketers. Learn more at CRMC 2026, June 1-3. https://aglbrnd.co/r/d15ec37a537c0d74 We're proud to be a media partner for #MAICON26 - Oct. 13-15! Learn how AI can power your marketing and business and help you grow smarter. Use code AGILE150 to save! https://aglbrnd.co/r/7fe458ced0f04658 Enjoyed the show? Tell us more at and give us a rating so others can find the show at: https://aglbrnd.co/r/faaed112fc9887f3 Connect with Greg on LinkedIn: https://www.linkedin.com/in/gregkihlstromDon't miss a thing: get the latest episodes, sign up for our newsletter and more: https://aglbrnd.co/r/35ded3ccfb6716ba Check out The Agile Brand Guide website with articles, insights, and Martechipedia, the wiki for marketing technology: https://www.agilebrandguide.com The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company

What if your most visible, most exciting product wasn't your real product at all, but was actually a Trojan horse for building a much deeper, stickier customer relationship?Agility requires more than just a willingness to change; it demands a deep understanding of what truly motivates your customer, allowing you to evolve your model in service of their emotional outcomes, not just their transactional needs.Today, we're going to talk about how a brand can embody the very principle it sells, turning a core service into a flywheel for customer retention, emotional engagement, and scalable business growth.To help me discuss this topic, I'd like to welcome, Mark Van Wye, CEO at Zoom Room. About Mark Van Wye Mark Van Wye is the CEO of Zoom Room, the nation's premier dog training franchise, and the author of the #1 bestselling Puppy Training in 7 Easy Steps. He's a systems architect who saw white space in the $100 billion pet industry and positioned dog training as behavioral infrastructure for modern life. A lifelong builder of scalable learning environments, he taught adults to code at eleven, developed a national learning platform for the Boys & Girls Clubs of America, and has spent his career designing environments – physical and digital – that scale without losing their human edge. Mark Van Wye on LinkedIn: https://www.linkedin.com/in/zoomroom/ Resources Zoom Room: https://www.zoomroom.com The Agile Brand podcast is brought to you by TEKsystems. Learn more here: https://aglbrnd.co/r/2868abd8085a9703 Drive your customers to new horizons at the premier retail event of the year for Retail and Brand marketers. Learn more at CRMC 2026, June 1-3. https://aglbrnd.co/r/d15ec37a537c0d74 We're proud to be a media partner for #MAICON26 - Oct. 13-15! Learn how AI can power your marketing and business and help you grow smarter. Use code AGILE150 to save! https://aglbrnd.co/r/7fe458ced0f04658 Enjoyed the show? Tell us more at and give us a rating so others can find the show at: https://aglbrnd.co/r/faaed112fc9887f3 Connect with Greg on LinkedIn: https://www.linkedin.com/in/gregkihlstromDon't miss a thing: get the latest episodes, sign up for our newsletter and more: https://aglbrnd.co/r/35ded3ccfb6716ba Check out The Agile Brand Guide website with articles, insights, and Martechipedia, the wiki for marketing technology: https://www.agilebrandguide.com The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company Hosted on Acast. See acast.com/privacy for more information.