**Forwarded from [Dmitry Bezuglyi](https://t.me/Cless75)** I don't understand this phenomenon. Every time I see this picture, something dies inside me ☹️ A waterfall methodology masquerading as an Agile framework. Not applicable to modern product management. And yet, companies still take it seriously. Let's not be fooled. SAFe (Scaled Agile Framework) 6.0 is a marketing name for the full-scale waterfall and controlling people with a heavy process. Phrases like “Design Thinking,” “Lean UX,” or “Scrum” are just smoke and mirrors. ![[Pasted image 20240520173018.png]] In short, it goes like this: 1. Waterfalling the requirements In product, we understand that empowered teams are given meaningful problems to solve and are held accountable for the outcomes. But in SAFe, every quarter, teams gather for two days of "PI planning." The goal is to commit to specific features for the next 3 months. A feature factory. 2. The PM vs. PO dichotomy Product Owner is not a job title. I consider splitting the roles one of the worst anti-patterns in product management. But in SAFe, Product Owners spend long hours writing detailed specifications and do not even have to talk to the users: “Customers (...) may have direct or indirect relationships with the PO.” - Scaled Agile, Inc. Backlog administrators. 3. A team of doers In product, we understand that for Product Discovery to work, we need a cross-functional collaboration (aka. "product trio"). But in SAFe, Engineers are largely disconnected from discovery. Product Managers perform a waterfall discovery to fill the ART backlog with work before the next quarter. Engineers and Designers are not even considered “key collaborators” of the Product Management function. 4. Untrustworthy engineers In No Rules Rules, Reed Hastings and Erin Meyer highlight the most critical aspect of Netflix's culture - leading with context, not control. But according to SAFe, Engineers can’t be trusted as professionals. The Product Owner reviews and approves their work and ensures that what they have provided is not sloppy work. That's dangerous and toxic. 5. Following the plan SAFe claims to split the quarter into iterations. But the main goal of “inspection and adaptation” in each Sprint is to ensure everyone follows the plan and that committed features are delivered. They recommend what they call an “Agile Release Train.” Have you ever seen an agile train? --- At the end of the day, managers are delighted. They have paid a lot of money to consultants, the transformation was lightning-fast. They don’t have to change anything that matters, but now they can call themselves “Agile.” It’s no coincidence that no successful, innovative product organization (Meta, Google, Airbnb, Dropbox, Uber, Apple, etc.) uses that methodology. No buzzword can cover its true nature. --- What are your thoughts? Does anyone still use it? Let me know in the comments. --- P.S. Enjoy this? See my full, free post with in-depth analysis: https://lnkd.in/dS2c-gkc [ ## Itamar Gilad (https://www.linkedin.com/in/itamargilad) I'm not a fan, but I've encountered product folks that like elements of it (and many who don't like any of it). Some parts of the allure: 1. A set process to follow (see [](https://www.linkedin.com/in/ACoAAAb9BSUBSI510LmbH92K0qgwZ88PsAK3RvY)[David Pereira](https://www.linkedin.com/in/davidavpereira/)'s comment) - big orgs love that 2. "Solving" dependencies with big-room planning 3. 3-month waterfall planning cycles feel "agile" to an org used to 18-month planning cycles (or more) None of this is to say SAFe is good, just that it found a real need in the market.