Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't | Tudor Girba

Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't | Tudor Girba

AI Assisted Coding: Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't With Tudor Girba

In this BONUS episode, we explore Moldable Development with Tudor Girba, CEO of feenk.com and creator of the Glamorous Toolkit. We dive into why developers spend over 50% of their time reading code—not because they want to, but because they lack the answers they need. Tudor shares how building contextual tools can transform software development, making systems truly understandable and enabling decisions at the speed of thought.

The Hidden System: A Telco's Three-Year Quest

"They had a system consisting of five boxes, but they could only enumerate four. If this is your level of awareness about what is reality around you, you have almost no chance of systematically affecting that reality."

Tudor opens with a striking case study from a telecommunications company that spent three years and hundreds of person-years trying to optimize a data pipeline. Despite massive effort and executive mandate, the pipeline still took exactly one day to process data—no improvement whatsoever. When Tudor's team investigated, they asked for an architecture diagram. The team drew four boxes representing their system. But when Tudor's team started building tools to mirror this architecture back from the actual code, they discovered something shocking: there was an entire fifth system between the first and second boxes that nobody knew existed. This missing system was likely the bottleneck they'd been trying to optimize for three years.

Why Reading Code Doesn't Scale

"Developers spend more than 50% of their time reading code. The problem is that our systems are typically larger than anyone can read, and by the time you finish reading, the system has already changed many times."

The real issue isn't the time spent reading—it's that reading is the most manual, least scalable way to extract information from systems. When developers read code, they're actually trying to answer questions so they can make decisions. But a 250,000-line system would take one person-month to read at high speed, and the system changes constantly during that time. This means everything you learned yesterday becomes merely a hypothesis, not a reliable answer. The fundamental problem is that we cannot perceive anything in a software system except through tools, yet we've never made how we read code an explicit, optimizable activity.

The Context Problem: Why Generic Tools Fail

"Software is highly contextual, which means we can predict classes of problems people will have, but we cannot predict specific problems people will have."

Tudor draws a powerful parallel with testing. Nobody downloads unit tests from the web and applies them to their system—that would be absurd. Instead, we download test frameworks and build tests contextually for our specific system, encoding what's valuable about our particular business logic. Yet for almost everything else in software development, we download generic tools and expect them to work. This is why teams have tens of thousands of static analysis warnings they ignore, while a single failing test stops deployment. The test encodes contextual value; the generic warning doesn't. Moldable Development extends this principle: every question about your system should be answered by a contextual tool you build for that specific question.

Tools That Mirror Your Mental Model

"Whatever you draw on the whiteboard—that's your mental model. But as soon as the system exists, we want the system to mirror you back that thing. We make it the job of the system to show our mental model back to us."

When someone draws an architecture diagram on a whiteboard, they're not documenting the system—they're documenting their beliefs about the system. The diagram represents wishes when drawn before the system exists, but beliefs when drawn after. Moldable Development flips this: instead of humans reading code and creating approximations, the system itself generates the visualization directly from the actual code. This eliminates the layers of belief and inference. Whether you're looking at high-level architecture, data lineage across multiple technologies, performance bottlenecks, or business domain structure, you build small tools that extract and present exactly the information you need from the system as it actually is.

The Test-Driven Development Parallel

"Testing was a way to find some kind of class of answers. But there are many other questions we have, and the question is: is there a systematic way to approach arbitrary questions?"

Tudor explains that Moldable Development applies test-driven development principles to all forms of system understanding. Just as we write tests after we understand the functionality we need, we build visualization and analysis tools after we understand the questions we need answered. Both approaches share key characteristics: they're built contextually for the specific system, created by developers during development, and composed of many small tools that collectively model the system. The difference is that TDD focuses on functional decomposition and known expectations, while Moldable Development addresses architecture, security, domain structure, performance, and any other perspective where functional tests aren't the most useful decomposition.

From Thousands of Features to Thousands of Tools

"In my development environment, I don't have features. I have thousands of tools that coexist. Development environments should be focused not on what exists out of the box, but on how quickly you can create a contextual tool."

