What Is Scaled Agile Framework: 9 Principles
An outline of the principles of Scaled Agile Framework (SAFe).
Join the DZone community and get the full member experience.Join For Free
When answering the question “what is Scaled Agile Framework?” it helps to understand its principles.
What is Scaled Agile Framework?
Well, according to Version One’s 12th Annual State of Agile Report, “The Scaled Agile Framework (SAFe) is reported as the most widely-used approach to scaling agile, with nearly 1/3 (29%) saying that SAFe is the method they “follow most closely”.
The report also revealed that “52% of respondents stated that more than half of teams in their organizations are using agile practices.”
And get this:
70% of US Fortune 100 enterprises have Certified SAFe® professionals continuously delivering value on a regular and predictable schedule.
All that to say…
SAFe is super popular and very effective at delivering results.
We’ll dive into the 9 principles of SAFe in today’s post.
But before we do, let’s fully define SAFe.
What is SAFe?
SAFe is used by companies worldwide because of all its benefits to software development.
SAFe is short for Scaled Agile Framework.
It’s sometimes referred to as the SAFe model, the SAFe method, or SAFe software development.
But it’s officially known as simply SAFe.
SAFe is a fusion of Lean, Agile, and DevOps principles and practices into a cohesive, scalable, and configurable framework.
It helps small and large enterprises deliver products and services in the shortest time possible. It gives you a strong technological competitive advantage by guiding the roles, responsibilities, and activities in software development to their most productive means and ends.
What’s the History of SAFe?
It all started back in 2011.
January of that year a seminal book was published, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series), 1st Edition.
It was written by Dean Leffingwell and it described the “Agile Enterprise Big Picture” — a framework that visualized how to apply Lean and Agile to various levels of a business, from teams to programs to portfolios.
The concepts outlined in the book were drawn from practices and tools such as Lean, Kanban, Scrum, and Extreme Programming (XP).
This new framework was soon applied in major enterprises like IBM, John Deere, and Nokia.
The results were so exciting, Dean — with the help of Drew Jemilo — decided to create a business model to spread this framework to enterprises worldwide.
Later in 2011, they create Scaled Agile, Inc.
And that was when Scaled Agile Framework was officially born.
A training and certification program was launched soon after.
That was SAFe 1.0.
Today, it’s in its 4th iteration and has trained over 400,000 practitioners.
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, and 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.
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.
This means that value isn’t provided until every single feature committed is finally available.
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 cool is integration points can act as 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
The Scaled Agile Framework builds software in increments, every milestone contains requirements, designs, testing, and so on; therefore, every milestone is an increment of value.
This is done routinely (which we’ll touch on in principle #7) and allows for regular evaluation.
At every integration point, the system can be measured, assessed, and evaluated.
- 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.
- 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.
A few things are 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 any 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.
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.
- Turn unpredictable events into predictable ones.
- Support cross-functional coordination and regular planning.
- Limit batch sizes.
- Control and regulate new work.
- Provide scheduled integration points.
- Cause multiple events to happen simultaneously.
- Create cross-functional tradeoffs.
- Provide 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.
After that is achieved and time goes on, it may come to a point where the money is no longer a motivator; however, just as money won’t work to motivate them, neither will fear or intimidation.
What knowledge workers 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.
Decisions that are frequent, time-critical, and require local information should all be decentralized.
How to Implement Scaled Agile Framework in Your Business
Putting Scaled Agile Framework into practice in your business won’t happen overnight. You probably know that.
It takes the dedication of your team, organizational leaders, and top executives to make a new software development model work consistently for you and your clients.
Getting everyone on board isn’t easy when you’re doing it alone. That’s where we come in.
Published at DZone with permission of ATC Team. See the original article here.
Opinions expressed by DZone contributors are their own.