SAFe can be applied to smaller scales than those for which it was designed by treating it, not as an “off-the-shelf” approach, but rather as a thinking framework and collection of valuable practices to be mined according to an organization’s situation. This article discusses some of the issues in using SAFe in this way.

• The idea of mining approaches instead of adopting them “off the shelf”
• Some of the valuable ideas in SAFe that can be implemented at smaller scales

SAFe at (smaller) scale

In the software field, “solutions” reign. Hope springs up with each new method or technology, despite a long history where they never meet the need and the software-development “solution d’jour” changes every five years on average.

While this is good for the consultants who ride these waves, it doesn’t serve clients well. No “solution” works for every organization or even most of them, because no two organizations are at the same place when they become ready to make significant improvement.

There is undoubtedly value in most “solutions.” However, a turnkey solution is not the path to the results an organization desires. Rather, the way to success is for the experts in the organization’s condition, its members, to understand their situation at the time they become ready to change. Then they can choose what helps with their actual needs.

It’s your ball and your ballpark

You should never change something just because someone says “that’s the way our solution says you must do it.”

This principle applies when an organization smaller than those in SAFe’s target market recognizes the wealth of good ideas in SAFe and seeks to draw from them. Because of its several scaling mechanisms, the full definition of SAFe works most naturally in organizations running multiple projects and sized roughly a hundred people on up to hundreds. However, we’ve had clients that don’t match this profile yet want to use SAFe.  Some of the values they find in SAFe include:

• An enterprise agreement on how work is to get sequenced and started
• A way to avoid shoulder taps
• How to load balance teams
• Mechanism for having teams work together

The first two are especially compelling but doing a full-up SAFe release planning event doesn’t always seem needed to accomplish them. One such case got us looking at what really is it about SAFe that can be heavy.  And, more importantly, when does it manifest itself.  See What is it that can make SAFe^® heavy?

With an understanding of what is heavy about SAFe under what circumstances, it seems fairly simple to use the framework part of SAFe and not do a heavier than needed release plan.  This is actually pretty easy.

Down-scaling example: SAFe planning

When the full degree of SAFe planning isn’t needed, perhaps because there are fewer teams or a natural alignment between the parts of the system being developed, we can adjust the planning event to be lighter.

The key is to adjust the degree and length of the planning.  Several folks might be left with a big “how?” but we have lots of ways to coordinate teams, including

• Cross-Functional teams (see the article How can we improve communications between people who work together)
• Dynamic Feature teams (similar to cross-functional, but everyone is focused on one feature; often much larger than the classic cross-functional of 10-12)
• Extended Core teams (partly cross-functional and partly borrowing people part-time from shared-services or infrastructure teams)
• Lean Shared Services team (a pool of people with the same specialized skill such as virtual server administration, all operating from a shared Kanban board)

Regardless of which team structure is chosen, to achieve cross-team collaboration several things are required:

1. an holistic view
2. an appreciation for systems thinking
3. an understanding of Lean Flow
4. an understanding of organizational development

The two-day SAFe planning event is just as much about socialization as it is about planning. Be sure to include lots of communication between the teams, even if you organize, for instance, with shared kanban boards and skip SAFe’s dependencies board.

Communicating is central at any scale

Different communication mechanisms are needed at different scales. You will need to decide on the mechanisms you need at your scale. These kinds of conversations, though, create an opportunity to do SAFe in a lighter way than prescribed.  This enables us to get the holistic view of things without adopting anything overly heavy.

A major benefit that SAFe at any scale provides is a set of useful default management agreements. These address:

• Managing workload
• Preventing unwarranted interruptions to development teams
• Requiring all teams to have the same cadence so that they can synchronize frequently
• Running the teams in a test-first manner

A light-weight implementation of SAFe provides a framework within which to do Kaizen (small-step incremental improvement) to refine the structure of the organization as well as its management system.

The bottom line is that anything can be applied in too rote a manner…and this happens more often than not. Don’t just accept any prescription of a framework or method without first asking, “does this serve the needs my organization is actually experiencing?” If the answer is no, then skip the prescription; there are plenty of other prescriptions available for the needs you have without adopting any for those you don’t.

Summary

There are two ways to think of SAFe: as a whole template to which you conform your whole organization, or as a thinking framework with multiple practices that you can mine to address different development needs.

Take the latter approach to benefit from ideas that SAFe or any framework offers, tailored to your organization’s realities. In particular, if your organization is smaller than the target size for using SAFe, you may still be able to benefit from its many good ideas by taking this flexible approach.