Traditional development environments offer dozens of features—buttons, plugins, generic views. But Moldable Development environments contain thousands of micro-tools, each answering a specific question about a specific system. The key is making these tools composable and fast to create. Rather than building monolithic tools that try to handle every scenario, you build small inspectors that show one perspective on one object or concept. These inspectors chain together naturally as you drill down from high-level questions to detailed investigations. You might have one inspector showing test failures grouped by exception type, another showing PDF document comparisons, another showing cluster performance, and another showing memory usage—all coexisting and available when needed.

The Real Bottleneck To Learning A System: Time to the Next Question

"Once you do this, you will see that the interesting bottleneck is in the time to the next interesting question. This is by far the most interesting place to be spending energy."

When you commoditize access to answers through contextual tools, something remarkable happens: the bottleneck shifts from getting answers to asking better questions. Right now, because answers come so slowly through manual reading and analysis, we rarely exercise the skill of formulating good questions. We make decisions based on gut feelings and incomplete data because we can't afford to dig deeper. But when answers arrive at the speed of thought, you can explore, follow hunches, test hypotheses, and develop genuine insight. The conversation between person and system becomes fluid, enabling decision-making based on actual evidence rather than belief.

Moldable Development in Practice: The Lifeware Case

"They are investing in software engineering as their competitive advantage. They have 150,000 tests that would take 10 days to run on a single machine, but they run them in 16 minutes distributed across AWS."

Tudor shares a powerful case study of Lifeware, a life insurance software company that was featured in Kent Beck's "Test-Driven Development by Example" in 2002 with 4,000 tests. Today they have 150,000 tests and have fully adopted Moldable Development as their core practice. Their business model is remarkable: they take data from insurance companies, throw away the old systems, and reverse-engineer new systems by TDD-ing the business—replaying history to produce pixel-identical documents. They've deployed Glamorous Toolkit as their sole development environment across 100+ developers. Their approach demonstrates that Moldable Development isn't just a research concept but a practical competitive advantage that scales to large teams and complex systems.

Why AI Doesn't Solve This Problem

"When you ask AI, you will get exactly the same kind of answers. The answer comes quickly, but you will not know whether this is accurate, whether this represents the whole thing, and you definitely do not have an explanation as to why the answer is the way it is."

In the age of AI code assistants, it might seem like language models could solve the problem of understanding systems. But Tudor explains why they can't. When you ask an AI about your architecture, you get an opinion—fast but unverifiable. Just like asking a developer to draw the architecture on a whiteboard, you receive filtered information without knowing if it's complete or accurate. Moldable Development, by contrast, extracts answers deterministically from the actual system. Software systems have almost no ambiguity in meaning—they're mathematical, not linguistic. We don't need probabilistic interpretation of source code; we need precise extraction and presentation. The tools you build give you not just answers but explanations of how those answers were derived from the actual system state.

Scaling Through Language, Not Features

"You need a new kind of development environment where the goal is to create tools much quicker. You need some sort of language in which to express development environments."

The technical challenge of Moldable Development is enabling thousands of tools to coexist productively. This requires a fundamentally different approach to development environments. Instead of adding features—buttons and menu items that quickly become overwhelming—you need a language for expressing tools and a system for composing them. Glamorous Toolkit demonstrates this through its inspector architecture, where any object can define custom views that appear contextually. These views compose naturally as you navigate through your investigation, reusing earlier perspectives while adding new ones. The environment becomes a medium for tool creation, not just a collection of pre-built features.

Making the Invisible Visible

"We cannot perceive anything in a software system except through a tool. If that's so important, then the ability to control that shape is probably kind of important too."

Software has no inherent shape—it's just data. Every perception we have of it comes through some tool that renders it into a form we can reason about. This means tools aren't nice-to-have accessories; they're fundamental to our ability to work with software at all. The text editor showing code is a tool. The debugger showing variables is a tool. But these are generic tools built once and reused everywhere, which means they show generic perspectives. What if we could control the shape of our software as easily as we write it? What if the system could show us exactly the view we need for exactly the question we have? That's the promise of Moldable Development.

