This post is cross-posted from the Gosei page at their blog

Scaling Agility or Bureaucracy

There are two very different strategies in adopting Agile in a large organisation, horizontal or vertical. In other words, you may take one product first with narrow and deep focus. Or you may focus on the vertical coordination layer, which is often perceived as The Scaling Problem.

First we look into the fascinating world of control, power and culture at different layers of a large organisation. Based on this analysis we draw our conclusions about the transformative power of LeSS and SAFe.

Ouchi’s control mechanisms

Professor William G. Ouchi is known for his book “Theory Z: How American Business Can Meet the Japanese Challenge”. It introducing the principles of Japanese management to Western business audiences and stayed at US bestseller list for 15 weeks.

Ouchi also studied mechanisms of controlling work in large organisations. He focused on two simple questions:

• What are the mechanisms through which an organisation can be managed so that it moves towards its objectives?
• How can the design of these mechanisms be improved, and what are the limits of each basic design?

He identified three different mechanisms by which the control was achieved: Market, Clan, and Bureaucracy.

In real life these co-exist, but typically one dominates.

Different ways to control the work evolve based on two factors: First, are we able to measure the output, and second how well we can describe the transformation process of the work, from input to output. The following matrix classifies the conditions for the different types of control:

Layers of control and power

Let’s look at a typical large product development organisation. It may be for example the internal product development of a bank, or a commercial telecom infrastructure provider. The top management is in contact with the owners and market realities. At the bottom there are the front-line workers, in direct contact with the technical realities. The middle layer is mostly dealing with internal questions of control, coordination, intermediation, analysis and execution.

Top management – Market control and Reward power

Top management is in direct contact with the capital market and business market. They have real profit and loss responsibility for the whole company or a business unit. They make decisions on behalf of the whole: where to invest money, if a product is started or cancelled, or people hired or laid off. They have power over resources, which is called reward power.

Market control is the dominant mechanism here. It is about money. You can look it as investment game; where to get the biggest return for my money. I don’t need to know how things happen inside the organisation, but the input (money) and output (what it I get with my investment) are measured.

Market control is not feasible when an exact contract can not be made or the parties involved can not measure profit and loss. Market control also requires competition that creates an incentive for both parties to do their best, and makes sure work is done using on fair price.

Front-line workers – Clan control and Expert power

Front-line workers create the product. They work with technical realities. They have expert power – decide how to solve technical problems. Clan control is the only control mechanism that functions well when the work performed is unique, interdependent or ambiguous like software development.

Clan control is based on informal shared values and rules, traditions and beliefs. It works when the goals of the individuals and the organisation are aligned, and there is a high level of trust. Building Clan control is hard since the controlling rules are mainly informal and value based. It requires thoughtful hiring. Also, people need a long period of socialisation in order to become members of the clan.

Clan control may work at any levels of the company, but is mostly observed amongst front-line workers and teams. When the problems require, Clan control enables the most economical collaboration between front-line workers. There is no hierarchy or predefined bureaucracy that needs to be taken into account.

When observed from outside, Clan control seems to have no control. New managers often try to control the front-line workers by establishing more bureaucracy or market control. It makes Clan control hard to achieve, because other control mechanisms easily dominate.

E.g. The top management hires professional coordinators (project/program management) and gives them hierarchical authority to manage and evaluate front-line workers i.e. installs Bureaucratic control. Or the top management establishes Market control by adding evaluation and reward practices where the front-line workers compete against each other to get the rewards. These control mechanism instantiated by top management fail to work, because software development is inherently complex, unique, ambiguous and interdependent. Front-line workers in software development painfully experience and recognise this mismatch. It causes constant conflicts and frustrations between front-line workers and middle management.

The middle management – Bureaucratic control and Dependent power

The middle management works with the internal realities, possibly many handovers away from any external realities. They transmit the business contract to the front-line workers. They coordinate between different teams or individuals. They do all kind of analysis, plans and work supervision for the whole system. The legendary researcher Nonaka, the grandfather of Scrum, said that good project managers, who translate between the business and workers are essential for the successful Japanese companies (a few decades ago).

