Rajveer Prasad: The Product Owner Who Commits Before the Team Can Think In this episode, we refer to product discovery, user acceptance testing, and REST APIs. The Great Product Owner: Market Knowledge Without Intrusion Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They have the knowledge, they are not intrusive with that knowledge." - Rajveer Prasad   Rajveer has seen strong Product Owners combine market understanding, discovery discipline, and technical awareness without taking control away from the team. Great Product Owners understand the product market, run product discovery and hypothesis cycles, and bring capabilities to the team only after doing the groundwork on value and importance. They also understand enough about the technology to follow the conversation when developers talk about APIs or architecture, but they do not use that knowledge to dictate the solution. Instead, they stay with the "what" and let the team work through the "how." Rajveer also values Product Owners who participate in retrospectives and sizing sessions, challenge the team to think better, and let the team learn through its own cycles.   Self-reflection Question: Where could your Product Owner's technical knowledge help the team think better without taking ownership away from them? The Bad Product Owner: Client Promises That Cut Testing 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.   "Don't give a date yet. We are not sure. Let's take this back to the team." - Rajveer Prasad   The anti-pattern Rajveer highlights is the client-facing Product Owner who commits too early. In his example, the Product Owner had technical acumen and good intentions, but when the client pushed for a better timeline, he shortened UAT, reduced integration time, ignored technical debt, and left the team to absorb the consequences. From the outside, this Product Owner looked successful because he got commitments and the organization rewarded that behavior. Under the hood, the team struggled. Rajveer's advice is to first understand the Product Owner's perspective and align around the same objective: helping the client win. Then get closer to the conversations where commitments are made. Rajveer became a sounding board, joined key cadences, and helped the Product Owner replace instant dates with a better habit: take the request back to the team, include the tech lead, and return with a commitment the team could actually hold.   Self-reflection Question: What commitment habit do you need to help your Product Owner change before it damages the team?   [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 Rajveer Prasad   Our guest today is Rajveer Prasad, founder of OAKKTREEUNII. He's spent years helping aspiring and working project managers and Scrum Masters break into IT delivery — and grow once they're there — through real projects, real interview prep, and real accountability. He's mentored hundreds through career changes most people call impossible. Welcome, Rajveer   You can link with Rajveer Prasad on LinkedIn.