About Tudor Girba

Tudor Girba is CEO of feenk.com and creator of Moldable Development. He leads the team behind Glamorous Toolkit, a novel IDE that helps developers make sense of complex systems. His work focuses on transforming how teams understand, navigate, and modernize legacy software through custom, insightful tools. Tudor and Simon Wardley are writing a book about Moldable Development which you can get at: https://moldabledevelopment.com/, and read more about in this Medium article.

You can link with Tudor Girba on LinkedIn.

Jaksot(200)

BONUS Tom Gilb: Building True Engineering Culture and Delivering Value Through Evolutionary Methods

BONUS Tom Gilb: Building True Engineering Culture and Delivering Value Through Evolutionary Methods

BONUS: Tom Gilb on Building True Engineering Culture and Delivering Value Through Evolutionary Methods In this BONUS episode, we dive deep into the world of true engineering discipline with Tom Gilb, a pioneer who was writing about Agile principles before Agile was even named. We explore his latest book "Success - Super Secrets & Strategies for Efficient Value Delivery in Projects and Programs, and Plans" and uncover the fundamental flaws in how organizations approach project delivery and stakeholder management. The Genesis of Success-Focused Engineering "People were failing at project deliveries - even when using Agile. I saw there was very little about setting clear goals and reaching them, it had nothing to do with being successful." Tom's motivation for writing his latest book stems from a critical observation: despite the widespread adoption of Agile methodologies, project failure rates remain unacceptably high. The core issue isn't methodology but rather the fundamental lack of clarity around what success actually means. Tom emphasizes that true success is about achieving the improvements you want at a price you can afford, yet most organizations fail to define this clearly from the outset. In this segment, we refer to the book How Big Things Get Done by Bent Flyvbjerg who published statistics on the poor performance of projects in general. Beyond OKRs: The Power of Quantified Multi-Dimensional Objectives "First you need to have a definition of what it means to succeed. And that needs to be multi-dimensional. And you need to clarify what they are." While many organizations believe they're already quantifying objectives through frameworks like OKRs, Tom reveals significant weaknesses in these approaches. True value isn't just profit—it encompasses multiple dimensions including security, usability, and other stakeholder-specific benefits. The key insight is learning to quantify what needs to be achieved across all critical dimensions, as you simply cannot design for high-quality attributes like security without first quantifying and designing for them explicitly. In this segment, we talk about Tom's paper on OKR's titled "OKR Objectives and Key Results: what's wrong and how to fix it". The Missing Engineering Discipline "Why is the failure rate of our projects so high?" Tom identifies a paradoxical problem: engineering organizations often lack true engineering discipline. This fundamental gap explains why project success rates remain low despite technological advances. Real engineering requires systematic approaches to design, stakeholder analysis, and incremental value delivery—disciplines that are often overlooked in favor of rushed implementations. Stakeholder Analysis: Beyond User Stories "Stakeholders have a requirement - even if we don't know it. They might be people, but also law, contract, policies, etc. They all have requirements for us." Traditional user-centered methods like user stories can lead to failure when critical stakeholders are overlooked. Tom advocates for comprehensive stakeholder analysis as the foundation of engineering discipline. Stakeholders aren't just people—they include laws, contracts, policies, and other constraints that have requirements for your system. The practical tip here is to use AI tools to help identify and list these stakeholders, then quantify their specific requirements using structured approaches like Planguage. The Gilb Cycle: True Incremental Value Delivery "Get things done every week, next week, until it's all done. We need to decompose any possible design into enough increments so that each increment delivers some value." What distinguishes Tom's evolutionary approach from popular Agile frameworks is the focus on choosing the most efficient design and then systematically improving existing systems through measured increments. Each increment must deliver tangible value, and the decomposition process should be aided by AI tools to ensure optimal value delivery. This isn't just about iteration—it's about strategic improvement with measurable outcomes. Building Engineering Culture: A Two-Leader Approach "There are two leaders: the tech leaders and the management leaders. For management leaders: demand a value stream of results starting next week. To the tech leaders: learn the engineering process." Creating a true engineering culture requires coordinated effort from both management and technical leadership. Management leaders should demand immediate value streams with weekly results, while technical leaders must master fundamental engineering processes including stakeholder analysis and requirement quantification. This dual approach ensures both accountability and capability development within the organization. Further Resources During this episode we refer to several of Tom's books and papers. You can see this list below Software Metrics by Tom Gilb Principles of software engineering management - Also available in PDF Evo book About Tom Gilb Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile, before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name that Tom used to describe his approach. You can link with Tom Gilb on LinkedIn.

