Scaled Agile Framework (SAFe): The Ideal Way to Apply Agile Principles

SAFe - Scaled Agile Framework

Scaled Agile Framework (SAFe): is it that perfect?

It seems that Agile software development has been around forever, but in fact the Agile Manifesto was only released in 2001. That’s a pretty good sign that the Agile movement has achieved its goals. It shifted the balance of power and responsibility from management to developers.

Today, the Scaled Agile Framework (SAFe) framework is an attempt to apply Agile practices on a larger scale. However, while it may seem like a logical extension in principle, scaling agile has been criticized by longtime Agile practitioners like Ken Schwaber.  

To understand the critique of SAFe, we need to begin by looking at what it really is, what the four levels of the Scaled Agile Framework are, and how it compares to Scrum. Then, we can discuss each major problem highlighted by critics, the available solutions, and how Panaya’s Release Dynamix [RDx] fits into the picture.

Achieving Agile


What is SAFe (Scaled Agile Framework)?

AFe applies the concepts that all Agile frameworks have in common, as laid out in the twelve points of the Agile Manifesto, on an enterprise level. Among these twelve points are:

  • Prioritizing customer satisfaction by continually delivering software of value.
  • The changing nature of stakeholder requirements.
  • Working in short, fixed cycles.
Scaled Agile Framework

The SAFe framework takes those key elements of the Agile methodology and translates them into nine new principles:

  1. Understand the economic and business value of a project.
  2. Make decisions using a systematic approach.
  3. Plan for potential changes.
  4. Build products in small increments.
  5. Set realistic objectives and deadlines.
  6. Limit batches to the smallest possible size.
  7. Work at a constant rate (cadence).
  8. Understand the true needs of stakeholders.
  9. Decentralize the decision-making process.

Building on these foundations, the development process for software-based projects can be effectively centralized across large enterprises and controlled by their management structure. As a result, they can plan for the long term, synchronize and coordinate efforts across the organization, and achieve ambitious time-to-market goals.

SAFe vs Scrum

Consider DevOps as a way to address the issue. It marries development to operations by automating common operational tasks via written code. DevOps practices include test automation, distributed version control, and continuous integration, delivery, and deployment.

Increased Technical Debt

Technical debt is one of those things that is hard to define. Yet, most of us recognize it when we see it. In the context of this article, let’s say it is the accumulated build-up of unresolved issues over the lifetime of a project.

In a SAFe environment, the responsibility for resolving technical debt is centralized in the organization’s management. This centralization can be highly beneficial for certain types of technical debt (caused by market pressures or corporate policies regarding time, resources, and budget allocation, for example) that can be resolved by a high-level, top-down approach. However, centralization is not a good approach for technical debt that originates at the team level.

This type of debt has highly specific causes (such as dev teams that don’t understand the long-term consequences of short-term decisions) or arises due to unstable teams with a high turnover rate. The organization’s management must take an active role in resolving such localized technical debt. If they don’t, then a larger, more intractable debt problem is created and it becomes more toxic over time.

The SAFe Solution – Agile principles

The best way of dealing with this type of technical debt is to follow Agile principles. For example, delegate problem-solving decisions back to the teams developing and testing the software. Give these teams the power to set their own deadlines and measure their output velocity. They will feel responsible for their work and be able to deal with problems as they arise. A culture of honesty and openness should be created, encouraging individuals to identify, assess, and fix technical debt and any related issues.

Management can play an important role in dealing with technical debt. This might include, for example, writing standard acceptance and exit criteria with a clear definition of “done” applied consistently across all projects. Management should also aggregate data from individual teams and create online systems that make this data visible to all.

Normalization of Story Points

Estimating how long it takes to complete a single task is a problem that has never been solved. The traditional solution has been to try to calculate the number of workdays needed to implement a single user story, indicating the absolute effort required for one person to execute a given task. A project manager who estimates that the effort involved is one workday, for example, might assign two developers and complete the task in half the time. Nonetheless, the overall effort calculation remains one workday.

One common criticism of effort-based estimation is that it does not take into account the complexity or difficulty of executing a task. Instead, the Agile world (including SAFe) has adopted story points, which take into account additional factors such as effort, difficulty, complexity and risks. Story points are expressed as a value on an abstract scale, such as a sequence of numbers, T-shirt sizing (small, medium, large, etc), or the Fibonacci sequence. For example, you can use a scale of 1 (easy) to 5 (hard), with each number translating to one workday of effort. So, a task that takes one workday of effort is equivalent to one story point.

