The Scrum Guide Expansion Pack represents a fascinating contradiction in the agile world. While attempting to cure Scrum’s reputation crisis, it may actually amplify the very problems it seeks to solve. Let me explain what this means for practitioners dealing with the aftermath of failed Scrum implementations.
The data couldn’t be more supportive: Despite 25 years of the Agile Manifesto, countless books, a certification industry, conferences, and armies of consultants, we’re collectively struggling to make Agile work. My recent survey, although not targeting Agile failure, still reveals systemic dysfunctions that persist across organizations attempting to implement Agile practices:
Stop treating AI as a team member to “onboard.” Instead, give it just enough context for specific tasks, connect it to your existing artifacts, and create clear boundaries through team agreements. This lightweight, modular approach of contextual AI integration delivers immediate value without unrealistic expectations, letting AI enhance your team’s capabilities without pretending it’s human.
Can you rely on pure Scrum to transform your organization and deliver value? Not always. While Scrum excels in simplicity and flexibility, applying it “out of the box” often falls short in corporate contexts due to limitations in product discovery, scaling, and portfolio management.
This article explores the conditions under which pure Scrum thrives, the organizational DNA required to support it, and practical scenarios where it works best—along with a candid look at where it struggles. Discover whether pure Scrum is a realistic approach for your team and how thoughtful adaptation can unlock its true potential.
Why might leaders turn to the Product Operating Model (POM) after a previous Agile transformation, for example, based on SAFe, failed?
This article uncovers the psychological, organizational, and strategic reasons behind this seeming contradiction, exploring what motivates leaders to believe that a new approach will succeed where others have not.
By all means, the “Product Operating Model” (POM) has surged in popularity, especially among traditional organizations keen to prove their adaptability. (And, of course, among the McBostonians who, now that ”Agile” is dead, need a substitute to bill their junior consultants.) Which brings us to the problem of Product Washing.
On the surface, the product operating model promises a more customer-focused, outcome-driven approach. Empowered teams create value iteratively rather than following rigid, output-focused roadmaps. Best of all, they do so autonomously, well-aligned with the organization’s overall strategy and the possibly myriad other teams working on different initiatives. Think of SAFe done right.
Yet, for all its promise, the product operating model risks becoming another buzzword rather than an actual driver of transformation. Organizations that tout a “product-led” philosophy often do so without making the profound changes needed to live by it. This hollow adoption of product practices, or what we might call “Product Washing,” leaves companies stuck in the same old dynamics but with a new vocabulary: transformation by reprinting business cards. (Does this sound familiar?)
