Last week, I covered the basics of Scrum. This week, I will cover the basics of the Scaled Agile Framework, A.K.A. SAFe, as I wish I would have had it explained to me when I first started researching it. I will do my best to make it as simple to understand as possible, so that you will not be as overwhelmed and as intimidated as I was when I began.
The Goal of SAFe
SAFe, like other frameworks such as Scrum@Scale, Large-Scale Scrum (LeSS) and Nexus among others, aims to take the principles of Agile and apply it to a much larger organization. While Scrum works well in a small organization, it is often challenging to have multiple Scrum or Kanban teams working in tandem with one another to meet organizational goals without some kind of framework to support it. One way that SAFe attempts to solve this problem is by making all four layers of the business follow a similar structure to a Scrum team.
Organizational Structure of SAFe
The easiest way to understand how SAFe is structured is by understanding the four levels of organization (Team, Program, Solution and Portfolio), and how they mimic the basic structure of a Scrum team in the roles that are involved.
Agile Team Level Organization
The Scrum Team (or Kanban team) forms the lowest level, standard unit of the Scaled Agile Framework. The Product Owner provides the business knowledge for the team and maintains the Product Backlog. The Scrum Master guides the team in their constant growth, coaches the team in Agile practices and helps remove impediments to the team’s success. The Development Team performs the work and are typically managed by an Agile Development Manager.
At EBSCO Information Services, the Product Owner, Scrum Master and Agile Development Manager form a triad who meet regularly to discuss the best ways to help guide the team in all aspects of their work and take personal stake in the success of their teams. While each of these roles may often be involved with up to three teams, the triads do their best to serve their teams and also communicate with other triads across the organization to solve problems so that the developers are free to do their work.
Scrum teams are grouped together based on similarity of work, products, or goals. These groups of Scrum teams are called Agile Release Trains, or ARTs, and are led by people who form another unit called the Program Team.
Program Level Organization
The Program team is made up in a similar way to the Scrum Team, just at a higher level. Instead of a Product Owner, the business side of the Program Team is filled by Product Managers who handle the needs of the business at a higher level (i.e. breaking down epics/capabilities into features instead of breaking features into product backlog items).
The Development side of the Program Team is handled by Systems Architects/Engineers, highly skilled technical employees who guide the over-all architecture of the technology being developed by the developers at the Scrum Team level.
Finally, the Program Team’s equivalent of a Scrum Master is called a Release Train Engineer. These people do many of the same things that a Scrum Master would do, just on a higher level. They work hand in hand with the Program Team to help track and encourage progress, remove impediments and facilitate ART level meetings. They help “move” the Agile Release Train forward in any way they can, thus the title of “Release Train Engineer”. They hold direct stock in the further growth of the Scrum Masters in their Agile Release Trains.
Solution Level Organization
When you zoom out further than the Program Team on a SAFe organization, you will see the Solution Team. This is the second highest level of a large scale SAFe organization, and governs entire solutions for the enterprise. The only thing larger than a solution is the organization’s portfolio.
Solution Management directs the business for the specific solution. They are in-tune with the markets and make decisions that guide the direction of the company’s work to solve business needs at the Solution level. They manage the Solution Roadmap, Solution Vision and helps prioritize the direction of the Solution.
The Solution Architect/Engineering manages the technological direction of each solution. They make big decisions about technology and make sure that the solution follows the technological decisions made at the highest level.
A Solution Train Engineer is the second highest level enabler for the organization’s smooth Agile implementation and growth. They empower the Release Train Engineers for all of the ARTs in the Value Stream and and provide guidance and support where possible.
Portfolio Level Organization
Finally, at the very top of the organization is the Portfolio Team. This is the team that ultimately makes the highest level decisions for the enterprise. They manage the Value Streams, Lean Budgets, Portfolio Kanban, Portfolio Vision and Portfolio Canvas.
The Epic Owners are the highest level employees on the business side that ultimately make the highest level decisions for the business. They roadmap the epics (highest level version of work to be done) through the Portfolio Kanban, essentially a prioritized list of large-scale work to be broken up and completed later.
The Enterprise Architects work across the value streams to help ensure the best architectural decisions are being made when it comes to technology.
Lean Portfolio Management is the highest level decision-making function for the organization’s portfolio, and they are also accountable for its finances. They deal with funding projects, govern the operations of the portfolio and the Lean enterprise
Conclusion – SAFe’s Recursive(ish) Structure
The easiest way to understand SAFe is that each level mimics the standard equation of a Scrum team, just with higher level duties and responsibilities the higher it goes. Or, in other words, SAFe is a Scrum-inspired Portfolio level that sits on top of a Scrum-inspired Solution level that sits on top of a Scrum-inspired Program level that sits on top of Scrum teams. In essence, it’s a Scrum-of-Scrums-of-Scrums-of-Scrums, and when it’s well done it’s a great thing to witness.
The only downside to this is that it’s very hard to do right without buy-in from everybody in the entire organization.
