AI Assisted Coding: Swimming in AI - Managing Tech Debt in the Age of AI-Assisted Coding | Lou Franco

AI Assisted Coding: Swimming in AI - Managing Tech Debt in the Age of AI-Assisted Coding | Lou Franco

AI Assisted Coding: Swimming in AI - Managing Tech Debt in the Age of AI-Assisted Coding

In this special episode, Lou Franco, veteran software engineer and author of "Swimming in Tech Debt," shares his practical approach to AI-assisted coding that produces the same amount of tech debt as traditional development—by reading every line of code. He explains the critical difference between vibecoding and AI-assisted coding, why commit-by-commit thinking matters, and how to reinvest productivity gains into code quality.

Vibecoding vs. AI-Assisted Coding: Reading Code Matters

"I read all the code that it outputs, so I need smaller steps of changes."

Lou draws a clear distinction between vibecoding and his approach to AI-assisted coding. Vibecoding, in his definition, means not reading the code at all—just prompting, checking outputs, and prompting again. His method is fundamentally different: he reads every line of generated code before committing it. This isn't just about catching bugs; it's about maintaining architectural control and accountability. As Lou emphasizes, "A computer can't be held accountable, so a computer can never make decisions. A human always has to make decisions." This philosophy shapes his entire workflow—AI generates code quickly, but humans make the final call on what enters the repository. The distinction matters because it determines whether you're managing tech debt proactively or discovering it later when changes become difficult.

The Moment of Shift: Staying in the Zone

"It kept me in the zone. It saved so much time! Never having to look up what a function's arguments were... it just saved so much time."

Lou's AI coding journey began in late 2022 with GitHub Copilot's free trial. He bought a subscription immediately after the trial ended because of one transformative benefit: staying in the flow state. The autocomplete functionality eliminated constant context switching to documentation, Stack Overflow searches, and function signature lookups. This wasn't about replacing thinking—it was about removing friction from implementation. Lou could maintain focus on the problem he was solving rather than getting derailed by syntax details. This experience shaped his understanding that AI's value lies in removing obstacles to productivity, not in replacing the developer's judgment about architecture and design.

Thinking in Commits: The Right Size for AI Work

"I think of prompts commit-by-commit. That's the size of the work I'm trying to do in a prompt."

Lou's workflow centers on a simple principle: size your prompts to match what should be a single commit. This constraint provides multiple benefits. First, it keeps changes small enough to review thoroughly—if a commit is too big to review properly, the prompt was too ambitious. Second, it creates a clear commit history that tells a story about how the code evolved. Third, it enables easy rollback if something goes wrong. This commit-sized thinking mirrors good development practices that existed long before AI—small, focused changes that each accomplish one clear purpose. Lou uses inline prompting in Cursor (Command-K) for these localized changes because it keeps context tight: "Right here, don't go look at the rest of my files... Everything you need is right here. The context is right here... And it's fast."

The Tech Debt Question: Same Code, Same Debt

"Based on the way I've defined how I did it, it's exactly the same amount of tech debt that I would have done on my own... I'm faster and can make more code, but I invest some of that savings back into cleaning things up."

As the author of "Swimming in Tech Debt," Lou brings unique perspective to whether AI coding creates more technical debt. His answer: not if you're reading and reviewing everything. When you maintain the same quality standards—code review, architectural oversight, refactoring—you generate the same amount of debt as manual coding. The difference is speed. Lou gets productivity gains from AI, and he consciously reinvests a portion of those gains back into code quality through refactoring. This creates a virtuous cycle: faster development enables more time for cleanup, which maintains a codebase that's easier for both humans and AI to work with. The key insight is that tech debt isn't caused by AI—it's caused by skipping quality practices regardless of how code is generated.

When Vibecoding Creates Debt: AI Resistance as a Symptom

"When you start asking the AI to do things, and it can't do them, or it undoes other things while it's doing them... you're experiencing the tech debt a different way. You're trying to make changes that are on your roadmap, and you're getting resistance from making those changes."

