BONUS Product Delight - How to make your product stand out with emotional connection With Nesrine Changuel

Simina Fodor: Why the 'Why' Matters—Product Owner Communication Lessons 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 Great Product Owner: Transparency and Customer Focus This exemplary Product Owner shaped Simina's entire view of product management and even inspired her to consider a future transition to that role. Despite not having a traditional product background (coming instead from support), this PO demonstrated exceptional openness to both giving and receiving feedback. They consistently explained the logic behind decisions, sharing the "why" that motivated their priorities. What truly set them apart was bringing customer perspectives and use cases directly to the team, helping developers understand the features through the lens of personas and user scenarios. The PO's transparency extended to their own professional journey, openly sharing how they grew into the role, which created an atmosphere of continuous learning and development. The Bad Product Owner: The Ghost Commander This experienced Product Owner approached the role with a command-and-control mindset carried over from previous Project Management experience, believing that backlog grooming was "beneath them." Essentially a ghost to the team, they avoided retrospectives while issuing constantly shifting priorities with little explanation or logic. The PO would issue commands and demand immediate responses without considering consequences, creating a toxic environment that threatened to destroy team morale. Simina recommends coaching such Product Owners on agile mindset principles and seeking leadership support when necessary to prevent team deterioration. Self-reflection Question: How can you effectively bridge the gap between command-and-control Product Owners and teams seeking more transparency and collaboration? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Simina Fodor Simina is a career rebel with a passion for bold moves. From HR to Agile delivery, she's ditched the rulebook to inspire others to build careers that ignite passion. No apologies, no detours—just fearless pivots and real talk about creating work that truly fires you up. You can link with Simina Fodor on LinkedIn.

16 Maj 18min

Simina Fodor: The Courage to Question—Signs of a Healthy Agile Team 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. For Simina, Scrum Master success goes far beyond facilitation skills – it's about what happens when you're not in the room. True success means creating a self-sustaining team that maintains healthy practices even in your absence. Simina looks for indicators like: Do team members feel safe raising concerns regularly? Can they push back with the Product Owner and offer suggestions? Do they proactively ask for the "why" behind requests instead of blindly following directions? She emphasizes that successful teams raise dependencies early in the sprint, have the courage to plan work with other teams, and handle integrations independently. The ultimate test of Scrum Master effectiveness is whether the team continues to thrive even when you step away for a few days. Self-reflection Question: What specific behaviors would indicate that your team has reached a level of self-sustainability that would allow you to step back? Featured Retrospective Format for the Week: Start/Stop/Continue Simina advocates for the simplicity of the Start/Stop/Continue retrospective format. After experimenting with numerous complex approaches, she found that sometimes the most straightforward formats yield the best results. This classic structure cuts through noise and focuses teams on what truly matters: what new practices they should begin, what isn't working and should stop, and what's effective and should continue. Simina appreciates how this format's simplicity makes it accessible and easy to follow, allowing teams to concentrate on meaningful conversation rather than getting lost in complicated retrospective mechanics. [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Simina Fodor Simina is a career rebel with a passion for bold moves. From HR to Agile delivery, she's ditched the rulebook to inspire others to build careers that ignite passion. No apologies, no detours—just fearless pivots and real talk about creating work that truly fires you up. You can link with Simina Fodor on LinkedIn.

15 Maj 15min

Simina Fodor: Building Bridges—How Cross-Department Champions Drive Agile Adoption 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. Simina shares her experience leading an enterprise Agile transformation from her position in Project Management. Rather than pushing for immediate, wholesale change, she started small - seeking out interested colleagues, sharing case studies from other companies, and gradually building internal support. This patient approach took years before the organization officially embraced Agile and Scrum, but created a strong foundation of champions across departments. When business needs finally demanded faster releases and better responsiveness to change, Simina had already established a community of practice ready to support the transition. She began with a single pilot team implementing just daily standups, which then expanded into a full Agile program that ultimately facilitated her transition from Project Manager to Scrum Master. Self-reflection Question: How might building informal networks and starting with small changes create a more sustainable foundation for organizational transformation than top-down mandates? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Simina Fodor Simina is a career rebel with a passion for bold moves. From HR to Agile delivery, she's ditched the rulebook to inspire others to build careers that ignite passion. No apologies, no detours—just fearless pivots and real talk about creating work that truly fires you up. You can link with Simina Fodor on LinkedIn.

