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.

Avsnitt(200)

Don't Scale Dysfunction—Fix the Team First | Karim Harbott

Don't Scale Dysfunction—Fix the Team First | Karim Harbott

Karim Harbott: Don't Scale Dysfunction—Fix the Team First Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "How do you define the success of a football manager? Football managers are successful when the team is successful. For Scrum Masters it is also like that. Is the team better than it was before?" - Karim Harbott   Karim uses a powerful analogy to define success for Scrum Masters: think of yourself as a football manager. A football manager isn't successful because they personally score goals—they're successful when the team wins. The same principle applies to Scrum Masters. Success isn't measured by how many problems you solve or how busy you are. It's measured by whether the team is better than they were before.  Are they more self-organizing? More effective? More aligned with organizational outcomes?  This requires a mindset shift. Unlike sprinters competing individually, Scrum Masters succeed by enabling others to be better.  Karim recommends involving the team when defining success—what does "better" mean to them? He also emphasizes linking the work of the team to organizational objectives. When teams understand how their efforts contribute to broader goals, they become more engaged and purposeful. But there's a critical warning: don't scale dysfunction! If a team isn't healthy, improving it is far more important than expanding your coaching to more teams.  A successful Scrum Master creates teams that don't need constant intervention—teams that can manage themselves, make decisions, and deliver value consistently. Just like a great football manager builds a team that plays brilliantly even when the manager isn't on the field.   Self-reflection Question: Is your team more capable and self-sufficient than they were six months ago, or have they become more dependent on you? Featured Retrospective Format for the Week: Systems Modeling with Causal Loop Diagrams "It shows how many aspects of the system there are and how things are interconnected. This helps us see something that we would not come up with in normal conversations." - Karim Harbott   Karim recommends using systems modeling—specifically causal loop diagrams—as a retrospective format. This approach helps teams visualize the complex interconnections between different aspects of their work. Instead of just listing what went wrong or right, causal loop diagrams reveal how various elements influence each other, often uncovering hidden feedback loops and unintended consequences.  The power of this format is that it surfaces insights the team wouldn't discover through normal conversation. Teams can then think of their retrospective actions as experiments—ways to interact with the system to test hypotheses about what will improve outcomes. This shifts retrospectives from complaint sessions to scientific inquiry, making them far more actionable and engaging. If your team is struggling with recurring issues or can't seem to break out of patterns, systems modeling might reveal the deeper dynamics at play.   [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 Karim Harbott   Karim is a consultant, trainer, and non-executive director. He bridges the gap between strategy, business agility, digital transformation, innovation, AI, and board governance. He is a Certified Scrum Trainer, and is the author of The 6 Enablers of Business Agility.   You can link with Karim Harbott on LinkedIn.

6 Nov 14min

You Can't Make a Flower Grow Faster—The Oblique Approach to Shaping Culture | Karim Harbott

You Can't Make a Flower Grow Faster—The Oblique Approach to Shaping Culture | Karim Harbott

Karim Harbott: You Can't Make a Flower Grow Faster—The Oblique Approach to Shaping Culture Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "How can I make a flower grow faster? Culture is a product of the behaviors of people in the system." - Karim Harbott   For Karim, one of the biggest challenges—and enablers—in his current work is creating a supporting culture. After years of learning what doesn't work, he's come to understand that culture isn't something you can force or mandate. Like trying to make a flower grow faster by pulling on it, direct approaches to culture change often backfire.  Instead, Karim uses what he calls the "oblique approach"—changing culture indirectly by adjusting the five levers: leadership behaviors, organizational structure, incentives, metrics, and systems. Leadership behaviors are particularly crucial.  When leaders step back and encourage ownership rather than micromanaging, teams transform. Incentives have a huge impact on how teams work—align them poorly, and you'll get exactly the wrong behaviors.  Karim references Team of Teams by General Stanley McChrystal, which demonstrates how changing organizational structure and leadership philosophy can unlock extraordinary performance. He also uses the Competing Values Framework to help leaders understand different cultural orientations and their tradeoffs. But the most important lesson? There are always unexpected consequences. Culture change requires patience, experimentation, and a willingness to observe how the system responds. You can't force a flower to grow, but you can create the conditions where it thrives.   Self-reflection Question: Are you trying to change your organization's culture directly, or are you adjusting the conditions that shape behavior?   [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 Karim Harbott   Karim is a consultant, trainer, and non-executive director. He bridges the gap between strategy, business agility, digital transformation, innovation, AI, and board governance. He is a Certified Scrum Trainer, and is the author of The 6 Enablers of Business Agility.   You can link with Karim Harbott on LinkedIn.

5 Nov 17min

Why System Design Beats Individual Coaching Every Time | Karim Harbott

Why System Design Beats Individual Coaching Every Time | Karim Harbott

Karim Harbott: Why System Design Beats Individual Coaching Every Time 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't change people, but you can change the system. Change the environment, not the people." - Karim Harbott   Karim was coaching a distributed team that was struggling with defects appearing constantly during sprints. The developers and testers were at different sites, and communication seemed fractured. But Karim knew from experience that when teams are underperforming, the problem usually isn't the people—it's the system they're working in. He stepped back to examine the broader context, implementing behavior-driven development(BDD) and specification by example to improve clarity through BDD scenarios.  But the defects persisted.  Then, almost by accident, Karim discovered the root cause: the developers and testers were employed by different companies. They had competing interests, different incentives, and fundamentally misaligned goals. No amount of coaching the individuals would fix a structural problem like that.  It took months, but eventually the system changed—developers and testers were reorganized into unified teams from the same organization. Suddenly, the defects dropped dramatically. As Jocko Willink writes in Extreme Ownership, when something isn't working, look at the system first. Karim's experience proves that sometimes the most compassionate thing you can do is stop trying to fix people and start fixing the environment they work in.   Self-reflection Question: When your team struggles, do you look at the people or at the system they're embedded in? Featured Book of the Week: Scaling Lean and Agile Development by Craig Larman and Bas Vodde "This book was absolute gold. The way it is written, and the tools they talk about went beyond what I was talking about back then. They introduced many concepts that I now use." - Karim Harbott   Karim discovered Scaling Lean and Agile Development by accident, but it resonated with him immediately. The concepts Craig Larman and Bas Vodde introduced—particularly around LeSS (Large-Scale Scrum)—went far beyond the basics Karim had been working with. The book opened his eyes to system-level thinking at scale, showing how to maintain agility even as organizations grow.  It's packed with practical tools and frameworks that Karim still uses today. For anyone working beyond a single team, this book provides the depth and nuance that most scaling frameworks gloss over. Also worth reading: User Stories Applied by Mike Cohn, another foundational text that shaped Karim's approach to working with teams.   [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 Karim Harbott   Karim is a consultant, trainer, and non-executive director. He bridges the gap between strategy, business agility, digital transformation, innovation, AI, and board governance. He is a Certified Scrum Trainer, and is the author of The 6 Enablers of Business Agility.   You can link with Karim Harbott on LinkedIn.

4 Nov 15min

The Day I Discovered I Was a Scrum Project Manager, Not a Scrum Master | Karim Harbott

The Day I Discovered I Was a Scrum Project Manager, Not a Scrum Master | Karim Harbott

Karim Harbott: The Day I Discovered I Was a Scrum Project Manager, Not a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I was telling the team what to do, instead of helping the team to be better on their own. There's a lot more to being a Scrum Master than Agile—working with people is such a different skillset." - Karim Harbott   Karim thought he had mastered Scrum. He had read the books, understood the framework, and was getting things done. His team seemed to be moving forward smoothly—until he stepped away for a few weeks.  But, when he returned, everything had fallen apart. The team couldn't function without him constantly directing their work. That's when Karim realized he had fallen into one of the most common anti-patterns in Agile: the Scrum Project Manager.  Instead of enabling his team to be more effective, he had become their bottleneck. Every decision flowed through him, every task needed his approval, and the team had learned to wait for his direction rather than taking ownership themselves. The wake-up call was brutal but necessary.  Karim discovered that pushing project management responsibilities to the people doing the work—as David Marquet advocates—was far more powerful than being the hero who solves all problems. The real skill wasn't in telling people what to do; it was in creating an environment where they could figure it out themselves. Geoff Watts calls this servant leadership, and Karim learned it the hard way: a great Scrum Master makes themselves progressively less necessary, not more indispensable.   Self-reflection Question: Are you enabling your team to be more effective, or have you become the person they can't function without?   [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 Karim Harbott   Karim is a consultant, trainer, and non-executive director. He bridges the gap between strategy, business agility, digital transformation, innovation, AI, and board governance. He is a Certified Scrum Trainer, and is the author of The 6 Enablers of Business Agility.   You can link with Karim Harbott on LinkedIn.

3 Nov 16min

Organizations as Ecosystems — Understanding Complexity, Innovation, and the Three-Body Problem at Work With Simon Holzapfel

Organizations as Ecosystems — Understanding Complexity, Innovation, and the Three-Body Problem at Work With Simon Holzapfel

BONUS: Organizations as Ecosystems — Understanding Complexity, Innovation, and the Three-Body Problem at Work In this fascinating conversation about complex adaptive systems, Simon Holzapfel helps us understand why traditional planning and control methods fail in knowledge work — and what we can do instead. Understanding Ecosystems vs. Systems "Complex adaptive systems are complex in nature and adaptive in that they evolve over time. That's different from a static system." — Simon Holzapfel   Simon introduces the crucial distinction between mechanical systems and ecosystems. While mechanical systems are predictable and static, ecosystems — like teams and organizations — are complex, adaptive, and constantly evolving. The key difference lies in the interactions among team members, which create emergent properties that cannot be predicted by analyzing individuals separately. Managers often fall into the trap of focusing on individuals rather than the interactions between them, missing where the real magic happens. This is why understanding your organization as an ecosystem, not a machine, fundamentally changes how you lead. In this segment, we refer to the Stella systems modeling application. The Journey from Planning to Emergence "I used to come into class with a lesson plan — doop, doop, doop, minute by minute agenda. And then what I realized is that I would just completely squash those questions that would often emerge from the class." — Simon Holzapfel   Simon shares his transformation from rigid classroom planning to embracing emergence. As a history and economics teacher for 10 years, he learned that over-planning kills the spontaneous insights that make learning powerful. The same principle applies to leadership: planning is essential, but over-planning wastes time and prevents novelty from emerging. The key is separating strategic planning (the "where" and "why") from tactical execution (the "how"), letting teams make local decisions while leaders focus on alignment with the bigger picture. "Innovation Arrives Stochastically" "Simply by noticing the locations where you've had your best ideas, we notice the stochasticness of arrival. Might be the shower, might be on a bike ride, might be sitting in traffic, might be at your desk — but often not." — Simon Holzapfel   Simon unpacks the concept of stochastic emergence — the idea that innovation cannot be scheduled or predicted in advance. Stochastic means something is predictable over large datasets but not in any given moment. You know you'll have ideas if you give yourself time and space, but you can't predict when or where they'll arrive. This has profound implications for managers who try to control when and how innovation happens. Knowledge work is about creating things that haven't existed before, so emergence is what we rely on. Try to squash it with too much control, and it simply won't happen. In this segment, we refer to the Systems Innovation YouTube channel. The Three-Body Problem: A Metaphor for Teams "When you have three nonlinear functions working at the same time within a system, you have almost no ability to predict its future state beyond just some of the shortest time series data." — Simon Holzapfel   Simon uses the three-body problem from physics as a powerful metaphor for organizational complexity. In physics, when you have three bodies (like planets) influencing each other, prediction becomes nearly impossible. The same is true in business — think of R&D, manufacturing, and sales as three interacting forces. The lesson: don't think you can master this complexity. Work with it. Understand it's a system. Most variability comes from the system itself, not from any individual person. This allows us to depersonalize problems — people aren't good or bad, systems can be improved. When teams understand this, they can relax and stop treating every unpredictable moment as an emergency. Coaching Leaders to Embrace Uncertainty "I'll start by trying to read their comfort level. I'll ask about their favorite teachers, their most hated teachers, and I'll really try to bring them back to moments in time that were pivotal in their own development." — Simon Holzapfel   How do you help analytical, control-oriented leaders embrace complexity and emergence? Simon's approach is to build rapport first, then gently introduce concepts based on each leader's background. For technical people who prefer math, he'll discuss narrow tail distributions and fat tails. For humanities-oriented leaders, he uses narrative and storytelling. The goal is to get leaders to open up to possibilities without feeling diminished. He might suggest small experiments: "Hold your tongue once in a meeting" or "Ask questions instead of making statements." These incremental changes help managers realize they don't have to be superhuman problem-solvers who control everything. Giving the Board a Number: The Paradox of Prediction "Managers say we want scientific management, but they don't actually want that. They want predictive management." — Simon Holzapfel   Simon addresses one of the biggest tensions in agile adoption: leaders who say "I just need to give the board a number" while also wanting innovation and adaptability. The paradox is clear — you cannot simultaneously be open to innovation and emergent possibilities while executing a predetermined plan with perfect accuracy. This is an artifact of management literature that promoted the "philosopher king" manager who knows everything. But markets are too movable, consumer tastes vary too much, and knowledge work is too complex for any single person to control. The burnout we see in leaders often comes from trying to achieve an impossible standard. In this segment, we refer to the episodes with David Marquet.  Resources for Understanding Complexity "Eric Beinhocker's book called 'The Origin of Wealth' is wonderful. It's a very approachable and well-researched piece that shows where we've been and where we're going in this area." — Simon Holzapfel   Simon recommends two key resources for anyone wanting to understand complexity and ecosystems. First, Eric Beinhocker's "The Origin of Wealth" explains how we developed flawed economic assumptions based on 19th-century Newtonian physics, and why we need to evolve our understanding. Second, the Systems Innovation YouTube channel offers brilliant short videos perfect for curious, open-minded managers. Simon suggests a practical approach: have someone on your team watch a video and share what they learned. This creates shared language around complexity and makes the concepts less personal and less threatening. The Path Forward: Systems Over Individuals "As a manager, our goal is to constantly evaluate the performance of the system, not the people. We can always put better systems in place. We can always improve existing systems. But you can't tell people what to do — it's not possible." — Simon Holzapfel   The conversation concludes with a powerful insight from Deming's work: about 95% of a system's productivity is linked to the system itself, not individual performance. This reframes the manager's role entirely. Instead of trying to control people, focus on improving systems. Instead of treating burnout as individual failure, see it as information that something in the system isn't working. Organizations are ever-changing ecosystems with dynamic properties that can only be observed, never fully predicted. This requires a completely different way of thinking about management — one that embraces uncertainty, values emergence, and trusts teams to figure things out within clear strategic boundaries. Recommended Resources As recommended resources for further reading, Simon suggests:  The Origin of Wealth, by Eric Beinhocker The Systems Innovation YouTube channel   About Simon Holzapfel   Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack, where he explores the intersection of economics, equality, and equanimity in the workplace.   You can link with Simon Holzapfel on LinkedIn.

1 Nov 40min

From Missing in Action to Present and Collaborative—The Product Owner Spectrum | Darryl Wright

From Missing in Action to Present and Collaborative—The Product Owner Spectrum | Darryl Wright

Darryl Wright: The PONO—Product Owners in Name Only and How They Destroy Teams 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 Great Product Owner: Collaborative, Present, and Clear in Vision "She was collaborative, and that meant that she was present—the opposite of the MIA product owner. She came, and she sat with the team, and she worked with them side by side. Even when she was working on something different, she'd be there, she'd be available." - Darryl Wright Darryl shares an unusual story about one of the best Product Owners he's ever encountered—someone who had never even heard of Agile before taking the role. Working for a large consulting company with 170,000 staff worldwide, they faced a difficult project that nobody wanted to do. Darryl suggested running it as an Agile project, but the entire team had zero Agile experience. The only person who'd heard of Agile was a new graduate who'd studied it for one week at university—he became the Scrum Master. The executive sponsor, with her business acumen and stakeholder management skills, became the Product Owner despite having no idea what that meant. The results were extraordinary: an 18-month project completed in just over 7 months, and when asked about the experience, the team's highest feedback was how much fun they had working on what was supposed to be an awful, difficult project. Darryl attributes this success to mindset—the team was open and willing to try something new. The Product Owner brought critical skills to the role even without technical Agile knowledge: She was collaborative and present, sitting with the team and remaining available. She was decisive, making prioritization calls clearly so nobody was ever confused about priorities. She had excellent communication skills, articulating the vision with clarity that inspired the team. Her stakeholder management capabilities kept external pressures managed appropriately. And her business acumen meant she instantly understood conversations about value, time to market, and customer impact. Without formal training, she became an amazing Product Owner simply by being open, willing, and committed. As Darryl reflects, going from never having heard of the role to being an inspiring Product Owner in 7 months was incredible—one of the most successful projects and teams he's ever worked with. Self-reflection Question: If you had to choose between a Product Owner with deep Agile certification and no business skills, or one with strong business acumen and willingness to learn—which would serve your team better? The Bad Product Owner: The PONO—Product Owner in Name Only "The team never saw the PO until the showcase. And so, the team would come along with work that they deemed was finished, and the product owner had not seen it before because he wasn't around. So he would be seeing it for the first time in the showcase, and he would then accept or reject the work in the showcase, in front of other stakeholders." - Darryl Wright The most destructive anti-pattern Darryl has witnessed was the MIA—Missing in Action—Product Owner, someone who was a Product Owner in Name Only (PONO). This senior business person was too busy to spend time with the team, only appearing at the sprint showcase. The damage this created was systematic and crushing. The team would build work without Product Owner engagement, then present it in the showcase looking to be proud of their accomplishment. The PO, seeing it for the first time, would accept or reject the work in front of stakeholders. When he rejected it, the team was crushed, deflated, demoralized, and made to look like fools in front of senior leaders—essentially thrown under the bus. This pattern violates multiple principles of Agile teamwork. First, there's no feedback loop during the sprint, so the team works blind, hoping they're building the right thing. Second, the showcase becomes a validation ceremony rather than a collaborative feedback session, creating a dynamic of subservience rather than curiosity. The team seeks approval instead of engaging as explorers discovering what delivers customer value together. Third, the PO positions themselves as judge rather than coach—extracting themselves from responsibility for what's delivered while placing all blame on the team. As Deming's quote reminds us, "A leader is a coach, not a judge." When the PO takes the judge role, they're betraying fundamental Agile values. The responsibility for what the team delivers belongs strictly to the Product Owner; the team owns how it's delivered. When Darryl encounters this situation as a Scrum Master, he lobbies intensely with the PO: "Even if you can't spare any other time for the entire sprint, give us just one hour the night before the showcase." That single hour lets the team preview what they'll present, getting early yes/no decisions so they never face public rejection. The basic building block of any Agile or Scrum way of working is an empowered team—and this anti-pattern strips all empowerment away. Self-reflection Question: Does your Product Owner show up as a coach who's building something together with the team, or as a judge who pronounces verdicts? How does that dynamic shape what your team is willing to try? [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 Darryl Wright Darryl is an Agile Coach and Instructor dedicated to helping organisations and leaders be both successful and humane. He has over two decades in IT delivery and business leadership, he champions Agile ways of working to create thriving workplaces where people are happy, productive, and deliver products customers truly love. You can link with Darryl Wright on LinkedIn, and visit Darryl's website at www.organa.com.au.

31 Okt 14min

Beyond Vanity Metrics—Defining Real Success for Scrum Masters | Darryl Wright

Beyond Vanity Metrics—Defining Real Success for Scrum Masters | Darryl Wright

Darryl Wright: The Retrospective Formats That Actually Generate Change 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. "My success is, how much have I helped the team achieve what they want? If what they want is to uplift quality, or to reduce their time to market, well then, my success is helping them achieve that." - Darryl Wright When Darryl enters a new organization, he's often told his success will be measured by percentage of Agile adoption or team maturity assessment scores. His response is direct: those are vanity metrics that show something for its own sake, not real success. True success requires multiple measures, carefully balanced to prevent gaming and to capture both the human and business dimensions of work. Darryl advocates balancing quantitative metrics like lead time and flow efficiency with qualitative measures like employee happiness and team self-assessment of productivity. He balances business outcomes like customer satisfaction and revenue with humanity metrics that track the team's journey toward high performance. Most importantly, Darryl believes his success metrics should be co-created with the team. If he's there to help the team, then success must be defined by how much he's helped them achieve what they want—not what he wants. When stakeholders fixate on output metrics like "more story points," Darryl uses a coaching approach to shift the conversation toward outcomes and value. "Would you be happy if your team checked off more boxes, but your customers were less happy?" he asks. This opens space for exploring what they really want to achieve and why it matters. The key is translating outputs into impacts, helping people articulate the business value or customer experience improvement they're actually seeking. As detailed in Better Value, Sooner, Safer, Happier by Jonathan Smart, comprehensive dashboards can track value across multiple domains simultaneously—balancing speed with quality, business success with humanity, quantitative data with qualitative experience. When done well, Agile teams can be highly productive, highly successful, and have high morale at the same time. We don't have to sacrifice one for the other—we can have both. Self-reflection Question: If your team could only track two metrics for the next sprint, what would they choose? What would you choose? And more importantly, whose choice should drive the selection? Featured Retrospective Format for the Week: The 4 L's and Three Little Pigs Darryl offers two favorites, tailored to different contexts. For learning environments, he loves the 4 L's retrospective: Liked, Learned, Lacked, and Longed For. This format creates space for teams to reflect on their learning journey, surfacing insights about what worked, what was missing, and what they aspire to moving forward. For operational environments, he recommends the Three Little Pigs retrospective, which brilliantly surfaces team strengths and weaknesses through a playful metaphor. The House of Straw represents things the team is weak at—nothing stands up, everything falls over. The House of Sticks is things they've put structure around, but it doesn't really work. The House of Bricks represents what they're solid on, what they can count on every time. Then comes the most important part: identifying the Big Bad Wolf—the scary thing, the elephant in the room that nobody wants to talk about but everyone knows is there. This format creates psychological safety to discuss the undiscussable. Darryl emphasizes two critical success factors for retrospectives: First, vary your formats. Teams that hear the same questions sprint after sprint will disengage, asking "why are you asking me again?" Different questions provide different lenses, generating fresh insights. Second, ensure actions come out of every retro. Nothing kills engagement faster than suggestions disappearing into the void. When people see their ideas lead to real changes, they'll eagerly return to the next retrospective. And don't forget to know your team—if they're sports fans, use sports retros; if they're scientists, use space exploration themes. Just don't make the mistake of running a "sailboat retro" with retiring mainframe engineers who'll ask if you think they're kindergarten children. For more retrospective formats, check out Retromat. [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 Darryl Wright Darryl is an Agile Coach and Instructor dedicated to helping organisations and leaders be both successful and humane. He has over two decades in IT delivery and business leadership, he champions Agile ways of working to create thriving workplaces where people are happy, productive, and deliver products customers truly love. You can link with Darryl Wright on LinkedIn, and visit Darryl's website at www.organa.com.au.

30 Okt 15min

Why AI Adoption Will Fail Just Like Agile Did—Unless We Change | Darryl Wright

Why AI Adoption Will Fail Just Like Agile Did—Unless We Change | Darryl Wright

Darryl Wright: Why AI Adoption Will Fail Just Like Agile Did—Unless We Change 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. "People are looking to AI to solve their problems, and they're doing it in the same way that they previously looked to Agile to solve their problems for them. The problem with that is, of course, that Agile doesn't solve problems for you. What it does is it shines a light on where your problems are." - Darryl Wright The world has gone AI crazy, and Darryl sees history repeating itself in troubling ways. Organizations are rushing to adopt AI with the same magical thinking they once applied to Agile—believing that simply implementing the tool will solve their fundamental problems. But just as Agile reveals problems rather than solving them, AI will do the same. Worse, AI threatens to accelerate existing problems: if you have too many things moving at once, AI won't fix that, it will amplify the chaos. If you automate a bad process, you've simply locked in badness at higher speed. As Darryl points out, when organizations don't understand that AI requires them to still do the hard work of problem-solving, they're setting themselves up for disillusionment, and in five or twenty years, we'll hear "AI is dead" just like we now hear "Agile is dead." The challenge for Scrum Masters and Agile coaches is profound: how do you help people with something they don't know they need? The answer lies in returning to first principles. Before adopting any tool—whether Agile or AI—organizations must clearly define the problem they're trying to solve. As Einstein reportedly said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." Value stream mapping becomes essential, allowing teams to visualize where humans and AI agents should operate, with clear handovers and explicit policies. The cognitive load on software teams will increase dramatically as AI generates more code, more options, and more complexity. Without clear thinking about problems and deliberate design of systems, AI adoption will follow the same disappointing trajectory as many Agile adoptions—lots of activity, little improvement, and eventually, blame directed at the tool rather than the system. Self-reflection Question: Are you adopting AI to solve a clearly defined problem, or because everyone else is doing it? If you automated your current process with AI, would you be locking in excellence or just accelerating dysfunction? [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 Darryl Wright Darryl is an Agile Coach and Instructor dedicated to helping organisations and leaders be both successful and humane. He has over two decades in IT delivery and business leadership, he champions Agile ways of working to create thriving workplaces where people are happy, productive, and deliver products customers truly love. You can link with Darryl Wright on LinkedIn, and visit Darryl's website at www.organa.com.au.

29 Okt 18min

Populärt inom Politik & nyheter

svenska-fall
motiv
aftonbladet-krim
p3-krim
fordomspodden
flashback-forever
rss-viva-fotboll
rss-krimstad
aftonbladet-daily
rss-sanning-konsekvens
spar
blenda-2
rss-vad-fan-hande
rss-krimreportrarna
rss-frandfors-horna
dagens-eko
olyckan-inifran
krimmagasinet
rss-expressen-dok
svd-nyhetsartiklar