In a SAFe environment, the defining story points are placed in the hands of management. As a result, critics say, the scale used to measure effort becomes more abstract and basically useless. It also makes individual teams feel that they have no control or accountability over the development process.

The SAFe Solution

One of the most important ways to address this issue is to give the development team member the autonomy and trust they need. This involves giving them the authority to determine their own metrics and self-govern their actions. Management should also educate multiple teams on how velocity should be used as a guide and not a measure of productivity and success. Management can again play an important role here, by educating and training the workforce to understand modern, Agile project management practices.

Making SAFe Work for You

Agile development started as a grassroots initiative by developers for developers. One reason for its rapid adoption was that it decentralized decision-making, handing developers the autonomy to make decisions and act on them in ways that made sense.

SAFe is an attempt to learn from the Agile movement and optimize project management, coordination and decision-making by centralizing them. One of SAFe’s many benefits is its value streams management, enabling a deep understanding what to develop and the optimal timing of any release.

As with many prescriptive frameworks, many of the problems with SAFe stem from trying to apply it too rigidly and not adapting it to the needs of a given organization. Ultimately sourcing the right solution for the job is more important than any religious adherence to the principles of any single method.  

That’s why Panaya’s Release Dynamix (RDx) provides tools to make your Agile and SAFe deployments work for you. Unlike other release management products, RDx was built from scratch to manage large-scale Agile enterprise delivery. It lets you monitor the entire development process and manage your portfolio, project and release train, value trains, requirements, tests, and risks. It also collects data, displays metrics and provides dashboards for reports with key insights and analytics.

Panaya’s Release Dynamix can help you implement the elements from both Agile and SAFe that best serve your specific purposes and goals, be it on a program, project or portfolio level.

Frequently Asked Questions

What is Scaled Agile Framework methodology?

Scaled Agile Framework (SAFe) was developed to adapt Agile processes for use in large enterprises. It coordinates the individual teams, placing them in a larger context, and allows the company to apply Agile workflows on a much wider basis to guide development coherently toward business goals.

What do all agile frameworks have in common?

The twelve principles laid out in the Agile Manifesto:
1. Prioritizing customer satisfaction by continually delivering software of value.
2. Accommodation to the changing nature of stakeholder requirements, even late in development.
3. Working in short, fixed cycles for frequent delivery of software (i.e., Sprints and iterations).
4. Collaboration between business stakeholders and developers throughout the project.
5. Support, trust and motivation for the people involved in the various teams.
6. Face-to-face interactions are more successful, efficient and effective.
7. Working software as the primary measure of progress.
8. Consistent, sustainable development pacing, which can be repeated for each release.
9. Attention to technical detail and design quality.
10. Simplicity – develop just enough for now.
11. Self-organizing teams, with decision-making powers, will take ownership and produce high quality architectures, requirements, designs and products.
12. Regular reflection on how to become more effective, followed by the needed behavioral or operational adjustments.
From a bird’s-eye view, the Agile methodology involves breaking large projects into smaller fragments, iterative repetition and short release cycles. Cross-functional teams operating according to Agile principles constantly and quickly learn, improve and adapt throughout the software development or upgrade project.

What are the 4 levels of Scaled Agile Framework?

The four levels of the SAFe framework reflect the application of Agile principles at increasing levels of complexity and hierarchy layers within an organization.
1. Team Level – A few development teams working together coordinate iterative Agile development under the eye of a Scrum Master, with work divided into Sprints.
2. Program level – Many development teams, business users and other resources come together for an ongoing solution development mission, usually with a definitive start and an end date. An Agile Release Train (ART) coordinates the teams, roles and activities needed to incrementally deliver a continuous flow by eliminating unnecessary handoffs and intermediate steps.
3. Large Solution Level – Two or more ARTs get together to create large and complex solutions, coordinating and managing their interdependent Agile processes in what is known as a Solution Train.
4. Portfolio Level – Bringing Agile methodologies to management practices, so that portfolio execution can be more easily aligned with enterprise strategy. Multiple SAFe portfolios may exist across a single enterprise.

Achieving Agile

Start changing with confidence

Book a demo
Skip to content