14 Maj 14min

Simina Fodor: How Leadership Communication Can Destroy Team Morale 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. Simina recounts working with a diverse, remote team on a high-visibility project to retire legacy systems under strict deadlines. The team made sacrifices, working overtime and through vacations to meet the challenging timeline. When Simina recommended team bonuses to recognize their extraordinary efforts, leadership not only rejected the request but publicly announced that overtime was simply "expected" as part of the job. This single communication destroyed the team's trust, leading to disengagement, dropped velocity, missed deadlines, and team members skipping Scrum events. Simina highlights how quickly team dynamics can collapse when leadership dismisses extra effort and fails to acknowledge team contributions. Self-reflection Question: How might you advocate for proper recognition of your team's extraordinary efforts when leadership views such work as simply expected? Featured Book of the Week: The Making of a Manager by Julie Zhuo Simina recommends "The Making of a Manager" by Julie Zhuo, a book she initially dismissed because she wasn't in a management role. However, upon reading it, she discovered numerous parallels between effective management and Scrum Mastery. The book's message that managers don't need to know all the answers resonated deeply with her, reinforcing the importance of understanding humans first before implementing processes. Despite not being an Agile-specific book, Simina found its people-focused approach incredibly valuable for her Scrum Master practice. [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Simina Fodor Simina is a career rebel with a passion for bold moves. From HR to Agile delivery, she's ditched the rulebook to inspire others to build careers that ignite passion. No apologies, no detours—just fearless pivots and real talk about creating work that truly fires you up. You can link with Simina Fodor on LinkedIn.

13 Maj 19min

Simina Fodor: From Corporate to Startup—Navigating the Scrum Implementation Gap 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. In this episode, Simina shares a critical failure story from her transition from corporate settings to a startup environment. Believing she had all the necessary tools and experience, she attempted to scale up Scrum practices too quickly with developers who weren't familiar with the framework. Instead of starting with fundamentals and understanding where team members were in their Agile journey, she made assumptions based on her corporate experience. Simina emphasizes the importance of a proper discovery phase for Scrum Masters when joining new teams, especially in dynamic startup environments where roles are still evolving and significant change is occurring. Self-reflection Question: How might your previous experiences be creating blind spots when you join a new team or organization? [Scrum Master Toolbox Podcast Recommends] 🚀 Global Agile Summit 2025 Join us in Tallinn, Estonia, from May 18th – 20th, 2025, for an event that will inspire, challenge, and equip you with real-world Agile success stories. 🌍 Connect with global Agile leaders. 💡 Learn practical strategies for impact. 🔥 Break free from Agile fatigue and become a Pragmatic Innovator Check Full Program [Scrum Master Toolbox Podcast Recommends] About Simina Fodor Simina is a career rebel with a passion for bold moves. From HR to Agile delivery, she's ditched the rulebook to inspire others to build careers that ignite passion. No apologies, no detours—just fearless pivots and real talk about creating work that truly fires you up. You can link with Simina Fodor on LinkedIn.

12 Maj 16min

