Agile

We were in the middle of a critical API design decision, and the VP of Engineering had just received an urgent message. His team was scattered across three continents — Singapore's developers were heading home, London was deep in their workday, and San Francisco was still hours from logging on. "There's no way we can get everyone in a room anymore," he told us during our coffee chat last week. "But honestly? That turned out to be a good thing." He's right. The days of quick hallway consultations and crowded whiteboard sessions feel like ancient history now. Instead, we've discovered something unexpected: our technical discussions have actually grown richer (Chen, Johnson, and Sawyer, 2020). Engineers who might have been hesitant to speak up in rapid-fire meetings now craft thoughtful proposals that their colleagues around the world can consider and build upon. Take last month's authentication service redesign. It started with a detailed proposal from our Singapore team, got refined during London's working hours, and by the time San Francisco began their day, they had a wealth of perspectives to work with (Jiang and Gutierrez, 2020). The Real Challenge of Remote Teams The conventional wisdom suggests that remote work primarily challenges team bonding and culture. After sitting down with dozens of engineering leaders over the past year, a pattern emerged that went deeper than the usual remote work challenges (Davis, 2020). At the heart of their concerns lay a delicate balance: how to give technical decisions the space they deserve while keeping innovation flowing. This tension came to life in my conversation with one of the engineering leaders. Their team had taken a bold step, requiring every technical decision to be documented in writing — from major architectural shifts down to API design choices (Lee and Wong, 2021). "We knew it would slow things down initially," she explained, "but we believed the trade-off would be worth it." While this approach created a valuable knowledge base, it also meant that even minor architecture decisions could take days as comments and suggestions trickled across time zones. Yet surprisingly, when they looked back after six months, they found they were shipping features faster than ever before (Garcia and Ibrahim, 2023). Why Async Works (When It Works) The success of teams like Sarah's isn't accidental. It stems from fundamental changes in how they approach technical leadership. Written decisions become team assets. When a senior engineer in Germany documents their reasoning for a particular API design, that knowledge doesn't just inform the current decision — it becomes a reference point for future choices, enabling teams to build on past insights rather than relitigating old decisions (Evans and Ko, 2020). Time zones become an advantage. One team we spoke with turned their global distribution into a superpower: Engineers in India would document technical challenges at the end of their day, allowing their American colleagues to review and respond during their workday, effectively creating a 24-hour development cycle (Nandi and Rekha, 2023). Making It Work As we thought deeper about remote leadership, we quickly realized something crucial: the real challenge wasn't about finding the right tools or creating better templates. It was about rethinking how we make technical decisions (Kang and Mitchell, 2022). I remember the day we transformed our architecture review process. The old routine of herding everyone into a conference room (or, these days, a Zoom/Gmeet call) for hours of technical discussion just wasn't cutting it anymore. Some of our best engineers were struggling to contribute meaningfully in these time-boxed sessions, especially those joining from different time zones. This change in the mode of communication has been revolutionary. We also noticed that there were problems resulting from the traditional meeting structure not being time-flexible. Conversations on technology had become more complex than anticipated. Some engineers were not comfortable speaking their minds in meetings, yet they contributed the most thoughtful ideas when given more time and space (Zhang and Porter, 2019). Meetings, which used to be brief, became forums for deeper discussion. We didn't just change how we work — we transformed how our team thinks about building software together. The feedback I get now is usually very analytical; it comes with possible solutions that I may not have even thought of and the author's own ideas for solving the problem. Our shift to asynchronous work also transformed our approach to quality assurance. Rather than rushing through QA in real-time sessions, we developed systematic review processes that caught subtle issues early (Martinez, 2021). This proved especially valuable for our complex, certified projects where small oversights could snowball into significant problems. Our initial success with asynchronous communication led us to an important realization. In our enthusiasm, we attempted to make all our technical discussions asynchronous. This decision revealed a critical limitation during a complex debugging session. What typically required just thirty minutes of direct collaboration extended into several days of written exchanges (Naik and Roberts, 2021). This experience provided valuable insight into the optimal balance of communication methods. While asynchronous collaboration presents numerous benefits, some issues are better solved synchronously. It's about recognizing which types of decisions benefit from slow, thoughtful consideration and which need the energy of real-time collaboration (O'Leary and Mortensen, 2019). Finding this balance is key to keeping both our technical rigor and our innovative spirit alive. Building Tomorrow's Engineering Culture The future of engineering leadership isn't about choosing between async and sync communication — it's about knowing when to use each effectively. The most successful teams we've observed maintain clear guidelines about which decisions require real-time discussion and which are better suited for async consideration (Rosenbaum and Liu, 2022). They also recognize that async communication can actually improve team dynamics. More introverted team members often provide more detailed and thoughtful input when they can compose their thoughts in writing rather than competing for airtime in a meeting (Larson and DeChurch, 2020). Junior engineers feel more confident contributing when they can take time to research and refine their ideas before sharing. Cultural Evolution What started as a forced experiment in remote work has sparked a fundamental shift in engineering culture. At Stripe, the infrastructure team discovered that their most innovative solutions often came from their quietest team members — engineers who rarely spoke up in traditional meetings but thrived in written discussions (Stripe Engineering Blog, 2022). "We were missing these voices all along," notes Sarah Chen, their Engineering Director. "Now they're driving some of our most important architectural decisions." This pattern repeats across the industry. When Mozilla revamped its code review process last year, they found that detailed written feedback led to deeper technical discussions than their previous in-person reviews (Mozilla Engineering Report, 2022). Engineers spent more time considering architectural implications instead of getting caught up in surface-level details. The result? More thoughtful solutions and better knowledge transfer between teams. The tools enabling this transformation matter less than how teams use them. While every organization has its preferred stack — from Notion for documentation to Linear for project tracking — the real innovation lies in how teams adapt these tools to their unique needs. Datadog's platform team, for instance, created a hybrid approach where engineers document initial proposals asynchronously but jump into real-time discussions when complex trade-offs need exploration (Datadog Engineering Blog, 2023). The most successful organizations have learned to blend synchronous and asynchronous work naturally. They've developed an instinct for when a quick video call can unblock a technical decision and when a written discussion will lead to better outcomes. At Plaid, for example, if a technical decision will impact more than one team, it requires written documentation and asynchronous review (Plaid Engineering Case Study, 2023). Conclusion The challenges of remote engineering leadership aren't going away. If anything, teams will become more distributed, making effective async decision-making even more crucial. But here's what's exciting: we're just beginning to understand how to do this well. The next frontier isn't just about making remote work function — it's about making it excel. It's about building engineering cultures that leverage the best of both async and sync communication to drive innovation forward. For leaders like Sarah, the morning standup dilemma might never completely disappear. But by embracing new ways of making decisions and fostering innovation, we can build engineering teams that aren't just surviving in a remote world — they're thriving in it. References Chen, R., T. Johnson, and A. Sawyer. "Distributed Team Structures in Modern Software Development." ACM Digital Library, 2020.Jiang, Y., and M. Gutierrez. "The 24-Hour Development Cycle: Leveraging Time Zones for Continuous Delivery." ACM Queue, 2020.Davis, L. "Synchronous vs. Asynchronous Work: Finding the Right Balance." Harvard Business Review, 2020.Lee, S., and T. Wong. "Documentation-Driven Development: A Systematic Review." Empirical Software Engineering Journal, 2021.Garcia, L., and S. Ibrahim. "Adapting Collaboration Tools for Distributed Teams." Journal of Software Innovation, 2023.Evans, M., and A. Ko. "Decision-Making Rhythms in Distributed Engineering Teams." IEEE Software, 2020.Nandi, P., and V. Rekha. Beyond Boundaries: Distributed Workforces and the Future of Engineering Teams. Springer, 2023.Kang, H., and B. Mitchell. "Rethinking Technical Decisions in Global Teams." MIT Sloan Management Review, 2022.Zhang, Y., and R. Porter. "The Introvert's Advantage in Asynchronous Collaboration." Academy of Management Proceedings, 2019.Martinez, R. "Empowering Junior Engineers through Asynchronous Collaboration." IEEE Engineering Management Review, 2021.Naik, S., and D. Roberts. "The Pitfalls of Eliminating Synchronous Communication in Healthcare Tech." Journal of Health Informatics, 2021.O'Leary, M. B., and M. Mortensen. "Go (Con)figure: Subgroups, Imbalance, and Isolates in Geographically Dispersed Teams." Organization Science 21, no. 1 (2019): 115–131.Rosenbaum, M., and J. Liu. "Decision Guidelines for Remote Teams." Journal of Management Information Systems, 2022.Larson, L., and L. DeChurch. "Leading Teams in the Digital Age: Four Perspectives on Technology and What They Mean for Leading Teams." The Leadership Quarterly 31, no. 1 (2020): 101377.Stripe Engineering Blog. "Surfacing the Quiet Voices: How Asynchronous Discussions Enabled Hidden Innovators." Stripe, 2022. https://stripe.com/blog/engineering.Mozilla Engineering Report. Transforming Code Reviews: A Shift to Asynchronous Feedback. Mozilla Technical Reports, 2022.Datadog Engineering Blog. "Building Hybrid Communication Models at Scale." Datadog, 2023. https://www.datadoghq.com/.Plaid Engineering Case Study. Scaling Decision-Making in Distributed Teams. Unpublished internal document, 2023.