The top management has delegated some power to the middle management. The front-line workers have given some power over their doings to the middle management. So the power of the middle management depends on top and bottom. When there are many middle managers, they are also dependent on each other. They need to negotiate, which is called politics. The more middle managers, the more different roles, the more difficult politics. The level of complexity in this mess is reduced by agreed rules, responsibilities, processes and authorisations – bureaucracy.

The Bureaucratic control identified by Ouchi is based on rules, policies, a hierarchy of authority, written documentation, standardisation, etc. To make a bureaucratic organisation work managers need authority to maintain control over the organisation. One example of this control is the employment contract, where employees give power to managers to direct and evaluate their work. Employees trust that management will do a fair job in evaluation.

The German sociologist Max Weber argued that bureaucracy constitutes the most efficient and rational way in which one can organise human activity. Systematic processes and organised hierarchies were necessary to maintain order, maximise efficiency, and eliminate favouritism and other misuse of power. But Weber also saw unfettered bureaucracy as a threat to individual freedom, in which an increase in the bureaucratisation of human life can trap individuals in an “iron cage” of rule-based, rational control. – Wikipedia/Bureaucracy.

“What is not often understood is that bureaucracy developed as a reaction against the personal subjugation and cruelty, as well as the capricious and subjective judgments, of earlier administrative systems (such as monarchies and dictatorships) in which the lives and fortunes of all were completely dependent on the whims of a despot whose only law was his own wish.” – Evolution of Management Thought, 6th edition.

Bureaucratic control breaks when the work process is ambiguous, invisible, unpredictable. It also breaks when managers can not fairly evaluate the employees. Both of these happen easily in software development. The management often responds to these failures with more bureaucracy, which is part of the scaling problem.

Bureaucracy dominates

The control mechanism type evolves from the system conditions, based on what is possible, and what is economical. Ouchi compares the control mechanisms with fish living in different kind of environments. Market control is a salmon, and Clan control a trout. They survive only in clear oxygen-rich water. Bureaucracy is like a catfish. It survives everywhere, also in muddy waters. It is the winner, as long as the organisation stays alive.

The fundamental mechanism of power, as recognised by Ralph Stacey, is “Power constrains the enabling conversation in organisations.” You enable desired patterns by releasing constraints and dampen undesired by adding constraints. You direct by lowering constraints in the desired direction. From this follows that it requires skill to use power with minimal friction and loss of energy. Bureaucracy is very effective in creating constraints. The more fragmented organisation, the more (conflicting) rules, the more friction – waste.

Control in Scrum

One-team Scrum beautifully creates the minimal bureaucracy, that enables the Market control and Clan control to be in dialogue. There are some rules but no middle manager roles.

The product owner can make a bounded risk investment. The input is measured accurately. Referring to Ouchi’s definition of Market control, the Product Owner can evaluate the result after an iteration. The Product Owner herself is evaluated based on her achievements using Market control. The team has conditions, which enable Clan control, for example a clear goal, immediate feedback, autonomy over it’s own ways of working, and empowerment to act on emerging impediments.

How to scale this to large organisations?

Organisational layers in LeSS and SAFe

We have now analysed the layers of a typical large organisation and compared it with the elegance of Scrum. Next we look how LeSS and SAFe deal with the layers in large organisations.

More with LeSS – minimise bureaucratic control

LeSS has Scrum in the center. It provides a set of principles, rules, guides and 600 experiments that help to change the surrounding organisation so, that Scrum scales up to a whole organisation. From the control perspective, this means minimising Bureaucratic control and getting Market control and Clan control into a close dialog.

LeSS adoption aims to remove the coordinating and intermediating middle management roles. The teams need to have as direct contact as possible with the business and with the customers. There is no program (coordination layer) – the empowered real Product Owner decides, and Teams with direct customer interaction clarifies needs. This reduces the work for the bureaucratic layer dramatically. What to do with the coordinators and managers? They will learn new things, move into teams, move to product management to work with the customer, or take a coaching role. There is job security, but no role security.

Reducing Bureaucratic control is only possible when the whole organisation from the real business to teams is changing together. LeSS has narrow and deep focus to ensure enough support for the organisation changing, to limit the risk, and to have a real working example for the neighbouring products after the first success.

Play SAFe – better coordination

