What are the 9 SAFe Principles?

"When discussing what Scaled Agile Framework is, we have to cover the fundamental principles underlying the framework itself.

Below we detail the 9 principles that form the bedrock of SAfe.

Principle #1 - Take an Economic View

Every person in the leadership chain - from executives, to managers, to knowledge workers - must recognize the economic impact of their choices.

Economics should inform and drive decisions at all levels. Poor economics is one of the most common drivers of failed solutions.

In order to take an economic view, you must:

Deliver early and often

Apply an economic framework

Delivering early and often has a direct economic benefit.

Unlike the Waterfall method - which delivers value only until the end of a development cycle - SAfe delivers value very early in the process and it accumulates over time. The longer the customer has it, the more value they’re getting out of it.

Because SAFe is rooted in Lean-Agile development, enterprises who use it embrace a model of continuous value delivery.

Applying a comprehensive framework allows teams to align themselves with the core economics of the system.

Best practices are to:

Operate within lead budgets and guardrails - allocating funding to long-lived portfolio value streams and implementing guardrails to guide ongoing spending decisions.

Understand solution economic trade-offs - recognize the 5 considerations that affect your decisions, such as the cost of labor and materials, the time needed to implement capabilities, the manufacturing cost of goods sold, the economic worth of the capability to the business and customer, and the uncertainty of your solution’s success.

Establish relationships between suppliers and buyers with mutually beneficial economics - either long-term considerations or mergers and acquisitions.

Principle #2 - Apply Systems Thinking

Systems thinking is a holistic approach to solution development.

And there are essentially 3 systems in SAFe.

The first system is the solution itself that you’re developing.

This means that developers need to understand how the system interacts with its environment and other systems surrounding it.

They also need to realize that optimizing a component may not optimize the system. A component can soak up resources like computing power or memory.

Also, continuous attention needs to be paid to interfaces and interactions to provide the highest value possible.

The second system is your enterprise.

The people, management, processes, and workflows that you use to build a solution (the first system) comprise a system of its own.

To optimize this system:

Leaders should cultivate an environment that encourages collaboration toward better and better systems.

Treat suppliers and customers as partners.

Eliminate silos and create cross-functional organizations to accelerate flow delivery.

The third system is the full value stream.

And value streams are fundamental to SAFe.

A great practice to optimize this system is value stream mapping, which allows you to see all the steps required. This lets you recognize the steps that take up the smallest portion of total time-to-market.

Through that recognition, you’re able to focus on eliminating any delays between steps.

Principle #3 - Assume Variability; Preserve Options

Variability is inevitable and unavoidable.

By assuming it will crop up, and preserving options, you’ll be able to remain flexible and in control.

The way to preserve options is with set-based design.

This approach allows developers to consider multiple design choices at the start of a project. And then, at integration-based learning points, they can evaluate the economic and technical trade-offs.

Over time, developers eliminate the weaker options and converge on the final design.

This keeps design options open for longer, assembles the best ones naturally, and produces high-value outcomes.

Principle #4 - Build Incrementally with Fast, Integrated Learning Cycles

Old methods like Waterfall have high investment costs that accumulate until the solution is finally delivered.

And this means value isn’t provided until every single feature committed is finally available.

But integration points change this.

Instead of choosing a single design and requirement choice that you must commit to throughout the development process, the solution is built incrementally in a series of short timeboxes.

These timeboxes build one on top of another - evolving the solution until it’s released.

What’s really cool is integration points can act like prototypes for testing the market and validating the usability of the latest release. This lets you choose an alternate course of action if you need to.

It also allows for faster learning thanks to more frequent points.

Principle #5 – Base Milestones on Objective Evaluation of Working Systems

Because the Scaled Agile Framework builds software in increments, every milestone contains requirements, designs, testing, and so on. So every milestone is an increment of value.

And because this is done routinely (which we’ll touch on in principle #7), it allows for regular evaluation.

At every integration point, the system can be measured, assessed, and evaluated.

This means: Stakeholders can be reassured their financial investment was worth it.

Testers can find all the hidden bugs and errors before they cause too big of a problem.

And developers can be informed about how well they’re doing.

Principle #6 – Visualize and Limit WIP, Reduce Batch Sizes, and Manage Queue Lengths

Your goal should always be achieving a continuous state of “flow” - moving new systems from idea to sales as quickly and smoothly as possible.

But there are a few things holding you back from getting there.

One of which is having too much work-in-progress (WIP).

A lot of WIP creates confusion, causes overload, and increases overhead.

There isn’t an upside to having more work than you can handle.

A tool like a Kanban board can help you visualize all the work that needs to be done and consciously “pull” just enough work at a time to move the project forward without getting overwhelmed.

Visualizing work this way also helps you identify bottlenecks and even recognize systemic problems you wouldn’t have noticed otherwise.

You should also try to reduce the size of each batch of work, such as requirements, code, tests, and any other work items.

Smaller batches move through the system more quickly with less variability.

And it’s a good idea to manage queue lengths.

According to Little’s Law:

“The long-term average number of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system.”

Basically, the longer the queue, the longer the wait.

Reduced queue lengths reduce delay and waste while improving flow.

Principle #7 – Apply Cadence, Synchronize with Cross-Domain Planning

Cadence helps developers focus on managing the variable part of solution development.

Synchronization helps you understand and integrate multiple solutions to find the best one.

Cadence can:

Turn unpredictable events into predictable ones.

Supports cross-functional coordination and regular planning.

Limits batch sizes.

Controls and regulates new work.

Provides scheduled integration points.

And synchronization can:

Cause multiple events to happen simultaneously.

Create cross-functional tradeoffs.

And provides multiple feedback perspectives.

Together, they help DevOps teams make progress in the face of uncertainty.

Principle #8 – Unlock the Intrinsic Motivation of Knowledge Workers

You don’t have to study motivational methods to unlock the intrinsic motivation of knowledge workers, the Scaled Agile Framework does it inherently.

SAFe and its principles are a system unto itself.

SAFe allows knowledge workers to:

Communicate across operational boundaries.

Use economics to make decisions.

Receive feedback quickly about the efficacy of a solution.

Take part in continuous, incremental learning.

Participate in a more productive and fulfilling solution development process.

The idea is that, at one point, if you don’t pay a developer enough money they won’t be motivated.

But after that is satisfied and time goes on, it may come to a point where money is no longer a motivator. But just as money won’t work to motivate them, neither will fear or intimidation.

What knowledge workers really need is autonomy. They need to feel and understand the mission and purpose for the work they’re doing, for the reason they’re working.

You may also provide minimal project plans or specific work, allowing them to self-direct while providing them with challenging requirements for completing the work they engage in.

Principle #9 – Decentralize Decision-Making

Decentralizing decision-making can reduce delays and improve the flow of product development. It can also foster faster feedback and smarter solutions.

This doesn’t mean all decision-making should be decentralized. There are plenty of strategic and far-reaching choices that have to be made by specific, select individuals or groups.

But decisions that are frequent, time-critical, and require local information should all be decentralized.

American technology consulting: ATC is a preeminent training provider, supporting professionals across industries to develop new expertise and skills for recognition and growth in the corporate world. ATC offers a wide range of services in training, learning, and development in technology and management fields developed to deliver high-value training through innovative and practical approaches. Please visit our website to learn more about our course offerings