Which Framework Suits My Organization?

Which framework suits your organization best can be an emotional topic. Everybody has their own opinion. Here goes mine:

The Truth in Between Safe® …

In my experience, many organizations are attracted to SAFe® because it takes minimal imagination to find their organization on the shiny and detailed SAFe® posters. What looks like a great advantage to users is often the reason for agile coaches and consultants to complain. Their argument: a SAFe® implementation sticks too close to the status quo. It doesn't address the necessary changes that lead an organization to an end-to-end delivery with fewer dependencies.

Most organizations focus on executing the many rules and guidelines of SAFe® and lose focus on the real purpose of their transformation. For me, the truth lies somewhere in between. Organizations operating on the edge of chaos due to overload, multitasking, and lack of prioritization, will undoubtedly improve through SAFe®. Prioritization, cadences, and synchronization will enhance the effectiveness of such an organization, even though this may not yet be agile in the strict sense. For example, it ignores common system theories (ToC) and has low flexibility.

… Nexus, SoS, LeSS …

Nexus, Scrum of Scrums, and LeSS, in contrast to SAFe®, are very lean concepts that are very close to Scrum. When some teams already work with Scrum within the organization, these approaches enable an entry into agile scaling with little preparation and overarching structures. Especially in smaller settings with up to 30 developers, Nexus is a lean, manageable approach.

… and Scrum@Scale

Unlike the other three approaches, Scrum@Scale does not define fixed levels but roles and rules for Scrum-team collaboration. This level-independent definition is fractal, so in Scrum@Scale, you can create arbitrarily large networks of Scrum teams. The vital points of the transformation, the "what" and the "how", are always at the top of management. This is where the ScrumMaster and Product Owner organizations come together.

This makes Scrum@Scale, from my perspective, more flexible yet remains straightforward in its definition.

Start Simple

Independently of the scaling frameworks, I suggest not introducing a "big bang" change through the whole organization but starting with a clearly defined set of Scrum teams. The agile organization grows organically over time by adding other teams when the organization is ready. This approach allows the organization to learn from the pilot and apply the learnings to further implementation.

Start a Pilot

Unfortunately, this approach often clashes with the prevailing time pressure for transformation and the delivery pressure that comes with it. Therefore, we at borisgloger promote starting with pilot projects first. In practice, all frameworks from the slow-growing Scrum@Scale to SAFe® require many months or several years to be established throughout the organization. Regardless of any deadlines. So don't let yourself fool into the delusion that a big-bang transformation with a ready framework will give your company a time advantage.

Try to Be Realistic

My tip is to engage intensively with all the scaling approaches you are considering. Also, try to contact organizations that have been using them for some time. If you are working with external consultants, look for a partner familiar with more than one of these approaches. Finally, dive into the topic before planning. Trainings like the one of our myScaled Agile approach enable you to identify all by yourself the crucial elements of a transformation. This way, you can create a scaling framework based on the various frameworks according to your organization’s needs and lead the change with a customized transformation team. This increases the likelihood that the solution you choose will align with your organization’s maturity and your challenges rather than the consulting firm’s portfolio.