The Scaled Agile Framework (SAFe) is a foundational platform that allows Agile to be scalable for enterprise systems and software. SAFe is the most commonly used version of a scaled agile framework and offers the same benefit to companies as Scrum does to Agile teams. The goal then is to align development to further business objectives. Similar to Scrum, SAFe offers a flexible, evolving framework in which milestones are met to complete a larger project.
SAFe has become a well-loved resource for large enterprise companies whose teams share interdependencies. Its popularity is driven by its structured and methodical approach to project alignment and completion.
Based on agile principles, SAFe has five main components that it tackles: 1) architecture, 2) integration, 3) governance, 4) funding, 5) roles. It does this in three levels: Team, Program and Portfolio.
SAFe combines the knowledge base from proven successful agile methods to create a new platform for software development of enterprise programs.
Team Level Requirements
SAFe takes a multiple team approach to scaling for enterprise software. Many teams work interdependently with one another. But no matter the duties each team is assigned, every team is agile in nature.
As is characteristic of agile teams, each consists of 5-9 members working toward a programming goal. A Systems Team, also known as a Design Build Test (or D/B/T) Team, is responsible for the testing and delivery of software once every two weeks.
A two week period is referred to as a “sprint.” Each team works to deliver their part during a sprint using Extreme Programming (XP) techniques. Where SAFe differs from traditional agile is that teams are interdependent with one another, and sprints can occur concurrently.
One unique goal of SAFe is to create a perceived rhythm that synchronizes all teams progress. The objective is to promote reliability as opposed to variability in the team programming environment.
Program Level Requirements
An Agile Release Train typically consists of 3-5 teams working in sync on a piece of software development for a Program Iteration (PI). It is the primary vessel for delivering value during a PI. The PI is a larger unit of measurement within the program.
Where a single sprint has one team producing one piece of the software puzzle, a PI contains multiple teams who were timed to complete a sprint, synchronously. All of the development in a PI is subject to the Innovation and Planning Iteration (IP), which occurs at the end of the PI.
During IP, all of the development that occurred during the PI is tested and demonstrated and an Inspect and Adapt session occurs. In this phase of the program, developers research and identify improvements and causal dependencies.
At the Program Level, roles are defined as follows System Team, Product Manager, System Architect, Release Train Engineer (RTE), UX and Shared Resources and Release Management Team.
The Product Manager and System Architect
The Product Manager has complete authority over the content, while the System Architect is the design authority at the Program Level.
Release Train Engineer
The Release Train Engineer is a stakeholder in that they are the ScrumMaster of the Program Level. This person is responsible for progress during the PI, and making sure all team members are in alignment.
The UX Designer
This person is in charge of providing design elements to teams. These make up the user interface of the enterprise agile framework and overall user experience of the software.
The Release Management Team
The Release Management Team consists of people across many functions from development to marketing. They all have a part in ensuring that the release goes smoothly.
Portfolio Level Requirements
The Portfolio consists of multiple value streams collected together. It is connected to the overall enterprise software via themes like strategy, investment funding, program management and governance.
Each theme assists in overall budget planning for a period of 6-12 months. Large development initiatives, called epics, span across Agile Release Trains and assist in defining the development needed to realize themes.
Business epics are customer facing, while architectural epics are technology solutions not visible to customers. These types of epics are managed in a Kanban system.
Configurations of SAFe
There are several configurations of SAFe that businesses can choose from out-of-the-box to complete their enterprise software. They are defined as follows.
Essential SAFe is the basic configuration. Many businesses starting out with SAFe choose this configuration because it focuses on the most critical elements needed to be successful. It includes a Foundation, with Team and Program levels.
Large Solution SAFe
For industries like Government and Defense, that specialize in large, complex systems but do not require considerations of the Portfolio level – there’s Large Solution SAFe. This is the same as Essential SAFe with a Large Solutions Level added in place of Portfolio Level. At the Large Solutions Level, a Solution Train ensures value delivery of even the most complicated, large-scale systems.
This is the most common iteration of SAFe, often just referred to as SAFe. Portfolio SAFe is the structure defined above. It contains three levels Team, Program and Portfolio-Level requirements. During the Portfolio phase, budgets are defined with the help of epics and themes.
Value Stream – The 4th Level
There’s a fourth level SAFe framework sometimes used to scale enterprise solutions. This includes an additional layer of value streams between Program Level and Portfolio Level. This is most applicable during large system development, but can be applied to any enterprise system.
A value stream can be defined as the series of steps it takes to deliver value from the beginning of development to customer interaction. The flow is usually triggered by something, like a customer request. It ends upon delivery.
Full SAFe is the configuration that describes all configurations of SAFe in one package. It’s for very sophisticated large systems that might take up to thousands of people to develop. It comprises of Team, Project, Portfolio and Large Solutions – making room for value streams throughout the process.
Certification and Training
Several certifications are available for people considering using SAFe for their next large enterprise project. These assist in providing knowledge, training and resources for success. There are certifications available for developers at all levels of experience with SAFe. To learn which is best for you or your team, see below.
- SAFe Agilist (SA): This training is ideal for anyone looking to apply their agile principles in a SAFe environment.
- SAFe Practitioner (SP): SAFe Practitioner certification is a good multi-functional certification for anyone on the SAFe team.
- SAFe Program Consultant (SPC): In this training, you learn the skills necessary to be a program consultant in charge of furthering your company’s business goals via SAFe.
- SAFe Product Manager / Product Owner (SPMPO): Product managers control flow and execution. This program helps them develop the Lean-Agile skills needed for the job.
- SAFe Program Consultant Trainer (SPCT): This is a training certification for those already certified as Program Consultants.
- SAFe Scrum Master (SSM): This certification teaches scalable engineering for ScrumMasters.
- SAFe Advanced Scrum Master (SASM): This is the advanced version of the previous certification. It offers a more in depth, expert level approach to being a SAFe ScrumMaster.
Adoption of SAFe
Identifying a value stream that produces consistent results across the board is essential to the adoption of SAFe in an organization. To identify a value stream consider the following questions.
- Who supports this idea? Which executives are ready for a change?
- Where are team members physically located? How are team members distributed?
- What programs provide the biggest opportunity in that they are inherently challenged?
- What programs will adopt SAFe the fastest?
There is no “toe-in” SAFe experience. Once you’ve identified the best program for adoption, it’s essential to go all-in or not at all.
Other experiences that might signal you are ready for a full adoption of SAFe include:
- You’ve used Agile successfully at the team level.
- You have multiple teams who are running their own Agile adaptations and it’s not consistent. This has caused problems throughout the delivery process.
- You’d like to use Agile across an organization but you need the structure that SAFe provides to define management roles.
- You’ve implemented an Agile approach but haven’t achieved consistency and alignment.
- Product development lead times are a pain point for your organization.
A SAFe Solution
If you’re looking for a solution to scale your development platform for large-scale enterprise solutions, SAFe could be the right iteration of Agile for your business. As with any change, there’s much to consider.
Some benefits of using SAFe as your enterprise solution include it’s regimented structure, clear definitions and boundaries, flexibility and overall ability to scale with program needs, it’s multiple configurations and ability to get all teams in alignment on a single project. It also has a wealth of educational resources supporting it’s use and adoption, which include tools and certifications.
The fact is your development teams may already be using versions of Agile to meet their goals but if everyone’s not on the same page you could be sacrificing end-user quality.
The SAFe framework, based on the principles of Agile, provides a familiar system for developers who are used to Scrum and sprints, with the same level of reliability to provide consistent results.
This makes it an excellent choice for developers who want to branch out to enterprise solutions or for any organization that needs to restructure their development framework and processes.
- System Administrator vs Security Administrator: What’s the Difference?
- First Call Resolution: #1 Service Desk & ITSM Metric Explained
- IT Strategic Plans: 5 Great Examples from Higher Education and Why You Should Read Them
- Data Lake vs. Data Warehouse vs. Database: What’s The Difference?
- Java Developer Roles and Responsibilities