We live in a world where businesses have been tossed back and forth between fads, frameworks, and trends for years. Reorganization is almost as common as the annual budgeting cycle, and change has become the only constant. Some people embrace this idea with gusto and are always looking for the silver bullet to stimulate growth, attract talent, and gain a competitive advantage. While the more pragmatic among us are tired of hearing about the next best business process and have settled on a belief that frameworks are an invention to keep consultants employed rather than a proven ways to grow a company.

Regardless of the camp you fall in, everyone agrees that project management is a required roll in modern enterprises. With that established, it is safe to say that all businesses fall into one of two camps on this belief. The first is that traditional Waterfall Project management is the only logical, time tested method for shepherding a project through to successful completion. This camp is entrenched, but seems to be dwindling in favor of the Agile approach. People who embrace the Agile concept believe that time has proven that the Waterfall approach is too slow and delivers inconsistent results.

Regardless of the camp you fall in, these two methods for getting work done are both prevalent and I believe are here to stay. Now the frameworks and tools that are built on top of these methodologies are not as universally adopted and there is still significant debate on how to best leverage the nuances of human interaction to best align an organization around a vision and then facilitate growth to meet that vision.

In a small organization, basic frameworks and tools will do the trick. As an organization grows however, structures must be formed to keep the company aligned. This is where large scale frameworks come into place. In traditional companies the framework was developed implicitly through following the example of the largest organizations known to man. Governments and militaries. This concept is known as command and control and works through a complex, downward, hierarchy that handles communication of vision and execution of strategy. This concept is being challenged as Agile principles mature. This evolution is being driven by the creation of frameworks that flip that concept on its head where vision still comes from the top down, but strategy on how to execute that vision comes from the bottom up. For a list of frameworks and details on why this change is occurring, check out the article on Does Agile Scale. In today’s post I want to dive into the most widely adopted, large scale Agile framework called SAFe, which stands for “Scaled Agile Framework for the Enterprise”.

The first thing to acknowledge about SAFe is that it can seem overwhelming at first. The framework uses a complex graphic to help communicate the nuances of its practices which at first glance appears significantly more complex than it actually is. The graphic is used as a guide for the intensive training sessions it offers and thus was designed to take several days to fully explain. In this post I hope to break this down at a high level to give you the major points without making you sit in a two day training session to understand the concepts. 

The Scaled Agile Framework

SAFe Levels

SAFe teaches that companies should have defined layers of hierarchy, and that more layers should be added as a company grows. This layer system is the foundational teaching of SAFe. The rest of the framework is focused on specifics for making vision & work flow up and down through the layers. The specifics are important, but they are designed to work in the context of this layered system. So first let’s understand the layers:

Small Company

  • Team Layer

Medium Company

  • Program Layer
  • Team Layer

Large Company

  • Portfolio Layer
  • Program Layer
  • Team Layer

Large Company with highly complex systems

  • Portfolio Layer
  • Solution Layer
  • Program Layer
  • Team Layer

Mega Corporation with portfolio of distinct businesses

  • Corporate Layer
  • Portfolio Layer
  • Solution Layer
  • Program Layer
  • Team Layer

Team Layer

The team layer uses the Scrum framework, with one variation. Sprints are clustered into groups of 4-6 called Planning Intervals. By doing this, SAFe introduces better forecasting and planning on a 10 to 12 week basis. The goal of this layer is to define and build a solution that matches the high level objectives handed to them from the layer above, or in the case of a small company, the objectives from the companies leadership. Each team should contain 7 people, give or take 2. SAFe does not specifically speak to this layer as a stand alone layer because the framework itself is focused on what Agile looks like when a company scales beyond a few teams.

Program Layer

As a company grows and several teams are created, the company needs a way to align these teams around a common vision. The goal of the program layer is to establish the high level objectives for the teams so as to leverage the organization’s size to point it in a focused direction. SAFe teaches that a program Layer should be established once a company has more than 50 people in teams. 

Note that newer versions of the framework do not split out the Team & Program Layers quite as clearly, but they still teach the same general structure.

Solution Layer

When a group working on the same product or solution contains more than 150 people, as is the case on highly complex systems such as an airplane, or enterprise cloud computing complex. SAFe suggests that an additional layer be added between the program and portfolio layers. The goal of this layer is to break the group into smaller groups of between 50 and 125 and then coordinate efforts across these large groups.

Portfolio Layer

This layer is added when the leadership of the organization extends beyond one or two owners. The goal of this layer is to establish the organizational vision and high level strategic direction. It defines a method not only for establishing this vision, but also for aligning budgets and resources to accomplish the vision. This layer drives the ship, while the program layer directs the troops.

Corporate Layer

There is one additional layer worth mentioning that exists in what I would call a Mega Corporation which is responsible for numerous, autonomous businesses. The role of this layer is to measure and manage the individual businesses to insure they are adding value to the overall corporation. They generally operate as an oversight group managing investments and are concerned more about the growth and profit of a division then they are about the specific vision and implementation strategies. I wanted to point out that this layer exists, but note that SAFe does not speak to this layer directly. SAFe eludes to each individual business unit having its own Portfolio layer which the Corporate Layer would be speaking into and receiving reports from. 

