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 they arise, or on very short cycles — not the Program Increment cycle time imposed by SAFe. Smaller frameworks promoting flow, like Scrum with Kanban, are infinitely better suited to this work.

4 — Due to the focus on deliverables and accountability through project or product managers, teams may be discouraged from assisting each other, as they are measured by their own deliver: how much they assist other teams is rarely valued. This goes against everything other Agile frameworks stand for, in particular the 5 Scrum Values.

5 — The concept of ideal dev days is often used for estimating in SAFe. Everyone else knows that ideal dev days are a fallacy. Instead, look at past similar deliverables, and see how long they took. This is a much more predictive metric, and is less susceptible to optimism bias or wanting to please the boss. Empiricism is the foundation of agility. Let's keep our estimations as empirical as possible. This means adjusting your views, based on what's observed — eliminating or at least reducing the effect of the cone of uncertainty.

6 — The concept of value often breaks down in SAFe, through a focus on volume of delivery and meeting the arbitrary deadlines imposed by management in PI planning. As a result, what end-users actually want is often ignored in favor of what management wants.

And when the deadline is missed, as it normally is (remember the front loaded planning), the Program Increment is so rigid that adjusting is impossible. You are now left with an incomplete increment and another Program Increment that will be ruined in order to adjust. That's six months gone in an average organization.

7 — PI planning includes a small element of retrospective activity, but it's too little, too late. The retrospective feedback loops need to be short and light, not tagged on to PI planning as an afterthought. This is a major problem with the framework, as all the dependencies you're working through need to be evaluated. Because this creates an unwanted amount of overhead, it's often skipped or treated as a "that's how we work here".

Agile was created as a response to frustrations felt across the industry from heavyweight, top-down project management methodology that was killing the sector. Trying to scale Agile up by applying heavyweight, top-down methodologies is antithetical. It's also counter productive.

Some SAFe practitioners describe it as a transition stage, a process through which organizations can achieve increased capability at scale. I would agree: if an organization feels the need to adopt SAFe, it should be as training wheels, a structure through which great capabilities can be built, before throwing off the shackles of a rigid, top-down framework. If it was really true that SAFe is a transitionary framework, why does the SAFe model not include anything about the transition away from it?

In reality, most organizations don't need SAFe. They're not so big that they need such an extensive solution. SAFe is a comfort blanket for organizations used to traditional, slow, heavyweight, command-control structures. Your projects and products actually aren't that big — and if they are, then that's the problem, not the management process.

Fundamentally, SAFE tends to ignore, or encourages management to ignore the possibility that those closest to the work might be the best equipped to make decisions about it. Scale the work down, not the process up. SAFe should fit the delivery model to the organizational structure, rather than forcing the organization to adopt new ways. Unfortunately, SAFe gets treated as most frameworks do; Proposed by, and implemented by people who don't really understand the benefits and challenges it brings. It's better to not do it all in that case.

Thanks for reading my blog. If you have thoughts on it, I'd love to hear from you in the comments or in a direct message. Liking and sharing the article is highly appreciated! I write about agility, software development, cognitive biases, change in organizations, team dynamics, and my observations in over ten years of product management. Follow me if you're into that sort of stuff. Want to become a member?