27 Touko 42min

BONUS Solution-Focused Coaching for Agile Teams With Ralph and Veronika

BONUS Solution-Focused Coaching for Agile Teams With Ralph and Veronika

BONUS: Solution-Focused Coaching: The Game-Changing Method Every Scrum Master Needs With Ralph Miarka and Veronika Jugwirth In this BONUS episode, we dive deep into solution-focused coaching with Ralph and Veronika, co-authors of "Solution Focused Coaching For Agile Teams." This conversation explores how to shift from problem-solving to solution-building, helping Agile teams thrive through a forward-looking approach that empowers teams to find their own path to success. Understanding Solution-Focused Coaching "Solution focus, focuses on the goal itself. We are not talking about 'how', but first start with 'what we want to achieve'." Solution-focused coaching represents a fundamental shift from traditional problem-solving approaches. Rather than diving into root cause analysis and retrospectives focused on what went wrong, this methodology centers on the future and desired outcomes. It operates as a communication system that recognizes the complexity of modern work environments where simple cause-effect relationships don't always apply. In engineering, root causes make sense when dealing with predictable systems, but in complex organizational dynamics, solution-focused coaching acknowledges that we often can't identify clear root causes and instead focuses on creating a "preferred future." In this segment we refer to Solution-focused brief therapy and the Cynefin model. The Power of Not-Knowing "Instead of suggesting solutions, we should start by asking questions. The "Not-knowing position" is about accepting this." The "not-knowing position" challenges coaches and leaders to resist the urge to immediately diagnose problems and offer solutions. When someone shares their story, they're not sharing the version we think we know. This approach transforms coaching conversations by starting with questions like "What difference would it make for you to solve this problem?" This shift toward asking questions about a positive future can even help identify advocates among those who initially resist change, creating unexpected allies in transformation efforts. Everyone as an Expert "When we help teams change by themselves, they change much faster." The principle that "everyone is an expert in their situation" fundamentally changes how coaches approach team dynamics, especially during periods of pressure or conflict. Instead of imposing external solutions, this approach involves asking teams what they already like about their current practices. For example, when observing daily standups with their natural diversity of approaches, focusing on what teams appreciate about their existing practices creates a foundation for sustainable change. Teams that discover their own path to improvement implement changes more rapidly and with greater commitment than those following prescribed solutions. The Miracle Question Technique "What would be a very small first sign that tells you that there was a small miracle during the night?" The Miracle Question emerges from real coaching conversations where clients express that "only a miracle can help." Rather than dismissing this statement, solution-focused coaches embrace the client's language to create powerful exploration opportunities. The technique involves asking teams to imagine their situation after a small miracle has occurred overnight, then identifying the first small signs they would notice. This approach helps teams explore possibilities and envision concrete steps toward their preferred future, making abstract goals tangible and achievable. Unlearning the Fix-It Mentality "Don't work by yourself in the problems of others, let them work." For Agile practitioners trained to identify and fix problems, solution-focused coaching requires a significant mindset shift. Instead of jumping into problem-solving mode, coaches must learn to hold space for solutions to emerge naturally from the team. This involves trusting that team members are experts in their own situations and developing strong questioning skills. Coaches and Scrum Masters need to clarify their own goals and resist the urge to solve problems for others, instead creating conditions where teams can work through challenges themselves. Practical Questions for Immediate Implementation "What do we want to achieve? What is our goal, and why?" Teams can immediately begin incorporating solution-focused approaches by bringing specific questions into their regular ceremonies. Key questions include exploring what the team wants to achieve and understanding the underlying purpose behind their goals. Additionally, asking "What works already?" helps teams build on existing strengths rather than focusing solely on problems. Confidence-building questions like "How confident are we?" and "What would make you more confident?" create opportunities for teams to identify specific actions that would increase their likelihood of success. About Ralph and Veronika Ralph Miarka is an Agile coach, trainer, and co-author of the book that is our topic for today's episode: Solution Focused Coaching For Agile Teams. Ralph helps teams thrive through solution-focused coaching. With a background in engineering and leadership, he bridges structure and empathy to spark real change. You can link with Ralph Miarka on LinkedIn. Veronika Jungwrith is a coach, consultant, and facilitator, Veronika blends solution-focused coaching with leadership development. Her work empowers individuals and teams to navigate complexity with clarity, meaning, and lasting impact. You can link with Veronika Jungwrith on LinkedIn.