Lou identifies a fascinating pattern: tech debt from vibecoding (without code review) manifests as "AI resistance"—difficulty getting AI to make the changes you want. Instead of compile errors or brittle tests signaling problems, you experience AI struggling to understand your codebase, undoing changes while making new ones, or producing code with repetition and tight coupling. These are classic tech debt symptoms, just detected differently. The debt accumulates through architecture violations, lack of separation of concerns, and code that's hard to modify. Lou's point is profound: whether you notice debt through test failures or through AI confusion, the underlying problem is the same—code that's difficult to change. The solution remains consistent: maintain quality practices including code review, even when AI makes generation fast.

Can AI Fix Tech Debt? Yes, With Guidance

"You should have some acceptance criteria on the code... guide the LLM as to the level of code quality you want."

Lou is optimistic but realistic about AI's ability to address existing tech debt. AI can definitely help with refactoring and adding tests—but only with human guidance on quality standards. You must specify what "good code" looks like: acceptance criteria, architectural patterns, quality thresholds. Sometimes copy/paste is faster than having AI regenerate code. Very convoluted codebases challenge both humans and AI, so some remediation should happen before bringing AI into the picture. The key is recognizing that AI amplifies your approach—if you have strong quality standards and communicate them clearly, AI accelerates improvement. If you lack quality standards, AI will generate code just as problematic as what already exists.

Reinvesting Productivity Gains in Quality

"I'm getting so much productivity out of it, that investing a little bit of that productivity back into refactoring is extremely good for another kind of productivity."

Lou describes a critical strategy: don't consume all productivity gains as increased feature velocity. Reinvest some acceleration back into code quality through refactoring. This mirrors the refactor step in test-driven development—after getting code working, clean it up before moving on. AI makes this more attractive because the productivity gains are substantial. If AI makes you 30% faster at implementation, using 10% of that gain on refactoring still leaves you 20% ahead while maintaining quality. Lou explicitly budgets this reinvestment, treating quality maintenance as a first-class activity rather than something that happens "when there's time." This discipline prevents the debt accumulation that makes future work progressively harder.

The 100x Code Concern: Accountability Remains Human

"Directionally, I think you're probably right... this thing is moving fast, we don't know. But I'm gonna always want to read it and approve it."

When discussing concerns about AI generating 100x more code (and potentially 100x more tech debt), Lou acknowledges the risk while maintaining his position: he'll always read and approve code before it enters the repository. This isn't about slowing down unnecessarily—it's about maintaining accountability. Humans must make the decisions because only humans can be held accountable for those decisions. Lou sees potential for AI to improve by training on repository evolution rather than just end-state code, learning from commit history how codebases develop. But regardless of AI improvements, the human review step remains essential. The goal isn't to eliminate human involvement; it's to shift human focus from typing to thinking, reviewing, and making architectural decisions.

Practical Workflow: Inline Prompting and Small Changes

"Right here, don't go look at the rest of my files... Everything you need is right here. The context is right here... And it's fast."

Lou's preferred tool is Cursor with inline prompting (Command-K), which allows him to work on specific code sections with tight context. This approach is fast because it limits what AI considers, reducing both latency and irrelevant changes. The workflow resembles pair programming: Lou knows what he wants, points AI at the specific location, AI generates the implementation, and Lou reviews before accepting. He also uses Claude Code for full codebase awareness when needed, but the inline approach dominates his daily work. The key principle is matching tool choice to context needs—use inline prompting for localized changes, full codebase tools when you need broader understanding. This thoughtful tool selection keeps development efficient while maintaining control.

Resources and Community

Lou recommends Steve Yegge's upcoming book on vibecoding. His website, LouFranco.com, provides additional resources.

About Lou Franco

Lou Franco is a veteran software engineer and author of Swimming in Tech Debt. With decades of experience at startups, as well as Trello, and Atlassian, he's seen both sides of debt—as coder and leader. Today, he advises teams on engineering practices, helping them turn messy codebases into momentum.

You can link with Lou Franco on LinkedIn and visit his website at LouFranco.com.

Jaksot(200)

The Product Owner Who Made Retros Unsafe (And How We Fixed It) | Terry Haayema

The Product Owner Who Made Retros Unsafe (And How We Fixed It) | Terry Haayema

