Is SAFe® (Scaled Agile Framework®) not Agile?

There has been some amount of criticism about SAFe. Some Agile experts are not hard-core fans of SAFe. They say there are hundreds of pages, hours of videos, several different training courses, and more. This makes SAFe more complicated, and bureaucratic than the Agile Manifesto recommends. They also have this opinion that SAFe is so heavy, that maybe it is not Agile at all.

Let us dig deeper

Most of us started our Agile journey with one framework, and that is Scrum. Scrum is simple to understand with some immutable principles & guidelines. It is a lightweight framework suitable for small self-managed teams. For a long period, our idea of Agile was only Scrum.

When more and more organizations and teams adopted Agile, it required scaling in a big way. The entire organization had to be in the process, not just a few self-managed teams.

That's when SAFe came to the party. It provided us with a unique framework and guidelines for the entire organization, including the chief executives, to be part of the process. It is for large-scale software development teams of 50-125 people on multiple projects but wants to still adopt the best Agile practices, despite their size. When the scaling was done for the entire organization, it needed more complex processes and guidelines for obvious reasons. It meant having multiple readiness meetings, planning meetings, checklists, etc. This was perhaps overwhelming for people. And probably that is the reason to be perceived that SAFe is not Agile.

Let us look at some of the Agile principles and how they are embedded in SAFe

• 1Individual interactions over Processes and Tools:- If you look at the basic configuration of SAFe, i.e., Essential SAFe big picture looks complex showcasing the different roles involved, frameworks like Scrum, XP, Kanban, and core competencies. So, the perception is made that SAFe is process-heavy. The foundational unit in SAFe is the Agile team, with the option to use Scrum, XP, or Kanban. SAFe also adds additional interaction events to ensure collaboration happens across the teams and not just within the agile teams aligned to a common goal and work with a synchronized cadence.
• 2Working Software over Comprehensive Documentation:- SAFe reemphasizes and uses working software as the means of progress toward achieving the objectives. System Demo and PI Demo confirm this theory.
• 3Customer Collaboration over Contract Negotiation:- SAFe supports and has built-in events to increase Customer Collaboration. The roles like Product Owner, Product and Solution Management, and the agile teams collaborate with the Customers to develop and deliver products or solutions. Also, "SAFe Managed-Investment Contracts" provides an approach to deal with how organizations engage suppliers, which is more in line with agile ways of working.
• 4Responding to Change over following a plan:- One of the worries people dislike SAFe might want to point out is how SAFe deals with the business changes, as the common pattern for a PI (Program Increment) is a time box of 4 to 5 sprints. The ability to change when required is built-in SAFe. It helps to balance the organization's need to run the business. We cannot run a business with a vision, roadmap, or plan that is limited to two weeks.

Why is the perception of SAFe not being Agile?

Layers of Process: One viewpoint is that SAFe adds layers of process to product development that are not required.

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.

It may appear good on its face because communication like this is a good thing, as is the planning and understanding resulting from it. But the process by which it is getting achieved makes it overly troublesome in practice and takes away a team's agility both by forcing the set meetings at the set time and locking in many of the commitments of those meetings with little wiggle room after the fact.

Layers of Management: The pundits also say that SAFe also adds (or keeps) management layers throughout the development process, starting from the Development Teams to RTEs to Epic Owners and beyond. The many layers of management reflect the many layers of process, confusing the overall workflow.

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 unsettling, and slowdowns as a lot of people are involved in the process. Each group may have different ways of doing things.

For the above 2 points, let's be honest here – typical Agile enterprise transformations are complicated! It stands to reason that most enterprises will need a reasonably large framework to leverage when seeking full enterprise agility. Designed specifically for large enterprise, SAFe addresses the critical enterprise-level challenges such as:

• How business strategy is getting translated into executable actions at the development team level
• How to ensure seamless collaboration between IT and business
• The lean economics
• Funding
• Pull-based model of bringing the work to persistent teams
• Consistent estimation approaches across all teams

Lack of Autonomy and Agility: There is also a viewpoint from critics - rather than giving autonomy to teams, SAFe removes autonomy from teams and ties them down often to lists of features. Part of PI usually involves determining the features of the next three months. That isn't necessarily bad, 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. The process now constrains decisions that may have otherwise been able to be made independently.

Also, having agility means being able to shift priorities or features to deliver outcomes better. It allows teams to learn from their experiments and then make adjustments as they go. Does SAFe allow this? The pundits ask.

Now, you could still have a cross-functional, self-managed team at the Team level. The iteration starts with a planning meeting where the team decides what user stories they can deliver by the end of the iteration. Each day, the team discusses their progress and demos to the Product Owner at the end.

It is to ensure they have delivered what is needed. They then get together to retrospect where they can improve for the next iteration before starting the cycle again with a new Planning meeting. All of this is under the guidance of a Scrum Master who makes sure the team works smoothly.

In the context of SAFe®, you have multiple Agile teams working independently but in sync. By implication, all teams need to have the same Sprint start date, end date, and duration. This is a key tenet of the SAFe® framework and is referred to as 'Develop in Cadence' in the big picture.

Thereby, the basic atom comprising the SAFe® molecule is a Scrum team. The aggregated increment of multiple Scrum teams is the 'feature' planned and agreed to be released with the Product Owner (PO) beforehand.

Too many templates: Some say there are too many templates, and reports prescribed in SAFe. Does it stick to the Agile principles? While training and coaching teams on Scrum or Kanban, we often come across people who ask if we have any ready templates that they can use. For every development process, Scrum has given the independence to the teams to use whatever suits them.

But, teams often look for something to begin with. What SAFe has done is to provide us with all the templates that may be required to kick-start. You are free to customize or create your own as you see fit for your teams.

So, Is SAFe® Agile?

The Agile Manifesto at no place mentions the ideal team size for the adherence of its principles. Hence, it would be argumentative to state that delivery in Agile cannot scale. Also, the principles do not state 'how' to practice Agile going over the Agile manifesto. Nor do they recommend any best practices. Agile principles guide toward the end goal. They can be taken to scale, encompassing bigger numbers of representatives to collaborate creatively to achieve a common goal.

SAFe is a fantastic tool for managing large-scale programs consisting of multiple teams working on large epics. It does have some unusual terms. But the terms map to common-sense ideas, and their language is easy to adopt. Scrum patterns at the team level roll up to the program level and somewhat to the portfolio level. Teams that have already mastered Scrum have an easier time adopting SAFe.

SAFe's top-level diagram is incredibly neat and shows every nook and cranny of a robust framework. Some ideas might bother me in SAFe, and I tend to adjust them, but the overall framework is strong, well-planned, and easy to follow.

SAFe might not be the ONLY solution to scale. There could be other scaling frameworks that might better work for your organization. No matter which framework you choose, Agile remains an inert, lifeless set of ceremonies without an Agile mindset. The real question should be, is your Organization Ready for an Agile mindset? Are your executives, and managers ready to unlearn the old patterns of management behavior?

Suppose everyone in the organization was to understand and practice what the Agile Manifesto recommends. In that case, the organization might very slowly evolve to the effectiveness that real Agile provides. Remember, it is a journey, and no framework solves the problem, and people do.