Blog /

LeSS SAFe comparison

Scaling Agile

25.3.2015 — Agile Scaling frameworks LeSS and SAFe have a history with Nokia. What problem were they solving and how?

LeSS SAFe comparison
Ari Tikka
Ari TikkaFounding Partner
Ran Nyman
Ran NymanFounding Partner

Both Large-Scale Scrum (LeSS) and Scaled Agile Framework (SAFe) have a history with Nokia and use it as a reference. What most people do not realize, is that Nokia was two big loosely coupled companies. LeSS was and is mostly used at Nokia Networks (now still called Nokia Networks) side while SAFe was mostly used at Nokia Mobile Phones side (now mostly Microsoft or closed down).

Both sides of Nokia were gradually facing the same problem that they later tried to solve by scaling Agile: overspecialized component organizations and external coordination. Most big organization around the world face the same problem. Nokia provides a relevant story to understand and compare what these approaches offer.

Our analysis of Nokia may seem blunt, but it is for a reason. We want to communicate our point of view clearly. Coordination Chaos is significant and treacherous pattern. Its real impact will surface late.

In big organizations the culture and organizational structures constrain, what people are able to do. We want to express our empathy for the individuals, who have done their best as the members of the system.

The authors contributed to the implementation and evolution of LeSS and SAFe at Nokia Networks and worked with SAFe in Nokia Mobile Phones. Gosei founders have been working with all Finnish companies that tried out SAFe in the first wave about five years ago. One of them is currently implementing SAFe en masse in an enormous global product company. We have seen the SAFe SPC course by Dean Leffingwell last year and now certified LeSS trainings by Bas Vodde and Craig Larman.

What problem is “scaling Agile” solving?

Nokia was growing about 35% per year for long times, which is very hard to lead. The natural solution was specialization: component teams, functional teams, specialists know, managers decide, and teams execute. This was true for both Nokia Networks and Nokia Mobile Phones. Both companies relied heavily on program and project management in getting things done.

This became increasingly difficult by the time. The more overspecialized organization needed even more external coordination. This pattern of Coordination Chaos was one of the main reasons leading to the infamous “Burning Platform” of Nokia Mobile Phones.

The hidden problem – learning

By taking the path of specialization and external control of the front-line engineers, Nokia needed less education for the mass of them. The specialists knew, project managers coordinated, and intelligent recruits easily learned their narrow roles. This experience suggested that more learning was not needed, and strengthened the machine metaphor in management thinking. This management thinking optimizes resources and cost, locally and in the short term. It treats learning as cost, especially learning outside of one’s special role.

Let’s contrast this with a Scrum team (the team + the product owner + the Scrum master). It cross-learns inside the team. It inspects and adapts at the market. Here learning creates value. This is what you want to scale up.

Both LeSS and SAFe are based on Scrum at the team level. Both have their own selection of Lean and Agile practices to support the scaling. The critical difference is, how the proposed process and organizational structure drive learning, because Organizations learn like horses

SAFe and Nokia Mobile Phones problem

A new Nokia phone model had a limited life span and a tight deadline. The huge backlog (plan) had detailed old and new features for the numerous components. Every component needed to implement system-wide features, like a new consistent UI design.

As the solution, the first SAFe process was introduced internally at Nokia Mobile Phones around June 2009, having release trains, planning meetings and 4-level hierarchy in the product backlog. There was the first version of the famous SAFe big picture, accompanied by 170 slides carefully crafted together by Dean and Nokia management. Since those days, SAFe has incorporated a wide set of Agile practices and dropped obsolete Nokia flavor. However, the core value is still explicitly there:

Program Execution
– SAFe

When looking at the market, this seems to be the solution to the perceived problem in many organizations.

The core of SAFe is a new very detailed process layer on top of Scrum, intended to coordinate the big mess and give predictability. In many cases the new process may stop old stupid things and take a step towards Agile values. For example starting all-hands-planning may energize and improve communication. SAFe removes projects and encourages to control Work In Progress.

It is difficult for the authors to imagine that an old troubled organization would be able to implement SAFe process by the book. The competence of the people will limit the possibilities. In a large organization, there will be diversity between different implementations of SAFe. Things will change by the time in each implementation of the SAFe process. It is a philosophical question, when and how long the new way will still be called SAFe.

