SAFe: Which Companies Need Scaling?

Who needs Scaled Agile Framework (SAFe) and who does not? What are SAFe’s advantages and disadvantages? In this interview Sergey Prokhorenko answers these and other questions.

Sergey Prokhorenko, a certified SAFe Program Consultant, who has successfully implemented projects to scale agile product development for banks, IT, telecommunications, pharmaceutical, and other companies.

Sergey, as Agile becomes increasingly popular, many companies try to associate themselves with “Agile”, “scaling”, and SAFe (Scaled Agile Framework) in particular. Do they really need SAFe?

— It all depends on the peculiarities and scale of each company. I’m not talking about IT only. Banks, logistics, telecommunications, manufacturing enterprises — all need automation, agility, and process acceleration.

Dean Leffingwell, the creator of SAFe, said, “Every business is a software business now.“

Before I proceed, I would like to emphasize the context we all find ourselves in.

Do you mean the boom of digitalization?

— Exactly. In the last decade, it has flooded the global economy with the speed of Elon Musk’s rocket, while the pandemic has raised a new wave of digitalization because of the urgent need for digital solutions, cybersecurity, and responding to the new consumer inquiries.

What does this mean for businesses?

— According to recent research (State of Agile Report, for example), it is clear that most global companies have realized the need for agility in product development. Regardless of scale or geography, in half or most cases they already use Agile, and every year this percentage is only growing! We can observe this trend in the organizations whose mission is not even related to IT directly.

As for IT companies, no doubt the growing demand for product development opens up new opportunities for them. However, there is one little warning. If they had not yet embraced the Agile mindset, they should probably get ready for the serious competition with those who already use the agile approach.

After all, agile teams create more value in a shorter period, make product delivery faster, and test product hypotheses quicker — with less costs and not wasting money on unnecessary functionality. Today agility is a key to everything.
Thus, companies are looking for the opportunities to bring their products to the market faster, meet new consumer needs quicker, and protect data better.

That is why top executives come to us and ask: “How do we integrate IT development into our company, even though our industry is banking (logistics, telecommunications, etc.)?” How can I manage multiple teams at the same time? How to distribute portfolio budget between different digital products? How to apply changes (make a transition to Agile) in the entire company in one time-limited period?

How many staff are we talking about? When can I use SAFe?

— When a company has one thousand or more staff, and when it already has internal development with hundreds of developers involved, and plans to implement Agile, then it should seriously consider SAFe.

Often these are the companies with tens or even hundreds of thousands of people! SAFe is an ideal solution for such organizations in such a case.

Why?

— Just imagine: you have to prepare several thousand people for adopting the new approach to product development. How is this possible? Where can we find so many competent experts capable of implementing such a task? How do we get the funding for this?

As you can see, such massive integration is almost impossible to implement manually. In addition, it is unlikely that anyone will find so many consultants from various companies who are on the same page. So far, I haven’t seen a company-level budgeting for such initiatives, either. Obviously, there must be another way.

This is where SAFe steps in, suggesting scaled “agilization” and prompt changes at a system level, not disrupting the current business operations.

Everyone talks about the “system level”, but what does it mean in SAFe’s context?

— This is the question each client has to answer before we proceed to consulting. What exactly does he mean by mentioning such terms as “scaling”, “SAFe implementation”, etc.? What goals does the company really want to achieve?

Sometimes we have to refuse, in situations when SAFe is not exactly what the client imagined, or when it does not correspond to the goals he wants to achieve.

Here’s the thing. Unlike other approaches, SAFe does not destroy the traditional managerial hierarchy, introducing the “dual operating system”, where the employees are under the traditional management model formally, but at the same time, they build self-managed teams organized around customer value, rather than operating within the “department” box. Gradually they are forming a new way of thinking, taking more ownership, initiative, and responsibility for the value they produce.

In the case of SAFe, we work on the following three levels: Essential, Large Solution, and Portfolio (there’s also a Full SAFe configuration which combines the latter two).

Changes can occur at the level of a single program, a number of related programs, or portfolio management, depending on the needs of the company. However, for the sustaining effect, SAFe must gradually expand to the entire organization.

As simple as that?

— It sounds simple in theory, but it is difficult to practice. To grasp a basic idea of SAFe’s key concepts only, we would have to study the SAFe Reference Guide — 800 pages of the manual written by Dean Leffingwell. Or, at least, take several training courses, or read an array of articles in the Scaled Agile knowledge base!

Of course, the in-depth understanding of the practices that are appropriate in a particular setting comes only with the experience gained by working with different companies and situations.

That is why there are not so many experts who can transform large companies comprising tens of thousands of people working for them. That’s why they turn to us for professional help.