The SAFe big picture fits perfectly to the typical structure of an existing large organisation. It introduces a new coordination process for the middle layer. The top layer of SAFe big picture is portfolio coordination, high-level queue management. Scrum, which is at it’s best in creating the dialogue between Clan and Market control, can be seen at the bottom.

SAFe removes projects that control individuals’ time, but is liberal in having old and new coordination roles in the middle management. This means that the proportion of the bureaucratic control is not reducing significantly. This is logical because of systemic conditions remain the same, or change slowly. When the need for coordination stays, the coordination stays.

SAFe actually takes granted that you need the various middle management roles. “We need to have people in roles (it doesn’t matter what their titles are) that can take a large initiative, break it into smaller initiatives, manage the small initiatives, and deliver them. You have to have that.” – http://www.ugilic.dk/blog/2017/04/interview-with-dean-leffingwell-about-safe/

To support the process, SAFe provides a wide set of Lean-Agile best practises to improve the ways of working. Good consultation often helps to get results, also with SAFe. However, there is the risk that the systemic conditions are not changing, and the change remains superficial.

Conclusion – two different local optimums

SAFe and LeSS target into two different local optimums, each having a consistent set of practises, structures, skills, technology and culture. This has an analogy to species in nature. Grass-eaters and predators have different combinations of characteristics.

SAFe is not aiming to reduce the Bureaucratic control enough to move the organisation away from the Traditional optimum. Instead, it tries to optimise the existing organisation by creating Lean-Agile programs. The project/program management is an old mainstream practise at this optimum.

LeSS aims to reduce significantly the Bureaucratic control. It provides a mutually consistent set of practises that move the large organisation to a new Agile-optimum. In next blogs we will write more about the characteristics of the two optimums.

Some references and further reading on topics covered in this blog post:

• William G. Ouchi: A Conceptual Framework for the Design of Organizational Control Mechanisms, Journal Article, 1979, Management Science p833-48
• William G. Ouchi: Markets, Bureaucracies, and Clans, Administrative Science Quarterly, Mar 1980, v25 n1 p129-41
• Ralph Stacey: Complex responsive processes in organizations, ISBN-13: 978-0415249195
• Daniel A. Wren, Arthur G. Bedeian: The Evolution of Management Thought, 6th Edition, ISBN 978-0-470-12897-8

Descaling Organizations with LeSS

Scrum is a successful and widespread framework, but at some point almost everyone started to talk about scaling. Large organizations want to spread this miracle and Agilize everyone. Many consider agilizing large organisations as bad, and some say it is inevitable. In any case, opinions are often negative about “big Agile”.

But what exactly is being scaled when we talk about scaling in Scrum or Agile software development? It seems that most imagine growing something larger, usually the number of people, or painting everyone in fake Scrum colours. “I see task boards, task boards everywhere!”. :-)

Naturally, this triggers negative reactions from the Agile community.

“Why would you want to deliver and support a product with multiple teams, when one team is so much more effective?”


The first purpose of LeSS (Large-Scale Scrum) is actually descaling through organizational change. Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about scaling one team into multiple teams. LeSS is about scaling up Scrum itself in order to achieve organizational descaling. Just to be clear, looking for a scaling framework to “buy and install” and to organize lots of people for the sake of “painting agile or Scrum onto our big group”, is just plain wrong.

A major purpose of LeSS is to expose the pain of being large, wasteful, and slow.

Fake Descaling with Fake Small “Products”

Here’s a common thought that people have when they learn and like the idea of descaling, rather than “big Agile”:

Why should an organization scale up Scrum? Why not just have many independent Scrum teams, each dealing with their own product and own users?


This leads to a very important question: What should be the definition (or scope) of a product?

Bas Vodde, the co-creator of LeSS (Large-Scale Scrum), gave this nice explanation:

Having multiple ‘fake’ small products that don’t deliver any real value is not better. Neither is losing the overview due to many small products.

Contrast these situations:



Small independent products

We take the large product and split it into smaller ‘independent’ products, with a few dependencies. This is nice as smaller is better. However, now in the organization we’ll need to figure out which of the products the teams need to work on. So therefore, we’ll need to add “portfolio management” so that we ensure the teams work on the high value products.