The detailed process serves as a very good sales story. Based on the actual circumstances something different will emerge.

Learning in SAFe

Organizations as cultural learning systems will optimize the one primary focus. In SAFe that is program execution, and the given process defines the way. This is not inviting learning at the organizational level. There is the danger that investment in learning is further delayed, when the primary goal shows some success.

Second comes the new Lean and Agile way of working for the several defined roles. For the decision makers it is a new commitment step, scaling the investment in learning. SAFe consultant network supports this by training and consultation. The actual practices are not especially unique for SAFe, so the real question is how good consultants you have, and how much do you invest in learning.

LeSS at Nokia Networks

Nokia Networks is producing extremely complex and long-living products. Some products were required to offer 20 years of maintenance. Still the development was mainly coordinated with heavy release programs, often lasting years.

The evolution of LeSS is not attributable to a single corporation. LeSS at Nokia Networks started around 2005. Now, after nearly ten years there are LeSS huge organizations still going on in Nokia Networks.

So what was the perceived problem at Nokia Networks? Lack of productivity and flexibility in the product development. A more careful analysis reveals the death spiral: fragmented organization, cluttered flow, confused leadership and narrow learning. They are the root causes of Coordination Chaos. LeSS is reversing this spiral. Authors’ condensed wording as LeSS value proposition is:

More with LeSS.
– LeSS

LeSS is scaling Scrum teamwork up and out without adding layers or processes. On the contrary, it is simplifying the organization radically – more with less. The teams take care of the technical coordination. The product owner team works with the market and with the teams. The managers become coaches. No layers of indirection are added.

Feature teams is a key concept in LeSS. Specialization is necessary. It creates clarity and efficiency. However, it is critical in which dimension you specialize. LeSS clearly recommends to specialize in the customer-centric and product, not in component direction.

If the organization is new and growing, LeSS can give some golden advice to avoid the death spiral.

There is no magic available. Transforming a large old organization does not happen overnight. There are many phases and silos along the process. It takes time to pay back the organizational and technical debt. LeSS adoption respects inspect and adapt. You start in one corner, make sure that things work, and then expand. The long lasting cases are best way to study, what kind of value has been created.

Learning in LeSS

It has surely become clear, how central learning is in LeSS. The coordination cost transforms to investment in learning. LeSS tradition supports this by sharing experience of what has worked in what context.

Strategic decision

Which way to go? The decision is heavily influenced by how the decision makers perceive the organization’s situation.

SAFe suggests a direct solution to a burning perceived problem, a new better program process, explained in familiar terms. It is easily understood by the traditional operative management. It is scratching the same coordination itch as the massive project and program management industry, adding Lean/Agile methods.

LeSS provides a radical long-term solution. The simplicity of LeSS makes it versatile. Different kind organizations are able to use it for long time. However, because of this versatility, the decision makers, including the top management, need to have more understanding and courage to take this path.

In many large companies, the top management actually wants to have the radical change. They are for example establishing internal startups to create totally new market-oriented culture. LeSS is a way to scale this evolution up.


In the next blogs we will explore more details, for example the very different ways to scale Scrum, and the organizational layers of SAFe versus the customer oriented teams in LeSS. We will comment 1) leadership and power 2) organizational structure and hierarchy 3) flow of value 4) learning, adoption and continuous improvement.

We will give a session about this topic at XP2015 in Helsinki.

Ari Tikka
Founding Partner

Before finding Agile, Ari built software for embedded distributed fault tolerant software for seven years. For the next decade he worked as an organizational therapist with cultural change, teamwork and leadership. Since 2006 he has contributed to LeSS-flavoured Agile transformations including mechanical engineering, market automation, and embedded system development. For the last couple of years Ari had international coaching assignments ranging from teams to board.

All posts →

Ran Nyman
Founding Partner

Ran is an experienced software professional who has worked since 1995 in professional software development field. Currently, Ran is working as a consultant and trainer in process improvement field helping large multinational organizations to move from sequential product development to more agile ways of working. The primary focus has been on how to move big products (over 100 people) to use Large-Scale Scrum (LeSS) and Lean. This work includes giving wide range of trainings, workshops, team coaching and management consulting.

All posts →