TL; DR: Bridging Agile and AI With Proper Prompt Engineering Agile teams have always sought ways to work smarter without compromising their principles. Many have begun experimenting with new technologies, frameworks, or practices to enhance their way of working. Still, they often struggle to get relevant, actionable results that address their specific challenges. Regarding generative AI, there is a better way for agile practitioners than reinventing the wheel team by team — the Agile Prompt Engineering Framework. Learn why it solves the challenge: a structured approach to prompting AI models designed specifically for agile practitioners who want to leverage this technology as a powerful ally in their journey. Why The Agile Prompt Engineering Framework Is Different Most existing approaches to technology-assisted work lack the context-awareness and the human-centered focus that Agile requires. This prompting framework, however, changes that by applying core agile principles — iterative improvement, collaboration, and continuous adaptation — to these interactions. The result is not just high-quality, actionable prompts that help to solve everyday challenges all agile practitioners face. It is also a structured approach to broaden your mindset by learning to interact with new, defining technology for years to come. A Practical, Tiered Framework You Can Start Using Today What makes this prompting framework for agile practitioners immediately worthwhile is the tiered structure that allows you to implement it progressively: Must-Have Elements (Core) These five essential components will immediately improve your results: Clarify the Agile context. Provide specific details about team composition, sprints, or known bottlenecksDefine the core task or goal. State clearly what you want to accomplishAssign roles and perspectives. Specify which Agile role to adoptSpecify output format and style. Define how you want information structured and presentedIncorporate real or sample data. Include actual metrics or examples from your team without violating governance rules Even implementing just these core elements can dramatically improve the quality and relevance of your results. Should-Have Elements (Enhanced) Once comfortable with the core elements, these additions significantly improve output quality: Impose constraints or special requirements. State limitations like time or resource constraints,Ask for iterations or variations. Request multiple approaches to evaluate trade-offs,Build a feedback loop. Treat interaction as a conversation, not a one-time request,Prohibited words or phrases. Ban generic language for more authentic results. Could-Have Elements (Advanced) For optimal results in complex scenarios, integrate these sophisticated techniques: Verify and address inaccuracies. Include fact-checking mechanisms,Privacy and ethics guidelines. Establish boundaries for sensitive information,Baked-in collaboration flow. Structure prompts to include pauses for human judgment. How It Works in Practice Imagine you’re a Scrum Master or Agile Coach facing tension between remote and in-office team members. Using this framework, you may structure your initial prompting approach like this: Plain Text <role> You are an experienced Scrum Master or Agile Coach specializing in hybrid team dynamics, psychological safety, and conflict resolution. </role> <context> - I facilitate a Scrum team with six developers, one PO, and one SM (me). • Three team members work remotely full-time, while four are in the office. - We've been using this hybrid model for two months. - Our last two Retrospectives revealed tension between in-office and remote members. - Remote members feel left out of informal discussions, while in-office members feel remote colleagues aren't as engaged. - Our Sprint performance is still stable, but team satisfaction scores are dropping. </context> <task> Design a 60-minute Retrospective format to address the remote/in-office divide and strengthen team cohesion regardless of location. </task> <constraints> - Both remote and in-office participants must be engaged equally. - Should address underlying tensions without creating blame. - Time limit: 60 minutes total. - Available tools are Miro, Zoom, and Slack. - One remote team member has an unreliable internet connection. </constraints> <outputFormat> Provide: 1. A detailed timeline with specific activities and timeboxes. 2. Required preparation steps. 3. Facilitation notes for each activity. 4. Guidance on managing potentially difficult moments. 5. Techniques to ensure balanced participation. </outputFormat> This structured approach yields a detailed, contextually relevant Retrospective design tailored to your situation, which you can start iterating on until you find a helpful Retrospective format. How to Make the Agile Prompt Engineering Framework Work for You The most straightforward way to start using the Agile Prompt Engineering Framework is iteratively and incrementally — no pun intended: Progressive Improvement Through Measurement The framework also includes practical metrics to help you evaluate and improve your results: Relevance score (1-5): How well did the output address your specific context?Actionability (1-5): Could you implement the suggestions without significant additional work?Time savings: How much time did you save compared to traditional approaches? By tracking these metrics, you can continuously improve your effectiveness. Start Simple, Grow Your Skills You don’t need to implement everything at once: Start today. Use just the must-have elements for your next Retrospective approach.Next week. Add constraints and output format specifications for more refined results.As you gain comfort. Explore the more advanced techniques outlined in the complete framework. The Full Framework Is Yours The complete Agile Prompt Engineering Framework includes: All 12 framework elements across three tiersComplete examples for multiple Agile scenariosA practical worksheet to build prompts yourselfTroubleshooting guide for common prompting challengesModel-specific considerations for different tools I created this framework in collaboration with Holger Dierssen. It represents a thoughtful approach to integrating new technologies into practices while preserving the human-centered values at the heart of Agile.

By Stefan Wolpers CORE