CTO Series: Jussi Mononen on the Human Side of Software Development and Technical Leadership In this CTO Series episode, we explore the intersection of technology and people with Jussi Mononen, CTO of CarbonLink. Drawing from his extensive experience as an Agile practitioner and technical leader, Jussi shares valuable insights on effective software development, technical strategy alignment, and the critical human elements that drive successful technology implementations. The Transformative Power of Agile "It's all about people." Jussi's journey as a technology leader was fundamentally shaped when he discovered Agile methodologies. Coming from a background of waterfall-like approaches to software development, the introduction of Agile principles opened up a broader perspective that transformed his view of the profession. What began as technical work creating billing software evolved into a deeper understanding of the collaboration challenges in problem-solving. This shift helped Jussi develop a more humanistic and holistic approach to software development, recognizing that the human dynamics are often more complex than the technical challenges themselves. Every line of code eventually becomes a liability, as software is maintained over decades Software is only truly "done" when you remove the plug and it no longer exists Direct communication with customers is essential for understanding the real problems that need solving Balancing Technical Strategy with Business Needs "Be careful what you choose in terms of technology as you need to maintain it forever—hopefully." Creating a technical strategy that aligns with business objectives while remaining adaptable requires careful consideration of both immediate and long-term factors. Jussi emphasizes the importance of considering maintainability over a decade-long horizon while organizing technology stacks that don't limit organizational agility. When selecting technologies, consider whether you can find people already familiar with your tech stack Evaluate whether your technology choices allow you to fulfill the responsibilities your customers pay you to handle Be prepared to abandon technologies that aren't working, despite the sunk cost Structure your technical organization to maximize speed and adaptability Fostering Collaboration Between Tech and Business "It's not about 'who wins,' it's about making good decisions." Effective collaboration between technical and business units is built on foundations of respect and trust. As a self-described optimist about humanity, Jussi approaches cross-functional work by giving respect to colleagues and trusting them to make sound decisions within their domains of expertise. Listen carefully to people and make a genuine effort to understand their perspectives Focus on making well-considered decisions rather than striving for theoretical "best" decisions Remember that people develop software, not processes or tools—maximize each team member's potential Create environments where differing viewpoints are valued as inputs to better decision-making Strategic Roadmapping and Adaptability "We constantly seek information about what might be changing." Maintaining a clear vision of the future while remaining adaptable is a critical balancing act for technology leaders. Jussi's approach involves maintaining a rolling two-quarter roadmap that provides directional clarity while incorporating new information and signals from various sources. Review and revise roadmaps weekly to incorporate new information Use tools like Trello to maintain lists of priorities and possibilities Actively seek diverse signals about changing requirements and technologies Use the roadmap to communicate investment priorities to stakeholders like the board Overcoming Complex Technical Challenges "Someone needs to give enough love to the items in the backlog." The most significant challenge in Jussi's career came during a 4.5-year project reimplementing critical university systems that had been in use for over 20 years. This complex undertaking highlighted the importance of people skills alongside technical capabilities when managing diverse stakeholders with conflicting needs. Be prepared to handle conflicting needs and requirements from different stakeholders Establish a shared direction before attempting to solve detailed technical challenges Recognize that many critical challenges in large projects are about people, not technology Give proper attention to backlog items to ensure they receive the consideration they deserve Leadership Philosophy and Learning "Choose the context more accurately. Involve yourself with people you look up to." Rather than pointing to a single book that influenced his approach to technical leadership, Jussi emphasizes the importance of context and learning from those around you. His leadership philosophy centers on carefully selecting environments with admirable people and absorbing knowledge through direct experience and observation. Understand the specific context you're operating in before applying generic principles Surround yourself with people whose approach and values you respect Learn continuously from the practical experiences of peers and colleagues About Jussi Mononen Jussi is a problem solver, programmer and business-to-technology translator. People side of software systems development, as he often says: "it's all about people".He has both tech and people street cred, being a long time Agile practitioner, and now the CTO of a promising scale-up in Helsinki: CarbonLink. You can link with Jussi Mononen on LinkedIn.

8 Maj 47min

