Wasim Osman: When a Scrum Team’s Silence Becomes a Self-Fulfilling Prophecy

“No team is interested in deliberately destroying their outcome or their team. Nobody does that on purpose.” – Wasim Osman

Wasim’s team was building a SaaS product with real potential. They followed Scrum, shipped features fast—and quietly let the bugs pile up. When customers finally pushed back (“you built five features, four of them have bugs”), the team made a confident bet: one quarter for new features, then one month to fix everything. It didn’t work.

The bug-bashing month revealed deeper, structural problems that demanded refactoring, and the roadmap was already packed. Then the fixes got handed to a single team, who felt demoted from the “prestigious” work of building features. Resentment grew between the teams.

At the height of that tension, the company was acquired by a waterfall-driven parent company. The head of engineering left, the chief architect and two senior engineers followed, and it became chaos. Wasim’s hardest lesson wasn’t about the acquisition—it was about voice.

The engineers assumed waterfall was being forced on them and stopped pushing back; leadership assumed the engineers were fine with it. Nobody said what they actually thought, and the fear became reality. As Wasim puts it, there was “no captain on the ship.”

In this segment, we talk about how even conversations need to be iterative, and how a Scrum Master has to balance speaking up (so the team isn’t rudderless) without speaking so much that the team stops voicing their own opinions.

Self-reflection Question: Where on your team is an unspoken assumption quietly hardening into reality, and what would it take for you to name it out loud first?

Featured Book of the Week: Difficult Conversations by Douglas Stone, Bruce Patton, and Sheila Heen

Wasim’s most-recommended book is Difficult Conversations: How to Discuss What Matters Most. What stuck with him is a deceptively simple model: every hard conversation is really made of three conversations—the “what happened” conversation (the content), the feelings conversation, and the identity conversation (what the situation says about whether you’re competent, good, or lovable). “When I first read it, I thought there can’t be only three types of conversations,” Wasim admits.

“But once you’ve gone through the book, you can put any conversation into one of those funnels.” He found it especially powerful in retrospectives: when the same issue keeps resurfacing, the real conversation is often about feelings, not action items—someone was never okay with an earlier decision, and that’s why the follow-ups never happened.

Self-reflection Question: In your last tense retrospective, which of the three conversations—content, feelings, or identity—was really driving the room?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!

About Wasim Osman

Wasim Osman is a seasoned Agile Coach and a Product Owner at Orkestra SCS. He launched his agile career at a Silicon Valley startup based in New York, then spent years coaching teams across Canada, helping organizations transform how they deliver value. Wasim brings a rare blend of agile discipline and product thinking. He’s passionate about building technology that drives real business impact.

You can link with Wasim Osman on LinkedIn.

AI Assisted Coding: AI as an Amplifier—Why Engineering Practices Matter More Than Ever

AI Assisted Coding: How Spending 4x More on Code Quality Doubled Development Speed

What happens when you combine nearly 30 years of engineering experience with AI-assisted coding? In this episode, Eduardo Ferro shares his experiments showing that AI doesn’t replace good practices—it amplifies them. The result: doubled productivity while spending four times more on code quality.

Vibe Coding vs Production-Grade AI Development

“Vibe coding is flow-driven, curiosity-based way of building software with AI. It’s less about meticulously reviewing each line of code, and more about letting the AI steer the process—perfect for quick experiments, side projects, MVPs, and prototypes.”

Edu draws a clear distinction between vibe coding and production AI development. Vibe coding is exploration-focused, where you let AI drive while you learn and discover. Production AI coding is goal-focused, with careful planning, spec definition, and identification of edge cases before implementation. Both use small, safe steps and continuous conversation with the AI, but production code demands architectural thinking, security analysis, and sustainability practices. The key insight is that even vibe coding benefits from engineering discipline—as experiments grow, you need sustainable practices to maintain flexibility.

How AI Doubled My Productivity

“I was investing four times more in refactoring, cleanup, deleting code, introducing new tests, improving testability, and security analysis than in generating new features. And at the same time, globally, I think I more or less doubled my pace of work.” Continue reading AI Assisted Coding: AI as an Amplifier—Why Engineering Practices Matter More Than Ever

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

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

Vibecoding vs. AI-Assisted Coding: Reading Code Matters

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

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

The Moment of Shift: Staying in the Zone

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

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

Thinking in Commits: The Right Size for AI Work