Terry Haayema: The Product Owner Who Made Retros Unsafe (And How We Fixed It) Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The biggest anti-pattern was that he made the retro unsafe... he would come to the retro and called people out for things that had not been done." The Bad Product Owner: The PO Who Made Retros Unsafe Terry describes a product owner who came from a management background focused on widgets and KPIs, completely unprepared for the collaborative nature of the product owner role. This person's biggest anti-pattern was making retrospectives unsafe by calling out individual team members for things not completed or not done to his satisfaction. When gentle coaching interventions failed, Terry took the dramatic step of excluding the PO from retrospectives entirely. Surprisingly, this shock treatment worked - when the PO asked why he wasn't invited, Terry used SBI feedback (Situation, Behavior, Impact) to help him understand how his actions were destroying team dynamics. The story has a positive ending, with the PO eventually understanding and changing his approach. In this segment, we refer to the Retrospective Prime Directive, and the SBI feedback framework. The Great Product Owner: The Customer Connector Terry's best product owner example saw their role not just as the voice of the customer, but as the connector between team and customers. Instead of relying solely on user stories and personas, this PO organized regular informal events where real customers and team members could meet, share pizza and beer, and have genuine conversations. These social connections led to deep customer understanding and resulted in their best feature ever - a simple addition that showed customers their last six orders for easy reordering. This feature increased both order frequency and size while dramatically improving the team's ability to empathize with their users. Self-reflection Question: How might you help your product owner move from being the voice of the customer to being the bridge that connects your team directly with real users? [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 Terry Haayema Terry is an international Author, Speaker, Conference Host, Trainer, Facilitator, Mentor and Transformative Coach whose personal purpose is to help people see differently, so they find joy. You can link with Terry Haayema on LinkedIn, or visit his website to learn more about his book.

26 Syys 16min

Why "Working Myself Out of a Job" Is Wrong for Scrum Masters | Terry Haayema

Why "Working Myself Out of a Job" Is Wrong for Scrum Masters | Terry Haayema

