The Major Problems with SAFe
Putting the Focus on Frameworks Rather Than Outcomes
In my post about Product Thinking vs. Project Thinking, I highlight the differences between the two mindsets. Fundamentally, project thinking is about outputs and timelines while product thinking is focused on outcomes and solutions. And while there are instances where project management is critical, applying project thinking (or project management) to the entire lifecycle of product development is incredibly problematic.
And that is what I see with SAFe (Scaled Agile Framework if you’re unfamiliar with the term). While its intentions may be good — and there may even be companies or situations where it is helpful — as a whole, SAFe is the wrong answer. It may be a project management dream come true, but the issues with SAFe are numerous and significant.
Practical Problems
From a practical perspective, there are several issues.
Layers of Process. SAFe adds layers of process to product development that don’t need to be there. For example, Program Increment Planning (PI) is a formalized process by which all teams plan out and discuss their deliverables for the next quarter and align with all other groups. It is a formal meeting that takes place for several days. Now, this may sound good on its face because communication like this is a good thing, as is the planning and understanding that can result from it. But the process by which it is accomplished makes it overly burdensome in practice and takes away a team’s agility both by forcing the set meetings at the set time, and by locking in many of the commitments of those meetings with little wiggle room after the fact.
By putting so much focus on the structured meetings and process, it also takes away the emphasis on continual learning. Discovery shouldn’t be happening once a quarter, but continuously. Same with prioritization. Locking in these important aspects of product development to be done only at specified times does a real disservice to teams.
Generally speaking, if you look at the diagrams and processes outlined for SAFe, you can easily understand why the entire thing is overly burdensome and complex. Rather than simplifying or streamlining, it bogs down the entire development cycle with unnecessary processes.
Layers of Management. In addition to the heaviness of the process, SAFe also add (or keeps) layers of management throughout the development process. From the development teams to release train engineers to epic owners and beyond. The many layers of management reflect the many layers of process, complicating the overall workflow and adding a lot of cooks to the kitchen. While this may look incredibly appealing to managers, centralizing a lot of control at each level, the reality of having so many hands involved is often confusion and slow-downs as everyone steps on each other’s toes and each group may have different ways of doing things.
Additionally, it removes too many teams and people from the impact of their work. Instead of having a product owner or team responsible for features, and another layer responsible for business communication and yet another layer responsible for market needs, a development team should know and understand all of those facets. How can anyone be expected to truly deliver value to users beings so far removed?
Stagnation. In some regards, SAFe could be considered remedial agile. I never like to get into the debates about what is agile and what isn’t — they tend to be unproductive and pointless — but SAFe isn’t about scaling agile for large organizations in the sense that it takes agile principles and applies them to large groups. Rather, it is about beginning to apply some agile principles to large organizations that have no other agile experience. This could be great for a large company that is steeped in processes and waterfall methodology. But if SAFe is the end rather than a stepping stone in the process, it will ultimately result in stagnation of teams and products.
Philosophical Problems
From a more philosophical perspective, the issues are even greater.
Focus on Methodology. SAFe begs for the focus to be on the methodology itself. With the heavy processes and prescriptions, it’s almost necessary. This, of course, isn’t unique to SAFe. It is a fundamental issue with many methodologies: the process becomes an end unto itself. Scrum has the same problem, where the focus too often drifts from creating value for users to optimizing the development process, as measured by story points, velocity, etc. Optimizing may be important, but it is a means to an end, not an end itself.
Lack of Autonomy. Second, rather than giving autonomy to teams, SAFe removes autonomy from teams and ties them down often to lists of features. Part of PI often involves determining the features of the next 3 months. That isn’t necessarily a bad thing, but it becomes an issue by locking a team into features rather than outcomes. SAFe also ties all teams together into release trains and other processes. Rather than allowing a team to function independently — experimenting, releasing, and learning — teams are all formally tied together and dependent on each other. Decisions that may have otherwise been able to be made independently are now constrained by the process.
Lack of Agility. The purpose of agile is to allow teams to be, well, agile. That means allowing teams to design, build, test, learn, and iterate. The focus is on outcomes, which may or may not be achieved by certain features. Having agility means being able to shift priority or feature in order to better deliver the outcomes. It allows teams to learn from their experiments and then make adjustments as they go. This type of agility is the antithesis of the planning and processes imposed by SAFe and project thinking in general.
Hiding the Real Issues. Finally, rather than addressing the real underlying issues, many of which are described above, SAFe can cover them up with its processes and prescriptions. If an issue an organization faces is too many interdependencies among teams, SAFe’s prescription adds lots of planning and coordination between those team prior to having work begin. That is great if those dependencies can’t be decoupled. But what about organizations where they can and should be decoupled? Rather than tackle the hard work of reducing complexity, we paint over it with more meetings and processes.
That includes complexity from a product as well as from a people structure. If there is too much hierarchy within an organization, SAFe realigns it, but doesn’t fix it. The real issue is likely too much structure already, and the solution may be to flatten the organization so that people can actually have ownership of their work.
Finally, rather than fostering better communication up and down the chain, SAFe adds too many layers. If the real issue is executive communication and buy-in, SAFe may seem like a good answer with its processes and pyramid structure. But it doesn’t address the underlying issue, which may be a lack of understanding or a lack of real involvement from executive leaders.
Theoretically, SAFe is meant to solve some real problems for teams and organizations. Unfortunately, it fails in too many regards in practice. By overburdening teams with heavy processes and prescriptions, it ultimately takes away too much autonomy and agility. Rather than supporting product development teams, it asks that product teams support all the layers of management above. This isn’t unique to SAFe, and managers too often have their roles backward in thinking their teams are meant to support management rather than the other way around, but it is ingrained in the process.
SAFe is another embodiment of project thinking. While product thinking is the solution for product development, it is easy to slip back into a project mindset where the goal is to map out features and outputs and then simply focus on delivering them on a specific timeline. And that is what SAFe does: it puts the focus on outputs rather than outcomes. Success is measured on committing to features and then delivering them throughout the quarter. Of course, this is great if you’re right about all your guesses ahead of time, but that won’t generally be the case. And when processes take the place of outcomes, it’s not good for teams, organizations, or users.
Ultimately, the focus should be on the users of our products and services. We should eliminate as many processes and constraints as possible to better allow our product teams to deliver value. That means reducing complexity and organizational overhead, not adding to it. Get the right people and the right goals, then get things out of their way. Principles will scale to any size, so get those right and you’ll find the right scaled structure.
You can follow me on twitter here:
Subscribe to my new product newsletter here:
You can check out our product podcast here:
