My Problem with SAFe
I have a problem with SAFe. It’s not that it’s necessarily a bad scaling methodology for Agile (I’m not familiar enough with it to make that judgment). It’s that it’s the default Agile scaling methodology.
Why is that? It seems that anybody who’s starting to research scaling online stumbles upon SAFe – and pretty much only SAFe. The conclusion drawn from this is that SAFe is the only option. SAFe has the advantage of having been early to market in this space and filled a vacuum. There have been and are other methodologies out there, but they are – for some reason – less known, less catchy and definitely not branded and promoted as well. Therefore SAFe is perceived as the only viable option. On top of that, it seems comprehensive and prescriptive enough to appeal to enterprise users seeking “all the answers” and an “enterprise-class process” they can roll out. If that does happen, the Agile mindset and culture may quickly be forgotten since the process seems provide all the answers.
Again, I’m not all against SAFe. There are good things about it. But it’s not the only option and has – despite the hype – remained somewhat controversial in the Agile community and has its critics.
Let’s not forget other ways to scale, such as Scrum of Scrums (admittedly a questionable methodology in terms of effectiveness and ability to scale large), Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), the Spotify model, as well effective methodologies used and proven by Agile consultancies (let’s call them custom methodologies). For an interesting comparison check out www.agilescaling.org.
As always in Agile, let’s make sure we do our homework and pick an approach that’s appropriate for the given organization and problem space – instead of jumping straight into SAFe.