Scaling agility has been talked about for over a decade. SAFe and LeSS have strong ties to Nokia’s Symbian era and the development of NSN’s mobile network. The Spotify model, as the name says, came from Spotify. What these and other models have in common is that they are born out of a particular organizational culture, software architecture and business model. Their merits, however, are most pronounced when used in a similar environment in which they were originally developed.

Why is it so hard to succeed?

The company can successfully scale agility only from its own perspective.

Why is it that scaling agility often does not fully meet the aspirations and goals that were initially set? There are many reasons, but one of them is that the chosen model did not have any prerequisites for success. In particular, organizations often try to implement the wildly popular SAFe model, even when they do not have a common software platform or a product that would require extensive collaboration in value creation. Recently, the Spotify model has begun to be rolled out to organizations with such a strong component team architecture that a successful change will require years of work to create new teams.

What these failed projects have in common is that they have failed to realize one important thing. That is, that scaling successful agility can only be done from the company’s own perspective. When a model is imported from the outside, it also brings with it the goals from the outside. This is pretty much the same as having a runner use a hockey player’s summer exercise program. Surely there will be development, but not in the desired qualities.

When it comes to scaling agility, we must first consider the most important limiting and enabling factors for scaling. The key issues when considering how an organization scales agility are largely related to the product and service architecture, technology architecture and business and sales models. It is possible that these are changed during scaling, but they should be taken into account  when selecting a model. 

Why is product and service architecture important when considering scaling agility?

Product and service architecture refers to the kind of products or services an organization produces. That is, does the organization have many products or services that need to be developed, or just one service or product. This does not directly determine how scaling should be done, but it is definitely significant. For example, the SAFe model’s original mindset has been developed to respond to the development of one massive product platform.

Of course, at its best, a single product, such as online banking or a Spotify player, can be divided into many areas, allowing individual teams to work well in isolation and with own initiative. On the other hand, a multi-product environment can also be based on a common platform, which requires teams to work closely together. Understanding the current state and hopes for the future of this product and service architecture is an absolute requirement before any decisions are made about methods for scaling agility.

Why does scaling agility require consideration of the technological architecture?

The technological environment largely dictates how much the teams need to collaborate. Can individual teams deliver value alone or do they need to work with others to get things done for the customer? It is very common that organizations are based on technologies and components, and as such require a lot of collaboration. Going from a situation like this to a model like Spotify will take years and will require excellent change management. It is sad how little agility coaches, both internal and external, talk about this. Sure, they tell you how to deliver complete stories or features, but do not give any medicine to correct the situation. Quite frankly, if this is not mentioned in the agility scaling project, it will not succeed.

Why are sales and business models so central to scaling agility?

Although project has become a curse word in the 2010’s, in reality, many organizations are still very much project driven. Outwardly, we tout and talk about being in the product business, but in practice most of the development is done through as customer projects. This project-based delivery does not leave product teams with much responsibility for the roadmap and iterative development. And I am not against project-based operation, as for many organizations it is probably the best way to operate. The problem comes from the fact that scaling agility is based on a product-based organization while the real business model is project deliveries.

Another important factor related to business models is what is being sold (product portfolio). For example, are services part of a whole, as is often the case in the banking world. Or are several products sold as a single delivery, even though the products appear to be separate from one another? These factors significantly determine the autonomy and capabilities of an individual team. Therefore, these issues also need to be clarified before finding the right model of scaling agility for the organization.

Ready scaling models or their variants are seldom suitable.

How, then, is a successful model of scaling agility created?

Surely a disappointment to many, there is no silver bullet here. Ready scaling models or their variants are seldom suitable. For the most, they take the agility scaling in the wrong direction.

Comprehensive agility scaling is so complex that it would require a book instead of a blog post. But we have tried to sum up the most important things in these six points:

• Common understanding of the strategy and its sub-strategies and customer base in the organization. Cliché as it is, it is the most common issue causing problems in product organizations, especially as the organization grows. This in itself is not related to scaling agility, but without it, there cannot be a successful model for it.
• A decision-making model where the most knowledgeable people make decisions about products and services. This includes investment, portfolio levels, and product releases. The most important thing is that the model allows the right people to make decisions on the right issues.
• An organization model that is able to deliver and enables a dynamic reorganization of resources. Teams need to be able to deliver results as finished as possible in close collaboration with sales and marketing. In addition, it has to be possible to make dynamic changes in the team structure as the market needs change.
• An operating model that ensures business continuity and the quality of delivery. Dynamics must be counteracted by operating models that ensure that the current business and technology are taken care of. Business continuity and product maintenance need to be ensured while creating new with as much agility as possible.
• Separation of business responsibilities and staff development and well-being. One problem with the organizational models of the past century has been that line management has become a tool of power and a major obstacle for business agility. Dismantling this opens up opportunities for a more dynamic model of the organization. This poses different challenges for staff development and development discussions, but nothing that cannot be solved.
• Agile development skills of key people in the teams and product organization. If the team level is not agile, then agility cannot be scaled. So, the basics of operating models must always be put in order.

Think about what would produce the desired results in your unique environment.

Conclusions: Scaling agility is based on the company’s own perspective.

Scaling agility can only be done from the company’s own perspective. In some cases, ready-made models meet all the needs of the organization, and are worth using to start building scalability. In most cases, this is not the case and the scaling model should be carefully considered. Challenge the thoughts of prophets, both internal and external, about scaling agility, and ponder what would produce the desired results in your unique environment. Digital development and scaling agility will sooner or later become an issue in almost all organizations, and it is worth spending some time to understand it.