“I think of prompts commit-by-commit. That’s the size of the work I’m trying to do in a prompt.” Continue reading AI Assisted Coding: Swimming in AI – Managing Tech Debt in the Age of AI-Assisted Coding

BONUS: Consulting is Different—How Consulting Contracts Work Against Agile Development, With Jakob Wolman and Wilko Nienhaus

In this BONUS episode, we explore the critical differences between building software as a consultant versus inside a product company. Jakob Wolman contributed an insightful article to the Global Agile Summit book examining how third-party software development operates under entirely different constraints than in-house product development. Joined by Wilko Nienhaus, CTO of Vaimo, a global consulting company, we dive into ownership dynamics, misaligned incentives, contracting challenges, and the business pressures that shape consulting—along with practical stories from the field about what really works.

The Cobbler’s Shoes Problem

“I come back to the office from this workshop, and suddenly, with these eyes on looking for improvements in process, I just suddenly am hit by this revelation of why things are so slow here? Why are we working so inefficiently?”

Jakob describes the striking paradox many consultancies face: they excel at helping clients improve their processes while their own internal operations remain inefficient. This “shoemaker’s children” phenomenon reflects a fundamental challenge in consulting—the difficulty of investing in your own improvements when all energy flows toward billable client work. Digital agencies often have outdated or poorly implemented websites despite building sophisticated solutions for others, illustrating how consultancies struggle to apply their own expertise internally.

Misaligned Incentives Create Antagonistic Dynamics

“It’s almost as if the clients are actually paying us to be slow, because our incentive is to spend more time on achieving what the client wants, because we get paid by the hour.”

The incentive structures in consulting create inherent conflicts that don’t exist in product companies. Consultants typically bill by the hour, creating a perverse incentive to spend more time rather than deliver efficiently. Meanwhile, clients pursue business outcomes and want results as quickly and cheaply as possible. This fundamental misalignment leads to:

- Clients adopting a procurement mindset, treating software development like ordering from a catalog
- A “wall” between stakeholders and development teams that’s even stronger than in product companies
- Antagonistic relationships where scope changes feel like financial traps rather than necessary learning
- Contracting processes that reinforce waterfall thinking even when both parties claim to want agility

Wilko emphasizes that contracting has a huge impact on these dynamics, and companies must deliberately change their engagement models to break free from these patterns.

The Budgeting Trap and Specification Overload

“Because of this budgeting process where you now need to motivate what this budget does, or you need to spend that budget, you essentially create this necessity to define everything.” Continue reading BONUS: Consulting is Different—How Consulting Contracts Work Against Agile Development, With Jakob Wolman and Wilko Nienhaus

BONUS: Zach Goldberg shares how to build high-performing engineering teams and master the startup CTO role

In this BONUS episode, we dive deep into the world of startup leadership with Zach Goldberg, author of The Startup CTO’s Handbook. We explore the critical transition from engineering to leadership, the art of balancing technical debt with startup urgency, and the communication skills that separate great CTOs from the rest.

The Genesis of The Startup CTO’s Handbook

“My original training in software engineering was not enough for being a leader. All the people and leadership skills, I had to learn on my own.”

Zach’s journey to writing The Startup CTO’s Handbook began with a stark realization about the gap between technical training and leadership reality. Despite his classical software engineering background, he discovered that the people and leadership skills required for CTO success had to be self-taught. The book emerged from a growing Google Doc of topics and frameworks addressing the leadership and management challenges that CTOs consistently face – from hiring and performance management to making strategic decisions under pressure. Today, we can either buy the digital/print book on Amazon, or read the book on GitHub.

In this segment, we also refer to the book The Great CEO Within.

Learning to Truly Learn: The Max Mintz Story

“Max only cared about my ability to learn – to get curious about something hard. He wanted to help me deal with complexity.”

Zach opens his book with a deeply personal story about his mentor, Max Mintz, who fundamentally changed his approach to learning during what he calls “the most impactful single coffee” of his life. Over 1.5 years of conversations, Max taught him that true learning isn’t about accumulating facts, but about developing curiosity for hard problems and building the capacity to handle complexity. This lesson forms the foundation of effective CTO leadership – the ability to continuously learn and adapt in an ever-changing technical landscape.

The Three Critical CTO Mistakes

“As a CTO, the most important 3 things: people, people, people. Do the people have the right energy, the right passion? Assemble the right team.” Continue reading BONUS: Zach Goldberg shares how to build high-performing engineering teams and master the startup CTO role