BONUS: From Waterfall to Flow—Rethinking Mental Models in Software Delivery With Henrik Mårtensson In this BONUS episode, we explore the origins and persistence of waterfall methodology in software development with management consultant Henrik Mårtensson. Based on an article where he details the history of Waterfall, Henrik explains the historical context of waterfall, challenges the mental models that keep it alive in modern organizations, and offers insights into how systems thinking can transform our approach to software delivery. This conversation is essential for anyone looking to understand why outdated methodologies persist and how to move toward more effective approaches to software development. The True Origins of Waterfall "Waterfall came from the SAGE project, the first large software project in history, where they came up with a methodology based on an economic analysis." Henrik takes us on a fascinating historical journey to uncover the true origins of waterfall methodology. Contrary to popular belief, the waterfall approach wasn't invented by Winston Royce but emerged from the SAGE project in the 1950s. Bennington published the original paper outlining this approach, while it was Bell and Tayer who later named it "waterfall" when referencing Royce's work. Henrik explains how gated process models eventually led to the formalized waterfall methodology and points out that an entire generation of methods existed between waterfall and modern Agile approaches that are often overlooked in the conversation. In this segment we refer to: The paper titled "Production of Large Computer Programs" by Herbert D. Benington (direct PDF link) Updated and re-published in 1983 in Annals of the History of Computing ( Volume: 5, Issue: 4, Oct.-Dec. 1983) Winston Royce's paper from 1970 that erroneously is given the source of the waterfall term. Direct PDF Link. Bell and Thayer's paper "Software Requirements: Are They Really A Problem?", that finally "baptized" the waterfall process. Direct PDF link. Mental Models That Keep Us Stuck "Fredrik Taylor's model of work missed the concept of a system, leading us to equate busyness with productivity." The persistence of waterfall thinking stems from outdated mental models about work and productivity. Henrik highlights how Frederick Taylor's scientific management principles continue to influence software development despite missing the crucial concept of systems thinking. This leads organizations to equate busyness with productivity, as illustrated by Henrik's anecdote about 50 projects assigned to just 70 people. We explore how project management practices often enforce waterfall thinking, and why organizations tend to follow what others do rather than questioning established practices. Henrik emphasizes several critical concepts that are often overlooked: Systems thinking Deming's principles Understanding variation and statistics Psychology of work Epistemology (how we know what we know) In this segment, we refer to: Frederik Taylor's book "The Principles of Scientific Management" The video explaining why Project Management leads to Coordination Chaos James C. Scott's book, "Seeing Like a State" Queueing theory Little's Law The Estimation Trap "The system architecture was overcomplicated, and the organizational structure followed it, creating a three-minute door unlock that required major architectural changes." Henrik shares a compelling story about a seemingly simple feature—unlocking a door—that was estimated to take three minutes but actually required significant architectural changes due to Conway's Law. This illustrates how organizational structures often mirror system architecture, creating unnecessary complexity that impacts delivery timelines. The anecdote serves as a powerful reminder of how estimation in software development is frequently disconnected from reality when we don't account for systemic constraints and architectural dependencies. In this segment, we refer to Conway's Law, the observation that explicitly called out how system architecture is so often linked to organizational structures. Moving Beyond Waterfall "Understanding queueing theory and Little's Law gives us the tools to rethink flow in software delivery." To move beyond waterfall thinking, Henrik recommends several resources and concepts that can help transform our approach to software development. By understanding queueing theory and Little's Law, teams can better manage workflow and improve delivery predictability. Henrik's article on coordination chaos highlights the importance of addressing organizational complexity, while James C. Scott's book "Seeing Like a State" provides insights into how central planning often fails in complex environments. About Henrik Mårtensson Henrik Mårtensson is a management consultant specializing in strategy, organizational development, and process improvement. He blends Theory of Constraints, Lean, Agile, and Six Sigma to solve complex challenges. A published author and licensed ScrumMaster, Henrik brings sharp systems thinking—and a love of storytelling—to help teams grow and thrive. You can link with Henrik Mårtensson on LinkedIn and connect with Henrik Mårtensson on Twitter.

7 Maj 49min

