Comment by skeeter2020 | Hacker News Reader

Comment by skeeter2020 | Hacker News Reader

Parent Full thread

This post is classic SAFe and SAFe-certified trainer talk:

* It starts by stating "I'm a SAFe consultant now, but at heart I'm a developer just like you!",

* It conflates what SAFE says it does (continuous deployment; empower developers; responsive teams) with what it PRESCRIBES (coordinated release trains; process over people; commitment to long term deliverables up front),

* It speaks to the executives and management that will decide to adopt SAFe, not the developers who will need to somehow work within it,

* It somehow promises to combine bottom-up agile with top-down date-based delivery commitments then hand-waves away the collision of these intractable approaches,

* It pleads that SAFe is not heavy weight even though all SAFe offers is hundreds of pages of process and rituals,

* It attacks anyone who is concerned or unwilling to do SAFe, as obviously they'r the ones with a vested interest in not adopting SAFe,

* It presents the straw-man argument that the alternative to SAFe is teams that can't coordinate,

* It concludes that if you didn't see all the supposed benefits from SAFe, "you did it wrong",

* Like SAFe itself,it's long, full of platitudes, self-promotional and in the end leaves you ready to surrender just to make it stop.

Question for the group: Do you know anyone who's livelihood doesn't directly depend on adopting or enforcing SAFe who is a big booster?

My favorite SAFe quote:

"SAFe uses agile like a drunk uses a lamp-post: for support, not illumination".

> * It conflates what SAFE says it does (continuous deployment; empower developers; responsive teams) with what it PRESCRIBES (coordinated release trains; process over people; commitment to long term deliverables up front),

As is common with political initiatives. First the values are listed, then the motivation for those values are presented in a way that nobody can disagree with. Then the slight of hand: the proposed solution is assumed to be the only possible fulfillment of the values. All discussion about the mechanisms by which the solution fulfills the promises of the values is cast as disagreement about the values. "How could you disagree with coordinating your work" instead of "how do you think our activities don't lead to coordination between teams".

It's unfortunately a very effective strategy.

I’m not a SAFe consultant. I’m certified but I consult on a lot of things: Postgres and application performance tuning, DMARC deployment, pipeline automation and organizational process.

I’ve also never certified anyone in SAFe professionally. The principles work but I’m not a believer in adopting it strictly in organizations. Instead I observe and recommend improvements in existing companies once I understand their dynamics.

In many cases, aspects of SAFe are effective recommendations.

Whether you formally follow the PI Planning approach to get everybody together or you find a better fit for remote staff, letting your devs plan 10 weeks at a time instead of 2 is beneficial for everybody. And cuts down on a lot of every 2 week meetings to support it.

And all I’ve shared is my own experience. I constantly see straw men arguments against it posted.

When you scrap the SAFe with Scrum approach and replace it with SAFe with Kanban 90% of the ceremonial meetings go away.

Most devs I talk to don’t even realize there’s supposed to be a backlog that they prioritize without having to consult the business side of the house.

There’s no question that the anti-SAFe crowd has legitimate gripes with bad environments. Their concerns aren’t any more valid than the concerns of anti-Scrum proponents who have been in bad environments.

It’s trying to solve a hard problem but under the hood it’s just best practice after best practice smooshed together.

Get the scrum ceremony out and SAFe gets a lot cleaner for everyone involved. You’re basically just adding more ceremony if you use scrum within SAFe. If you use Kanban, you trade for much less frequent ceremony so you can focus.

SAFe instructors are taught WITH the scrum ceremony and IMO that is the root of all of the blowback.

SAFe is for managers, Agile is for developers. As developer, you don't need to know SAFe and it rituals. SAFe is not heavy weight, it very lean for the problem it solves.

> It somehow promises to combine bottom-up agile with top-down date-based delivery commitments then hand-waves away the collision of these intractable approaches,

It OK to fail few early goals or dead-lines until right pace will be found.

If you haven't met the customer, it's not agile.

Product owners are not the customer. Scrum is watered down agile.

SAFe is simply not agile.

Reply on news.ycombinator.com