Not only that, we have now dependencies between the products. These are outside the products and hence it is probably more difficult to see when they happen and harder to coordinate by the teams themselves. Thus, we’ll need to add some project/program management to ensure the features in different products are synchronized.



Where do we put all that. Probably a PMO which we’ll need to create for that.

Large product definition

Now, the alternative. We define product broader. This means we’ll more quickly end up with LeSS Huge… but… we don’t need any additional portfolio management nor any project/program management to deal with all the organizational issues and different resource allocations :)

Though, we have a large-scale product… all these things are managed within the LeSS framework and … thus actually much less complex. Less roles, less management and a better overview.



Hence, we prefer a broader product definition, unless the products are truly independent products

A similar comment could be said about users and customer, since they are very much connected to definition of a product. A team dealing with a fake small “product” is likely to have fake users. “Our user is another product, and our customer is an IT application manager”. Or even worse, “Our user is the QuotingEngine,” where the so-called “products” are just architectural components, and other components are fake users. You don’t make any money from another internal component!

How LeSS Helps in Descaling

Just like Scrum, LeSS removes your organizational band-aids that apparently solved the problems, but actually masked them and didn’t address the root causes. “We have a quality problem, let’s create a quality manager, and then the pain is gone… for now.” Scrum is a band-aid removal system on a team scale, while LeSS is a band-aid removal system on a multi-team and organizational scale. With LeSS, transformation happens along two dimensions:

1. Do the right thing and always the most important thing

Create organizational flexibility to always work on the most important goals from the overall customer-perspective product level, based on recognizing a world of learning and change. LeSS replaces big-batch and rigid portfolio management practices and decisions, where investments are matched to objectives, often for a year or even longer. The traditional project and portfolio management model also implies a fixed allocation of teams to specific programmes and projects, also for a long time.

In contrast, an example of the LeSS solution is one Product Backlog and one Product Owner for a whole product. Based on feedback and learning, a Product Owner can change direction and assign new goals with increased flexibility at a low cost of change, since teams are not fixed within boundaries of projects and programmes.

2. Do things right

Each cross-functional feature team grows capability and responsibility for taking care of the whole value stream. Ideally, all teams co-create and maintain value together with the end-customer. The Definition of Done is far-stretching and all teams deliver each Sprint one single potentially shippable product increment for all involved teams. The foundation for this is made up of technical-excellence practices such as continuous integration, ATDD, TDD, etc.

Descaling Roles, Structures, and Workforce


During a LeSS adoption, along both dimensions of “do the right thing and always the most important thing” and “do things right”, it becomes painfully evident that parts of the original organizational structure are not needed. For a single product, a LeSS organization does not need portfolio, programme, or project management. It does not need a separate analysis, architecture, UX, or QA/test group. It probably does not need a separate operations group.

In LeSS, the basic organizational building block is the cross-functional and cross-component feature team. Most people will simply become regular members of feature teams, delivering running, tested features and a shippable product every Sprint. It’s very simple. There are no fancy titles, no release trains, no layers of management. But some people will also leave because they do not fit in this new value-driven organizational structure that emphasizes hands-on making solutions over status and “managing”.

We often have a gut feeling that there’s untapped potential: what if our organisation can create value with fewer teams, or even with a single team? If that possibility is present, how would we know what to look for? LeSS gives us the means to see this potential, and act upon it.

A goal of LeSS is to create a learning organization with a high level of collaboration and knowledge sharing through communities and other means of coordination. This is important to prevent duplication and the potential architectural chaos of having many empowered but potentially disconnected teams. But a learning organization doesn’t happen overnight. An organization that grows this culture, driven by the LeSS framework, will take time.

In short, LeSS is a scaled up Scrum framework, which enables descaling of the organization.

Also posted on leanarch.eu blog

I recently attended the first of hopefully many Certified LeSS Practitioner Courses in London. We were facilitated, trained and educated by Craig Larman, one of the co creators of the LeSS framework to scaling agile in organisations. Over a year prior to the course, I had participated as one of the lead coaches in a LeSS adoption for a large gambling company, so I had already read the two existing books, Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum: Successful Large, Multisite and Offshore Products with Large-scale Scrum and Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum.

