Ask HN: Why do you hate SAFe (Scaled Agile Framework)?
But I keep seeing comments on here from people talking about threatening to quit their jobs if SAFe is implemented or actively looking because of it...and I want to know where it's all going wrong?
Examples from today: https://news.ycombinator.com/item?id=30944386
Please discuss here or feel free to reach out on Keybase (in my profile). I want to understand and potentially write about it to help fix it.
I got into this thanks to a lot of guidance from Hacker News. Posted a long rant ( https://news.ycombinator.com/item?id=17154355 ) about the state of all things agile (largely scrum based) and one of the commenters pointed me to a great book by Donald Reinertson called 2nd Generation Lean Product Development. It's not process heavy, but it is math and theory heavy. I loved it and absolutely advocate for it. When I got a chance to use it with my team it was working great, but I realized I was falling very short with communicating with the rest of the business so I started looking for a more formal process based around his work and that's how I found SAFe.
I went deep on the material because I needed to know how to trim the fat on the processes involved, because it's too much for less than 50 people and I'm happy with the results I've seen.
What SAFe should result in...
- Developers setting the development schedule based on business priorities rather than being handed arbitrary deadlines
- Far fewer meetings because you're trading the 2-3 day PI Planning meeting for dozens of smaller ones over the next quarter
- 2 separate backlogs with a 70% / 30% capacity planning split. One for Product priorities (70%) and one for dev/ops/arch priorities (30%) to ensure that technical people don't have to work with non-technical people to prioritize system level things that they KNOW need to be done.
- Avoidance of last second priority changes due to the agreed upon priorities and plan for the upcoming quarter
- No over-scheduling because SAFe calls for planning based on 2/3 capacity estimate per team per 2 week iteration and then leaves the final two weeks of the PI entirely unplanned as buffer or a 20% time reward for teams who did finish on schedule. The goal is "maximum sustainable pace" and it's one of the reason that "iteration" is used in place of "sprint" because by definition, a "sprint" is not a sustainable pace.
- Better coordination between multiple teams because they have a time to plan it out that doesn't derail short sighted 2 week "sprint" processes
All of these things (and more) can only happen if leadership is in board. If company or product leadership is unwilling to trust their developers to relinquish this type of control and try to maintain a grip on the process, none of it's going to work.