Rajveer Prasad: Success for Scrum Masters Is the Team's Life After You Leave Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you have not helped your team move from point A to point B positively, you are just doing part of the job." - Rajveer Prasad   Rajveer defines success for Scrum Masters through the change they leave behind in the lives of the people they serve. Delivery outcomes matter, and he names lead time as a useful end-to-end metric, but he warns that numbers alone miss the deeper work. For Rajveer, success shows up in relationship signals: whether people want to have lunch with you, whether they trust you enough to help in a rare crunch without being forced, and whether they still call you after you leave the organization. Those signals matter because Scrum Masters often come from outside the technical team and must earn a place in the system. The job is to help people move from point A to point B, not only in output, but also in work-life balance, skills, confidence, and the quality of collaboration across the whole team, including the Product Owner.   Self-reflection Question: If you left your team next month, what evidence would show that their day-to-day life improved because you were there? Featured Retrospective Format for the Week: Sailboat Retrospective Rajveer's preferred retrospective is the Sailboat format because it helps teams move beyond sprint details and talk about the system they operate in. He uses it to explore what is pushing the team forward, what is anchoring them, where the risks are, and how the team feels. For Rajveer, the format works because it "conditions you for a conversation" and creates space to discuss patterns, behaviors, and ways of working instead of only reviewing tasks.   [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 Rajveer Prasad   Our guest today is Rajveer Prasad, founder of OAKKTREEUNII. He's spent years helping aspiring and working project managers and Scrum Masters break into IT delivery — and grow once they're there — through real projects, real interview prep, and real accountability. He's mentored hundreds through career changes most people call impossible. Welcome, Rajveer   You can link with Rajveer Prasad on LinkedIn.

Rajveer Prasad: Using Scrum Master Working Agreements to Make AI Safer 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.   "AI can put garbage in a very good wrapping and give it to you, and you're none the wiser." - Rajveer Prasad   Rajveer brings a current challenge from his own work with AI: the false sense of achievement that comes from getting a polished output before the work is truly safe, scalable, or responsible. As a non-developer building AI-supported systems, he found that an agent can quickly produce something that appears to work, while missing security, architecture, testing, or cost implications. The coaching conversation turns toward something Scrum Masters know well: working agreements. Rajveer started defining roles, values, principles, and rules for the agent, treating it like a team member that needs clear expectations. He asks the AI to explain decisions in a way a Scrum Master can understand, captures lessons when something goes wrong, and plans more before building. The surprise is that AI work mirrors team coaching: set agreements, run small experiments, inspect the results, update the system, and avoid rushing into output just because the tool can move fast.   In this episode, we refer to working agreements, red-green-refactor, Ollama, and AI agents.   Self-reflection Question: What working agreements would make your AI experiments safer before you scale them?   [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 Rajveer Prasad   Our guest today is Rajveer Prasad, founder of OAKKTREEUNII. He's spent years helping aspiring and working project managers and Scrum Masters break into IT delivery — and grow once they're there — through real projects, real interview prep, and real accountability. He's mentored hundreds through career changes most people call impossible. Welcome, Rajveer   You can link with Rajveer Prasad on LinkedIn.

Rajveer Prasad: The Agile Team That Turned Overtime Into a Quality Problem Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Working harder and working longer is not helping anyone. It's just making what we do more difficult and complex." - Rajveer Prasad   Rajveer worked with a retail organization moving into SAP HANA, with teams spread across geographies and cultures. The team wanted to help, so they worked evenings, weekends, and extra hours to keep commitments alive. At first, the organization did not demand that behavior, but once it became visible, it became the new normal. The downstream effect was predictable: bad planning, overcommitment, reduced testing, skipped regression, failed integrations, rework, and a rising defect rate. Rajveer gathered data to show the cause and effect, then worked first with leadership because expectations had already been formed outside the team. Once stakeholders understood that the "faster" approach was degrading quality, Rajveer brought the data to the team and created a stricter operating routine. The team needed slack, a five-day working rhythm, and permission to say no so they could improve quality instead of competing against themselves.   In this segment, we talk about SAP HANA, technical debt, and sustainable pace.   Self-reflection Question: Where is your team using extra hours to hide a planning or quality problem? Featured Book of the Week: The Goal by Eliyahu M. Goldratt Rajveer has read and listened to The Goal by Eliyahu M. Goldratt many times, and each pass gives him a new angle on bottlenecks, flow, and the theory of constraints. For him, the book is foundational because it teaches Scrum Masters to look beyond local effort and see how the system shapes outcomes. As Rajveer puts it, "Every time I'm going through the book, I'm thinking slightly different."   [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 Rajveer Prasad   Our guest today is Rajveer Prasad, founder of OAKKTREEUNII. He's spent years helping aspiring and working project managers and Scrum Masters break into IT delivery — and grow once they're there — through real projects, real interview prep, and real accountability. He's mentored hundreds through career changes most people call impossible. Welcome, Rajveer   You can link with Rajveer Prasad on LinkedIn.  

Rajveer Prasad: When Delivery Pressure Pulls Scrum Masters Into the Details 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.   "Failures are expected no matter when and where you are." - Rajveer Prasad   Rajveer Prasad did not plan to become a Scrum Master. He studied hospitality management and expected to build a career as a chef, but the travel and hospitality industry froze after 9/11. A survival job led him into a call-center environment, then American Express, and eventually into delivery work and Scrum training. In this episode, Rajveer shares a failure from a new product introduction where he was brought in as a consultant, expected to run the team, and slowly pulled into delivery management. The milestone plan looked reasonable, but customer collaboration was weak, dependencies were unclear, and Rajveer found himself operating at a 50-foot view when he needed to step back. The turning point came from a client-side manager who gave direct feedback without turning the situation into a personal judgment. That support helped Rajveer move from firefighting to orchestration, rebuild structure, and treat the problem as a system to improve.   In this episode, we refer to new product introduction and systems thinking.   Self-reflection Question: When delivery pressure rises, do you move closer to the details, or do you step back far enough to see the system?   [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 Rajveer Prasad   Our guest today is Rajveer Prasad, founder of OAKKTREEUNII. He's spent years helping aspiring and working project managers and Scrum Masters break into IT delivery — and grow once they're there — through real projects, real interview prep, and real accountability. He's mentored hundreds through career changes most people call impossible. Welcome, Rajveer   You can link with Rajveer Prasad on LinkedIn.  

BONUS: Breaking the Permission Loop in Agile Teams In this BONUS episode, we explore why teams often wait for permission even when they already have skill, tools, and good ideas. Tara Scott, executive, product, and culture coach and author of Breaking the Permission Loop, explains how agency starts with noticing our own reactions, building alignment, and practicing small moments of self-trust. When a Compliment Becomes a Detour "You don't really feel like you can say no. So I said yes."   Tara starts with a startup story many Scrum Masters and product leaders will recognize. She was building momentum with user research when a CEO redirected her into a data science initiative that sounded urgent, but did not answer the core product question: do people actually use this product? The request was framed as a compliment, and that made it harder to challenge. Tara's point is practical: sometimes the permission loop begins in the small space between our concern and the automatic yes that comes out before we have understood the tradeoff. Slow Down Before the Yes "Sometimes no isn't even no. It's just not right now or give me more context."   For Tara, the first move is observation. Before a team can change a pattern, people need to notice what happens inside them when pressure rises: defensiveness, shame, blame, justification, or the urge to please. Tara connects this to The Responsibility Process, a practice for recognizing when we are below the line and bringing attention back to our own behavior. In a team setting, this is not about blaming ourselves for everything. It is about giving ourselves enough room to ask a better question before committing to work we do not believe in. Permission Loops Are Patterns We Can Interrupt "For me, a permission loop is there's different opportunities within those loops where we can step in and say, this could be a really good time to break this."   Tara chose the word loop because the pattern repeats until someone interrupts it. Teams say, "it is what it is," decisions wait for a manager, and people move through the same script because it feels familiar. The useful part is that loops also create openings. A meeting, a question, a moment of discomfort, or a request for one more thing can become the cue to pause and run a small experiment. The goal is not dramatic confrontation. It is a calmer, clearer way to step into the moment with evidence, context, and a suggestion. Healthy Alignment Is Different From Waiting for Permission "It is validate, communicate, confirm."   Tara makes an important distinction between acts of authorization and permission-based behavior. In software teams, some decisions need security, architecture, compliance, or dependency alignment. That is real. The permission loop starts when people ask for approval for things nobody can actually give them, such as self-trust, courage, or the right to raise a concern. Tara's working pattern is simple: validate what needs to happen, communicate it clearly, and confirm that the right people are aligned. That connects closely with intent-based leadership from David Marquet's Turn the Ship Around!: say what you intend to do, check alignment, then move. Autonomy Without Direction Can Leave Teams Lost "I was told I have total freedom, but to do what?"   Tara challenges a common agile assumption: autonomy alone will not solve the problem. She describes a team that had been told they had freedom, but no shared goal. Leadership and developers blamed each other, and everyone was using different language for success. Without direction and explicit alignment, autonomy becomes another source of confusion. That is why Tara shifts the focus toward agency: enough trust in yourself to speak, enough confidence to offer a path forward, and enough humility to be wrong and still keep working with others. Atomic Habits for Breaking the Loop "We have to start where we start and start small."   Tara connects her six-week practice to James Clear's Atomic Habits: habits continue because the cues and rewards are already wired into us. Breaking a permission loop also needs cues. In Tara's startup example, the cue could have been the CEO asking, "What do you think?" That would have been her window to explain the user research data, name the tradeoff, and propose a better way forward. If the cue does not appear, we may need to create it ourselves. The practice is small, but the shift is significant: prepare for the moment before emotion runs the meeting. About Tara Scott Tara Scott is an executive, product, and culture coach with 20+ years in agile, helping organizations build healthier, behavior-driven cultures. Her book, Breaking the Permission Loop, is out now. Tara is a certified Fearless Organization practitioner focused on psychological safety. LinkedIn: Tara Scott.   You can link with Tara Scott on LinkedIn and find more about Tara's work and Breaking the Permission Loop at TaraScott.net.

BONUS: AI as the Third Perspective for Agile Delivery AI is already changing how agile delivery managers, Scrum Masters, and software teams handle the day-to-day work of delivery. In this BONUS episode, Rohini Prava shares how her team moved from experimenting with Cursor to using AI for practical work: bug analysis, ticket preparation, test planning, reporting, and reducing painful meetings. From Java Developer to Agile Delivery Manager "I see a good fit. And one of the scrum masters was going on holiday and I got the opportunity, I tried it, I liked it and I think I did well because I was given the role."   Rohini started her career as a Java developer in India, then moved into people management and delivery-focused work before relocating to the UK. A temporary opportunity to cover for a Scrum Master opened the door to a new direction. That experience eventually led her into the Agile Delivery Manager role, where she now leads a distributed team delivering insurance solutions. When AI Became Part of the Work "It stopped being a curiosity when I integrated it in my work. And the fun started."   For Rohini, the shift happened when her company gave access to Cursor, a developer-focused AI tool. Instead of treating it as something only developers could use, she tested it against real delivery work. The first meaningful example came before a retrospective-style meeting on a difficult project. By giving AI access to project data from Jira Service Management and Azure DevOps, she generated an eight-page analysis in under an hour. The result was a more factual, constructive conversation instead of a meeting based on memory, frustration, or blame. AI Across the Delivery Team "It really helps the devs to investigate issues, going through the legacy code, because some of the technology they may not even be familiar with."   Rohini describes AI adoption as early, practical, and team-specific. Her team connected Cursor with Azure DevOps through the Model Context Protocol concept, giving the tool useful context about tickets and code. Developers use it to explore legacy code, brainstorm solutions, and support pair-programming-style thinking. Business analysts use it to draft tickets and acceptance criteria. QA team members use it to strengthen test plans and coverage. Rohini uses it for reporting, meeting preparation, email drafting, and pulling useful data from delivery events. Measuring Impact Beyond Speed "If you're just simply going with, oh, I've used it for quickly getting the reports, but we need to sit and look at, do we really need that report?"   Rohini is careful not to frame AI only as a speed tool. Her point is that teams need to measure whether AI changes anything that matters. One personal example was timesheet review: a weekly task that used to take five to six hours. By building a small tool to help with review, she reduced that work to about one hour. The lesson for agile practitioners is direct: start by looking at the work that consumes time, then ask whether AI actually reduces waste or simply creates more output. Using AI to Reduce Meetings and Improve Quality "AI showed us that you can do less meetings, but just focus on one or two actions and see what change you can bring."   One of the strongest team examples came from long root cause analysis meetings. The team had many bugs and spent 60 to 90 minutes with 11 or 12 people trying to analyze them. The meetings produced long action lists, but those lists were hard to turn into focused improvements. Rohini gave AI six months of bug data and asked for the most painful patterns. The suggestion was simple: QA slippage was high, and the team needed an "escape reason" field to understand why bugs were missed before reaching customers or UAT. That small change helped the team move from broad discussion to focused learning about test plan gaps and test coverage. The Risks: Over-Reliance, Overuse, and Governance "We don't have to automate everything just because we have AI. We don't have to include it in every task."   Rohini warns teams not to trust confident AI answers without checking them. AI can produce well-structured responses that feel authoritative, but teams still need to validate the output against their own context. She also warns against overuse: AI does not need to be inserted into every task simply because the tool is available. For organizations, governance and security matter as well, especially when project data, customer context, source code, and delivery information are being exposed to AI-enabled tools. Start Small, Inspect, Iterate, Adapt "Start something basic, small that you know how to validate."   Rohini's advice for Scrum Masters, Agile Coaches, and Agile Delivery Managers is to start with a familiar, time-consuming task. Pick something you understand well enough to evaluate. Ask AI to help with version one. Measure the result, validate it, then iterate after a week. This gives teams a practical way to build judgment before using AI on larger or more ambiguous problems.   About Rohini Prava   Rohini leads a diverse, distributed software development team delivering insurance solutions. She bridges business strategy and technical execution, managing stakeholders, mitigating delivery risks, and reducing cycle times. A composed, detail-oriented leader, she coaches autonomous, cross-functional teams, fostering innovation, continuous improvement, strong customer satisfaction, and meaningful impact across organizations.   You can link with Rohini Prava on LinkedIn.

BONUS: AI Makes Starting Work Easy, But Flow Still Finishes It AI is changing software teams, but Liz Rettig brings the conversation back to flow, strategy, and the discipline of finishing. In this BONUS episode, Vasco and Liz explore how Scrum Masters can use AI to make policies visible, help teams manage WIP, support Product Owners, and keep the organization focused on valuable slices instead of faster output alone. From Anthropology To Kanban And AI "As a Scrum Master, you're an anthropologist because you're watching people and you're recording how they are working."   Liz starts with her path from anthropology to Scrum Mastering, agile coaching, and professional Kanban training. That background matters because her work has always been about observing how people interact with systems. AI did not replace that skill. It made the system easier to see. In one client engagement, a team adopting an agentic framework also needed agile ways of working around that new capability. Liz saw that AI could help teams reach forecasting, strategy, and board-reading conversations much faster than before, as long as the human system was still designed with intent. AI Helps Teams See Flow Earlier "This is a tool that can help me get teams further quicker than ever before."   Liz describes AI as a practical accelerator for visibility. Instead of spending months collecting and cleaning data by hand, teams can use AI-enabled tools to surface the information already living in Jira, code repositories, customer feedback, and flow metrics systems. That changes the coaching conversation. Scrum Masters and agile coaches no longer need to persuade teams that the data could exist. They can bring the data into the room and ask what it means for the way work is moving. Starting Is Free, Finishing Is Still The Discipline "Starting is free with AI, and I get into that pickle all the time too."   The central warning from Liz is simple: AI makes it easier to start work, but it does not automatically make teams finish the right work. She connects this directly to Kanban practices: limit work in progress, watch aging work, make policies explicit, and help the team focus on moving existing items before pulling more into the system. Liz has used AI hooks, skills, commands, and team rules to remind people when they are about to break their own policies. The point is not to block people blindly. The point is to make the tradeoff visible, capture why the team chose to break a WIP limit, and bring that evidence into retrospectives. Scrum Masters Can Put Team Policies Into The AI System "Everybody has the ability to run it, and I expect everybody on the team to run it."   Liz does not keep the AI-enabled flow tools as a coaching black box. She works with teams to define their policies, then embeds those policies into the tools the team uses every day. A daily board walk can highlight aging work, blocked items, WIP issues, and the topics worth discussing in the daily review of flow or daily Scrum. This shifts the Scrum Master's work away from repeating reminders and toward helping the team interpret what they see. AI becomes a way to make the team's agreements visible and repeatable. Leaders Still Need Outcome Conversations "Everybody wants more faster."   Liz is clear that many organizations begin AI adoption with an output goal: more stories, more work items, more projects, less time. One client moved from roughly 75 items per month to around 400. That created a new and more important question: are those 400 items connected to the value the organization actually wants? Liz explains how AI helped reorganize work around objectives, key results, epics, and delivery data so leadership could see how throughput was being spent. The useful conversation was not "how much more did we do?" It was "how much of our capacity went to strategy, bugs, maintenance, and the work we said mattered?" The Constraint Moves Left "The constraint that we're finding is having the right work that aligns to the strategy ready in our backlog."   When delivery gets faster, the bottleneck often moves toward product strategy, customer discovery, and backlog readiness. Liz saw teams capable of shipping far more work than before, but the business was not always ready with the strategic work it wanted delivered. That makes Product Owners more important, not less. AI can help with the administrative side: checking whether a ticket already exists, turning customer conversations into well-structured work items, and keeping Jira cleaner. But Liz argues that Product Owners still need time to talk with customers, shape direction, and decide what is worth building. Smaller Slices Matter More With AI "Now we've just built the wrong thing faster."   Liz pushes back on the idea that AI makes big upfront specifications or waterfall thinking attractive again. If teams use AI to build large batches faster, they can also waste budget faster. Her answer is smaller valuable slices, delivered incrementally, with feedback built into the way the team works. She has used AI to help break epics into customer-facing slices rather than functional layers. That matters because the team can validate learning earlier, change direction cheaply, and keep the work connected to customer value. About Liz Rettig Liz Rettig is founder of Lil Agile Monster and a Professional Kanban Trainer. She helps teams use Kanban, flow metrics, and real data to improve predictability. Her work spans healthcare, insurance, marketing, portfolio Kanban, and AI-assisted delivery. LinkedIn: lizrettig-agilecoach.   You can link with Liz Rettig on LinkedIn, visit Lil Agile Monster, and explore Liz's Kanban Playbook.

BONUS: AI Is Not Just Typing Faster With Marcus Hammarberg In this BONUS episode, Vasco Duarte and Marcus Hammarberg explore what changes when AI agents move from writing small functions to creating whole features, running through tickets, and even improving their own instructions. The conversation keeps coming back to a simple but difficult question: if agents make software delivery faster, what should humans use that speed for? When the Agent Writes the Feature "What I realized was that the agent could now write the code from a prompt that I gave it, and it was good enough that I didn't have to touch a lot of it."   Marcus starts with the moment that changed his own practice: in December 2025, he used an AI agent to build a feature for a flow metrics app based on Jira change logs. Before that, AI coding felt like asking for small functions and then cleaning up the result. This time, the agent could take a feature-level prompt and produce something useful. That shifted the question from "can AI help me type code?" to "what happens to planning, quality, and ownership when implementation becomes dramatically faster?" Slowing Down Enough To Think "You end up not only not having seen the code, but not maybe even know what you wrote."   Vasco connects Marcus' experience to an earlier episode where Marcus had to learn to program after breaking his hand. Back then, the lesson was that typing was not the bottleneck. Thinking was. Now AI has made "typing" even faster, and Marcus warns that this creates a new danger: teams can approve suggestions, specs, and generated code without really understanding the intent they gave the system. In that world, slowing down becomes part of the human job. From Developer To Robot Instructor "With the robot in place, what are you doing now? You're giving the robot instructions, and you're verifying the result. This is exactly what we are doing with the AI now."   After rereading The Goal, Marcus started to see AI agents as the software equivalent of factory robots. A welder used to make the weld directly. With robots, the human writes instructions and verifies the result. Software is entering the same kind of transition. The open question is uncomfortable: can someone reliably verify AI-generated software without being a strong developer first? Marcus does not pretend to know the answer, and that uncertainty is part of the value of the conversation. Harnesses, Feedback Loops, And Agent Teams "A really good harness should also have some deterministic checks in the feedback mechanism."   Marcus describes teams experimenting with "lights-out" agent factories: a project manager agent receives intent, delegates to sub-agents, the agents move work across a Kanban board, and they even run retrospectives to improve their own instructions. That sounds futuristic, but Marcus brings it back to Agile basics. If prompts and guardrails are non-deterministic, then the harness needs deterministic feedback: tests, linting rules, functional checks, non-functional checks, architectural rules, and explicit slices of work that humans can test before moving on. The lesson is not to abandon Agile. It is to make feedback loops more concrete because the work is moving faster. The Human Side Of Losing The Easy Wins "I don't feel the same kind of ownership when I have prompted my way to a good application as I did when I wrote it."   The episode also names a quieter transformation: developers may lose the small dopamine hits that came from solving tiny coding problems, seeing tests pass, and refactoring by hand. If agents handle the easy work, humans may be left with harder, slower problems: intent, architecture, product value, safety, and trade-offs. That changes the emotional shape of development. Marcus and Vasco explore what happens when a developer is no longer only a coder, but the manager of an agent team. Stop Measuring AI By Output "Awesome, are you selling percentages?"   Marcus brings the conversation back to Theory of Constraints: throughput is not how busy the robots are, how many pull requests were merged, or how many tokens were consumed. Throughput is economic value. Vasco and Marcus connect this to product thinking: if AI lets teams produce more features, that only matters when those features create better outcomes for customers and the business. Otherwise, AI becomes a faster feature factory. As Marcus puts it, if people do not understand the "why" and the metric they are optimizing, AI is truly just typing faster. What To Read Next "It starts and stops with The Goal."   Marcus recommends starting with The Goal by Eliyahu Goldratt, then applying its factory lessons to software, flow, and AI agents. Vasco also mentions Ari-Pekka Skarp's Scrum Master Toolbox episode, Philip Su's work on dark factories, and Spec Kit. Marcus points listeners to his writing at marcusoft.net, where he is exploring AI as software development's new set of robots.   About Marcus Hammarberg   Marcus Hammarberg is a Swedish agile consultant, Kanban practitioner, and author of Kanban in Action and Salvation: The Bungsu Story, about using Lean, Agile, and Kanban to help an Indonesian hospital recover from crisis. Previous Scrum Master Toolbox episodes: Marcus page. LinkedIn. Today he explores agentic software development in practice.   You can link with Marcus Hammarberg on LinkedIn, read his writing at marcusoft.net, and find his previous Scrum Master Toolbox episodes on the Marcus Hammarberg guest page.

BONUS: AI in the SDLC Puts Customer Feedback Before Faster Typing AI is already changing software development, but David Mantica argues that the real shift is not only in code generation. In this BONUS episode, Vasco and David talk about what happens when AI enters the whole software development life cycle: executive decision-making, Scrum Master work, product feedback, data quality, agentic systems, and the human skill of learning to adapt. From Executive Curiosity to Real AI Use Cases "You have two directions you can go with AI. One is productivity. The other part of AI that organizations haven't quite tapped into yet is how do you make money with it?"   David describes AI adoption as something that, like agile and AWS before it, often starts in the middle of the organization before executives fully understand what is happening. Early conversations were about policy, regulation, and tool choices. Now, the conversation has moved toward use cases: where GenAI helps personal productivity, where agentic systems fit, and how organizations turn the tools into actual business value. David also points out a gap that matters for leaders: many executives know their people are using AI, but they are not using it deeply themselves, which makes it harder for them to see what is possible inside their own business model. AI Should Move Teams Closer to the Business "If a team does this right, they're going to keep getting closer and closer to the business. They're going to keep spending more time on what it is that we should be building, not on just building it."   For David, faster coding is only one part of the SDLC change. Scrum Masters can use AI to improve backlog work, user story mapping, retrospective follow-up, and team data, but the point is not better administrative output. The point is to free time for coaching, communication, and helping teams return to the agile way of working instead of being trapped by artifacts and process. If developers become faster while product discovery, testing, security, and customer feedback stay unchanged, the organization has only accelerated part of the system. The Bottleneck Is Value, Not Typing Speed "Can I test more before I go to production? And can I talk to the client more before I actually lock in?"   David and Vasco connect AI in the SDLC to product discovery. Coding tools such as Factory may help teams produce software faster, but David argues that the bigger opportunity is to test more ideas, prototypes, classes, webinars, or internal tools with real customers. This links directly to The Black Swan by Nassim Nicholas Taleb: only the market can tell us what is valuable. In practical terms, AI should help teams bring product thinking closer to the coder and bring customer feedback into the SDLC instead of treating it as something that happens after delivery. Governance Has To Catch Up With AI Productivity "Organization uses AI, they see the productivity increases, they hire 10-20% less staff because they're getting that productivity increase, and then they create no real new value."   David is blunt that many organizations are not yet changing governance, portfolio decisions, budgeting, or success metrics fast enough. Measuring more pull requests per developer is not the same as measuring more value for customers. Vasco and David explore the need for internal product marketing, lightweight feedback loops, and ways for internal and external customers to touch, test, and react to what is being built. Without that, companies risk using AI to reduce cost while missing the larger opportunity: learning faster than competitors. Agentic Systems Are Only As Good As Their Data "The agent is only as good as the pool of information by which it's pulling from to answer the questions by which you're asking it to answer."   Data quality becomes much more concrete when agents move from answering questions to taking action. David frames agentic systems as coded agents: they behave like a person using GenAI, but they still depend on the information they can access. That means teams need to think carefully about grounding, retrieval, trusted documentation, and the boundaries around what an agent is allowed to use. A weak data pool creates weak action, and a poorly grounded customer service agent will act like a poorly trained human agent. Lightweight Testing Beats Big AI Programs "What is your lightweight way of testing your agents without boiling the ocean?"   David warns against treating AI adoption as a top-down program that must be perfect before anyone uses it. Agentic systems will make mistakes, just like people do, so teams need controlled environments, visible feedback, and repeated adjustment. Vasco connects this to startup odds: most new initiatives fail, so the answer is not to plan harder, but to test more ideas and learn faster. David's advice is to keep the experiments lightweight, fund learning, and build the capability to test agents without trying to build an entire AI universe first. The Human Skill Is Adaptation "The human skill needs to be teaching people to change and adapt, and be comfortable with getting rid of skills that they thought made them hundreds of thousands of dollars that are totally unnecessary now."   David closes with the human side of AI in software organizations. He connects AI adoption to adaptive leadership and the fear people feel when skills that once made them valuable may no longer be enough. For Scrum Masters, leaders, and product people, the work is to help teams learn, test, and adapt without pretending that the future is already clear. The customer remains the final judge of value, and AI makes that truth more urgent, not less. About David Mantica David Mantica is Managing Director at SoftEd, where he helps organizations build practical skills for AI, agile, leadership, and business analysis. With 30+ years of experience and 700+ speaking engagements, he makes emerging technology accessible for working teams.  LinkedIn   You can link with David Mantica on LinkedIn and find role-specific AI resources at SoftEd.