There’s a lot to unpack with SAFe, not the least of which are claims it’s too unwieldy to be useful. Here’s a look at what SAFe is, and isn’t, as well as best practices and strategies to get the most out of it no matter where an organization is on its journey to modern software development.
The history of software development methodologies impacts SAFe metrics
It’s safe to say that before 2001, software development was a hodgepodge of “get it done” processes that mostly cascaded over teams, which encouraged silos and discouraged collaboration and iteration.
(Despite the passage of over 20 years, one could argue that software development *remains* a hodgepodge today as most large enterprises use several methodologies in different teams across the organization, but I digress…)
The Agile Manifesto, published in 2001, was a revelation to developers and the organizations that employed them. People more important than tools? Change the plan if it’s not working? Collaborate with customers? All those ideas were revolutionary at the time, and certainly represented the genesis of software development today. Agile’s 12 principles include everything from the idea of continuous delivery to a minimum viable product, concepts that are commonplace today but were practically unheard of at the time. According to the 2022 State of Agile Report, 80% of companies use Agile today either by itself or in combination with other software development methodologies.
Not long after the Agile Manifesto, the book Lean Software Development was published. Lean software development borrowed “lean” ideas from manufacturing and married them to Agile and broader software creation. Lean and its seven principles are now widely seen as an extension of Agile software development, and “lean” and “Agile” are often mentioned in the same breath.
Agile has two other frameworks besides lean – Scrum, which is project-management focused, and Kanban, which is a way to visualize workflows. Scrum adherents work in sprints (usually of two-week duration) with an overarching goal of breaking down large projects into small parts that can be completed independently of one another.
Like other Agile frameworks, Scrum emphasizes fast software delivery, transparency, and an openness to change as circumstances require it. Kanban, on the other hand, is a way to literally visualize work, with a focus on eliminating works-in-progress, increasing flow (or development velocity), and continuously improving. Scrum and Kanban are not “either-or” propositions and can certainly be used together as part of an Agile or DevOps effort.
We’d be remiss if we left out DevOps, which is a methodology that brings development and operations together, and in some cases the entirety of software development as in DevSecTestBizOps, potentially ad infinitum. DevOps came into being around 2014, and is widely used alongside Agile, Scrum, Kanban, and even SAFe.
To sum up, Agile, Lean, Scrum, and Kanban could all be present in an organization following the Scaled Agile Framework, but again it’s important to remember that, in many organizations, software development continues to be more than a bit of a collection of frameworks, methodologies, practices, and processes, so don’t be surprised if DevOps and even Waterfall or iterative software development are also present.
What is the Scaled Agile Framework?
SAFe is made up of a number of different values, principles, and configurations.
Key SAFe values
The Scaled Agile Framework has five core values: alignment, built-in quality, transparency, program execution, and leadership.
Alignment is a way to make sure everyone in the organization is on the same page about projects and business goals. Alignment happens thanks to regularly scheduled planning meetings and times for retrospectives and check-ins.
Built-in quality aims to hand control of “the definition of done” to the people doing the work. In order to ensure Agile teams are also quality-focused, SAFe recommends focusing on five metrics specifically, including flow metrics, quality of the design/architecture, code, system, and release.
Transparency is a way to make sure no one is surprised by delays, bottlenecks, or the size of the backlog. Transparency is part of the greater Agile mission of continuous improvement, and one way teams can prioritize transparency is through regular retrospectives or what SAFe refers to as “inspect and adapt rituals.”
Program execution is described as “at the heart of SAFe,” and basically reflects a strong emphasis on quality efforts throughout the software development process.
The final core value, leadership, emphasizes the need for Agile and Lean management involvement. Without that, creating an organization adept enough to change and pivot as necessary would be impossible.
The SAFe Principles
10 SAFe principles together act as an organization’s North Star for this process.
Take an economic view
Although it’s vital for organizations and teams to move quickly, it’s also key for everyone involved to understand the economic impact of business decisions and tradeoffs. Each development value stream must operate independently, have its own budget, and stick within any internal or external constraints.
Apply systems thinking
Software development is a complex undertaking with many moving parts. Using the concept of systems thinking, organizations are encouraged to look at the biggest possible picture rather than the individual pieces in order to have clarity about what’s happening and be able to support change. The SAFe principles stress that systems thinking should apply to both the products and the teams.
Assume variability; preserve options
In developing software, it’s important to keep all the options open for as long as possible. This SAFe principle warns teams against making hard and fast decisions early in the process that, if later proven incorrect, will take too long to fix. Instead, the idea is to have several designs or plans in the works for as long as possible in order to be able to pivot quickly as needed.
Build incrementally with fast, integrated learning cycles
In DevOps, this principle is commonly known as “fail fast.” The idea is that shortened development cycles or sprints should result in shorter feedback loops, which in turn will lead to improved overall development and increased knowledge and understanding of both processes and customer requirements.
Objectively evaluate working systems to create milestones
Regular, clear-eyed check-ins on projects in development are non-negotiable and critical to ensuring a team delivers customer value. Teams have many opportunities to conduct these evaluations as part of Agile-Lean development.
Make value flow without interruptions
Every team operates best when “in the flow” but achieving that status on a regular basis can be challenging. To know if a team is in the flow it’s critical to measure, assess, and address impediments without delay regularly.
Apply a cadence, and synchronize with cross-domain planning
This is a long way of saying it makes sense to have pacing when it comes to software development and working cross-functionally in an organization. A great example of applying cadence are Scrum sprints.
Unlock the intrinsic motivation of knowledge workers
SAFe believes employees are motivated by far more than just a paycheck, and there is certainly plenty of market research to show that developers want to do work that matters. A 2022 Hired.com survey found devs are highly motivated to use their skills to improve healthcare, access to education, and climate change. One-on-one meetings are an ideal opportunity to explore passion projects and determine how to incorporate them into the broader team.
Decentralize decision-making
In order to move more quickly it is important to make decision-making local and straightforward. But SAFe acknowledges not all decisions can be made on the fly and suggests the creation of a “decision-making framework” so everyone has clear expectations of when management needs to be involved.
Organize around value
This principle encourages organizations to embrace the principles of business agility and achieve literal agility, as in the ability to quickly pivot and respond to market requirements. SAFe recommends organizing around development value streams rather than by business group or department.
Why SAFe?
In the rather complex and ever-changing world of software development, the Scaled Agile Framework can be seen as a way to formalize Agile and Lean principles while at the same time breaking them down into steps and processes organizations can implement. The inclusion of the word “Scaled” in the name of the framework isn’t an accident – SAFe is best implemented by teams looking to take the next steps and grow.
SAFe represents an extensive and some would say opinionated collection of best practices for getting the most out of Agile in an evolving organization. While wildly popular, it’s important to note SAFe does not exist in a vacuum. It is regularly in use alongside project management tools like Jira, but could also benefit from pairing with value stream management, as it’s impossible to make a sweeping change (like embracing SAFe) without an organization actually being able to baseline where it is now, and where it wants to go. A number of key SAFe principles – notably tying business value to development, the prominent role of flow, an emphasis on business agility, and more – are central to value stream management as well and the deeper an organization dives into the frameworks the more it will benefit from metrics and measurement.
Why Agile and SAFe continue to dominate software development
There are likely more than 100 flavors of Agile exist in the world, including that popular version “Agile and” (meaning a team practices Agile alongside other methodologies). It remains widely adopted—and for good reasons. According to the 2022 State of Agile Survey, 52% of teams are using Agile to accelerate delivery while 44% like the predictability and 31% said it lowers risks. But when asked what’s most important about application development and delivery, 54% said company goals and 43% said end customer satisfaction, all clear signs that it is critical to align software development with the creation of business value.
To a great degree, SAFe, the most popular Agile framework, is also the mechanism for helping Agile bring about key organizational changes necessary to stay relevant in today’s tricky economy and markets.
What are the disadvantages of SAFe?
As is no doubt evident by now, SAFe is a lot: of steps, values, frameworks, processes, reorganizing and rearranging. It’s so much, in fact, that its detractors say it can be too easy to get caught up in the “rules” and miss the bigger picture of the importance of aligning software development to what matters most in the organization. We agree SAFe is a lot to process but, it is possible to start small and to even pick and choose what works best for the organization. If nothing else, teams can point to the long history of “Agile and” to explain the reason for embracing some, rather than all, of the SAFe principles.
How to get more out of SAFe
Clearly, SAFe can help growing teams scale their Agile practices successfully, but there are some bigger-picture decisions that can help make the process less painful.
- Start where you are. Before making any organizational changes, it’s important to know, exactly, what works and what doesn’t, in the developer teams, of course, but also across the organization. The only way to do that is to measure *everything* from flow velocity to technical debt, OKRs, number of coding days, and works-in-progress.
- Map it out. Use the metrics data to ensure every part of the organization is aligned around what matters most. Are teams creating value, or going off on a potential features tangent? Does the business side fully understand potential development roadblocks? Is it possible to make a case for more headcount or resources? Without answers to those and other questions it doesn’t make sense to embrace SAFe or any other sweeping organizational change.
- Do the research. Read the books, see what the pundits say (and here as well), consult the customer stories, or consider some SAFe training.
SAFe, Agile, and metrics: secret weapons for successful teams
SAFe makes Agile transformations at scale a reality, applying lean thinking in a way that helps minimize delays when delivering software. Any organization looking to grow quickly but efficiently should leverage SAFe to get the most out of Agile methodologies and modern software development. But scaling organizations also need a metrics measurement program in order to know where they started and to agree on the direction they’re headed. Without a value stream management solution like Allstacks to help put data into context and align engineering work to strategic business initiatives, it’s difficult to get the most out of SAFe.
You need a holistic view of how value is being delivered from top-to-bottom and left-to-right in order to connect the dots. You also need visibility across teams, tools, and data sources. It all comes down to accelerating the flow of value and identifying areas to improve so that value gets into the hands of customers sooner.
Luckily, SAFe, Agile, Lean principles, and value stream management work beautifully together – and when technical leaders need to make decisions that impact the business, understanding what “good” looks like to quantify success is key. That’s where the right metrics can establish a baseline for benchmarking engineering performance and quantify engineering productivity in a way that relates to the business. It also helps you understand how your teams stack up against industry standards so that you can remain competitive in the market at-large. Additional metrics frameworks such as Flow, SPACE, or DORA are also popular for this reason and can be great starting points for organizations undergoing transformation that haven’t yet “turned the lights on” with their engineering data. When SAFe, Agile, and meaningful metrics all work together in unison, they act as a secret weapon for growing organizations to improve software delivery in a scalable way and empower teams to be successful.
Written By: