Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness

At the highest level, called the “Portfolio”, SAFe does advocate funding indefinite “Value Streams”. However, the Lean Portfolio Management function that controls funding are given sole authority to approve which Portfolio Epics (large initiatives) move into each stream. Epics are not explanations about a problem that needs to be solved. They are pre-formed ideas about how best to solve those problems.

SAFe collects small product teams (often Scrum teams) into “Agile Release Trains” — groups of teams with an additional layer of management roles spanning each group at what is called the “Program level”.

Generally these roles impede the autonomy of teams. They add process and communication overhead out of proportion with the value they provide.

Right away we can see signs of the old-school mindset of viewing teams as a “delivery” function instead of a strategic one. The high level thinkers come up with ideas, and the low level doers execute on those ideas. Ignored is the possibility that those closest to the work might be best equipped to make decisions about it.

The Product Owner and team might theoretically be able to prioritize other, smaller pieces of work against the work imposed on them, but these efforts have limited visibility and buy-in from above.

SAFe actually chooses to manage dependencies is by increasing focus on planning, process, hierarchy, and standardization. Predictably, this results in lots of meetings that interfere with the ability to get work done. It imposes this approach through a universal roll-out that affects the entire organization at once.

There is definitely some value in having people get together in person to build relationships, share information, and orient around goals. On the other hand, using that limited time window to make 10 week plans of specific user stories based on pre-defined features, and then requiring commitment to those plans is much less valuable.

As soon as PI planning ends, those plans created based on limited understanding and numerous assumptions will become obsolete as soon as anything new is learned. Teams will be continuously torn between sticking to the plan they’ve learned doesn’t make sense and and reorienting expectations for reasons those above them may not be in a position to understand.

Roles at the program level and above cannot possibly attend all team retrospectives. This means retrospectives will not be directly heard by the people who can actually change many of the things being discussed.