If you touch software development in any way, you know all too well about today’s imperative to deliver higher quality software faster.

The reasons to meet this goal are plentiful, and teams no longer need to buy in on speeding up their processes. But knowing what you need to do is one thing. Knowing how to achieve that goal is quite another.

So how can testing and development teams bring higher quality software to market faster? Numerous approaches have emerged in recent years to help answer this question. One of the most talked about approaches today is SAFe, aka the Scaled Agile Framework. But what exactly does SAFe entail? And what are the pros and cons of using it compared to agile? Here’s what you need to know.

A primer on SAFe

SAFe was developed in 2011 to help software development teams bring better products to market faster. Based on a combination of agile and lean principles, SAFe calls for close collaboration and alignment across teams and aims to centralize decision-making. SAFe offers multiple configuration options depending on the size of the team and includes three levels: Team, Program and Portfolio.

Ultimately, SAFe allows organizations to visualize the big picture by mapping roles, responsibilities and activities required for software development. In doing so, it helps organizations answer questions about a software development initiative’s alignment with business objectives or its predictability. It also helps identify how to measure success and pinpoint opportunities to improve workflows.

The impetus behind SAFe was to make agile principles scalable for large enterprises, and the framework’s ability to centralize decision-making and bring a top-down mindset to a typically bottom-up process accomplishes that goal.

Pros of adopting SAFe

The biggest benefit of adopting SAFe is the opportunity to tap into a relatively lightweight framework that creates efficiency in software development while maintaining the centralized decision-making necessary at the enterprise level. Essentially, SAFe extends the idea of agile beyond the front lines of software development to software leaders who must answer higher level strategy questions.

Specifically, because SAFe was designed to maintain a big picture view of software development, it can easily handle a coordinated strategy for large-scale and complex projects with teams that number into the hundreds. However, because it is rooted in agile and lean principles, it remains more efficient than traditional approaches to software delivery.

SAFe is particularly beneficial for organizations that need to work across teams, as its centralization makes multi-team coordination possible. In this scenario, it allows for standardized processes across teams and helps avoid obstacles and delays that may pop up when different teams need to work together.

Another notable benefit of SAFe is its ability to help teams maintain alignment with business goals. This alignment can often get lost in agile environments that take more of a bottom-up approach, as developers and testers can sometimes lose sight of bigger picture business objectives. In contrast, SAFe’s top-down alignment and centralized decision-making helps ensure strategic objectives remain top of mind and that all decisions get made in support of those objectives.

Cons of adopting SAFe

Although SAFe brings many benefits to the table, it also comes with its drawbacks. For instance, many teams find that SAFe takes too much of a top-down approach.

SAFe provides additional layers of oversight, administration and coordination. These layers make SAFe particularly popular with larger enterprises, but somewhat ironically they make it resemble the waterfall approach that many teams are trying to leave behind. And where methodologies like scrum give more freedom to developers to identify and solve problems that arise due to different sprint cadences, dependencies, etc., SAFe calls for administrative roles to oversee multiple projects and coordinate those releases and dependencies. In taking this freedom away from developers and harkening back to a waterfall environment, SAFe can often slow down processes and limit flexibility compared to an agile environment.

Along the same lines, the bigger picture, top-down approach of SAFe removes front-line players, including developers, testers and product owners, from the decision-making process and even from one another. This distance can limit their understanding of the entire software development lifecycle and hinder their ability to conduct well-informed and collaborative planning sessions as a result.

Finally, the fact that SAFe emphasizes the big picture can often lead to longer planning cycles and more fixed roles within development cycles — two points that go against the ideas of delivering in short sprints to get new software to market faster and creating a continuous loop to ensure quality at every step of the way.

Will you play it SAFe?

At the end of the day, SAFe brings a lot to the table, particularly by making it possible for organizations of a certain size to take a more agile approach to software development. However, it’s clear that SAFe has several shortcomings of which teams should be aware and plan for prior to adopting the framework.

As with many methodologies, there’s no right or wrong when it comes to whether or not your organization should adopt SAFe. Rather, it’s all about educating yourself on your options as well as your organization’s unique needs so that you can determine the best approach for your team.