SAFe Roles

SAFe takes the general concept of the Scrum troika and expands that to the various layers in the organization. A troika is a term for three people working together in an organizational or managerial way. Here is what the troika looks like at each layer:

Portfolio

  • Business Owners
  • Epic Owners
  • Enterprise Architects

Large Solution

  • Solution Manager
  • System Train Engineer (STE)
  • Solution Architect

Program

  • Product Manager
  • Release Train Engineer (RTE)
  • System Architect

Team

  • Product Owner
  • Scrum Master
  • Development Team

Each troika is made up of three types of people. The business person, the organizer, and the technical talent. Each roll can be filled by a single individual, or group of individuals depending on the workload. Each troika works together to prepare work for the level below, through translating the corporate vision into increasingly smaller chunks of work that the development teams will eventually build.

SAFe Flow

Just as SAFe uses the best practices of Scrum at the team level, it teaches organizations to use the best practices of Kanban at every level. The idea being that each level should maintain a Kanban board of work they are moving through their process. This creates top to bottom visibility across all levels of the organization, and helps create a consistent flow of value to the customers. Each level takes items from the level above, breaks them down into smaller pieces, then refines them before handing them off. Here are the names given to chunks of work at each level:

Portfolio

  • Strategic Themes are defined and prioritized into Epics

Large Solution

  • Epics are defined and broken into Capabilities

Program

  • Epics or Capabilities are defined and broken into Features

Team

  • Features are defined and broken into Stories

The Kanban board is used to track each item as it goes through the process of being broken down at a specific level. When the item moves across the board at one level it is passed to the board at the next level as a cluster of smaller items.

SAFe Trains & Big Room Planning

Trains are one of the key constructs that make the Scaled Agile Framework effective. Think of a train as a long lived group of teams that start and stop a Planning Interval together. Much like a train is a group of train cars that arrive and leave the station on time. The nomenclature of ‘train’ is used to elicit the idea of predictability and consistency.

Here is how this plays out. Let’s say we have 5 teams working on a specific product. These teams have dependencies and there is value in sharing lessons and best practices for the collective growth of all teams. These teams would be called a train. Trains run on PI’s or Planning Intervals, much like a train runs on a predefined schedule each day. This Planning Interval is made up of 4 to 6 sprints where a sprint is 1 to 4 weeks. The general goal is to have between 4 to 5 PI’s per year. Each PI starts with a Big Room Planning session. This session is generally two days and includes everyone on the train. This would mean everyone at the team and program levels. The two days start with a series of presentations on vision from the Portfolio and Large Solution levels as well as presentations on specific objectives for the PI presented by the program level. This is followed by a series of planning and check-in meetings to craft a plan for the entire PI. As part of this exercise the teams outline what they are able to tackle each sprint, known dependencies and risks are mapped out, and the train commits to what they are able to produce before the end of the PI. The secret sauce here is that the teams commit to the work they can get done in the PI minus one sprint. So in the case of a 5 sprint PI they commit to enough work for 4 sprints. The last sprint gives the train a buffer for unknowns, but is officially referred to as the Innovation and planning sprint, because the goal is to give the team time to pollish up their work, or to explore innovative ideas before the next PI starts. This creates predictability through built in margin, and increases team morale before everyone launches into another PI. The last sprint in a PI is when the two day planning event is held for the next PI. 

While the team level is working on fulfilling the commitments for the PI, the Program level is pushing work through their Kanban board to make sure there is enough work prepared for the next PI. This keeps planning focused on a 3-6 month horizon which is critical to organizational agility.

The makeup of trains should be defined by the Portfolio level, or organizational leadership and should be long lived. Meaning they should stay together for a minimum of six months with one to two years being optimum. 

Conclusion

There are a hundred nuanced details on how to make all of this work, and I would highly recommend the official Leading SAFe training if you are interested in pursuing this as an option for your organization. The framework is extremely prescriptive which tends to polarize peoples opinions. I want to encourage you though, regardless of your opinion on SAFe, if your organization has adopted Agile at the team level, but the rest of the organization has not aligned to create top to bottom transparency and alignment, then you should absolutely consider SAFe as a first step in spreading Agile thinking across the organization. Once the organization understands SAFe it can innovate and create its own unique version like Spotify has done. (Google Spotify Agile to see how they have adapted SAFe to fit their own unique situation.) Take a look at the example from my post called How to start anything and win to understand the pitfalls of trying to create your own version prior to fully understanding the details of an existing one that is already proven to work. Don’t forget Gall’s Law:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

SAFe may seem complex at first, but it was built on top of a slew of proven, simple systems, all of which embody the Agile mindset. First you must learn and internalize the simpler systems that operate as the foundational truths of the complex system. Only then are ready to diverge from the complex system while still leveraging the truths it was built on.