Coming into the course, I felt I knew LeSS and that I was at risk of just hearing everything I had already read. By the end of the first session that was no longer a risk. Overall, my key takeaways were learning from hearing how Craig applies LeSS with clients, attaining a deeper appreciation for the interrelatedness of all the rules and principles, and how much LeSS really is just Scrum, done properly. I also felt challenged in how I understood some parts of basic scrum, and the debates were super beneficial. I also learnt new tools, in particular, Causal Loop diagrams. I really enjoyed Craig’s approach, and “a man walks into the bar” jokes running throughout the course.

So suggested preparation for the course: Know scrum, read the scrum guide,again. Read the 2 and soon to be third book from Craig and Bas on LeSS. There is an assumed level of Scrum to do the course, and I would advise against doing the course if you do not know Scrum very well.

Would I recommend the course: Yes, wholeheartedly. If you have an interest in deeply understanding how to approach “applying scrum” and what supporting factors you need to consider to do so, for one or more teams, then this is a great course to attend. So much so, that I am looking forward to attending the upcoming course lead by Bas

Also, some participants in London gave feedback during an interview, you can find that video here

This post is cross-posted from the Tabar page at their blog

LeSS is more in Australia

It was great to have Bas Vodde in Melbourne from 24 - 26 February 2015 to bring the first Certified LeSS Practitioner course to Australia. Its been several months in the making following a plot with Bas to visit Australia, crafted over great Japanese barbeque and Sake at Clarke Quay in Singapore. The Melbourne location was also good enticement to exploring Tasmanian Whisky in pursuit of the most excellent in the world! With that trigger discussion still clear in my memory I started day 1 of the 3 day LeSS training with Bas and 15 others at our partner organisation Elabor8’s training room.

My initial expectation of LeSS was that there could not be that much more to scaling Scrum that we weren’t already intuitively doing in some way, so anything new under the sun? I was very wrong! It dawned quickly that what Bas presented was taking Scrum itself to a whole new level of excellence! What I learned was somewhat of a surprise because “LeSS lets you do better Scrum” too. It’s not only about scaling teams and large product delivery but also at the same time amplifying the practical goodness at the heart of Scrum i.e. the agile stuff that really works. The course also brings many new agile aspects to the fore while also remaining simple, compact and focused. The particularly powerful concepts that resonated deeply with me were:

• Steps and strategies to evolve Agile scaling into the wider organisational context in a low risk productivity enhancing way
• Building cross functional feature teams across the organisation while driving understanding and contribution to the business domain
• Applying organisational, product and process improvement from running retrospectives (overall) at scale emphasising that learning is at the core of LeSS
• Specific roles for management steers them in support of teams and not control of people
• Managing the one product backlog and driving Done and Un-Done work to get to extended enterprise level “totally Done”
• Sincronisation of sprint time boxes into the same calendar cycle
• What do we do when the product requires more than 8 teams i.e. going “Less Huge”
• Two step sprint planning to cover enterprise level and team level planning for delivery
• Managing the backlog according to dynamic requirements areas that reflect the enterprise contexts
• Moving the teams and the organisation structure to customer and whole product focus
• Applying Less principles underpinned by systems thinking that further enhance and support better Scrum
• Moving away from project focus to continuous emergent Inspect and Adapt driven delivery
• Moving from component teams to feature teams using a planned strategy based on a long term adoption map
• Sometimes temporary fake product owners are valuable and needed!
• Using and authority matrix to differentiate responsibilities for product owners, management and teams
• The simplicity at the core of LeSS will de-complicate the organisational structure over the longer term and drive efficiency

In summary LeSS is not only about how to scale Scrum into a transforming organisation but also how to do better Scrum at every level. This emerged strongly from the stories throughout the training informed by Bas’s years of experience and deep thinking on practical application of LeSS.

Indeed a great start to more LeSS being done in Australia! I am convinced that LeSS.works as what happened to the relatively recent and unknown Tasmanian Whisky is also earmarked to become the de-facto reference to Scaling Agile excellence in the world. Go LeSS!

This post is cross-posted from the Gosei page at their blog

Comparing LeSS and SAFe

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 are your consultants, 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.

Next

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.