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?)
Scrum is a purposefully incomplete framework. Consequently, it needs to be augmented with tools and practices to apply its theoretical foundation to an organization’s business reality: what problems shall be solved for whom in which market? Moreover, there is an organization’s culture to take into account. However, the intentional “gap” is not a free-for-all to accept whatever comes to mind or is convenient. Some tools and practices have proven highly effective in supporting Scrum’s application and reaping its benefits. And then there are others — the Scrum trap.
Let’s look at what practices and tools for collaboration and team building are not helpful when used with Scrum.
This post on Scrum team failure addresses three categories from the Scrum anti-patterns taxonomy that are closely aligned: Planning and process breakdown, conflict avoidance and miscommunication, and inattention to quality and commitment, often resulting in a Scrum team performing significantly below its potential.
Learn how these Scrum anti-patterns categories manifest themselves and how they affect value creation for customers and the organization’s long-term sustainability.
This is the third of three articles analyzing the 183 anti-patterns from the upcoming Scrum Anti-Patterns Guide book. The other two articles, see below, address adhering to legacy systems, processes, practices, and communication and collaboration issues.
One of my favorite exercises from my Professional Scrum Product Owner classes is how to best sabotage a Product Owner as a member of the middle management. The exercise rules are simple: You’re not allowed to use any form of illegal activity. So, outsourcing the task to a bunch of outlaws is out of the question. Instead, you are only allowed to use practices that are culturally acceptable within your organization.
Read on and learn more on how to best sabotage a Product Owner from the exercise results of more than twenty PSPO classes. (I edited the suggestions for better readability.)
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. One area where Scrum’s nature of being intentionally incomplete causes issues regularly is whether Scrum teams shall stick to the event schedule even if the team’s life is uneventful? For example, is skipping Retrospectives okay?
Join me and delve into the consequences of skipping Retrospectives in less than 90 seconds.
