AI Assisted Coding: Augmented AI Development - Software Engineering First, AI Second With Dawid Dahl

AI Assisted Coding: Augmented AI Development - Software Engineering First, AI Second With Dawid Dahl

BONUS: Augmented AI Development - Software Engineering First, AI Second

In this special episode, Dawid Dahl introduces Augmented AI Development (AAID)—a disciplined approach where professional developers augment their capabilities with AI while maintaining full architectural control. He explains why starting with software engineering fundamentals and adding AI where appropriate is the opposite of most frameworks, and why this approach produces production-grade software rather than technical debt.

The AAID Philosophy: Don't Abandon Your Brain

"Two of the fundamental developer principles for AAID are: first, don't abandon your brain. And the second is incremental steps."

Dawid's Augmented AI Development framework stands in stark contrast to "vibecoding"—which he defines strictly as not caring about code at all, only results on screen. AAID is explicitly designed for professional developers who maintain full understanding and control of their systems. The framework is positioned on the furthest end of the spectrum from vibe coding, requiring developers to know their craft deeply. The two core principles—don't abandon your brain, work incrementally—reflect a philosophy that AI is a powerful collaborator, not a replacement for thinking. This approach recognizes that while 96% of Dawid's code is now written by AI, he remains the architect, constantly steering and verifying every step.

In this segment we refer to Marcus Hammarberg's work and his book The Bungsu Story.

Software Engineering First, AI Second: A Hill to Die On

"You should start with software engineering wisdom, and then only add AI where it's actually appropriate. I think this is super, super important, and the entire foundation of this framework. This is a hill I will personally die on."

What makes AAID fundamentally different from other AI-assisted development frameworks is its starting point. Most frameworks start with AI capabilities and try to add structure and best practices afterward. Dawid argues this is completely backwards. AAID begins with 50-60 years of proven software engineering wisdom—test-driven development, behavior-driven development, continuous delivery—and only then adds AI where it enhances the process. This isn't a minor philosophical difference; it's the foundation of producing maintainable, production-grade software. Dawid admits he's sometimes "manipulating developers to start using good, normal software engineering practices, but in this shiny AI box that feels very exciting and new." If the AI wrapper helps developers finally adopt TDD and BDD, he's fine with that.

Why TDD is Non-Negotiable with AI

"Every time I prompt an AI and it writes code for me, there is often at least one or two or three mistakes that will cause catastrophic mistakes down the line and make the software impossible to change."

Test-driven development isn't just a nice-to-have in AAID—it's essential. Dawid has observed that AI consistently makes 2-3 mistakes per prompt that could have catastrophic consequences later. Without TDD's red-green-refactor cycle, these errors accumulate, making code increasingly difficult to change. TDD answers the question "Is my code technically correct?" while acceptance tests answer "Is the system releasable?" Both are needed for production-grade software. The refactor step is where 50-60 years of software engineering wisdom gets applied to make code maintainable. This matters because AAID isn't vibe coding—developers care deeply about code quality, not just visible results. Good software, as Dave Farley says, is software that's easy to change. Without TDD, AI-generated code becomes a maintenance nightmare.

The Problem with "Prompt and Pray" Autonomous Agents

"When I hear 'our AI can now code for over 30 hours straight without stopping,' I get very afraid. You fall asleep, and the next morning, the code is done. Maybe the tests are green. But what has it done in there? Imagine everything it does for 30 hours. This system will not work."

Dawid sees two diverging paths for AI-assisted development's future. The first—autonomous agents working for hours or days without supervision—terrifies him. The marketing pitch sounds appealing: prompt the AI, go to sleep, wake up to completed features. But the reality is technical debt accumulation at scale. Imagine all the decisions, all the architectural choices, all the mistakes an AI makes over 30 hours of autonomous work. Dawid advocates for the stark contrast: working in extremely small increments with constant human steering, always aligned to specifications. His vision of the future isn't AI working alone—it's voice-controlled confirmations where he says "Yes, yes, no, yes" as AI proposes each tiny change. This aligns with DORA metrics showing that high-performing teams work in small batches with fast feedback loops.

Prerequisites: Product Discovery Must Come First

"Without Dave Farley, this framework would be totally different. I think he does everything right, basically. With this framework, I want to stand on the shoulders of giants and work on top of what has already been done."

AAID explicitly requires product discovery and specification phases before AI-assisted coding begins. This is based on Dave Farley's product journey model, which shows how products move from idea to production. AAID starts at the "executable specifications" stage—it requires input specifications from prior discovery work. This separates specification creation (which Dawid is addressing in a separate "Dream Encoder" framework) from code execution. The prerequisite isn't arbitrary; it acknowledges that AI-assisted implementation works best when the problem is well-defined. This "standing on shoulders of giants" approach means AAID doesn't try to reinvent software engineering—it leverages decades of proven practices from TDD pioneers, BDD creators, and continuous delivery experts.

What's Wrong with Other AI Frameworks

"When the AI decides to check the box [in task lists], that means this is the definition of done. But how is the AI taking that decision? It's totally ad hoc. It's like going back to the 1980s: 'I wrote the code, I'm done.' But what does that mean? Nobody has any idea."

Dawid is critical of current AI frameworks like SpecKit, pointing out fundamental flaws. They start with AI first and try to add structure later (backwards approach). They use task lists with checkboxes where AI decides when something is "done"—but without clear criteria, this becomes ad hoc decision-making reminiscent of 1980s development practices. These frameworks "vibecode the specs," not realizing there's a structured taxonomy to specifications that BDD already solved. Most concerning, some have removed testing as a "feature," treating it as optional. Dawid sees these frameworks as over-engineered, process-centric rather than developer-centric, often created by people who may not develop software themselves. AAID, in contrast, is built by a practicing developer solving real problems daily.

Getting Started: Learn Fundamentals First

"The first thing developers should do is learn the fundamentals. They should skip AI altogether and learn about BDD and TDD, just best practices. But when you know that, then you can look into a framework, maybe like mine."

Dawid's advice for developers interested in AI-assisted coding might seem counterintuitive: start by learning fundamentals without AI. Master behavior-driven development, test-driven development, and software engineering best practices first. Only after understanding these foundations should developers explore frameworks like AAID. This isn't gatekeeping—it's recognizing that AI amplifies whatever approach developers bring. If they start with poor practices, AI will help them build unmaintainable systems faster. But if they start with solid fundamentals, AI becomes a powerful multiplier that lets them work at unprecedented speed while maintaining quality. AAID offers both a dense technical article on dev.to and a gentler game-like onboarding in the GitHub repo, meeting developers wherever they are in their journey.

About Dawid Dahl

Dawid is the creator of Augmented AI Development (AAID), a disciplined approach where developers augment their capabilities by integrating with AI, while maintaining full architectural control. Dawid is a software engineer at Umain, a product development agency.

You can link with Dawid Dahl on LinkedIn and find the AAID framework on GitHub.

Avsnitt(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 Sep 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 Sep 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 Sep 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 Sep 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 Sep 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 Sep 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 Sep 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 Sep 13min

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