Scrum Master Toolbox Podcast: Agile storytelling from the trenches

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.