A few years ago, at my previous company, I found myself on a familiar quest: hunting down a specific Jira issue. What I discovered was both amusing and alarming — three versions of the same problem statement, each with different solutions spaced four to six months apart. Every solution was valid in its context, but the older ones had become obsolete. This scenario is all too common in the software development world. New ideas constantly emerge, priorities shift, and tasks often get put on hold. As a result, the same issues resurface repeatedly, leading to a chaotic backlog with multiple solutions for identical problems. This clutter makes it challenging to grasp our true roadmap and impedes our ability to achieve objectives. Digging deeper, we found hundreds of issues languishing in our backlog. In a rather humorous yet sobering realization, our back-of-the-envelope calculations suggested it would take over eight years to address all those features. From this experience, we concluded that any issue left unresolved for over six months should be deemed outdated and permanently deleted. If a problem remains unsolved for that long, it likely needs to be revisited and addressed from scratch. Based on these lessons, I'd like to share some best practices to help you manage your development process more effectively. Issues in Backlog: No Longer Than 4 Months Trello recommends regular backlog grooming to keep issues relevant and actionable. Why It's Important Issues that linger in the backlog for more than four months often lose context and priority. Regularly grooming the backlog ensures that the team focuses on the most valuable tasks and avoids unnecessary clutter. You can read more about how Jira recommends backlog grooming here. When the team is aware of the age of a Jira issue, it encourages them to be more mindful of prioritization and to spend their time more effectively. Regular reviews and a four-month limit on backlog items help maintain a clear, actionable roadmap and ensure that outdated tasks are addressed promptly. Techniques such as weighted scoring or the MoSCoW method (Must have, Should have, Could have, Won't have) can be useful in prioritizing tasks effectively. Backlog ages like milk, not like wine. Branches: No Longer Than a Month GitHub recommends regularly merging branches to avoid merge conflicts. Engineering leader: "Jamie, what’s the status of this client request?" Developer: "It’s all done, currently in QA. It should go out in a day or so." A week later: Engineering leader: "Jamie, did we push this feature to the client?" Developer: "Sorry, it’s waiting for another feature due to some merge conflicts." If you’ve ever experienced this, you know how frustrating it can be. Regularly merging branches can prevent these delays by ensuring that code conflicts are addressed early, maintaining code quality, and keeping the development process smooth. Keeping branches open for more than a month can lead to significant merge conflicts and integration issues. Regularly merging branches helps maintain code quality, reduces technical debt, and ensures that the team is working on the latest version of the code. Best Practices for Managing Branches 1. Frequent Integration Integrate changes at least once a week, if not more frequently, to ensure your branch doesn't diverge significantly from the main codebase and avoid merge conflicts. 2. Small, Incremental Changes Make small, incremental changes rather than large, sweeping updates. This makes it easier to integrate and review code, reduces the risk of conflicts, and speeds up and improves the review process. Epics: No Longer Than a Quarter Atlassian recommends breaking down epics that can be completed within a quarter. The higher up in the hierarchy, engineering leaders rely heavily on epics to understand where the team's efforts are being invested. Often, I’ve noticed that some epics, like those for technical debt or enhancements, end up containing hundreds of issues. These catch-all epics bloat badly because engineers are forced to associate every issue with an epic. As a result, it becomes difficult to distinguish between efforts spent on roadmap items versus technical debt or KTLO (Keep The Lights On) tasks. This leads to epics dragging on for years, making tracking progress difficult. Long epics can become unwieldy and difficult to manage. Teams can maintain momentum and deliver incremental value by ensuring that epics are completed within a quarter. This practice also facilitates better planning and tracking, ensuring that large projects are broken down into manageable parts that can be tackled effectively. Read more about this in Atlassian's guide. Best Practices for Managing Epics 1. Define Clear Boundaries Ensure each epic has a well-defined scope and objective. Avoid using catch-all epics by creating specific epics for distinct tasks. 2. Regular Review and Pruning Regularly review and break down large epics. Move completed tasks out and create new epics for ongoing work to keep the list manageable. For example, you can have a tech debt epic for every quarter. 3. Prioritize and Categorize Clearly categorize epics based on their purposes, such as roadmap items, technical debt, or KTLO. This helps in tracking where the team's efforts are being invested. 4. Limit Epic Duration Set a time limit for how long an epic can remain open. This ensures that long-term tasks are broken down into achievable milestones, facilitating better progress tracking. By managing epics effectively, engineering leaders can gain better insights into the team's workload, ensure that efforts are aligned with strategic goals, and reduce the risk of bloated, unmanageable epics. Tickets: No Longer Than a Sprint Scrum recommends that user stories should be completable within a sprint, usually 2-4 weeks. One of the challenges in agile development for both developers and managers is dealing with issues that spill over from sprint to sprint. In sprint 1, 20% of the work is done; in sprint 2, 30% is completed, and so on, but some issues always get carried over. The story points for these issues keep changing, setting wrong expectations for product managers and stakeholders. This can be demotivating for developers as it feels like progress is being stalled when, in reality, the ticket is simply too large for a single sprint. Instead, these large tickets should be treated as epics, broken down into multiple issues, and spread across sprints to set the right expectations. Keeping tickets manageable within a sprint ensures that tasks are bite-sized and achievable, leading to more predictable progress and faster delivery cycles. This practice also helps maintain team morale and clear focus. Ideally, each ticket or user story should deliver value to the end user and be independently completed within a given sprint. Implementing these time-based best practices can significantly enhance your software development process, ensuring that projects stay on track and deliver value consistently. By keeping tasks and initiatives timely, you can maintain focus, reduce waste, and drive continuous improvement.

If you weren’t at the virtual Hands-on Agile 2025 conference earlier this month, you missed an incredible opportunity to explore the shift from concept-based to context-based agility with nearly 800 fellow agilists. But don’t worry — I’m here to share some of the key takeaways and insights! Check out the slides from the live-stream speakers below; I will keep you posted on the availability of the recordings. The Slides from Cliff Berg to Jonathan Odo As someone in the agile trenches for years, I've seen my fair share of organizations struggling to apply agile frameworks without considering their unique context. It's a common mistake and one that often leads to frustration, resistance, and even failure. That's why I was so excited to see this year's Hands-on Agile Barcamp focus on the importance of adapting agile principles to each organization's specific needs and challenges. Throughout the three-day event, we had the chance to learn from a fantastic lineup of speakers who shared their experiences, strategies, and hard-won wisdom: Cliff Berg: Leadership Behaviors That Lead to Actual AgilitySandrine Olivencia: Lean Engineering Practices to Scaling Craftsmanship in the Digital WorldFabrice Bernhard: The Lean Tech Manifesto: Scaling an Agile CultureLynn Kelley: Change Questions: The Keys to Implementing Organizational Change That SustainsJohanna Rothman: Fake Agile is the Norm: How to Instill Agility, Not Agile Practices - Hands-on AgilePeter Merel: The Agile WayMaarten Dalmijn: The Five Obstacles to Empowered TeamsDavid Pereira: How to Overcome Common Mistakes with Product DiscoveryRoman Pichler: Common Strategy Mistakes: The Top Reasons Why a Product Strategy FailsJonathan Odo: AI Methodology and Operating Model Evolution Hands-On Agile 2025: The Takeaways So, what did I take away from this event? Three key things: Context is king. There's no one-size-fits-all approach to agility — we need to adapt our practices to each organization's unique needs and goals.Leadership buy-in is essential. Without the support and commitment of leaders at all levels, even the best-laid plans for context-based agility will struggle to take hold.Continuous learning and experimentation are non-negotiable. As we navigate this shift, we need to cultivate a culture of curiosity, openness, and a willingness to try new things. What's been your experience with context-based agility? What challenges have you faced, and how have you overcome them? What questions or concerns do you have as we move forward? Please share your thoughts in the comments below — let's keep this conversation going and learn from each other.

By Stefan Wolpers CORE

TL; DR: The Alignment-to-Value Pipeline Effective product development requires both strategic alignment and healthy Product Backlog management. Misalignment leads to backlog bloat, trust erosion, and building the wrong products. By implementing proper alignment tools, separating discovery from delivery, and maintaining appropriate backlog size (3-6 sprints), teams can build products that truly matter. Success depends on trust, collaboration, risk navigation, and focusing on outcomes over outputs. Learn more about how to embrace the alignment-to-value pipeline and create your product operating model. Introduction: The Alignment-to-Value Pipeline Two critical challenges persist regardless of team experience or organizational maturity: creating meaningful alignment between stakeholders and teams, and maintaining a healthy, actionable Product Backlog. These challenges are fundamentally connected — alignment issues manifest as Product Backlog dysfunctions, you create things that do not solve your customers’ problems, and Product Backlog anti-patterns often signal deeper alignment problems. The following two graphics display the principle idea of the alignment-to-value pipeline: Alignment Tools Product Backlog Management The optimal flow from strategic alignment through product discovery and validation to delivery is not a linear process but a continuous cycle where each element reinforces the others: The first graphic shows how various alignment tools connect to different stages in the product development lifecycle, from strategy to tactics.The second graphic demonstrates how validated hypotheses flow from product discovery into the Product Backlog, while items deemed not valuable flow into an “Anti-Product Backlog.” The Cost of Failing the Alignment-to-Value Pipeline When alignment breaks down, the consequences cascade throughout the development process: Strategic disconnection. Without proper alignment tools, teams lose sight of why they’re building what they’re building, leading to feature factories prioritizing output over outcomes.Backlog bloat. Misalignment leads to Product Backlogs that become “storage for ideas” rather than actionable plans, creating a “collection of work items” — an expensive investment with quickly diminishing returns.Trust erosion. When stakeholders and teams operate from different understandings of goals, product value, and priorities, trust erodes and is replaced by micromanagement and control mechanisms.Validation bypass. Without alignment on what constitutes value, teams often skip proper validation, leading to mere busyness; “garbage in, garbage out” is real in product development. Insights into Bridging Alignment and Product Backlog 1. Separation of Discovery and Delivery There is a critical need to separate discovery from delivery while practicing them simultaneously. This separation is not about different teams but about different artifacts and processes. Product discovery artifacts (like Opportunity Canvas or Opportunity Solution Tree) help validate what’s worth building, while the Product Backlog contains only validated items ready for refinement and implementation. 2. The Right Size for the Right Action Excessive preparation is instead a hindrance rather than a benefit: Maintain just enough alignment and just enough Product Backlog to enable effective action without creating waste. The sweet spot appears to be 3-6 sprints of refined work aligned with clear strategic goals. 3. Empowerment Through Structure A seemingly paradoxical insight emerges: the right structures and tools enable greater empowerment and autonomy. Alignment tools provide frameworks that empower teams to make autonomous decisions aligned with organizational goals.Clear Product Backlog practices (like proper refinement and INVEST principles) empower Developers to challenge the Product Owner constructively. Jocko Willink refers to it as “discipline equals freedom,” or the dichotomy of leadership. 4. Balancing Technical and Business Concerns There is no way to avoid acknowledging the tension between business features and technical quality: While the business may push for delivering more features, the engineers are — at the same time — responsible for preserving the quality of the technology stack to ensure long-term technical viability and avoid technical debt running havoc. The alignment tools, particularly the Product Goal Canvas and Opportunity Solution Tree, provide frameworks to incorporate both business outcomes and technical quality into planning and prioritization. Practical Recommendations: Creating the Alignment-Backlog Connection Let us delve into a short list of conversation starters to create the vital alignment-backlog connection: 1. For Organizations Implement Dual-Track Agile Formalize the separation between discovery and delivery tracks while ensuring they inform each other continuously. Ideally, product teams do both in parallel. Adopt Strategic Alignment Tools Choose appropriate tools based on your context: For startups or new initiatives: Lean Canvas and Now-Next-Later Roadmap.For established products: Product Strategy Canvas and GO Product Roadmap.For all contexts: Regular alignment sessions using the selected tools; inspect and adapt apply as first principles here, too. Create Transparent Artifacts Ensure product roadmaps, strategic goals, and Product Backlogs are visible to everyone, helping everyone to understand “what they fight for.” Normalize Continuous Refinement Establish regular refinement as an organizational habit, not just a team activity. 2. For Product Owners Maintain an Anti-Product Backlog Explicitly track ideas considered but not pursued to avoid the “storage for ideas” Product Backlog anti-pattern. Limit Work in Progress Keep your Product Backlog small enough to be manageable (3-6 sprints worth) but comprehensive enough to guide development by providing the bigger picture. Balance Validation Methods Use proper tools for validation rather than prematurely adding items to the Product Backlog: Opportunity Canvas for understanding the problem space.Lean experiments for testing hypotheses.Usability testing for validating concepts. Employ Visual Management Visual tools like user story mapping create shared understanding across stakeholders and teams. 3. For Developers Demand Technical Excellence Allocate approximately 20% of capacity to preserve long-term technical quality by regularly tackling technical debt and quality improvements. Embrace Slack Time Request 20% of unplanned capacity to enable adaptation to operational challenges and innovation. Challenge Value Propositions Question why items are in the Product Backlog and if they best use the team’s time from a value creation perspective. Participate in Discovery Take active roles in the product discovery process rather than waiting for requirements. 4. For Scrum Teams as a Whole Regular Alignment Check-Ins Schedule dedicated sessions to revisit and update alignment tools, ensuring they reflect current understanding. Whole-Team Refinement Involve the entire Scrum team in refinement activities, avoiding the “involving the Scrum team — why?” anti-pattern. Balanced Refinement Time Invest appropriate time in refinement — neither too little (resulting in poor quality) nor too much (leading to analysis paralysis). Link Everything to Outcomes Connect all work items to specific, measurable outcomes using tools like the Opportunity Solution Tree. Reflection Questions on the Alignment-to-Value Pipeline Before starting a discussion in your organization about the alignment-to-value pipeline, ask yourself: Where is the line between product discovery and delivery in your organization? Are they separate processes with different artifacts, or are they blurred together?Which of the alignment tools mentioned would most benefit your current context, and why?What are the top three Product Backlog anti-patterns you observe in your organization, and how might better alignment tools address them?How might you implement the concept of an “Anti-Product Backlog” to track ideas considered but not pursued?Is your team allocating adequate time for technical excellence and slack time? If not, what could help make the case for this investment? Remember, achieving alignment is not about creating perfect documents or following processes rigidly. It’s about building shared understanding through conversations facilitated by appropriate tools. Also, maintaining a healthy Product Backlog is not about perfection but continuous improvement and adaptation. The more alignment you create upfront, the less waste you’ll generate downstream. And the healthier your Product Backlog, the more effectively you can deliver on the promise of that alignment. In other words, shift decisions on what to build left. Conclusion The journey from alignment to delivery is not a linear process but a continuous cycle. Alignment tools create the context for effective discovery, which feeds validated hypotheses into the Product Backlog. Proper Product Backlog management and refinement ensure the team builds the right things correctly, delivering increments that provide feedback for realignment. The success of this cycle depends on several critical factors: Trust – Between stakeholders and teams and among team members.Collaboration – Not just working together but true partnership in solving problems.Risk navigation – Using alignment and validation to reduce uncertainty.Value creation – Focusing consistently on outcomes over outputs. By integrating alignment practices with proper Product Backlog management, teams can avoid building products that technically meet specifications but fail to deliver real value — the build trap of the feature factory. Instead, they can create products that genuinely matter to users and organizations. How are you creating alignment? Please drop me a line or comment below.

By Stefan Wolpers CORE

I have been interested in how artificial intelligence as an emerging technology may shape our work since the advent of ChatGPT; see my various articles on the topic. As you may imagine, when OpenAI’s Deep Research became available to me last week, I had to test-drive it. I asked it to investigate how AI-driven approaches enable agile product teams to gain deeper customer insights and deliver more innovative solutions. The results were enlightening, and I’m excited to share both my experience with this research approach and the key insights that emerged. Working With Deep Research: A New Level of Analysis My experience with Deep Research was remarkably productive. After providing a detailed research prompt exploring how AI transforms agile product development, I received a comprehensive synthesis that went far beyond what I expected from market research handled by an AI agent. What impressed me most was how the research agent engaged with my initial request, asking clarifying questions about industry focus, development stages, timeframes, and company sizes of interest. This collaborative refinement process ensured the final report addressed my specific needs rather than delivering generic information. (Other agents are less inclined to do so; Perplexity or Grok, for example.) Within just 11 minutes, Deep Research compiled findings from 16 sources into a cohesive narrative featuring three in-depth case studies and a thoughtful cross-case analysis. The analysis didn’t just aggregate information — it extracted meaningful patterns and presented actionable insights in a structured, easily digestible format. (Download the complete report here: AI in Agile Product Teams: Insights from Deep Research and What It Means for Your Practice.) Three Illuminating Case Studies The report examined how diverse organizations leveraged AI within their agile frameworks to transform product discovery and delivery: Lightful: Agile “AI Squad” Powers Nonprofit Communication This London-based tech company formed a cross-functional “AI Squad” with designers, engineers, and product managers working in daily iterations. Rather than adopting AI for its own sake, they identified specific pain points for their nonprofit clients and experimented with AI solutions in short, rapid cycles. Their most successful innovation was an “AI Feedback” tool that helps nonprofit users improve social media posts by providing suggestions with explanations. The solution educated users while augmenting (not replacing) human creativity. The team’s agile approach allowed them to quickly adapt when new AI models became available, swapping in improved technology within Sprints. PepsiCo: AI Uncovers the “Perfect Cheetos” PepsiCo employed generative AI and deep reinforcement learning to experiment with Cheetos’ shape and flavor. First, they built a digital simulation of the production process. Then, they trained an AI system to optimize variables like dough moisture, temperature, and machine settings — running thousands of virtual trials far faster than physical lab tests could allow. The AI-designed “perfect Cheetos” drove a 15% increase in market penetration by aligning product attributes more closely with consumer preferences. PepsiCo combined human expertise with AI experimentation. Domain experts set clear objectives, while the AI explored the solution space extensively, identifying non-intuitive combinations that human R&D might have overlooked. Wayfair: Generative AI Enhances Customer Visualization Wayfair developed “Decorify,” an AI-powered interior design tool that lets shoppers upload photos of their room and describe a desired style. The generative model produces a photorealistic image of the space filled with Wayfair furniture and decor matching that style, with products linked for purchase. Within months of launch, the tool had generated over 175,000 room designs for users. It addressed a critical customer need: helping me envision what furniture would look like in my space. Wayfair treated this as an MVP: launching early, then improving through iterative updates based on user feedback and usage data. Six Key Patterns for Success Across these case studies, Deep Research identified recurring patterns that contributed to successful AI integration within agile frameworks. As the report concluded: “Common threads in our case studies include a relentless focus on customer needs, iterative development to harness AI’s fast improvements, cross-functional teamwork, and careful attention to ethics and data quality.” The six key patterns worth highlighting are: 1. AI as an Insight Engine, Not Just an Efficiency Tool In all three cases, AI revealed deeper customer insights that shaped product direction — from identifying content quality needs at Lightful, discovering precise product traits consumers love at PepsiCo and revealing style preferences at Wayfair. Organizations leveraged AI to uncover latent needs and patterns, not just to automate existing processes. 2. Customer-Centric, Problem-First Approach Successful teams started with customer problems and needs, then applied AI as appropriate — not vice versa. This discipline prevented wasted effort on “cool” AI ideas that don’t move the needle. The question was always: “How can AI help solve this specific customer problem?” rather than “Where can we use AI?” 3. Agile Methods Amplify AI’s Impact (and Vice Versa) The fast pace of AI advancement requires the adaptability that agile practices provide. Teams integrated AI work into their work cadence: using short experiments to test viability, Sprints to build AI-driven features incrementally, and frequent reviews to assess outcome quality with stakeholders. This created a powerful feedback loop where Agile’s adaptability enabled quick AI piloting, and AI-generated insights informed subsequent iterations. 4. Cross-Functional Teams and Skills Are Essential AI projects intersect with data science, engineering, design, and domain expertise. The most successful implementations involved diverse teams with a shared language around AI. This prevented miscommunication and unrealistic expectations, allowing for smoother collaboration and more effective solutions. 5. Human Oversight, Ethics, and Data Quality Teams created processes to verify AI outputs and mitigate errors or bias. This included adding QA steps in the definition of done, A/B testing AI decisions against human ones before full rollout, and proactively addressing ethical considerations. Transparency with users and ensuring regulatory compliance were essential. 6. Leadership Buy-In and Culture of Experimentation Leadership support provided vision and resources, empowering teams to iterate without fear. Setting realistic expectations — not overhyping AI as magic but as a powerful tool requiring refinement — and communicating progress in terms leadership cares about (customer metrics, ROI, competitive advantage) were crucial. Becoming Obsolete Is a Choice, Not Inevitable What strikes me most about these findings is how they challenge the fear narrative around AI for knowledge workers. Many professionals view AI as a threat rather than a paradigm-shifting technology like the printing press, electricity, or the Internet. Yet, these case studies tell a different story. In each example, human expertise remained essential. AI enhanced human capabilities rather than replacing them. At Lightful, the AI provided suggestions but kept humans in the creative loop. At PepsiCo, domain experts set objectives and guided the AI’s exploration. At Wayfair, the AI visualization tool helped customers make better decisions but didn’t replace the human shopping experience. These observations suggest that becoming obsolete in the age of AI is a choice, not an inevitability. The practitioners who thrive will be those who learn to leverage AI as a collaborator — using it to uncover insights from unstructured data, simulate complex scenarios, and enhance their decision-making. What This Means For Your Agile Practice As agile practitioners, we’re uniquely positioned to embrace AI. The agile mindset — focused on adaptation, continuous improvement, and delivering customer value — aligns perfectly with the evolving nature of AI technology. Here are three takeaways for your own practice: Start small, learn fast. Begin with specific customer pain points where AI might offer value. Run experiments in short iterations, gather feedback, and adapt quickly.Build cross-functional AI literacy. Ensure your team has a shared understanding of AI capabilities and limitations. “Understanding” doesn’t mean everyone should become a data scientist, but everyone should understand enough to collaborate effectively.Keep the human at the center. Design AI implementations that augment human creativity and decision-making rather than attempting to replace it. Most applications keep humans in the loop. Many agile teams are currently missing opportunities to leverage AI for deeper insights — particularly in transforming qualitative data from user research, retrospectives, and customer feedback into actionable patterns. There’s enormous untapped potential in using AI to extract meaning from the rich but unstructured data we already collect. Conclusion The future belongs to agile practitioners who can pair human judgment with AI’s analytical power. We can deliver unprecedented value to our customers and organizations by embracing this partnership rather than fearing it. Deep Research is merely a glimpse into this future. Have you experimented with AI in your agile practice? What opportunities do you see for AI to enhance rather than replace your team’s capabilities? How might we ensure that AI serves our agile values rather than undermining them? Please drop me a line or comment below.

By Stefan Wolpers CORE

Welcome to 2025! A new year is the perfect time to learn new skills or refine existing ones, and for software developers, staying ahead means continuously improving your craft. Software design is not just a cornerstone of creating robust, maintainable, and scalable applications but also vital for your career growth. Mastering software design helps you write code that solves real-world problems effectively, improves collaboration with teammates, and showcases your ability to handle complex systems — a skill highly valued by employers and clients alike. Understanding software design equips you with the tools to: Simplify complexity in your projects, making code easier to understand and maintain.Align your work with business goals, ensuring the success of your projects.Build a reputation as a thoughtful and practical developer prioritizing quality and usability. To help you on your journey, I’ve compiled my top five favorite books on software design. These books will guide you through simplicity, goal-oriented design, clean code, practical testing, and mastering Java. 1. A Philosophy of Software Design This book is my top recommendation for understanding simplicity in code. It dives deep into how to write simple, maintainable software while avoiding unnecessary complexity. It also provides a framework for measuring code complexity with three key aspects: Cognitive Load: How much effort and time are required to understand the code?Change Amplification: How many layers or parts of the system need to be altered to achieve a goal?Unknown Unknowns: What elements of the code or project are unclear or hidden, making changes difficult? The book also discusses the balance between being strategic and tactical in your design decisions. It’s an insightful read that will change the way you think about simplicity and elegance in code. Link: A Philosophy of Software Design 2. Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy Simplicity alone isn’t enough — your code must achieve client or stakeholders' goals. This book helps you bridge the gap between domain experts and your software, ensuring your designs align with business objectives. This is the best place to start if you're new to domain-driven design (DDD). It offers a practical and approachable introduction to DDD concepts, setting the stage for tackling Eric Evans' original work later. Link: Learning Domain-Driven Design 3. Clean Code: A Handbook of Agile Software Craftsmanship Once you’ve mastered simplicity and aligned with client goals, the next step is to ensure your code is clean and readable. This classic book has become a must-read for developers worldwide. From meaningful naming conventions to object-oriented design principles, “Clean Code” provides actionable advice for writing code that’s easy to understand and maintain. Whether new to coding or a seasoned professional, this book will elevate your code quality. Link: Clean Code 4. Effective Software Testing: A Developer’s Guide No software design is complete without testing. Testing should be part of your “definition of done.” This book focuses on writing practical tests that ensure your software meets its goals and maintains high quality. This book covers techniques like test-driven development (TDD) and data-driven testing. It is a comprehensive guide for developers who want to integrate testing seamlessly into their workflows. It’s one of the best software testing resources available today. Link: Effective Software Testing 5. Effective Java (3rd Edition) For Java developers, this book is an essential guide to writing effective and idiomatic Java code. From enums and collections to encapsulation and concurrency, “Effective Java” provides in-depth examples and best practices for crafting elegant and efficient Java programs. Even if you’ve been writing Java for years, you’ll find invaluable insights and tips to refine your skills and adopt modern Java techniques. Link: Effective Java (3rd Edition) Bonus: Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software As a bonus, I highly recommend this book to anyone looking to deepen their understanding of design patterns. In addition to teaching how to use design patterns, this book explains why you need them and how they contribute to building extensible and maintainable software. With its engaging and visually rich style, this book is an excellent resource for developers of any level. It makes complex concepts approachable and practical. Link: Head First Design Patterns These five books and the bonus recommendation provide a roadmap to mastering software design. Whether you’re just starting your journey or looking to deepen your expertise, each offers a unique perspective and practical advice to take your skills to the next level. Happy learning and happy coding! Video

By Otavio Santana CORE

The Forensic Product Backlog Analysis: A 60-minute team exercise to fix your Backlog. Identify what’s broken, find out why, and agree on practical fixes — all in five quick steps. There is no fluff, just results. Want technical excellence and solve customer problems? Start with a solid Product Backlog. A Team Exercise: Forensic Product Backlog Analysis Your Product Backlog is a mission-critical team artifact. It’s not just a list of features or tasks — it reflects your team’s ability to create value for customers and your organization. (You may have heard this before, but we are not paid to practice “Agile” but to solve our customers’ problems within the given constraints while contributing to the organization’s sustainability.) Like any critical system, the “garbage in, garbage out” principle applies: inferior Backlogs lead to inferior products. Here's a structured 60-minute Forensic Product Backlog Analysis that helps teams identify backlog issues and develop practical solutions. The format based on Liberating Structures encourages participation while keeping discussions focused and actionable. Step 1: Individual Anti-Pattern Identification (5 minutes) Each team member identifies five ways to make a Product Backlog low-quality and hamper the team's potential to create value. This silent brainstorming ensures everyone's voice is heard, not just the loudest participants. Take personal notes — you'll need them in the next step. (Learn more about TRIZ.) Step 2: Small Group Analysis (10 minutes) Form groups of 3-4 people. Each group merges their individual findings into a top-five list of Product Backlog anti-patterns. The key here is to rank these patterns from worst to least harmful. This step surfaces the most critical issues while building consensus through small-group discussions. (Learn more about 1-2-4-All.) Step 3: Collective Pattern Recognition (15 minutes) Bring all groups together. The first team presents their ranked list of backlog anti-patterns. Each subsequent team adds their unique findings, creating a merged, ranked list. This step reveals patterns across different perspectives and helps build a comprehensive view of the challenges. (Learn more about White Elephant.) Step 4: Root Cause Analysis (20 minutes) With your consolidated list, analyze each major Product Backlog anti-pattern: What exactly do you observe?What might be causing this pattern?What's one concrete step you could take to address it? This structured forensic Product Backlog analysis prevents the discussion from becoming a complaint session and keeps the focus on actionable insights. (Learn more about 9 Whys.) Step 5: Action Planning (10 minutes) Choose the top three anti-patterns and develop specific countermeasures. The emphasis here is on practical, achievable steps that the team can implement immediately. Remember, small improvements are better than grand plans that never materialize. (Learn more about 15 % Solutions.) Why This Exercise Works The Forensic Product Backlog Analysis exercise works because: It's time-boxed: 60 minutes maintains focus and energyIt's inclusive: Everyone contributes, not just the vocal fewIt's practical: The outcome is a ranked list of actionable improvementsIt's evidence-based: Solutions emerge from observed patterns, not assumptionsIt's team-owned: The group discovers and owns both problems and solutions. The most valuable Product Backlogs emerge from teams regularly examining and improving their practices. This exercise provides a framework for continuous improvement, helping teams move from identifying problems to implementing solutions in a true Kaizen spirit. Final tip: Schedule this session when the team has high energy. The goal is to generate insights leading to improvements, not just create another routine meeting with an action item list no one will ever touch again. Conclusion Start with the Forensic Product Backlog Analysis as outlined, then adapt this exercise to your team's needs. The format is flexible — what matters is the outcome: a clearer understanding of your Product Backlog's health, concrete steps to improve it, and an improved alignment with stakeholders. Remember: A strong Product Backlog is a prerequisite for delivering value. Make time to maintain and improve this critical team asset and invest in your team's reputation and performance — the management and customers will notice.

By Stefan Wolpers CORE

TL; DR: Stop Shipping Waste When product teams fail to establish stakeholder alignment and implement rigorous Product Backlog management, they get caught in an endless cycle of competing priorities, reactive delivery, and shipping waste. The result? Wasted resources, frustrated teams, and missed business opportunities. Success in 2025 requires turning your Product Backlog from a chaotic wish list into a strategic tool that connects vision to value delivery. Learn how to do so. Two Systemic Failures Leading to Shipping Waste Product management is a balancing act. Teams must manage customer needs, stakeholder expectations, technical constraints, and business goals while delivering measurable outcomes. Yet, despite their best intentions, many product teams fall short. Why? Two pervasive issues often lie at the root of this failure: A lack of alignment and a broken Product Backlog Management process. Let’s unpack why these failures matter — and how overcoming them can transform your team’s impact. (And, possibly, your career!) Failure #1: The Alignment Gap Imagine a scenario: Developers build features stakeholders think customers want, only to discover post-launch that the solution misses the mark. Sales teams push for one priority, product leadership has a different idea, engineering advocates for another, and executives demand faster timelines. The result? Often wasted efforts, frustrated teams, disappointed customers, and missed business objectives. Misalignment isn’t just inconvenient — it’s costly. When stakeholders operate in silos, ignoring the benefits of product leadership, product teams lose sight of the “why” behind their work. Product roadmaps become wish lists, product strategy feels disconnected from execution, and collaboration dissolves into competing agendas. Without shared ownership of priorities, even the most talented product teams struggle to deliver meaningful outcomes. The Fix Alignment isn’t about enforcing consensus — it’s about creating clarity. Teams need frameworks to connect product vision to daily work. Tools like user story mapping, outcome-focused roadmaps, and structured stakeholder workshops can bridge gaps. Moreover, by frequently integrating customer insights and data with business objectives, product teams foster collaboration, ensuring everyone rallies behind the same objectives. Failure #2: The Backlog Black Hole The Product Backlog is meant to be a strategic asset. Yet, for many teams, it’s an overwhelming, chaotic list of tasks — a “black hole” where ideas go to die. Common symptoms of dysfunctional Product Backlogs include: Endless, low-value items drowning critical priorities.Stakeholders bypassing processes to demand urgent work.Teams stuck in reactive mode, shipping outputs without measurable impact. A poorly managed backlog erodes trust. Stakeholders see delays and confusion; product teams feel overwhelmed by shifting demands. Worse, without transparency, the backlog becomes a source of conflict rather than a tool for value delivery. The Fix Effective Product Backlog management requires rigor and strategy. Teams need processes to prioritize ruthlessly, validate assumptions, and align backlog items with customer and business outcomes. Techniques like weighted scoring, value vs. effort analysis, and anti-pattern identification can transform Product Backlogs into dynamic, transparent tools. The Cost of Ignoring These Failures When alignment and Product Backlog Management break down, the consequences ripple across organizations: Lost opportunities: Teams waste precious capacity on low-impact work while competitors innovate.Stagnant careers: Product leaders lose credibility when they can’t articulate progress or outcomes.Cultural erosion: Misalignment breeds frustration, burnout, and attrition. But teams that address these challenges unlock transformative results. They ship solutions customers love (and contribute to the bottom line), build stakeholder trust, and create cultures where collaboration thrives. Why This Matters for Your Career Let me be blunt: The market doesn’t need more Product Owners who “manage” Product Backlogs. It requires product leaders who wield them strategically. When you master alignment and backlog rigor, you stop being seen as a “task coordinator” and become the person who delivers results. The product teams that thrive in 2025 and beyond will: Ship solutions customers love, not just tolerate.Turn stakeholders into collaborators, not critics.Use the backlog to drive decisions, not document them. This isn’t about process — it’s about impact. Conclusion Product teams often struggle with misalignment and chaotic Product Backlogs, leading to wasted effort, frustrated teams, and missed opportunities. By addressing these issues, teams can turn their Product Backlog into a strategic tool that drives value and aligns everyone around a shared vision. Success comes from fostering clarity and collaboration, prioritizing customer-centric decisions, and implementing rigorous Product Backlog management. Teams that embrace these principles will ship solutions customers love, build trust, and create a culture of accountability. For product leaders, this is a chance to elevate your career. Master alignment and backlog management to become a strategic leader who delivers measurable outcomes. Stop shipping waste and start delivering value.

By Stefan Wolpers CORE

Psychological safety isn’t about fluffy “niceness” — it is the foundation of agile teams that innovate, adapt, and deliver. When teams fearlessly debate ideas, admit mistakes, challenge norms, and find ways to make progress, they can outperform most competitors. Yet, many organizations knowingly or unknowingly sabotage psychological safety — a short-sighted and dangerous attitude in a time when knowledge is no longer the moat it used to be. Read on to learn how to keep your competitive edge. The Misinterpretation of Psychological Safety I’ve noticed a troubling trend: While “psychological safety” is increasingly embraced as an idea, it is widely misunderstood. Too often, it is conflated with comfort, an always-pleasant environment where hard conversations are avoided and consensus is prized over candor. This confusion isn’t just conceptually muddy; it actively undermines the very benefits that psychological safety is meant to enable. So, let’s set the record straight. Actual psychological safety is not about putting artificial harmony over healthy conflict. It is not a “feel-good” abstraction or a license for unfiltered venting. At its core, psychological safety means creating an environment of mutual trust and respect that enables candid communication, calculated risk-taking, and the open sharing of ideas — even and especially when those ideas challenge the status quo. (There is a reason why three out of five Scrum Values — openness, respect, and courage — foster an environment where psychological safety flourishes.) When Amy Edmondson of Harvard first introduced the term, she defined it as a “shared belief held by members of a team that the team is safe for interpersonal risk-taking.” Digging deeper, she clarified that psychological safety is about giving candid feedback, openly admitting mistakes, and learning from each other. Note the key elements here: candor, risk-taking, and learning. Psychological safety doesn’t mean we shy away from hard truths or sweep tensions under the rug. Instead, it gives us the relational foundation to surface those tensions and transform them into growth. It is the baseline of trust that allows us to be vulnerable with each other and do our best work together. When teams misunderstand psychological safety, they tend to fall into one of two dysfunctional patterns: Artificial harmony. Conflict is avoided at all costs. Dissenting opinions are softened or withheld to maintain an illusion of agreement. On the surface, things seem rosy – but underneath, resentments fester, mediocre ideas slip through unchecked, and the elephants in the room live happily ever after.False bravado. The team mistakes psychological safety for an excuse for unfiltered “brutal honesty.” Extroverts voice critiques without care for their impact, bullying the introverts, thus eroding the trust and mutual respect that proper psychological safety depends on. Both failure modes arise from the same fundamental misunderstanding: psychological safety prioritizes comfort over candor or honesty over care. In reality, true psychological safety dismisses these false dilemmas. It involves discovering how to engage in direct, even challenging, conversations in a way that enhances rather than undermines relationships and trust. Psychological Safety and Radical Candor This is where the concept of “radical candor” comes in. Coined by Kim Scott, radical candor means giving frank, actionable feedback while showing that you care about the person on the receiving end. It is a way of marrying honesty and empathy, recognizing that truly constructive truthtelling requires a bedrock of interpersonal trust. This combination of directness and care is at the heart of psychological safety, and it is utterly essential for agile teams. Agile’s promise of responsiveness to change, creative problem-solving, and harnessing collective intelligence depends on team members’ willingness to speak up, take smart risks, and challenge established ways of thinking. This requires an environment where people feel safe not just supporting each other but productively sparring. Consider the Daily Scrum or stand-up, a hallmark Agile event. The whole point is for team members to surface obstacles, ask for help, and realign around shifting goals. But that is hard to do if people feel pressured to “seem fine” or avoid rocking the boat. Actual psychological safety creates space for people to say, “I’m stuck and need help,” “I don’t know,” or “I disagree with that approach” without fear of judgment or retribution. Or take the Retrospective, which is also dedicated to surfacing and learning from failure. (Of course, we also learn from successes.) If people think that talking openly about mistakes will be held against them, they’ll naturally ignore, massage, or sanitize what happened. (This is also the main reason a team should not include members with a reporting hierarchy between them.) Psychological safety shifts that calculus. It says, “We’re in this together, win or lose,” which paradoxically gives teams the courage to scrutinize their losses more rigorously to learn from failure. Zoom out, and you’ll see psychological safety running like a golden thread through all the core Agile principles: “individuals and interactions over processes and tools,” “customer collaboration over contract negotiation,” and “responding to change over following a plan.” Enacting these values in the wild requires team environments of enormous interpersonal trust and openness. That is the singular work of psychological safety — and it is not about being “soft” or avoiding hard things — quite the opposite. (Think Scrum Values; see above). The research shows that psychological safety isn’t just a kumbaya aspiration — it is a performance multiplier. Google’s comprehensive Project Aristotle, which studied hundreds of teams, found that psychological safety was the single most significant predictor of team effectiveness. Teams with high psychological safety consistently delivered superior results, learned faster, and navigated change more nimbly. They also tended to have more fun in the process. Moreover, teams with high psychological safety are more likely to create value for customers, contribute to the bottom line, retain top talent, and generate breakthrough innovations — the ultimate competitive advantage. In other words, psychological safety isn’t a nice-to-have; it is a strategic necessity and a profitable asset. So, how do we cultivate authentic psychological safety in our teams? A few key practices: Frame the work as learning. Position every project as an experiment and every failure as vital data. Publicly celebrate smart risks, regardless of the outcome. Make it explicit that missteps aren’t just tolerated—they’re eagerly mined for gold.Model fallibility. As a leader, openly acknowledge your own mistakes and growth edges. Share stories of times you messed up and what you learned. Demonstrating vulnerability is a powerful signal that it is safe for others to let their guards down, too. (Failure nights are a great way of spreading this message.)Ritualize reflection. Take Retrospectives seriously to candidly reflect on what’s working and what’s not. Using structured prompts and protocols helps equalize airtime so that all voices are heard (Think, for example, of Liberating Structures’ Conversation Café). The more habitual reflection becomes, the more psychological safety will deepen. If necessary, consider employing anonymous surveys to give everyone a voice.Teach tactful candor. Train the team in frameworks for giving constructive feedback, such as the SBI (situation-behavior-impact) model or non-violent communication. Emphasize that delivering hard truths with clarity and care is the ultimate sign of respect — for the individual and the shared work.Make space for being a mensch. Kickoff meetings with quick personal check-ins. Encourage people to bring their whole messy, wonderful selves to work. Share gratitude, crack jokes, and celebrate the small wins. Psychological safety isn’t sterile; it is liberatingly human. Most importantly, recognize that building and sustaining psychological safety is an ongoing practice — not a one-and-done box to check. It requires a daily recommitment to choosing courage over comfort, purpose over posturing, and the hard and necessary truths over the easy fake-outs. Like any meaningful discipline, it is not always comfortable. Working and relating in a psychologically safe way can sometimes feel bumpy and exposing. We may give clumsy feedback, stumble into miscommunications and hurt feelings, and face hard facts we’d rather avoid. But that is the point: genuine psychological safety transforms uncomfortable moments from threats into opportunities. It allows us to keep showing up and learning together, especially when we feel most vulnerable. It fosters a team culture that is resilient enough to endure the necessary friction of honest collaboration and turns them into something impactful and clarifying. That is the promise of psychological safety. More than just another buzzword or checklist item, it is about cultivating the soil for enduringly healthy and productive human relationships at work. It is about creating the conditions that support us in growing into them together. Put simply, without psychological safety, Agile can’t deliver on its potential. With psychological safety, Agile can indeed come alive as a force for creativity, innovation, and, yes, joy at work. Conclusion Start by looking honestly at your team: How safe do people feel taking risks and telling hard truths? What is the one conversation, the one elephant in the room, you have been avoiding that might unlock the next level of performance and trust? Challenge yourself to initiate that talk next week — and watch the ripple effects unfold. Embracing this authentic version of psychological safety won’t be a walk in the park. You and your team will face uncomfortable moments of friction and vulnerability. Team members may drop out, feeling too stressed about it. But leaning into that discomfort is precisely how you will unleash your true potential. Psychological safety is about building a resilient team to navigate tough challenges and have difficult conversations because you know you have each other’s backs. That foundation will allow you to embrace agility as it is meant to be.

By Stefan Wolpers CORE