26 Touko 44min

Why Great Product Owners Listen—Communication Lessons from Product Ownership Extremes | Deniz Ari

Why Great Product Owners Listen—Communication Lessons from Product Ownership Extremes | Deniz Ari

Deniz Ari: Why Great Product Owners Listen—Communication Lessons from Product Ownership Extremes The Great Product Owner: The Power of Clear Communication Deniz describes a truly exemplary Product Owner who excelled through outstanding communication skills. This PO was an exceptional listener who maintained openness throughout all interactions. They ensured the team thoroughly understood requirements and priorities, always clearly articulating the rationale behind decisions. With a well-defined product vision and transparent prioritization process, this PO successfully bridged the gap between the development team and clients. Deniz emphasizes how this clear communication style naturally fostered team motivation, as everyone understood not just what they were building, but why it mattered. The Bad Product Owner: The Tyrant PO Deniz shares a challenging experience with a problematic Product Owner during what initially appeared to be a straightforward public sector migration project with adequate budget and timeline. Despite these favorable conditions, the situation deteriorated when the PO began pushing the team to work overtime, overstepping boundaries by questioning architectural decisions, and inappropriately assuming Scrum Master responsibilities. Described as a "tyrant" or "despot," this PO exhibited extremely poor communication skills and preferred dictating rather than collaborating. When Deniz attempted to address these issues, the situation became so toxic that it affected Deniz's health, ultimately leading to their decision to leave the project. The PO subsequently claimed no Scrum Master was needed. Deniz reflects that sometimes the best option is to recognize when a situation cannot be changed and to move on. Self-reflection Question: What boundaries would you establish with a dominant Product Owner, and at what point would you decide that the situation cannot be improved? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Deniz Ari Deniz is an innovative, driven professional with expertise in Agile coaching, delivery management, data science, and technology transformation. As a Scrum Master and Agile Coach, Deniz builds high-performing teams, drives strategic execution, and fosters collaboration. Passionate about continuous improvement, they lead cultural shifts, optimize processes, and deliver scalable, high-quality outcomes. You can link with Deniz Ari on LinkedIn.

23 Touko 19min

Stakeholder Management Rhythms for Successful Scrum Masters | Deniz Ari

Stakeholder Management Rhythms for Successful Scrum Masters | Deniz Ari

