I Don’t Like SAFe

Kevin Bendeler
5 min readJan 29, 2022

It’s coarse and rough and irritating, and it gets everywhere. — Anakin Skywalker

I’ve worked in agile software development for over 10 years now, a good chunk of it with SAFe. SAFe is a framework that attempts to scale up Agile principles to work in large enterprises. It incorporates stuff like the Release Train, Program Increments, Budgeting, and DevOps. There are benefits through using SAFe, and some very good use cases for full or partial adoption, as long as your eyes are open to the problems with SAFe, and your reasons for adopting it are sound.

However, here I’m describing seven key points why it might not be the magic bullet for an organization looking to scale technology delivery. I’m really interested in your opinion, so please do get in touch if you wish to make a comment or suggestion.

1 — Nothing in any agile method suggests that we need to measure work units (i.e. story points) in uniform manners across teams. Story points exist to help the people doing the work break things down into optimum “batch size”, which makes deliverables achievable, less complex, and the work flow. SAFe actually encourages larger batch sizes through extensive front-loaded planning, not smaller sizes planned through more iterative methods.

SAFe tries to normalize story points across teams for various reasons, but there is often a strong desire to measure and compare the delivery of teams and people. This is not what story points are for. Story points do not exist to measure how productive developers are, they’re just a tool to be used by the developers to discuss the various aspects of a story.

2 — Technical debt tends to increase in SAFe organizations because the prioritization of dealing with it is raised to a management level rather than team level. This is counter-productive for technical debt that originates at the team level (which most of it does). Management will tend to prioritize features and functions, delaying the pay-back of localized technical debt, and resulting in slower, higher risk, more brittle systems.

3 — If SAFe is applied to more operational functions, such as technology support, operations, or maintenance, conflicts between delivery and support functions arise, because supporting teams typically need to work either responsively, dealing with issues as…

Kevin Bendeler

4X Top Writer — Associate Partner @ Heroes. I write about managing products, people, teams, organizations, strategy, and execution. Owner of scrum-store.com