Terry Haayema: Why "Working Myself Out of a Job" Is Wrong for 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. "Success for a Scrum Master is to do myself out of a job... which I don't buy into at all, because a team will always need a coach." Terry challenges the common belief that Scrum Masters succeed by working themselves out of a job, arguing instead that teams always need coaching as they continuously improve. He emphasizes the importance of separating his outcomes from the team's success to avoid becoming part of the system he's trying to help. For Terry, success is measured by the visible joy he can create in people - when leaders approach him with happiness, when team members are excited to see him, when absenteeism drops because people actually want to come to work. He shares a powerful story of how helping teams find joy not only improved their performance but reduced their stress-related sick days from the highest to the lowest in their division. Featured Retrospective Format for the Week: Drawing Retrospectives Terry loves retrospective formats that use drawings and visual metaphors, like Draw Your Feelings, or the Sailboat retrospective. He explains that when teams draw pictures instead of immediately processing thoughts through language, they generate much richer and deeper insights. The approach works by having people first draw their thoughts, then asking "What led you to draw that picture?" This method bypasses the analytical mind and taps into more intuitive understanding. For longer-term retrospectives, Terry recommends Open Space Technology, which allows groups to self-organize around the most important questions they need to answer. Self-reflection Question: How do you measure your own success as a Scrum Master, and does that measurement inspire you to do your best work? [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 Terry Haayema Terry is an international Author, Speaker, Conference Host, Trainer, Facilitator, Mentor and Transformative Coach whose personal purpose is to help people see differently, so they find joy. You can link with Terry Haayema on LinkedIn, or visit his website to learn more about his book.

25 Syys 15min

When Consensus Becomes Paralysis—The Nemawashi Challenge For Agile Software Development | Terry Haayema

When Consensus Becomes Paralysis—The Nemawashi Challenge For Agile Software Development | Terry Haayema

Terry Haayema: When Consensus Becomes Paralysis—The Nemawashi Challenge For Agile Software 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. "The problem I'm facing is 'too much consensus'... we talk, bounce ideas, but we don't get going." Terry shares his current coaching challenge in a Japanese company where their cultural practice of Nemawashi (consensus building) has become a barrier to progress. While working across the entire organization, he's discovered that quality is suffering because teams aren't clear about desired outcomes before starting work. The excessive focus on building consensus means initiatives bounce between stakeholders without ever gaining momentum. Terry explains how he's experimenting with delaying detailed refinement to build shared understanding as teams progress, rather than trying to achieve perfect consensus upfront. He uses the metaphor of flying a plane - pilots don't stick rigidly to flight plans but constantly make small course corrections based on real-time feedback. Self-reflection Question: In your organization, what well-intentioned practices have become obstacles to the very outcomes they were designed to achieve? [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 Terry Haayema Terry is an international Author, Speaker, Conference Host, Trainer, Facilitator, Mentor and Transformative Coach whose personal purpose is to help people see differently, so they find joy. You can link with Terry Haayema on LinkedIn, or visit his website to learn more about his book.

24 Syys 17min

The High Cost of Unsafe Agile Retrospectives | Terry Haayema

The High Cost of Unsafe Agile Retrospectives | Terry Haayema

Terry Haayema: The High Cost of Unsafe Agile Retrospectives Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "She was kind of like the mum for the team... she was actually the glue that held the team together." Terry tells the story of a team that was functioning like a feature factory until a business analyst became their champion and "team mom." This BA supported everyone through agile transformation and helped build trust and healthy conflict. However, when she mentioned something in a retrospective that led to her being put on performance management and eventually leaving, the team rapidly self-destructed. They lost their sense of belonging and teamness, retreating back to working as independent professionals rather than collaborating. The story illustrates how leadership actions can instantly destroy weeks or months of trust-building work, and how critical psychological safety is for sustainable team performance. For more critical points on how to be a great leader, check this episode with Captain David Marquet, a thought leader in the leadership space who wrote Turn the Ship Around! Featured Book of the Week: The Five Dysfunctions of a Team by Patrick Lencioni Terry credits The Five Dysfunctions of a Team by Patrick Lencioni as massively influential in his career, particularly praising how Lencioni demonstrates that without trust as a foundation, teams cannot achieve anything else. The book's framework shows how lack of trust prevents healthy conflict, which prevents commitment, which prevents accountability, which prevents results. Terry found the way Lencioni illustrates these dysfunctions and their cascading effects to be incredibly valuable for understanding team dynamics and what's needed to build high-performing teams. In this segment, we also refer to Agile Software Development with Scrum, by Schwaber and Beedle. Self-reflection Question: What would happen to your team's dynamics if your most supportive, trust-building team member suddenly left tomorrow? [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 Terry Haayema Terry is an international Author, Speaker, Conference Host, Trainer, Facilitator, Mentor and Transformative Coach whose personal purpose is to help people see differently, so they find joy. You can link with Terry Haayema on LinkedIn, or visit his website to learn more about his book.

23 Syys 18min

When Scrum Practices Aren't Enough - Learning to Sense the System | Terry Haayema

When Scrum Practices Aren't Enough - Learning to Sense the System | Terry Haayema

Terry Haayema: When Scrum Practices Aren't Enough - Learning to Sense the System Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I didn't know how to 'sense' the system. I was focused on the scrum practices, I thought when practices were there all would be fine." Terry shares a powerful failure story from his second engagement as a Scrum Master, where he discovered that implementing Scrum practices isn't enough if you don't understand the underlying system driving team behaviors. He describes how individual KPIs were causing conflict between developers and testers - developers were measured on fewer defects while testers were measured on finding more defects. This systemic issue created dysfunction that no amount of daily standups or retrospectives could fix. Terry learned the hard lesson that Scrum Masters must be coaches for both the team and the organization, understanding how metrics and structures shape behavior before trying to implement agile practices. Self-reflection Question: What systemic forces in your organization might be working against the collaborative behaviors you're trying to foster in your 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 Terry Haayema Terry is an international Author, Speaker, Conference Host, Trainer, Facilitator, Mentor and Transformative Coach whose personal purpose is to help people see differently, so they find joy. You can link with Terry Haayema on LinkedIn, or visit his website to learn more about his book.

22 Syys 14min

BONUS: Building High-Performing Engineering Teams | Jochen Issing

BONUS: Building High-Performing Engineering Teams | Jochen Issing

BONUS: Jochen Issing on Building High-Performing Engineering Teams In this BONUS episode, we explore the fascinating journey of Jochen Issing, an engineering leader who brings unique insights from his background as a handball player and band member to building exceptional software development teams. From sports courts and music stages to engineering leadership, Jochen shares practical wisdom on psychological safety, team dynamics, and creating cultures where the best ideas win. From Sports and Music to Software Leadership "As soon as you complain about each other, you are starting to lose." Jochen's unconventional background as a handball player and band member has profoundly shaped his approach to engineering leadership. Drawing from team sports, he discovered that frustration leads to losing in both athletics and technology work. Great players in great teams optimize for the team's results, not individual glory. This translates directly to software development where great engineers slow down to make the team faster, recognizing that collective success trumps individual achievement. The lesson from the handball court is clear: when team members start blaming each other, they create a losing mindset that becomes self-fulfilling. Breaking the 10X Engineer Myth "It's not your success that makes our success, it's our success that makes your success." The mythology of the 10X engineer remains pervasive in software development, but Jochen challenges this with insights from team dynamics. The "hero culture" in companies often emerges when systems are already broken, requiring someone to step in and save the day. While we celebrate these heroes, we forget to ask the crucial question: how did we end up needing a hero in the first place? True high-performing teams don't require heroic individual efforts because they've built sustainable systems and shared knowledge. The goal isn't to eliminate talented individuals but to ensure that even the most skilled engineers can take time off without the organization grinding to a halt. Creating Psychological Safety Through Vulnerability "When psychological safety is missing, I try to ask ignorant questions - expose myself as being the least experienced person in the room." Building psychological safety requires intentional strategies that go beyond good intentions. Jochen employs a counterintuitive approach: when he senses team members hesitating to speak up, he deliberately asks "ignorant" questions to position himself as the least knowledgeable person in the room. This modeling behavior demonstrates that it's safe to admit uncertainty and ask questions. He also builds a culture of "challenging ourselves" by implementing ritualized dissent - assigning someone the specific job of finding flaws in proposed solutions. This prevents the dangerous harmony that can emerge when teams agree too quickly without proper scrutiny. The Power of the Expectation Sheet "I want people to share with me what might even drive them away from the company." Trust forms the foundation of effective team relationships, but building it requires explicit frameworks. Jochen uses an "expectation sheet" (See a prototype here Google Doc)- a document that formalizes mutual expectations between him and his team members. This tool establishes that he wants open, honest communication about everything, including situations that might drive someone to leave the company. The key principle is that he will never share confidential information or use personal disclosures against team members. This creates a relationship where he serves as both a representative of the company when necessary and a personal advocate for his team members when they need support navigating organizational challenges. Team-Centric Productivity and Collaboration "The team is the unit of productivity and delivery, not the individual." Effective engineering leadership requires balancing individual desires with team outcomes. Jochen emphasizes that while people naturally want to say "I did this," the focus must remain on team impact. This involves creating shared understanding of collective goals while still addressing individual needs and growth aspirations. Practical strategies include using on-call rotations to identify knowledge silos, implementing pair programming and mob programming to reinforce collaborative work patterns, and designing tasks that allow individuals to take ownership while remaining embedded in team efforts. The analogy to band dynamics is apt - when someone brings a song idea to the band, it evolves through collaboration into something different and usually better than the original vision. Building Sustainable High Performance "Great engineers slow down to make the team faster - which is how we get better teams." Sustainable high performance emerges when senior engineers invest in lifting the entire team rather than maximizing their individual output. This means senior staff level engineers focus less on their personal contributions and more on forming "tribes" across teams, coaching junior engineers, and building organizational capability. The measure of success shifts from individual heroics to collective achievement - if problems consistently require the same person to fix them, the team hasn't truly succeeded in building sustainable systems and shared knowledge. Recommended Resources for Further Reading Jochen recommends several foundational books for understanding team dynamics and engineering leadership. "The Culture Code" by Daniel Coyle explores the structure of high-performing teams and debunks myths about command-and-control leadership. "Product Development Flow" by Reinertsen provides the scientific foundation behind agile methodologies and explains what teams are really trying to solve. "The Culture Map" by Erin Meyer offers insights on working with diverse cultures and backgrounds to bring out the best in each team member. "Coaching Agile Teams" by Lyssa Adkins serves as a practical guide for developing coaching skills in technical environments. And our very own Scrum Master Toolbox podcast provides ongoing insights and real-world experiences from practitioners in the field. About Jochen Issing Jochen is an engineering leader who's all about building great teams and better developer experiences. From audio tech and cloud platforms to monorepos and feedback culture, he's done it all. A former bandmate and handball player, Jochen brings heart, trust, and collaboration into everything he builds with his teams. You can connect with Jochen Issing on LinkedIn and connect with Jochen Issing on Twitter.

20 Syys 53min

Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs | Shawn Dsouza

Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs | Shawn Dsouza

Shawn Dsouza: Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs 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. Shawn explores both ends of the Product Owner spectrum through real experiences. On one side, he addresses the "Forced" or "Accidental" Product Owner—a common but problematic pattern where organizations appoint someone based solely on product knowledge. He shares the story of a QA professional thrust into the PO role who knew the product inside out but lacked other essential PO skills, frustrating the team with inadequate responses. Through coaching questions inspired by "The Advice Trap," Shawn helped this reluctant PO reflect on responsibilities and develop confidence beyond technical knowledge. The Great Product Owner: The Story-Crafting Superstar Shawn celebrates a Product Owner who elevated user story writing to an art form—"the Picasso of writing user stories." This exceptional PO co-crafted clear, well-structured stories with the team and used AI to refine stories and acceptance criteria. Her meticulous preparation included intensive refinement sessions before vacations and expert story slicing techniques. By handling requirements clarity superbly, she freed the team to focus entirely on problem-solving rather than deciphering what needed to be built. The Bad Product Owner: The Forced/Accidental Product Owner Organizations frequently make the mistake of appointing the person with the highest product knowledge as Product Owner, assuming technical expertise translates to PO effectiveness. However, the Product Owner role requires diverse skills beyond product knowledge—stakeholder management, prioritization, communication, and strategic thinking. When a QA professional was thrust into this role, their deep product understanding couldn't compensate for underdeveloped PO competencies, leading to team frustration and project complications. In this segment, we refer to the Coach Your PO e-course published by your Scrum Master Toolbox Podcast! Self-reflection Question: What skills beyond domain expertise should you develop or look for when transitioning into or selecting someone for the Product Owner role? [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 Shawn Dsouza Shawn, a Mangalore native and Software Technology postgraduate from AIMIT, brings 8+ years of IT expertise, excelling as a Scrum Master fostering innovation and teamwork. Beyond technology, he leads SPARK, a social service initiative, and pursues his passion as an aquarist, nurturing vibrant aquatic ecosystems with dedication. You can link with Shawn Dsouza on LinkedIn.

19 Syys 15min

The Marathon Mindset—Building Agile Teams That Last Beyond Sprint Deadlines | Shawn Dsouza

The Marathon Mindset—Building Agile Teams That Last Beyond Sprint Deadlines | Shawn Dsouza

Shawn Dsouza: The Marathon Mindset—Building Agile Teams That Last Beyond Sprint Deadlines 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. Shawn defines himself as a "people-first Scrum Master" who measures success not through metrics but through daily interactions and team growth. He contrasts two teams: one that hit deadlines but lacked collaboration (unsustainable success) versus another that struggled with deadlines but excelled in conversations and continuous improvement (sustainable growth). For Shawn, protecting deep work and fostering genuine team collaboration indicates true success. He emphasizes that product development is a marathon, not a sprint, and warns that lack of meaningful conversations will inevitably lead to team problems. In this segment, we refer to the book Clean Language by Sullivan and Rees. Featured Retrospective Format for the Week: Sprint Awards Shawn champions the Sprint Awards retrospective format, moving beyond viewing retrospectives as just another Scrum event to recognizing them as critical team development opportunities. In this format, team members give awards to colleagues for various contributions during the sprint, with each award recipient explaining why they were chosen. Shawn prefers face-to-face, offline retrospectives and always starts with ice breakers to gauge how the team feels—whether they feel heard and connected. He believes in experimenting with different retrospective formats since no single approach works for every situation. Self-reflection Question: How do you balance achieving deliverable outcomes with building sustainable team relationships and collaboration patterns? [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 Shawn Dsouza Shawn, a Mangalore native and Software Technology postgraduate from AIMIT, brings 8+ years of IT expertise, excelling as a Scrum Master fostering innovation and teamwork. Beyond technology, he leads SPARK, a social service initiative, and pursues his passion as an aquarist, nurturing vibrant aquatic ecosystems with dedication. You can link with Shawn Dsouza on LinkedIn.

18 Syys 13min

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