Deniz Ari: Stakeholder Management Rhythms for Successful Scrum Masters 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. For Deniz, successful Scrum Masters create environments with positive team dynamics, easy communication, and a focus on continuous improvement that leads to valuable deliverables. The key indicators include whether team members can speak freely, whether there's trust between team members, and if the team feels like "a safe place to fail." Deniz recommends admitting your own mistakes in front of the team to model vulnerability, continuously observing team interactions, and noticing whether teams openly discuss obstacles. For stakeholder management, Deniz suggests establishing regular catch-up calls with leaders to keep team messages in the conversation and setting up routine discussions with stakeholders to maintain alignment. Featured Retrospective Format for the Week: The Worst Retro Deniz shares a playful yet effective retrospective format called "The Worst Retro," conducted using a MURAL board. The session begins with an energy/mood check to establish the team's current state. Then it moves into three key sections: what team members remember from the sprint, how they could make the next sprint worse, and finally deciding what actions to take next. Deniz explains that the power of this approach lies in using humor to discuss serious problems—by asking how to make things worse, team members can indirectly highlight what's already not working. This format creates an informal, relaxed environment where people feel comfortable addressing challenging topics that might otherwise remain unspoken. Self-reflection Question: How might introducing an element of humor or "reverse thinking" help your team discuss problems they've been avoiding in traditional retrospective formats? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Deniz Ari Deniz is an innovative, driven professional with expertise in Agile coaching, delivery management, data science, and technology transformation. As a Scrum Master and Agile Coach, Deniz builds high-performing teams, drives strategic execution, and fosters collaboration. Passionate about continuous improvement, they lead cultural shifts, optimize processes, and deliver scalable, high-quality outcomes. You can link with Deniz Ari on LinkedIn.

22 Touko 14min

Why Your Process Changes Are Failing—The Stakeholder Alignment Problem | Deniz Ari

Why Your Process Changes Are Failing—The Stakeholder Alignment Problem | Deniz Ari

Deniz Ari: Why Your Process Changes Are Failing—The Stakeholder Alignment Problem 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. Deniz explores the challenges of implementing change in organizations, emphasizing that change is always a long and difficult process requiring patience and trust. Drawing on the Change Curve concept, Deniz shares a personal experience trying to improve project visibility by cleaning up backlogs in JIRA for 10 in-flight projects. Despite good intentions, Deniz found themselves as the only person using the tool, with team members and Product Owners using different systems that better suited their specific needs—POs wanting only high-level items while the development team needed to split items into smaller tasks. Through this experience, Deniz learned the crucial importance of having all stakeholders (Product Owners, development teams, and managers) aligned on using the same tool, and understanding the unique perspectives of each group before implementing process changes. In this episode, we refer to the Change Curve. Self-reflection Question: What changes have you attempted to implement that failed because you didn't fully understand the different needs and perspectives of all stakeholders involved? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Deniz Ari Deniz is an innovative, driven professional with expertise in Agile coaching, delivery management, data science, and technology transformation. As a Scrum Master and Agile Coach, Deniz builds high-performing teams, drives strategic execution, and fosters collaboration. Passionate about continuous improvement, they lead cultural shifts, optimize processes, and deliver scalable, high-quality outcomes. You can link with Deniz Ari on LinkedIn.

21 Touko 16min

Security Team Breakdown—The Devastating Impact of Poor Product Ownership | Deniz Ari

Security Team Breakdown—The Devastating Impact of Poor Product Ownership | Deniz Ari

Deniz Ari: Security Team Breakdown—The Devastating Impact of Poor Product Ownership 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. Deniz shares the story of a security project with a team of eight experienced, senior engineers working on mission-critical systems. Despite initial motivation and clear architectural solutions, the team soon exhibited signs of negative behavior including complaints and criticism. The root cause traced back to frequent Product Owner changes—several within less than a year—and poor client management. Instead of shielding the team, the PO directly transferred stress from clients to the team, demanded overtime, and created unnecessary tension by bringing unfiltered conflicts to the team and requesting excessive details. Deniz emphasizes the importance of avoiding unnecessary tensions, being more political when necessary to protect the team, and being mindful of tone in written communications. Self-reflection Question: In what ways might you be failing to set proper boundaries in your role, and how could establishing clearer limits improve both your effectiveness and your team's performance? Featured Book of the Week: Boundaries by Henrik Cloud Deniz recommends "Boundaries" by Henrik Cloud, a book about human relationships and personal limitations. The book addresses crucial questions: Does your life feel out of control? Do you keep saying yes to everyone? Are you taking responsibility for others' feelings and problems? Have you forgotten your own limitations? Deniz explains how this book helped them learn to say "no" while still considering others' realities and feelings, and understanding why we often struggle with setting boundaries. Deniz highlights that being a Scrum Master involves much more than just processes and methods—it requires healthy personal boundaries. [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Deniz Ari Deniz is an innovative, driven professional with expertise in Agile coaching, delivery management, data science, and technology transformation. As a Scrum Master and Agile Coach, Deniz builds high-performing teams, drives strategic execution, and fosters collaboration. Passionate about continuous improvement, they lead cultural shifts, optimize processes, and deliver scalable, high-quality outcomes. You can link with Deniz Ari on LinkedIn.