Obviously, it is impossible to explain all the nuances of SAFe in a brief interview, but I want to underline a few features of SAFe in comparison with other approaches.

What are they?

— Firstly, SAFe is the most common approach in agile development. 35% of companies participating in the 14th State of Agile Report survey use SAFe. By the way, this is 5% more than in the previous year, and we expect that we will see an increase in the 15th report, as well. In other words, the feasibility and quality of the SAFe approach have been proven with many real cases.

The next feature of SAFe is the differentiation of practices, according to the company’s scale, specifics, and needs.
In contrast to SAFe, other approaches (for example, Large Scale Scrum) use similar practices for different setups, be it a product organization with a hundred or thousands of people.

On one hand, this encourages decomposing teams and reducing their interdependence, on the other — raises high standards requiring maturity in product management, engineering practices, cloud infrastructure, and the like, which might be challenging at the earlier stages of Agile adoption

SAFe is significantly different due to its variable agility solutions. Each level (essential, large solution, or portfolio) introduces additional practices for managing team interdependence, establishing flow and improving value delivery. Yes, this involves some additional costs for synchronization and joint planning, but it saves precious time for the rollout of the new approach.

What are the problems or disadvantages of SAFe?

— There is one feature that I consider both an advantage and a disadvantage at the same time — determinism.
What I mean are the practices prescribed for various situations (“best practices”.) These “best practices” are useful in many cases and can be applied at different levels. In a way, they serve as a multi-tool.

However, we understand that for some companies, “prescribed recipes”, experiences of others, or any ready-made solutions are not always the best option. This is especially true for organizations that build their own knowledge base. Implementing SAFe, such companies come up with a number of their own, more effective, “best practices”.

Another advantage and disadvantage of SAFe is the ability to create a “parallel structure” or a dual operating system when value stream oriented delivery network exists in parallel to the hierarchy of the given organization. In such a case, there is a risk that SAFe will remain a “parallel structure” within the old functional unit paradigm.

Then it’s no longer SAFe’s, but the company’s problem. If the organization does not change as a whole system, then there is a risk of “an organization emerging within an organization.”

This is important, because the ultimate goal of business is not to create an isolated innovation hub, but to rebuild the entire organization in such a way that it does not just “deliver” digital products in a fast and frequent way, but becomes agile — adaptive to new market conditions, permanently changing environment, and fierce competition, not to mention market leadership ambitions.

What are the advantages of SAFe in this case?

— SAFe allows you to adopt changes quickly. With SAFe you can implement the new agile development approach within a year. Of course, it all depends on the company’s size and specifics, but accelerating the transition to Agile is SAFe’s significant advantage.

Besides, SAFe does not require ruining the company’s current organizational structure. This is one of SAFe’s fundamental benefits, especially at the beginning of implementing Agile, however reorganizing structure around value becomes a logical step after building solid product development organization.

And for sure, there’s availability of ready-made solutions for different levels. The problem with some companies is that they are trying to reinvent the wheel, while SAFe has been using it successfully. Sooner or later they will understand that impulsive, haphazard attempts to rebuild large companies are costly.

SUMMARY

In the interview with Sergey Prokhorenko, a recognized expert in SAFe, we discussed the following issues and came to these conclusions:

Which companies need to embed SAFe?

• The SAFe approach is good for larger companies comprising thousands, tens, and even hundreds of thousands of people working for them;
• SAFe also fits well the organizations that have already launched their own IT development or are planning to do that, but who are still living within the classical project management paradigm;
• SAFe will surely to be useful for those companies who strive for faster product delivery;
• SAFe will also help when a company has a fixed innovation budget that needs to be wisely spent to gain strategic advantage;
• SAFe will save money for Agile transformation due to its proven implementation roadmap;
• SAFe will suit the companies that have many teams and at least 50 people working on one product.

Which companies SAFe would not be the best fit for?

• Firstly, SAFe may not be the optimal choice for those organizations who have been using agile principles since the beginning of their existence, or who have created their own agile culture and want to maintain it in the process of scaling.
• The second type of companies that do not need SAFe are those who want to save money on developing a product with fixed functionality. (In this case it is worth questioning why they are using Agile at all.)
• Smaller organizations, with few isolated product teams without many critical dependencies or with “ring-fenced” budgeting, for which communication and team synchronization overhead won’t be correlated with the benefits received.

JOIN AGILE.LIVE

• Check the nearest certification trainings at Agile.Live: Professional Scrum Product Owner (PSPO), Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E)
• Connect with Agile.Live on LinkedIn
• Subscribe to Agile.Live Telegram channel
• Subscribe to Agile.Live YouTube channel