How to Implement SAFe for Very Large Projects

If you are thinking about applying SAFe (Scaled Agile Framework), you probably already know that this is the most popular method for scaling Agile teams in the world today. You also probably have heard different opinions about the effectiveness of this model, and are not certain whether it can actually work for your organization. I am also guessing that you are trying to decide how to configure your project team to leverage SAFe and achieve your objectives.

Configuring SAFe effectively is a large topic that will likely require consultation with an expert SAFe program consultant (SPC). However, I would like to offer a few thoughts based on my experience helping large project teams adopt SAFe. Perhaps this will inspire some new ideas for you.

How “large” is large?

As you are aware, SAFe offers four different configurations, each with a specific focus area in mind. In this article, we will focus on one of these configurations, the SAFe Large Solution, so that you can gain some ideas on how this might work for your specific needs.

You may have noticed that SAFe does not specifically state how large a team must be in order to apply “Large Solution”. However, we can infer that by looking at the make-up of this model. The Large Solution approach includes a Solution Train, which is a concept that encompasses multiple Agile Release Trains (ARTs). If we look at the graphical representation from the Scaled Agile website, we see that there are 3 ARTs within the Solution Train, which we can interpret as the minimum requirement for a Large Solution.

Hence, if we do some basic math, knowing that each ART usually contains 50 to 125 people, we will have a Solution Train that contains somewhere between 150 to 375 people (at minimum). Since SAFe does not state a maximum limit to a Solution Train, we can assume that we could potentially deploy several more ARTs if it makes sense. This is where expert input would likely help you make that decision.

Now that we have established the size of the Solution Train, we must determine how to design the individual ARTs to support the overall product/solution that we are building. Below are a few ideas for your consideration.

All trains are the same

One possible implementation of the Large Solution configuration is to allow each train to build a subsystem for the overall product/solution. This means that each train will basically operate in a similar fashion, designing/building/testing a portion of the solution and integrating that with another train.

Platform train

If the need arises, there’s a possibility that it makes more sense to have one train dedicated to the infrastructure of the solution so that the other trains can focus on building features and capabilities. The benefit of this approach is that the platform train can focus on the system-level functionality and construct the architecture runway for other trains, which enables faster delivery of features.

Enabling train

If your project requires the implementation of new tools and technologies that only a small subset of the staff understands, it may make sense to dedicate a train to focus on these tools to allow other feature trains to work effectively. In this case, the enabling train would serve as a supporting system for all other trains and provide guidance/expertise as needed.

How to deploy “Large” teams?

Now that you have a few ideas on what types of trains you may need, how do you know the best way to assemble and deploy the trains? Here are a few thoughts.

Top-down approach

One approach some organizations have chosen to take is an all-out, top-down approach where all ARTs are launched simultaneously within a Solution Train. This is an aggressive and often costly approach, but likely enables fast learning.

Incremental approach

Another approach, which is more common in my experience, is to apply an iterative and incremental approach to launch a Solution Train. This approach involves launching individual ARTs at different times so that the teams can have more time to learn how things work. An example of this might be launching the platform train first and allow them to run for one Program Increment (typically one quarter in calendar time), then launch other feature ARTs together.

Another alternative could be launching each feature train incrementally at the Program Increment milestone for several increments. The reason that the Program Increment milestone is a good place to launch new trains is to ensure alignment and synchronization occurs across all trains at that checkpoint; if a new train is launched in the middle of a Program Increment, it would be much more challenging for all trains to plan work together and remain synchronized.

Additional thoughts

A few final thoughts related to Large Solution SAFe is something that many organizations forget about, which is the need for additional roles. In order to operate a Solution Train effectively, it is critical to ensure a Solution Train Engineer is identified and capable of resolving cross-train issues. This is one of the most important aspects of this model that can make a tremendous difference in the overall success of the project.

To conclude this brief article, if you have never applied SAFe in the past, I would recommend starting small to ensure adequate time for the team members to learn this new way of working. Start with a small ART to gain real-world experience with the model, then decide how to grow from there. Each organization is unique in its people, processes, and culture, so take success stories from other companies with a “grain of salt”; if you give your people a chance to contribute to find the best way to apply SAFe, you will maximize your chances of success.

Eugene Lai