20 Touko 17min

How Intense Delivery Pressure Destroyed Team Trust, Culture, and Brought Burnout | Deniz Ari

How Intense Delivery Pressure Destroyed Team Trust, Culture, and Brought Burnout | Deniz Ari

Deniz Ari: How Intense Delivery Pressure Destroyed Team Trust, Culture, and Brought Burnout 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. Working in the public sector, Deniz faced a challenging situation during a particularly busy winter period when the client wanted to combine multiple major initiatives simultaneously: migration, new features, and security improvements. This led to an oversized team of 25 engineers, which ultimately caused significant problems. The pressure to continuously deliver became overwhelming, breaking team trust and leaving members feeling abandoned. Several team members left, the team culture disintegrated, and cases of burnout emerged. After this difficult experience, Deniz conducted a comprehensive retrospective to process what happened and provide feedback to management about the dangers of excessive pressure in Scrum environments. Self-reflection Question: How might you recognize the early warning signs of team burnout before it reaches a critical point, and what boundaries would you establish to protect your team? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Deniz Ari Deniz is an innovative, driven professional with expertise in Agile coaching, delivery management, data science, and technology transformation. As a Scrum Master and Agile Coach, Deniz builds high-performing teams, drives strategic execution, and fosters collaboration. Passionate about continuous improvement, they lead cultural shifts, optimize processes, and deliver scalable, high-quality outcomes. You can link with Deniz Ari on LinkedIn.

19 Touko 18min

BONUS The PRFAQ Framework With Marcelo Calbucci

BONUS The PRFAQ Framework With Marcelo Calbucci