BONUS: Software Engineers are Paid to Solve Problems, Not Write Code! With John Crickett In this BONUS episode, we explore a thought-provoking LinkedIn post by John Crickett that challenges a fundamental misconception in software engineering. John shares insights on why engineers should focus on problem-solving rather than just coding, how to develop business context understanding, and why this shift in perspective is crucial in the age of AI. Beyond Writing Code: Understanding the True Value of Software Engineering "A lot of us come to software engineering because we care about building, and missed the goal: solving a problem for a customer." John Crickett explains the fundamental disconnect many software engineers experience in their careers. While many enter the field with a passion for building and coding, they often lose sight of the ultimate purpose: solving real problems for customers. This misalignment can lead to creating technically impressive solutions that fail to address actual business needs. John emphasizes that the most valuable engineers are those who can bridge the gap between technical implementation and business value. In this section, we refer to John's Coding Challenges and Developing Skills websites. The Isolation Problem in Engineering Teams "We have insulated people from seeing and interacting with customers, perhaps because we were afraid they would create a problem with customers." One of the key issues John identifies is how engineering teams are often deliberately separated from customers and end-users. This isolation, while sometimes implemented with good intentions, prevents engineers from gaining crucial context about the problems they're trying to solve. John shares his early career experience of participating in the sales process for software projects, which gave him valuable insights into customer needs. He highlights the Extreme Programming (XP) approach, which advocates for having the customer "in the room" to provide direct and immediate feedback, creating a tighter feedback loop between problem identification and solution implementation. In this segment, we refer to the book XP Explained by Kent Beck. The AI Replacement Risk "If all you are doing is taking a ticket that is fully spec'ed out, and coding it, then an LLM could also do that. The value is in understanding the problem." In a world where Large Language Models (LLMs) are increasingly capable of generating code, John warns that engineers who define themselves solely as coders face a significant risk of obsolescence. The true differentiation and value come from understanding the business domain and problem space—abilities that current AI tools haven't mastered. John advises engineers to develop domain knowledge specific to their business or customers, as this expertise allows them to contribute uniquely valuable insights beyond mere code implementation. Cultivating Business Context Understanding "Be curious about what the goal is behind the code you need to write. When people tell you to build, you need to be curious about why you are being asked to build that particular solution." John offers practical advice for engineers looking to develop better business context understanding. The key is cultivating genuine curiosity about the "why" behind coding tasks and features. By questioning requirements and understanding the business goals driving technical decisions, engineers can transform their role from merely delivering code to providing valuable services and solutions. This approach allows engineers to contribute more meaningfully and become partners in business success rather than just implementers. Building the Right Engineering Culture "Code is always a liability, sometimes it's an asset. The process starts with hiring the CTO—the people at the top. You get the team that reflects your values." Creating an engineering culture that values problem-solving over code production starts at the leadership level. John emphasizes that the values demonstrated by technical leadership will cascade throughout the organization. He notes the counter-intuitive truth that code itself is inherently a liability (requiring maintenance, updates, and potential refactoring), only becoming an asset when it effectively solves business problems. Building a team that understands this distinction begins with leadership that demonstrates curiosity about the business domain and encourages engineers to do the same. The Power of Asking Questions "Be curious, ask more questions." For engineers looking to make the shift from coder to problem-solver, John recommends developing the skill of asking good questions. He points to Harvard Business Review's article on "The Surprising Power of Questions" as a valuable resource. The ability to ask insightful questions about business needs, user requirements, and problem definitions allows engineers to uncover the true challenges beneath surface-level requirements. This curiosity-driven approach not only leads to better solutions but also positions engineers as valuable contributors to business strategy. In this segment, we refer to the article in HBR titled The Surprising Power of Questions. About John Crickett John is a passionate software engineer and leader on a mission to empower one million engineers and managers. With extensive expertise in distributed systems, full-stack development, and evolving tech stacks from C++ to Rust, John creates innovative coding challenges, insightful articles, and newsletters to help teams level up their skills. You can link with John Crickett on LinkedIn.

6 Maj 41min