BONUS: Marcelo Calbucci reveals Amazon's secret innovation framework that transforms product development! Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this BONUS episode, we explore "The PRFAQ Framework" (visit also the website) with author Marcelo Calbucci. He shares how Amazon's innovative approach to product development can be adapted by founders, product managers, and teams across industries. Learn how this powerful methodology creates alignment, clarifies vision, and ensures customer-centricity in product development. The Origins of PRFAQ "I learned the PR FAQ method at Amazon and realized this is a great tool that would be valuable for founders and product leaders." Marcelo Calbucci shares how his experience at Amazon introduced him to the PRFAQ framework—a structured approach to product ideation and development. He explains how this methodology transformed his thinking about innovation and why he felt compelled to share it with a wider audience through his book. The framework addresses a critical gap he observed in how teams approach product development, often lacking the clarity and customer focus needed for success. Understanding the PRFAQ Framework "PR FAQ stands for press release and frequently asked questions—it's a method to talk about and define a vision for the product." The PRFAQ framework is a six-page document with a highly prescriptive structure. Marcelo breaks down the components: Page 1: A press release announcing the product Page 2+: Customer FAQ addressing potential questions Page 3+: Internal FAQ covering implementation details This document serves as the foundation for product development, helping teams align on vision and strategy before diving into execution. Marcelo emphasizes that the framework forces teams to articulate the "why" behind their work, not just the "what" and "how." The Alignment Challenge "Challenge: pick a few people from your organization, ask each one 'why are we doing this?' Chances are you will get a different answer from different people." One of the most significant challenges in product development is the lack of alignment across teams. Marcelo highlights how common it is for team members to have different understandings of product goals and strategy. Without a shared vision, teams risk building features that don't solve the right problems or address customer needs effectively. The PRFAQ framework creates alignment by documenting and socializing product vision in a consistent format that encourages discussion and feedback. Practical Implementation Tips "Use the PRFAQ as a textual document, instead of a PowerPoint presentation—the discipline of writing helps clarify thinking." Marcelo offers several practical tips for implementing the PRFAQ approach effectively: Write things out in paragraphs rather than bullet points Consider writing the FAQs before the press release Use the document as a tool for discussion, not as a polished deliverable Conduct review sessions with peers, team members, and stakeholders Focus on substance over style—the goal is to discover feedback He emphasizes that the act of writing forces clearer thinking and exposes gaps in logic or understanding that might otherwise remain hidden. The Amazon Way "At Amazon, every product starts with a PRFAQ. It starts with someone having an idea. The first thing they do is to write the PRFAQ." Marcelo provides insight into how Amazon implements this framework across the organization. Every product initiative begins with a PRFAQ document that articulates the vision and strategy. Teams spend time discussing and refining this document before moving into execution. This methodical approach allows Amazon to get early feedback on ideas, helping to identify potential issues before significant resources are invested. The framework has been a cornerstone of Amazon's ability to innovate consistently across diverse product areas. Customer-Centricity in Practice "Here's one lesson about product leadership: understand the problems better than even the customer understands them." The customer-centric nature of the PRFAQ framework is one of its greatest strengths. By forcing teams to anticipate customer questions and articulate benefits from their perspective, the framework ensures products are built to solve real problems. Marcelo explains that sometimes the "customer" might be internal, but the principle remains the same—deeply understanding the problems before proposing solutions. This approach has proven particularly effective at Amazon, where customer obsession is a core value. Learning from the Book Development Process "In interviewing teams using the method, I discovered that the problem was convincing the whole team about the PRFAQ method." Interestingly, Marcelo applied the PRFAQ framework to the development of his own book. Through this meta-application, he discovered that the biggest challenge wasn't explaining the method itself but convincing entire teams to adopt it. This insight shaped the book's approach—making product strategy discussions less academic and more practical. He focused on providing concrete examples and templates that teams could immediately apply to their work. Resources for Deeper Learning "Read examples first, pay attention to how you write the phrases in the document." For listeners wanting to explore the PRFAQ framework further, Marcelo recommends starting with examples to understand the tone and structure. His book website offers resources and templates to help teams implement the framework. He emphasizes that seeing the framework in action is often more valuable than theoretical discussions, which is why he includes numerous examples in his book and supplementary materials. About Marcelo Calbucci Marcelo Calbucci is a founder, product and engineering leader, and innovation expert passionate about solving customers' biggest challenges through software. With over two decades of experience, he has launched dozens of products across industries and mentored nearly a thousand founders and professionals, shaping the future of product development and innovation. Marcelo Calbucci is the author of "The PRFAQ Framework: Adapting Amazon's Innovation Framework to Work for You," which describes Amazon's PRFAQ method—a strategic approach designed to refine and present new product ideas by focusing on customer-centric narratives. You can link with Marcelo Calbucci on LinkedIn and connect with Marcelo Calbucci on Substack.

17 Touko 28min

Suosittua kategoriassa Politiikka ja uutiset

rss-ootsa-kuullut-tasta
aikalisa
tervo-halme
ootsa-kuullut-tasta-2
politiikan-puskaradio
viisupodi
rss-podme-livebox
et-sa-noin-voi-sanoo-esittaa
otetaan-yhdet
rss-vaalirankkurit-podcast
aihe
the-ulkopolitist
rss-polikulaari-humanisti-vastaa-ja-muut-ts-podcastit
rss-hyvaa-huomenta-bryssel
rss-kuka-mina-olen
politbyroo
linda-maria
rss-lets-talk-about-hair
rss-50100-podcast
rss-tekoalyfoorumi