LeSS - Large-Scale Scrum Site

What Leaders Get Wrong About Knowledge — and Why the T-Shaped Model Misses the Point

wolfgang-steffens — Fri, 06 Mar 2026 00:00:00 +0000

There’s a hidden assumption behind most organizational charts and role descriptions — one that shapes how work, teams, and even people are designed.

It’s the belief that knowledge is fixed, that what someone knows defines what they can contribute.

That’s why we hire specialists, build silos, and admire deep expertise. But we forget something fundamental: Learning is humanity’s greatest skill.

Humans are not static repositories of expertise — we’re adaptive learning systems. We learn through collaboration, experimentation, and purpose.

So why do so many organizations treat their people like components in a machine, squeezed into narrow specialist boxes or T-shaped clichés?

“Do you want a heart surgeon to fiddle in your brain?”

That’s the usual argument when I talk about building multi-skilled product developers.

And sure — I don’t want a heart surgeon operating on my brain either. But software development, product design, or even organizational improvement aren’t brain surgeries. They are collaborative problem-solving systems where value emerges from integrating perspectives — not from protecting silos.

The problem isn’t that people can’t learn; it’s that the system doesn’t allow them to. We create processes, KPIs, and career paths that reward staying in your lane instead of learning something new.

The Multi-Skilled Product Developer

A multi-skilled product developer is not a generalist who dabbles in everything. They are someone who can:

Work deeply in their main area (say, backend development)
Contribute meaningfully in adjacent areas (frontend, testing, analysis)
Mentor junior colleagues
Understand the product and customer context
Collaborate across boundaries

They don’t replace specialists — they make collaboration work.

Multi-skilled developers increase adaptability, reduce dependencies, and create resilience in the product team. When work shifts, they shift with it. When problems cross boundaries, they follow the value, not the job description.

Learning Is the Leverage Point

If learning is a human’s greatest skill, then organization design should amplify it, not restrict it.

Design structures where learning flows freely:

Cross-functional teams rather than departmental silos
Shared backlogs rather than local priorities
Collaborative goals rather than individual KPIs
Time and safety to explore new domains rather than punishing mistakes

That’s how people — and organizations — become adaptive.

The Bottom Line

You don’t get resilience by hiring the best specialists. You get resilience by designing for learning.

So the next time you think,

“I don’t want my backend engineer touching the frontend,”

ask yourself instead:

“What system have I built that prevents learning, collaboration, and adaptability?”

Because the future doesn’t belong to the most efficient specialists — it belongs to the fastest learners.

Visit kaikaku.fi for more insights on organizational transformation and learning.

Project-based funding in Product Development

bas-vodde — Fri, 20 Feb 2026 00:00:00 +0000

In a good and evolved LeSS adoption, there are no projects in product development.
— Bas Vodde

In LeSS, development changes from project-based development to product-based development. What does that mean in practice?

Project-based development

Project-based development uses the concept of projects for managing work. A project has a goal, a relatively fixed scope, an expected timeline, and is funded and prioritised as one whole. When a project is over, it is over. If you want new work to be done, you’ll need to fund a new project. Management often assumes projects are independent of each other, while that is rarely true when they use the same technology infrastructure.

Product-based development

In product-based development, the construct and concept of projects is not used. Instead, we define a product broadly. Then we speculate about the large features we might want and put these on a roadmap. A Product Roadmap is a high-level view of a Product Backlog. The product is funded as a whole based on the value of the currently speculated features. Teams work from the one Product Backlog until the product ceases to exist. A release is simply a point in time where we decide to ship what we have right now. Ideally, this happens as often as is feasible.

Key shift:
From funding temporary projects → to funding a long-lived product.

When ditching projects is too big a step

Unfortunately, for many companies, ditching project-based development is too large of a change as their entire funding and governance models are project-based. In that case, what can you do? It is possible to create project-based funding and reporting while doing product-based development. It has its drawbacks, but it is a reasonable intermediate strategy until a change in the governance model is possible to be discussed.

Project funding, product development

How does it work? The company still plans and funds projects like they’ve always done. Then we take the scope of each of these projects and smash them together in one Product Backlog. However, each item has a project associated with it. This is hidden (as it is irrelevant) towards the teams. The teams work from the one Product Backlog without ever being aware of the existence of projects. Teams might even work on multiple projects in the same Sprint without being aware of that. But because each item is still associated with a project, we can create traditional project reporting as if there are projects in development.

Important:
Teams see one Product Backlog.
Projects exist only for funding and reporting.

A necessary condition

I’ve seen this being used in several companies, especially banks and insurance companies as they tend to be project-heavy. In order for this to work, at least one change is required. When funding and deciding on projects, they should have no assigned fixed people to these projects. This change can be different as people in companies want to secure ‘their’ project by having dedicated ‘resources’ on them… Hence, this simple change often requires a lot of discussion but it has been done before.

The end state

Eventually, we would recommend getting rid of projects completely. Keeping projects (even just for funding) causes a lack of flexibility in your development and an unnecessary additional complexity. In a good and evolved LeSS adoption, there are no projects in product development.

Three Metrics of Adaptiveness: Comparing LeSS and SAFe

illia-pavlichenko — Fri, 23 Jan 2026 00:00:00 +0000

Adaptiveness at product level can be reduced to three very concrete metrics:

how much started but not finished work (WIP) you carry at the product level at the end of the iteration,
how fast the product turns ideas into potential value (Lead Time),
and how easily any item from the Product Backlog can be handed over to any team (% of product items available to ≥80% of teams) in order to ensure work on the most valuable things at the product level.

1. WIP at the end of the iteration: how often the system “resets”

The first key metric of adaptiveness is WIP at the product level (or train level in SAFe) at the end of the iteration. It does not matter how agile an individual team is if the product as a whole is overloaded with started but not finished work. This unfinished work at the product level directly takes away your ability to sharply change the direction of the product when the context or priorities change.

In a good LeSS implementation, the product lives in short cycles: 1–4-week Sprints, a single Product Backlog, a single Definition of Done (DoD), and a single shared Increment for all teams. This creates the possibility of having WIP ≈ 0 at the end of every Sprint at product level: everything that was started is brought to Done, and the next iteration starts with a clean system.

In SAFe, work is aggregated around the Agile Release Train and Program Increments (PIs), usually 8–12 weeks. At PI Planning the train takes on a significant amount of work in advance, teams fix their PI Objectives and commitments, and the real “reset” of product/train WIP happens only at the end of the PI, while inside the quarter the train lives with high systemic WIP.

The more often product-level WIP returns to zero, the easier it is to radically change priorities without breaking the entire plan. LeSS is deliberately aimed at enabling the product to reconsider the entire Product Backlog every Sprint, while SAFe is aimed at enabling the train to hold its commitments over the PI horizon.

2. Lead Time from idea to potential value

The second metric is Lead Time from idea to potential value. Lead Time makes sense to measure at the product level: from the moment a new idea or request first appears in the Product Backlog to the moment when the change is part of a Done Increment and carries potential value for the user.

In LeSS, short Sprints and a single Product Backlog make it possible to quickly “push through” high-priority items across the entire product: the Product Owner reorders the Product Backlog, and already in the next Sprint several teams can focus on a new idea, turning it into potential value ready for release.

In SAFe, major course changes are more often reserved for the PI boundary: changing a significant part of the PI Objectives in the middle of a PI is expensive, politically difficult, and risky for train synchronisation. Formally, Increments can be released more often, but the organisational design of the train nudges you to wait for the next PI Planning for serious changes, thereby extending the actual Lead Time from idea to potential value for unexpected requests.

3. % of product items available to ≥80% of teams: a proxy for switching costs

The third metric is a proxy for “switching costs” at the product level: the percentage of items in the Product Backlog that can be worked on by at least 80% of the product’s teams.

In LeSS, the structure is deliberately rebuilt around feature teams: they are cross-functional and cross-component, capable of delivering end-to-end product features without dependencies. Regular multi-team Product Backlog Refinement sessions create shared understanding of product items across several teams, and the share of items that, in principle, can be taken by the vast majority of product teams grows over time.

In SAFe, train teams often specialise in components, subsystems, or narrow domains. This reduces the percentage of items in the product/train backlog that are available to most teams and increases the dependence on specific teams as “bottlenecks” for particular areas.

From the perspective of Transaction Cost Economics (TCE), this is a direct impact on transaction costs and switching costs: the higher the percentage of items available to ≥80% of product teams, the cheaper and faster the product can reassign work in line with changing priorities, and the less it gets stuck in an outdated plan.

A real LeSS case: five interchangeable feature teams

In one of the LeSS cases (SBP), it is clearly visible how these three metrics show up in practice exactly at the product level.

There were five interchangeable feature teams working on a single product in two-week Sprints. Each team could take almost any product feature within the domain — thanks to the feature-team structure and regular multi-team PBR, where teams jointly refined items from the shared Product Backlog. This gave a high percentage of items available to most product teams, and not just to one or two “elite” teams.

In the photo of the board from the middle of the Sprint there are three columns (roughly: To Do / In Progress / Done) and WIP = 5 at the product level: each team has one feature in progress, and all items are moving towards Done. At the same time, by the end of each two-week Sprint, product WIP systematically tended towards zero: everything started was brought to Done, and any unfinished work was consciously removed and returned to the reordered Product Backlog, opening the way to new priorities and new potential value.

As a result, the product in this LeSS case had high business flexibility:

low WIP at the end of every short product iteration,
short Lead Time from idea to potential value,
a high percentage of items available to most product teams, which means low switching costs and a real ability to manoeuvre.

LeSS and SAFe through the lens of three metrics

LeSS optimises adaptiveness at the product level through a single Product Backlog, a single Increment, feature teams, and multi-team PBR, which together create the conditions for frequent “resetting” of product WIP, reducing Lead Time and lowering switching costs thanks to high team interchangeability.

SAFe optimises coordination around the train and the PI: this gives a strong synchronisation structure, but often at the cost of higher product WIP for the whole quarter, a long path from idea to potential value for unexpected changes, and strong dependence on specialisation of train teams, which increases switching costs.

What to choose? Ultimately, it all comes down to an honest answer to the question: what level of flexibility do you really need?

If you operate in a low-competition market — for example, you are a state monopoly or a large organisation with slowly changing regulation and predictable demand — then SAFe might indeed be enough for you, where you can reconsider the product direction every 8–12 weeks at the PI level.

If, however, you live in a turbulent market — fintech, e-commerce, online services, B2C products with strong competition — and want to be truly flexible, to change product direction every 1–4 weeks, then you need to keep WIP and switching costs low at the product level, and your choice is LeSS.

Stop Building Fake Platforms

jurgen-de-smet — Tue, 09 Dec 2025 00:00:00 +0000

Why collapsing platform silos and forcing them to earn adoption is the only way to achieve speed, efficiency, and customer focus.

Large, software heavy companies are under constant pressure: customers expect seamless digital experiences, new channels, and rapid innovation. To cope, many companies try to “go agile.” The playbook often includes setting up platform groups to reduce duplication and support product teams.

But here’s the trap: these groups are usually split into “technical platforms” (infrastructure, CI/CD) and “business platforms” (catalogs, payments, customer accounts). At first glance, this looks smart. In practice, it creates silos, dependencies, and frustration.

A better path is to consolidate all non-differentiating functionality into a single commodity platform group. Governed by Russell Ackoff’s Internal Market Economies (IME) principle, this model creates clarity, independence, and speed at scale.

When Platform Groups Become a Problem

Picture a global retailer with a booming e-commerce arm. Leadership decides to get serious about agility and sets up two flavors of platform groups: one to build CI/CD pipelines, run cloud hosting, and manage monitoring tools; another to handle shared services like product catalog, customer accounts, and order tracking. On paper, this should free up product teams to focus on customer-facing apps and websites. But reality is messier.

The technical platform group proudly rolls out a new CI/CD pipeline. Teams running the webshop and mobile app rush to adopt it, only to discover it doesn’t support their integration testing setup. They file requests for improvements. Weeks turn into months. Some teams grow impatient and script their own release workarounds, fragmenting the very consistency the platform was supposed to create.

Meanwhile, the business platform group is redesigning the “customer account” module. Product teams are told they must use it. But the rollout slips, and when it finally arrives, it enforces flows that don’t fit the mobile checkout process. Suddenly, teams can’t release new features without adapting to the platform changes. Worse, when the account module updates again, all consuming teams are forced into simultaneous updates, wasting cycles on unplanned rework.

At this point, the cracks are obvious. Two platform groups with separate roadmaps and governance structures create duplication and siloing. Reciprocal dependencies arise, where the platform groups need requirements from product teams while product teams need working services from the platforms, so neither can move without endless coordination. “Fake platforms” sneak in, like a catalog service that only works for the webshop but not for the mobile app or marketplace, burning budget without creating scale. And autonomy disappears: product teams are dragged into lockstep with every platform release instead of focusing on shoppers.

What was meant to accelerate delivery now slows it down. Engineers are frustrated, customers wait longer, and leadership wonders why agility never materializes. This isn’t rare: a survey of platform engineering leaders suggests ~67% of platform initiatives struggle to scale or deliver against expectations. In industries like IIoT and incumbent digital platforms, studies show many investments don’t yield the returns hoped for.

The Commodity Platform Group

The antidote is straightforward: instead of fragmenting into technical and business platforms, create a single, larger commodity platform group responsible for all non-differentiating functionality.

For our retailer, this means CI/CD pipelines, hosting, observability, monitoring, and API gateways on the technical side, combined with authentication, authorization, notifications, customer profile stores, and generic payment rails on the business side.

The rule is simple: if multiple product teams need it and it doesn’t set you apart in the market, it belongs in the commodity platform. Everything else lives with the product groups. This model avoids duplication, clarifies ownership, and makes it obvious what belongs where.

The iOS Analogy

The best way to picture this is through Apple’s iOS ecosystem. Apple continuously evolves iOS: new APIs, improved performance, additional features. But app developers are never forced to update in lockstep.

A fitness app can adopt the latest Health API in iOS 18, but if it doesn’t, the app still works fine on iOS 17. The platform evolves on its own schedule. Apps evolve on theirs. The contract between them is stable.

Meanwhile, iOS takes care of all the commodity services: push notifications, biometric authentication, secure storage, networking, camera APIs. No app developer wants to reinvent those. They just use them when it makes sense.

This is how a commodity platform should operate inside the retailer: the platform group evolves authentication, CI/CD, or customer profiles at its own pace. Product groups (e.g. the webshop, the mobile app, the marketplace) choose if and when to adopt new features. Stable contracts prevent lockstep dependencies. Everyone benefits from consistency and scale, without being chained together.

Internal Market Economies for Commodity Platforms

Russell Ackoff’s Internal Market Economies (IME) makes this model stronger. Under IME, the commodity platform group is not a monopolistic utility that dictates what everyone must use. It operates like an internal business in a market.

That means the platform group can only demand a market-conform subscription fee. If its price is out of line with external providers or in-house alternatives, product groups won’t buy. Just as important, product groups have freedom of choice: they can decide whether to consume a service from the commodity platform or source it elsewhere. Adoption isn’t forced; it has to be earned.

Take authentication as an example. The commodity platform might offer login and identity services at €0.01 per active user per month. Product teams compare this to an external identity provider charging €0.009. Because the external option is cheaper, yet the internal option is better integrated with existing data, the product teams choose it. But the choice matters, if the internal platform ever drifts into overpriced or clunky territory, teams can walk away. That freedom keeps the platform lean and user-focused.

This financial discipline means the platform group must stay healthy. It covers its costs through the subscription fees paid by its internal customers. If adoption drops, revenue drops and the platform faces pressure to improve, streamline, or even shut down.

For the wider organization, the effects are powerful. Commodity services are delivered at a fair price, benchmarked against the market, so bloated IT monopolies can’t hide. Budgets flow where they belong: if the webshop consumes half the platform’s services, half the bill lands there. That transparency creates discipline. Platform groups can’t inflate scope or build pet projects; they must deliver what multiple product groups truly need.

And because survival depends on adoption, the platform evolves constantly. Just as AWS cuts prices and adds features to stay attractive, the commodity platform group has to improve its developer experience, lower costs, and enrich its services. This keeps the whole system aligned with strategy: product groups invest their budgets in differentiating features (e.g. smoother checkouts, smarter recommendations, new channels) while the commodity platform focuses on rock-solid, shared foundations like authentication, notifications, and infrastructure.

The result is a self-regulating system. If the platform delivers value, adoption grows, economies of scale kick in, and unit costs fall. If not, product groups walk away and the platform must adapt or disappear. It creates a healthy balance: product groups obsess over customers, while the commodity platform group obsesses over enabling them.

Conclusion

Large software players don’t need a zoo of technical and business platforms. They need a single commodity platform group: self-service, non-differentiating, used across product groups.

When run under Internal Market Economies, this group earns adoption instead of mandating it, creates financial transparency, and evolves under real demand. Crucially, the platform must stay financially healthy, covering its costs through internal subscription fees. This ensures adoption is not just a vanity metric, but the lifeline that keeps the platform lean, user-focused, and accountable.

The logic is the same as iOS: a stable, evolving foundation; apps (product groups) adopting new features when it fits their goals; and a clean separation between commodity and differentiation.

Benefits Across the Organization

Product Groups

Regain autonomy: can evolve at their own pace.
Faster time-to-market: no waiting for platform updates.
Clear focus on differentiating features that win customers.

Commodity Platform Group

Clear mandate: deliver only non-differentiating foundations.
Reduced waste: no building one-off features for single products.
Financial discipline: must cover its costs through adoption-based fees.
Market-like pressure keeps quality and developer experience high.

Finance & Leadership

Financial transparency: costs linked directly to consumption.
Economies of scale: unit costs drop as adoption grows.
Easier investment decisions: focus spending on real differentiators.

Customers

Faster, more reliable feature delivery.
Consistent experiences across channels (web, mobile, marketplace).
Higher trust thanks to secure and reliable shared foundations.

The payoff is real: financial clarity, economies of scale, autonomy and speed for product teams, and stronger focus on the end customer. Anything else is just another central IT empire with slicker branding.

Jurgen De Smet is a Certified LeSS Trainer and organizational simplification expert who writes about cutting through complexity to deliver real value. If this article challenged your thinking about platforms and organizational design, explore more of his insights on SubStack.com where he regularly shares practical strategies for achieving speed, autonomy, and customer focus at scale.

What my daughter's film industry job taught me about AI and the future of work

craig-larman — Thu, 30 Oct 2025 00:00:00 +0000

I have a sister and a daughter who work in the film industry. What’s happening there should terrify every organization leader.

Productions that currently take 1,000 to 2,000 people to complete are shrinking dramatically. Not by 10%. Not by 20%. The scale of reduction is orders of magnitude larger.

This is happening right now. These are very early days for AI, and the disruption is already visible.

The 2027 threshold

My thesis, which I’ve shared at every LeSS conference keynote since 2020: by October 2027—maybe within two years—we’ll see news of the first job category meaningfully replaced by AI.

I know this sounds like crying wolf. I understand the skepticism. But the boiling frog dynamic is already underway, and it will intensify over the next decade.

Here’s why this matters: these AI systems will be cheap as dirt. They work 24-7. They don’t ask for a vacation. They don’t ask for time off. The labor economics incentives to replace humans will be compelling. Not because companies are cruel, but because the math becomes irresistible.

We humans won’t compete if our only pitch is “please hire me, I’ll make you 10% better.” That won’t cut it anymore.

Throwing out Jerry Weinberg’s 10% rule

Jerry Weinberg wrote in Secrets of Consulting that you should never recommend more than a 10% improvement in business. There’s a whole bunch of interesting reasons for that advice.

But at this milestone we’re approaching—this disruption in intelligence-as-a-service—we need to suggest something more ambitious.

Ten times more ambitious.

The 10x org

One of the LeSS guides is “more outcomes, less outputs.” We focus on business impact, not just on producing more stuff. The 10x org takes that principle to its logical extreme: ten times the business impact, ten times the market share, ten times the revenue.

Before AI, that suggestion would have been ludicrous. Now I think it’s the survival strategy.

The core insight comes from org topologies. Think of it as a two-by-two matrix. When both the scope of skills mandate and the scope of work mandate are high, you land in the adaptive quadrant.

That’s always been the LeSS message. But we’re expanding it to a far broader audience—to all the markets that AI will disrupt. Moving to the adaptive quadrant is the fighting chance for our children and grandchildren to have good jobs.

The adaptive quadrant is where humans can deliver impact that no AI can match by following narrow scripts. It’s where people with broad skills and broad mandates can respond, adapt, and create value that multiplies rather than increments.

My mission

Hi, my name is Craig, and I’m trying to create good jobs for our children. That’s my professional mission for perhaps the next 10 or 20 years.

I have grandchildren now. Those of you who’ve been at previous conferences with me understand my motivation.

The adaptive organization isn’t a nice-to-have anymore. It’s the perfection vision of where LeSS gets to. And it’s how humans stay relevant in the labor market that’s coming.

unFIXing Your Organization With LeSS: the complete guide

robert-briese — Thu, 14 Aug 2025 00:00:00 +0000

unFIXing Your Organization With LeSS: the complete guide

An article by Robert Briese, LeSS trainer and unFIX practitioner.

Discover how combining unFIX and LeSS can help your organization scale agility with structural clarity and collaborate product delivery.

1. Introduction

Organizational agility is no longer a luxury but a necessity in today’s fast-moving business landscape. As you already know from working with unFIX, a flexible organizational design can help teams adapt swiftly to change, spark innovation, and deliver value to customers more effectively. Yet, when it comes to scaling product development across multiple teams, many organizations struggle to align structure with execution in a clear, cohesive manner.

This is where LeSS (Large-Scale Scrum) comes into play. While unFIX offers a versatile pattern library for shaping and reshaping organizational designs, LeSS focuses on multi-team product development through minimal rules, clear principles, and empirically driven experiments rooted in Scrum. By introducing the LeSS rules and using the unFIX-designed structure, you can not only visualize and adapt your current organizational setup but also ensure that the day-to-day product-development processes are straightforward, aligned, and optimized for true organizational adaptability.

In this article, we’ll explore four essential insights that illuminate how unFIX and LeSS complement each other:

Shared Goal – Both aim to foster agility in organizations.
Differentiation – unFIX provides the pattern library for modeling and redesigning organizational structures, whereas LeSS represents an organizational system for product development with a set of fixed rules, core principles and various guides and experiments aimed at maximizing an organization’s adaptiveness.
Versatile Toolbox vs. Framework – While unFIX is a flexible toolbox for various optimization goals, LeSS is a more prescriptive set of rules and guides for an organizational design focused on maximizing value delivered to customers and end-users.
Processes – unFIX intentionally avoids prescribing processes, whereas LeSS adapts the simplicity of the Scrum rules for product development in a multi-team environment, emphasizing empirical process control.

I will show how combining unFIX and LeSS delivers powerful results, with unFIX giving you a clear picture of how your organization is structured and how it might evolve, and with LeSS, providing proven, lightweight governance for product development across multiple teams. The goal is to equip you with practical steps for introducing LeSS principles into an unFIX-modeled organization—helping you maximize both adaptability and value delivery in a large-scale setting.

2. Introducing LeSS (for the unFIX Community)

For those experienced with unFIX, the idea of designing flexible, value-focused structures is second nature. However, once multiple teams and complex product initiatives enter the picture, the question becomes: How can we coordinate and align these teams without bogging them down in bureaucracy or losing agility? This is precisely the challenge that LeSS (Large-Scale Scrum) addresses.

Figure 1: The LeSS Complete Picture

Origins and Core Principles

LeSS, developed by Bas Vodde and Craig Larman in 2005, grew out of the need to scale Scrum without compromising its core values and simplicity. They documented over 600 agile experiments in their first two scaling books, and spent a few years distilling their continued experience down to a minimal barely sufficient core: the LeSS rules and a few principles. Here are a few of the 10 LeSS principles that should guide experimentation and adoption:

Lean Thinking: Focuses on minimizing waste and amplifying learning in all areas of product development.
Systems Thinking: Helps teams recognize interdependencies and unintended consequences, reinforcing holistic improvement instead of local optimizations.
Empirical Process Control: Retains Scrum’s reliance on short iterations, clear feedback loops, and continuous inspection and adaptation.
More with LeSS: Recognizing that innumerable roles, complex processes, and over-abundant artifacts lead to inflexible and slow organizations and looking for ways to simplify the organization.

In the following picture you can see all 10 LeSS principles:

Figure 2: LeSS Principles

Minimal Rules, Big Impact

Unlike traditional scaling frameworks that can feel top-heavy, LeSS emphasizes a “bare minimum” approach, which is in line with the More with LeSS principle. Its ruleset is intentionally small, guided by principles that empower teams rather than dictate every detail. Key elements include:

One Product Backlog shared across all teams, providing a single source of prioritized work.
One Product Owner providing vision and being responsible for maximizing product and customer value through prioritization of the one Product Backlog.
One shared Sprint and one integrated, shippable Product Increment that is delivered every Sprint enabling iterative and incremental development.
Joint Sprint Planning and Retrospectives to drive collaboration and reflection across all teams involved in the product increment.
Common Sprint Review with customers and stakeholders, reinforcing transparency and shared understanding of progress.

Here the complete LeSS organizational design system:

Figure 3: LeSS organizational design system

By centering on value delivery and whole product focus, LeSS encourages teams to swarm around high-priority items, ensuring that coordination is driven by real customer needs rather than arbitrary organizational silos.

Relevance for unFIX Users

Those familiar with unFIX already understand the importance of designing organizations that are adaptable, visually transparent, and aligned with the flow of work. LeSS offers a complementary layer focused on managing multi-team product development within a set of minimal rules and a few principles that guide further experimentation. Where unFIX helps you map out the current roles, and structure, LeSS provides guardrails for how those teams working on one big product plan, execute, and continuously improve together.

For example, if unFIX reveals a cluster of related teams working on a single product as a Fully Integrated Base, by introducing LeSS rules like “one Product Backlog for all teams” and “synchronized Sprints”, you would ensure that each team’s efforts contribute effectively to a shared goal. By creating visibility on the current organizational structure with the structural freedom from unFIX and introducing process consistency from LeSS you unlock higher levels of organizational agility without sacrificing clarity or coordination.

Overall, LeSS aligns well with unFIX’s ethos: Simple but powerful building blocks that encourage constant adaptation. In the chapters that follow, we’ll dive deeper into key insights comparing unFIX and LeSS, then explore a practical roadmap for combining them to create a truly adaptable, value-driven organization.

3. Key Insights Comparing unFIX and LeSS

At first glance, unFIX and LeSS appear to serve similar ends—enabling agile organizations to deliver higher customer value, faster. But each approach brings unique perspectives and tools to the table. Below are four key insights that clarify where unFIX and LeSS align and how they complement each other.

A Shared Goal of Organizational Agility

Both unFIX and LeSS aim to help organizations become more responsive and adaptable.

unFIX does this by offering pattern-based design options that make the organizational structure itself more flexible, more team-centric, and better able to shift with changing priorities.
LeSS pursues agility primarily through leaner, customer-focused product development at scale, ensuring multiple teams can work cohesively on a shared backlog and deliver iterative increments of value.

Why It Matters: Understanding that unFIX and LeSS both strive for organizational agility—and simply approaching this from different angles—sets the stage for combining them. You can use unFIX to model your current “big picture” structures and roles, then adopt the LeSS principles and rules to create an organizational design that is optimized for an adaptable organization that can deliver high customer value with low switching costs.

Differentiation: Structure Modeling vs. Product Development System

unFIX: Acts as a pattern library for visualizing and redesigning organizational structures. It helps you map how teams, roles, and workflows interconnect—revealing where bottlenecks or inefficiencies might lie.
LeSS: Functions as an organizational system for product development grounded in Scrum. Its minimal rules, simpler structures, and whole product focus empower multiple teams to apply empirical process control and continuous improvement in product development.

Why It Matters: unFIX allows you to see and adjust the structural “blueprint” of your company, while LeSS streamlines how teams collectively develop and deliver product value. Organizations often need both a clear structure and a clear process for product development when multiple teams are involved.

Versatile Toolbox vs. Prescriptive Framework

unFIX is a versatile toolbox—it doesn’t prescribe a specific “end state” or process. Instead, it provides building blocks and patterns that you can mix, match, and adapt to your unique context. It’s especially useful for organizations that want the freedom to experiment with different configurations.
LeSS is more prescriptive about how teams work together, especially regarding roles (e.g., one Product Owner) and ceremonies (e.g., joint Sprint Reviews). It provides a roadmap for large-scale product delivery without overly complicating the process.

Why It Matters: Many organizations appreciate unFIX’s open-ended nature for exploring multiple structural possibilities. However, once the need arises to coordinate several teams working on the same product, LeSS’s minimal rule set can keep everyone aligned. This balance between creativity (unFIX) and clarity (LeSS) is what makes combining them so effective.

Processes: unFIXed vs. Empirical Scrum-Based

unFIX does not define any particular process for getting work done. It deliberately leaves that up to the organization, letting teams design workflows or adopt agile methods as they see fit.
LeSS, on the other hand, extends Scrum to a multi-team environment. Its rules include a shared product Sprint, shared multi-team events (like Sprint Planning, Sprint Review, and an Overall Retrospective), and continuous feedback loops, all of which enforce empirical process control.

Why It Matters: Organizations that have used unFIX to reconfigure themselves around value streams or product lines may already see where multiple teams overlap. By adopting LeSS, they can ensure whole product focus, while creating strongly aligned but independent teams that maximize the value delivered to customers and end-users.

Here a summary of the 4 key insights above:

Table 1: Key Insights Comparing unFIX and LeSS

Bringing the Insights Together

When viewed collectively, these insights reveal unFIX’s and LeSS’s complementary strengths:

Both aim for agility but approach it from different angles. unFIX with its pattern library has a strong focus on structures while LeSS encourages a very simplified structure (that is usually far removed from the current reality) and has a strong focus on principles while it also comes with a set of and (process) rules.
unFIX’s visual modeling and dynamic adaptability can highlight where the LeSS ruleset will have the most impact.
LeSS provides a proven, minimal approach to coordinating multiple teams, which can solve the common scaling challenges that often arise after an organization has redesigned itself using unFIX patterns.

In the next chapter, we’ll examine how these insights translate into practical synergy—giving you a concrete look at how unFIX and LeSS can be layered together to deliver robust, adaptive, and customer-centric outcomes at scale.

4. Practical Synergy: unFIX + LeSS

Now that we’ve outlined the core similarities and differences between unFIX and LeSS, it’s time to see how they can work together in practice. At its heart, unFIX shines at revealing and reshaping organizational structures, while LeSS adds a streamlined way for multiple teams to build products collaboratively. When combined, they enable organizations to continually evolve both their design and their delivery processes, balancing flexibility with a clear operational rhythm.

Why Combine unFIX and LeSS?

Holistic Transformation: unFIX primarily addresses how an organization is architected—roles, team boundaries, value streams—while LeSS establishes how multiple teams plan, execute, and learn together. Using both ensures that structural changes actually support the day-to-day flow of work.
Customer-Centric Delivery: unFIX helps you visualize end-to-end value delivery, but without a standardized way for teams to coordinate, product development can still become fragmented. LeSS keeps teams laser-focused on a single Product Backlog and shared increments of value, aligning effort with customer needs.

Step-by-Step Approach

Below is a straightforward way to integrate LeSS practices within an unFIX-modeled organization:

1. Model Your Current State Using unFIX

Begin by mapping out how teams, roles, and value streams are organized. Pinpoint areas where multiple teams are already collaborating or overlapping on the same product or product line.
This step clarifies your organization’s “big picture” and helps you identify the multiple products that are ideal for your first improvement step.

Here an example:

Figure 4: Example of a Fully Integrated Base working on one product

2. Identify Opportunities for a LeSS Adoption

Once you see how work flows, note which parts of the organization could benefit from a unified approach to product development.
Look for clusters of teams working on one related product with shared dependencies, as these are natural candidates for LeSS. Prefer broader product definitions because it increases the overview of the whole product, improves the dependencies management of teams and allows for de-scaling your organization.

3. Adopt LeSS Fundamentals

Your definition of the one Product (in step 2.) will define the scope of your LeSS adoption.
Establish a shared Definition of Done (DoD) for all teams in the LeSS adoption. The stronger the Definition of Done, the better!
One Product Backlog: Create a single, prioritized list of customer-centric items via an Initial Product Backlog Refinement workshop.
One Product Owner: Assign clear accountability for maximizing product value, so teams don’t chase different goals.
Synchronized Sprints: Align teams on the same sprint timeline, establishing a joint Sprint Planning, a shared Product Backlog Refinement and Sprint Review, Team Retrospectives and a shared Overall Retrospective.
Empirical Control: Use each Sprint to inspect and adapt, refining the product, the Definition of Done, and the organizational design over time.

4. Have Appropriately Structured Teams

Your unFIX model will reveal where teams or roles might need to shift. For the new simplified LeSS structure people might need to move from their functional groups to new cross-functional teams.
Using unFIX’s visual and pattern-based approach, each iteration of your organizational design can be quickly captured and communicated to stakeholders. In addition you can use the Feature Team Adoption Approach (FTAM) from LeSS to visualize a non-linear and never ending adoption roadmap.

5. Inspect and Continuously Improve Towards Perfection

The Overall Retrospective in LeSS encourages regular whole-product retrospectives not only on the product work but also on structural aspects.
Use Systems Modeling techniques to spot hidden dependencies, local optimizations, or unintentional performance constraints. This can guide your next round of unFIX-based redesign or prompt further adaptations of LeSS rules.

Here an example of the same Fully Integrated Base now adopting LeSS:

Figure 5: Example of a Fully Integrated Base applying LeSS

Balancing Freedom with Structure

One of the biggest challenges in large-scale agility is maintaining enough freedom for teams to adapt while providing enough structure to keep them aligned. unFIX’s open-ended design tools can sometimes lead to a wide variety of team structures—even within a single product group. LeSS, by contrast, standardizes certain crucial elements of how teams operate (e.g., Sprint cadence, a single Product Backlog), preventing fragmentation or confusion across teams.

When you implement LeSS on top of an unFIX-based design, you gain:

Clarity in Delivery: Teams know exactly how they’re expected to collaborate, what they’re building, and how success will be measured.
Structural Agility: Your organization remains free to reorganize or evolve in response to new insights, without losing a proven rhythm for product development.

Conclusion

By combining unFIX’s structural insights with LeSS’s streamlined multi-team coordination, organizations can ensure that both the “blueprint” of their design and the daily practices of product development continuously reinforce true business agility. In the next chapter, we’ll look at additional tools and techniques—like Systems Modeling and coaching guidelines—that further enhance this synergy, helping you create an adaptive, high-performing environment where teams deliver consistent, meaningful value.

5. Supporting Tools and Techniques

Bringing unFIX and LeSS together can transform how your organization structures itself and delivers customer value. Yet, as with any change effort, the success hinges on understanding the bigger system, coaching teams effectively, and avoiding common pitfalls. Below are several tools and techniques that can amplify the benefits of combining these two approaches.

Systems Thinking and Modeling

Why It Matters

At the heart of LeSS is Systems Thinking. This principle underscores the importance of “optimizing the whole” rather than allowing teams or departments to pursue local optimizations in isolation. Organizational challenges rarely stem from individual roles or processes alone—they arise from complex interdependencies and feedback loops that span multiple teams, products, or functions. Making a change in one area can trigger unintended consequences in another.

How It Fits With unFIX and LeSS

Uncover Structural Patterns with unFIX: unFIX visually represents your organization, highlighting how roles, teams, and workflows interact. This mapping naturally reveals potential dependencies or bottlenecks that could impact value delivery.
Maintain Empirical Control with LeSS: LeSS emphasizes simplicity and an empirical approach to large-scale product development, but relies heavily on Systems Thinking to ensure changes don’t inadvertently create more complexity.
Strengthen Insights through System Modeling: By modeling cause-and-effect relationships—commonly via Causal Loop Diagrams or other visual tools—you can see how an incentive structure could undermine cross-functional collaboration or a local optimization could lead to a sub-optimization of the overall system goal.

Practical Tips for System Modeling

Optimize the Whole Keep a holistic lens when introducing new structures or Scrum practices. Focus on addressing root causes, not just symptoms, and avoid quick fixes that only solve problems locally.
Keep the System Optimization Goal in Focus In LeSS (and unFIX), the overarching objective is to optimize for global adaptiveness—the ability of teams to quickly change direction and consistently focus on delivering the highest-value work. Whenever you’re discussing system models on organizational change, continually ask: “Does this help our teams respond more effectively to shifting priorities and market conditions?” By keeping the system optimization goal variable (and thus the fixed goal) at the center of every decision, you minimize the risk of local optimizations that hinder the broader system’s ability to pivot and innovate.
Facilitate Collaborative Sessions Involve a range of roles (Developers, Product Owners, Managers, and so on) in building or refining system models. Their diverse viewpoints help paint a more accurate picture of how work actually flows—and where it gets stuck. LeSS suggests to use the Overall Retrospectives for system modelling sessions.
Iterate and Adapt: Use your findings to inform both your unFIX modelling (e.g change in your org. structure) and LeSS adoption changes (e.g., adopting LeSS rules, guides or experiments). Then reassess your model to see if new loops have emerged or if previous bottlenecks have been resolved.

Systems Thinking as a LeSS Principle

Within LeSS, Systems Thinking is more than a technique—it’s a core principle that shapes your entire organizational design. Instead of introducing additional layers of management or process complexity, LeSS encourages you to continually zoom out and look at the organization as a whole. By combining this principle with unFIX’s ability to visualize and redesign structures, you gain a powerful one-two punch for tackling the deeper, systemic organizational issues that hinder true agility.

Agile Coaching in LeSS and unFIX

Effective coaching is a cornerstone of any successful LeSS adoption, and it remains equally vital when integrating LeSS with unFIX. While unFIX helps visualizing and reconfiguring organizational structures, the people working within those structures ultimately drive real change. LeSS highlights the importance of focusing on human interactions, learning, and collaboration over simply prescribing new processes or organizational blueprints.

Coaching People, Not Just Structures

Coaches in a LeSS environment recognize that structures (such as those visualized with unFIX) only go so far. The real impact comes from shaping how teams and leaders think, act, and solve problems together. The coach’s role is to enable continuous learning, spark deeper insights, and promote genuine ownership of improvements.

Emphasis on Discovery Over Telling

According to LeSS principles, coaches do not simply hand out ready-made solutions. Instead, they challenge teams to explore and experiment, especially in areas like backlog refinement or multi-team coordination. This approach empowers individuals to identify system-level constraints and work collectively to remove them.

Spending Time Where the Work Happens

LeSS coaching emphasizes being present among teams—on the gemba—to observe real interactions and feedback loops. When combined with unFIX’s structural maps, coaches can see how daily operations align (or clash) with intended designs and help teams address issues in real time.

Coaching the Whole System

According to the Systems Thinking principle, coaching in LeSS spans the entire organizational system rather than focusing narrowly on a single team or department. Coaches facilitate collaboration across boundaries, ensuring that localized improvements do not create new problems elsewhere. By leveraging unFIX visuals, coaches can highlight these cross-team relationships and reinforce a holistic mindset.

Key Coaching Focus Areas

Align on Purpose LeSS’s system optimization goal is clear: maximizing adaptiveness and delivering the highest-value work. As a coach, continually tie each change—structural or procedural—back to this global aim, ensuring local actions serve the broader organizational vision.
Encourage Experiments Both unFIX and LeSS benefit from a culture of experimentation. Coaches guide teams to test small changes—for instance, coordinate working agreements between teams or introduce a new shared Open Space event—and use empirical feedback to refine or amplify successful practices.
Nudge, Don’t Command Reflecting LeSS’s emphasis on discovery, coaches introduce ideas as invitations rather than directives. They might ask: “How might this idea fit into our current structure?” while pointing to an unFIX diagram or a system model, letting teams own the path forward.
Foster a Learning Organization Encourage teams to embrace retrospection and continuous improvement. Involve multiple roles (from developers to product owners and managers) to ensure different perspectives are heard. Use your unFIX visuals in the LeSS Overall Retrospectives to iterate on both structure and process in tandem.
Bridge Gaps Between Leadership and Teams When combining unFIX with LeSS, leadership support is crucial. Coaches help leaders grasp how the structural changes modeled with unFIX and inspired by the LeSS principles, rules and guides reinforce the system optimization goal of maximizing adaptiveness and delivering the highest-value work. A unity of vision maintains consistent messaging and removes obstacles—cultural or bureaucratic—that might slow down adoption.

Coaching for Long-Term Agility

Ultimately, coaching in a LeSS environment aims to build an organization that can sustain agility independently. By guiding teams to discover their own solutions, staying close to where the work happens, and applying Systems Thinking at every level, coaches help ensure that structural changes modeled with unFIX become living, evolving realities. The outcome is a more adaptive, customer-focused organization—one that can continuously navigate change without losing sight of its global optimization goal.

Overcoming Common Pitfalls

Implementing LeSS in conjunction with unFIX offers exciting possibilities for organizational agility, but it also introduces challenges. Below are four typical pitfalls, drawn from LeSS guidance, along with strategies for overcoming them.

Focusing on Agile Management Tools Instead of Solving Real Problems

Symptom: An organization tries to prove its agility by investing in specialized project-management software—Jira, Azure DevOps, or similar. While these tools can visualize backlogs and burndown charts, they often become a substitute for tackling the deeper, systemic issues that hinder true agility (for example, command-and-control cultures, unclear roles, or weak product ownership).

Remedy: Tools do not fix underlying problems; they can even create an illusion of progress. Instead of a quick-fix reliance on new dashboards or data reports, encourage teams and leaders to confront the root causes of dysfunction—like overly complex processes or misaligned structures. Physical boards, spreadsheets, or a simple wiki can suffice in the early stages, keeping the spotlight on meaningful improvements rather than cosmetic ones. Only consider specialized tools after your organization has matured in its agile practices and you’re confident these tools won’t overshadow genuine problem-solving and continuous learning.
Broad and Shallow Adoptions vs. Deep and Narrow

Symptom: The organization tries to adopt agile practices across many teams at once, but changes stay superficial—teams only go through the motions without internalizing new ways of working.

Remedy: Concentrate on a smaller scope first—perhaps a single product line or a few select teams—allowing for deeper learning and more meaningful transformation. Prove success in one area before expanding. This approach builds momentum and validates the framework’s effectiveness before widespread rollout.
No or Inadequate Management Support

Symptom: Leadership may be initially enthusiastic but then withdraws support or prioritizes other initiatives, leaving teams to fend for themselves. Without consistent management backing, the structural and process changes of unFIX and LeSS often falter.

Remedy: Leadership involvement is critical. Ensure decision-makers understand the shifts in culture, roles, and accountability that LeSS and unFIX entail. Build alignment on the long-term vision so that managers champion, rather than merely tolerate, the transformation.
Seeing an Agile Adoption as a Multi-year Project Instead of a Never-Ending Journey

Symptom: Organizations create rigid timelines, hoping to be “done” with their agile transformation after a certain milestone—missing the point that agility is an ongoing evolution.

Remedy: Agility requires continuous inspection and adaptation. Treat each sprint and structural change as part of a learning cycle, not a final destination. By embracing this mindset, teams remain open to discovery and continuous improvement, evolving alongside market needs and organizational growth.

Making It Stick

Ultimately, using unFIX to visualize structures and reduce hierarchies, structures, roles, artifacts, meetings and processes according to LeSS rules and guidelines must become an ongoing practice rather than a one-time project. Systems modeling, vigilant coaching, and continuous experimentation form a virtuous cycle that keeps your organization resilient.

Inspect and Adapt: After each sprint, verify not just the product increment but also how well the organizational design and LeSS practices are supporting value delivery to customers.
Regularly Update the unFIX Model: Treat your organizational diagram as a living document. When roles shift or new teams form, reflect those changes quickly and communicate them widely.
Elevate Learning: Encourage a culture that views mistakes as learning opportunities—further strengthening both unFIX-modeled reorganization and LeSS-driven product development.

By investing in these supporting tools and techniques, you’ll amplify the power of unFIX and LeSS to create a truly adaptive, high-performing organization. In our final chapter, we’ll recap the key messages and outline recommended next steps for readers ready to put these insights into action.

6. Conclusions and Next Steps

The journey toward a truly agile organization doesn’t end with adopting an organizational system or reconfiguring a handful of teams. In fact, it’s an ongoing process of visualizing, experimenting, and refining—precisely the mindset embodied by both unFIX and LeSS. Throughout this article, we’ve seen how unFIX’s pattern-based approach to organizational design dovetails with LeSS’s streamlined rules and guidelines as well as overarching principles for multi-team product development.

By focusing on the complementary strengths of these two approaches—unFIX for structural flexibility and LeSS for a strict simple structure, a fixed set of rules, and guideline for adaptive delivery—you can shape a holistic environment where teams are both empowered and aligned, continuously improving at scale.

Key Takeaways

Shared Goal Both unFIX and LeSS seek to heighten organizational agility and deliver greater customer value—just from different angles.
Differentiation unFIX offers a robust toolbox for mapping and visualizing your current structures, roles, and interactions; LeSS provides a minimal structure and minimal but powerful rules for synchronized, multi-team development, leaving room for many experiments.
Versatile Toolbox vs. Prescriptive Framework unFIX’s open-ended patterns unlock creativity in reimagining your organization. LeSS’s principles and rules ensure focus clarity on one optimization goal in complex, large-scale product initiatives.
Process Layer While unFIX intentionally leaves the “how” open, LeSS anchors multi-team collaboration in empirical Scrum practices, fostering tight feedback loops and continuous learning.

Putting It All Together

Model and Diagnose: Use unFIX to create a clear picture of how your teams and roles interact at the moment.
Layer on LeSS: Introduce LeSS’s rules and principles first for one small group of teams working on one customer centric product, focusing on shared ownership of the product, working from one Product Backlog and having synchronized Sprint cycles. Try to extend your Product definition and include more teams with time, by using your unFIX models to visualize the structural change needed.
Coach and Refine: Leverage systems thinking, Agile coaching techniques, and retrospective insights to keep improving both your structural patterns and your delivery processes.

Recommended Next Steps

Experiment with a Parallel Organization: Select a product area or a set of teams to try combining unFIX and LeSS. Make sure that this is not just considered a pilot but a first step in gradually improving the whole organization.
Engage Leadership: Secure ongoing support from senior stakeholders. Show them how unFIX + LeSS aligns organizational structures with tangible product outcomes, reducing lead time and improving customer satisfaction.
Evolve the unFIX Model: Treat your organization design as a living entity. Update your unFIX diagrams as you learn from real-world experiments, ensuring any structural shifts are visible to all.
Join the Community: Share your experiences, ask questions, and learn from others who have embarked on this path. Both unFIX and LeSS have active communities that can offer fresh perspectives and insights.

Final Thoughts

By combining the structural adaptability of unFIX with the empirical process control of multi-team Scrum foundation of LeSS, organizations can strike a balance between evolving their designs and delivering incremental value to customers. This dynamic duo empowers teams to continually discover better ways of working, leading to sustainable agility that scales far beyond a single project or department.

Whether you’re an experienced coach, a product leader, or a curious team member, we invite you to embrace this synergy. Bring unFIX’s visual power to your next organizational redesign, layer in LeSS to guide multi-team product development, and watch as your capacity for learning and rapid adaptation becomes a durable competitive advantage.

References

About the authors: Robert Briese is a LeSS trainer and unFIX practitioner with extensive experience in organizational transformation. Article posted by Kévin TRELET.

Trust, Care, and Love

ari-tikka — Thu, 12 Jun 2025 00:00:00 +0000

Build the culture of Trust, Care, and Love for the shared mental and physical space.

Five significant patterns that are essential for group dynamics in teams. They happen all the time and have an essential function in the beginning. Skillfully facilitating them, again and again, will gradually develop a culture of Trust, Care, and Love for the shared mental and physical space.

Our instinctive traits for working in smallish, co-located teams have evolved over thousands of years. The same human needs, behavior, and potential exist in remote teams and larger organizations but are invisible. Understanding them is essential for good leadership.

However, even co-located teams struggle in the workplace. The researchers Richard Hackman and Susan Wheelan, as well as popular writers Katzenbach and Patrick Lencioni, who actually studied teams, all open their books by stating that good Teamwork is rare.

Trust, Care, and Love

Ikujiro Nonaka (1935-), the famous researcher of knowledge-creating organizations, researched and preached these bold words around 2000. Nonaka’s approach was to study real organizations and observe for successful patterns. For example, in 1984, after studying a handful of special projects, he coined the word Scrum in the sense we nowadays use it for the Scrum process.

Nonaka’s special interest was tacit knowledge, the unconscious or implicit knowledge. Formal concepts, language, and documents can convey explicit knowledge, but it is only the tip of the iceberg. Tacit knowledge is the invisible basis.

Tacit knowledge is only learned by imitation, by working together - by doing Teamwork. Trust, Care, and Love enable us to work with tacit knowledge.

Another researcher, William G. Ouchi, studied control mechanisms in organizations. He approaches from the opposite direction, stating that Teamwork is the only way to tackle novel, ambiguous, and interdependent challenges, where working with tacit knowledge is the key.

1 Individual’s Perspective

ndividuals want to become respected members of a team that succeeds. It will then provide them with safety, connection, and livelihood. People instinctively have three questions in mind:

Am I treated fairly? Especially, will I be punished for disagreeing? This psychological safety has been a hot topic lately, but there is more…
Will others do their part? Freeriding is a central question in any social system.
Are we going to survive? Do we have the conditions for success?
This is old knowledge, re-confirmed by Google’s large ReWork research in 2015. Google wanted to know who are the team players, but found that team culture is more significant than individual traits. The five factors from Google’s research fit well the points above.

Then we have the personal factor. Teamwork skills and experience matter, especially when the team needs to learn fast.

When joining a team, some facts are known beforehand, but mostly superficially. There are always surprises when you meet new personalities in a new team. Everyone is going through their favorite change resistance curve, which can pass quickly or take longer, depending on the situation and person.

People can take ownership of the situation and choose learning, open communication, and conscious choices. This can be supported through good launch facilitation, and it can be a personal intention. The opposite would be a victim attitude and extensive defensive behavior.

2 Launch

Preparations

Launch is the moment of truth. It is the first time all relevant people and ingredients are in the same room. It is the first time trying to work together, which is what Teamwork is about. Within minutes, the people form their first impression of whether we will succeed or not.

Richard Hackman stated in his landmark books that 60 % of the success is made in the pre-work (creating the conditions), 30 % in the launch, and 10 % while coaching the ongoing work.

Hackman did research on Teamwork for 40 years at Harvard. He crystallized his findings in 6 conditions (2011):

Right People
Real Team
Compelling direction/Purpose
Supporting Organizational Context
Clear norms of conduct
Team-focused Coaching
This is the single most important advice for creating successful teams. Please start with this article, and read the books!

Organizations have three natural stakeholders: Customers, Workers, and Owners. The team’s profit-and-loss-responsible Sponsor represents the Owners, who have put their wallets on the table to create a well-working organization.

So the Sponsor sees that the conditions and launch facilitation are flawlessly prepared. She of course is using other people as well as her own time and effort. Unlike “Just figure it out, you are adult people.”

Dependent Group Dynamics

When people enter the room, they start to look for collaboration. First, they need to make eye contact with each other. Next, they need to become visible in the group with their chosen history, first in pairs and then with the larger group.

Now, the team to come is in confusion. There is some understanding but also a lot of unanswered questions and needs. People start to probe who would lead us away from this confusion and anxiety. Different people offer their leadership, and finally, someone in the room is accepted as the situational leader.

The team has formed for the first time. Everyone has agreed to be lead by the chosen leader. It is sometimes amusing to see how team members exaggerate the wisdom and power of the leader by asking trivial questions, just to express their subordination.

The team may struggle to find this pattern when there are strong personalities, such as experienced specialists who want to do things their way. Or if there is no-one who dares to take leadership. This can be helped by creating clarity about the structures and goal, clear assignment by the sponsor, skillful facilitation, and individuals’ teamwork skills.

Like a newborn baby, the group is still vulnerable and protected by the chosen leader’s strength. In this way, the leader helps the group face the work-related anxiety.

Now, the leader needs to clarify the confusion and/or make the group succeed in some work.

Facilitation

A good facilitation covers all previously mentioned challenges:

Meticulous pre-work
Inviting invitation
Check-in that supports the members to join the team
Credible welcoming speech by the Sponsor, presenting the conditions of success
The Sponsor setting the expectations for the team: to put effort in and collaborate
Exercises for the team to clarify the situation, like knowing each other, clarifying the goal, agreeing on the first norms, and mapping the context.
Start to work

A specialized coach/facilitator may be beneficial, depending on the challenge and experience of the people involved. Whoever is leading the launch needs to adjust the dependency: In confusion, offer to lead, and with flow, give responsibility to the group.

The launch event is a unique opportunity to train Teamwork skills:

The right people are present - no need for the time and effort for a separate training
Learning about the real thing going on right now is motivating and enlightening
The team norms have not yet been established and are easier to shape
Real learning at the individual level and at the team level when people witness each other’s actions and reactions
Effective and economical to add small theory inserts and explain the why and how of the launch facilitation

Please check our Teamwork page for more details.

Work

Learn to share workload, competence, and leadership. This is the key to teamWORK. Do this from the very beginning, even when it seems uncomfortable first.

The team will try out working. For different work-related questions, the team will listen to different situational leaders. The team as a whole is still new and vulnerable. Team members give up their personal wisdom to align with the team and tend to use easy-to-agree solutions.

Learning about the realities and success in work increases the trust in the individuals’ three major questions.

3 Individuality Emerging

As increasing trust strengthens the team a little, individual members dare to challenge the leadership. They challenge the alignment and demand autonomy to work at their full capacity.

People seek support from small groups, which will have disagreements (aka conflicts) with other subgroups. Some conflicts are about practical work, and some also have the flavor of group dynamics.

Whoever takes the role of the situational leader needs to solve these conflicts so that the solution supports individuality, autonomy, and psychological safety.

To protect the still vulnerable team, the leader needs to pull all the critique towards herself. This makes her a strong and safe leader and prevents the conflict between the subgroups from threatening the team’s integrity.

Work

The team continues to work. There is more freedom to align for decision-making and planning and to work separately for effectiveness.

Learning and success in work increase trust. The team will find a practical balance between alignment and individuality. The members start to form an emotional bond with the team, which now fulfills their needs for connection, safety, autonomy, and sustenance.

4 Courage from Cohesion

Only after balancing alignment and individuality is the team able to work as one. Earlier, brave or rebellious individuals brought up difficult questions, but the team as one has not responded. Now, the team - as one team - starts to see the external challenges and gathers courage from group cohesion. It dreams about success, even unrealistically, and gradually turns into planning.

The blessing of this pattern is overcoming work-related anxiety, removing friction and hesitation, and finding unwavering commitment. It raises the feeling of safety to a new level and enables the members to work in a flow state.

Work

The work is now more effective, resulting from learning and smooth collaboration.

The group dynamic patterns explained above emerge as responses to acute situations, passing briefly or going deep for serious questions.

Whenever the team needs to work aligned, such as when making decisions, planning, or clarifying confusion, it will use the dependent pattern. Different people offer their solutions, and the team finally converges on one.

With any kind of disagreement in thinking or doing, the pattern called flight-fight will emerge. Some people will fight, and some will escape mentally or physically. The team now needs a leader and a moment of dependency to clear the confusion and return to work.

The team will use group cohesion to face challenges or just to enjoy a moment of rest.

5 Retrospectives

In a Retrospective team or the larger organization takes time to think about how we are doing. There is plenty of advice for retro facilitation, so I will only point out their precious value to the group dynamics.

When the team tries out Retrospectives early on, they will improve the development of group dynamics on two levels. The main focus is improving success in practical, real work. Simultaneously, the team comes together and practices the essential patterns explained above. The development of group dynamics happens on a small scale also during the Retro meeting

In the beginning, the team will take up easy questions and commitments. It will defend itself from too difficult questions, even if some individuals want to discuss them.

Later, with increased trust and cohesion, the team as a whole will look in the mirror and ask how we are doing, where we failed, where we succeeded, and where we - as a team - commit to doing differently.

The established Retro structures provide safety to bring up difficult questions. Good facilitation provides a safe fall-back to dependency and strong situational leadership to help with fight-flight. A well-facilitated Retrospective improves team cohesion by:

Connecting people. Everyone is invited to the same room to participate and influence Safety. The structures focus on the substance, not people. Different views are invited and not punished; for example, participating leaders are not pressured to give answers. Courage is gathered by accepting realities, looking at success, and dreaming together about solutions. Please check our page about establishing Retrospectives and Continuous Improvement.

Work

It is essential to work, have regular Retrospectives, and create an effective improvement mechanism. If the system does not improve, Retrospectives become frustrating. Sadly, when this happens, teams and Sponsors often give up Retros and stop the improvement.

A little about dysfunctions

The measure for Teamwork is performance, getting the right things done.

Perceived team underperformance may be just unrealistic expectations. Low performance may be process-oriented, like lacking skills, bad tools, or incoming bad quality. Or it might be something about collaboration. Interestingly, too low expectations may actually invite dysfunctional group dynamics.

If you consider acting, think first. Observe carefully and gather undeniable evidence. Consider multiple perspectives and hypotheses. Plan a participative, gentle, and firm intervention. Prepare to provide excessive leadership and coaching support. In most cases, the structures need to improve, and Hackman’s conditions for Teamwork provide a good checklist.

Dysfunctions become visible in the five patterns. Failures may be obvious, like unresolved conflict, or more intricate, like the scapegoat pattern. Fake performance is significant and popular, as shown by the many theories developed by different authors.

Please drop us an email if you suffer from a strange dysfunction. We gladly offer first aid advice, just out of the curiosity to hear about real cases.

Resources

J. Richard Hackman: From causes to conditions in group research (article)

J. Richard Hackman: Collaborative Intelligence: Using Teams to Solve Hard Problems

Susan A. Wheelan: Creating Effective Teams: A Guide for Members and Leaders

Maria-Elisa Männistö:Collective sensemaking during the early phases of sustainability working group identity creation: Walking the sustainability talk (Doctor’s dissertation)

https://retrospectivewiki.org/

Esther Derby, Diana Larsen: Agile Retrospectives: Making Good Teams Great

The Hidden Cost of High Performance - Why optimizing teams in isolation can cripple organizational outcomes

wolfgang-steffens — Mon, 19 May 2025 00:00:00 +0000

The Parts vs. System Paradox

“Changing parts will have little impact on the system. But changing interactions or purpose can create a massive impact.” — Steven Schuster

Systems thinkers have long understood this. So why do many organizations still obsess over optimizing individual teams — driving up local efficiency while system-wide performance stagnates or declines?

Here’s what happens:

A team gets faster
But what they produce isn’t aligned with what the customer actually needs
Or worse, it clashes with what another team is doing
You get work that’s faster, cheaper… and irrelevant

To improve real outcomes, stop focusing on parts. Start improving how the parts work together. Make collaboration worth it for individuals — not an extra burden, but a source of progress and shared wins.

The Suboptimization Trap

“When a subsystem’s goals dominate at the expense of the total system’s goals, the result is suboptimization.” — Donella Meadows

We see this every day:

Sales wants volume
Support wants lower tickets
Development wants fewer changes
Marketing wants launches

Each team wins, but the customer loses.

Suboptimization isn’t just inefficient — it’s invisible sabotage. It feels like “success,” but it erodes coherence and trust.

The Solution: System-Level Design

Fixing it means aligning incentives, breaking silos, and designing for shared outcomes:

Feedback loops between teams
Conversations across interfaces
Leadership that rewards system success, not heroism in isolation

Russell Ackoff’s Three Rules

Russell Ackoff laid it bare with three simple rules:

Optimize the system? You’ll sub-optimize some components
Optimize the components? You’ll break the system
Every subgroup follows the same pattern

These aren’t just rules. They’re warnings. You can’t build a great organization by piecing together high-performing parts. You need a coherent whole — teams designed not just to work, but to work together.

✅ Ready to move beyond parts-thinking?

If this resonates — and you’re ready to see your organization as a system, not just a chart of boxes — join my course:

🎓 Systems Thinking in Action: Exploring The Fifth Discipline

A hands-on learning experience rooted in Peter Senge’s work and applied to your real-world challenges.

🔍 Learn to see patterns, shift mental models, and improve the system — not just the symptoms.

What Is Your “Product” Operating Model?

gene-gendel — Fri, 25 Apr 2025 00:00:00 +0000

📢 Special Event: On May 2, please attend this free webinar "Using System Thinking & Modelling to Solve Tough Organizational Problems", delivered by Certified LeSS Trainer and Coach Gene Gendel and hosted by Lean, Agile and Large-Scale Product Development (LeSS) Global Community. Some of your pressing questions could be asked there!

What is your “Product” Operating Model?

Analogy: Your Restaurant Experience

By way of analogy, imagine you come to a restaurant and willing to spend a lot of money on a bowl of an expensive and exotic soup. You sit at a table and wait for your dish to be delivered. When a waiter comes, you see that on his tray, there are raw ingredients that are used to prepare a soup, but there is no actual soup. You are puzzled. This is not what you are prepared to pay for. Each ingredient, although the required constituent of a final product, is not a product in itself. Even if a waiter, head chef and restaurant owner tried to explain to you that ingredients also cost money, and are [raw] products on their own, you still have a strong reason to be unhappy, as you were willing to pay your money for something that you could consume immediately upon delivery: a delicious, exotic soup. As a customer, if you do not receive what you paid for, you would be unhappy an, probably, ask for your money back, and not come to this restaurant ever again.

What Is Operating Model

What is an operating model? This is the term that companies use, to describe their internal ways of working. Essentially, instead of using a term that may suggest the adoption of a commercial, off-the-shelf solution, a.k.a. framework, companies prefer creating their own, language that creates an impression of a home-grown, unique, sophisticated and tailored approach. Thus, the term: OPERATING MODEL.

The reluctance to use a large, commercially widespread, populistic, “unpack & install” solutions is understandable, especially, given the historical “dark side of agile business” that involves a lot of relabeling and “terminology mapping“. But of course, it always begs the question: how unique is each company’s situation that it justifies spending time, money and energy on a custom special operating model (a.k.a. framework)?

What Is “Product” Operating Model

Following the same train of thought, a PRODUCT” OPERATING MODEL (quotes around the word product are intentional) implies that a company’s ways of working are optimized for product development and delivery (it also assumes customer/user centricity). This further assumes that a company’s* organizational design* is improved to support a product operating model. More specifically, instead of defining “products” around traditional volumes/scopes of work (portfolios, programs, teams’ capabilities, teams’ private technical backlogs), real products should become a leading factor that dictates how teams (also, the rest of an org, involved in product development) should be structured, what capabilities they should have and what information should be kept in product backlogs. Traditional ways of managing work (portfolios, programs and projects) should become trivial and, eventually, seize to exist. For majority of organizations, this means 180 degrees course correction to their agile transformation.

The analogy above (an exotic soup) is synonymous to a product development situation, when at the end of a sprint (sprint review) users are presented with multiple technical components that were built by a scrum team but not not fully integrated into complete features. This kind of a sprint review, very quickly, becomes a low-interest event for business people and they stop attending it.

Lack of product centricity in sprint-work is often caused by lack of teams’ capabilities, to deliver front-to-back product features, without external dependencies. This is the problem of organizational design. If a team is designed, as a component/delivery team, its end-of-sprint delivery is a technical component, not a product feature, and therefore, of low interest to business people.

This lack of product centricity in team design can be further traced to a weak (fake) product definition, with each team, adopting a belief that they develop a “mini-product” or a “sub-product”.

At scale, and especially in organizations that rush to make a political claim that they have become a true product organization (large banks is a good example), this leads to what is a.k.a. Productization Saga – each and every body of work becomes a product.

Today, for many organizations, an internal “product operating model” is just a part of a much bigger Agile Theater Chaos.

Unless we see deep systemic improvements that involve changes to a reporting structure (flattening), removal of boundaries between traditional vertical silos (departments, groups) and ownership-by-technology areas (platforms, shared services), reduction of local management, in favor of self-management,** these product operating models will remain being just a fancy term, without much meaning.** Because of that, over time, some roles, maybe, even entire job families, such as fake program managers and product owners (with no real products to manage and business priorities to own) and agility leads (ex-no-longer-needed roles, fabricated just to keep people busy) may have to be reduced (RIFed), as non-essential, because they do not measurably contribute to ROI.

Are There Alternatives To This Chaos?

Yes, indeed, your daily reality does not have to be as unattractive and depressing as described above.

There a couple things you could do to improve the situation:

First, think holistically, and try to understand what would make your organization survive and prosper in the world of high-pace competition and AI. Here, what may come to rescue is understanding of how to drive Business Resilience in complex and dynamic markets.
Second, try to move away from the stale belief that organizational structure of your company is an untouchable “no go zone”. Do not treat traditional, legacy and oftentimes outdated functions, roles, departments etc. as perpetual elements. Everything in life evolves and so should your organizational structure. Once you overcome this mental blockage, it will be much easier for you to rethink your product definition and make it drive the optimal definition of your organization structure, not the other way around. You will see how, miraculously, your sub products, sub-sub products, “tech for tech” products, “area” products, components-as-products, and other “blah” products start disappearing.
Lastly, spend some time studying, how some of these problems been addressed and resolved by other companies that took things seriously and decided to improve themselves not just on paper/for PR but for real. Please review the following case studies.

Want More Help With Your Organizational Challenges?

The below list of challenges (top 25 are listed but there could be more) indicates that your agile transformation’ is offtrack and your ‘product operating model’ does not work. If you recognize that you are having a problem, you may wish to rethink if/how you wish to proceed further, because the further and for longer you move in a wrong direction, the more difficult it would be to course-correct later.

If you feel that you need help, in the form of an assessment, reflection, private consulting, training or extended coaching support, please reach out. Do not wait until it becomes too late.

Lastly, on May 2, please attend this free webinar “Using System Thinking & Modelling to Solve Tough Organizational Problems“, delivered by Certified LeSS Trainer and Coach Gene Gendel and hosted by Lean, Agile and Large-Scale Product Development (LeSS) Global Community. Some of your pressing questions could be asked there.

In a rush, to become agile, did your organization adopt an “operating model”, by incorrectly copy-pasting something that has been well known in the industry for years but required a much deeper understanding, before implementing?
In pursuit to become product-centric organization fast, did your end end up with tons of products-wanna-be, such as: “area products”, sub-products, technical products, “tech-for-tech” products, “no_real_customers_no_human_users” products?
At your company, are products defined by a technology managers and architects, or business people? What impact does it have on customer centricity?
Do multiple back-end applications get integrated into a single product way too late in a process, resembling a classic waterfall?
Does it feel that coordination between so many, so-called, products is unexplainably hard, time consuming and expensive?
Does it feel that the financial/budgeting aspect is missing from product management/ownership and is handled by org structures that are too distant from product management/ownership/development?
Does it feel that product managers and products owners, “manage and own” in spirit only, and are, mostly, disempowered?
Do you feel that technology people lack basic understanding of business, whereas business people have lost their trust in technology?
In your organization, does technology dictate “what agile is” and expect business to follow?
Do you feel that too many locally optimized, mid-level managers are focused too much on their own, personal successes that frequently do not add up to a collective success?
Does it seem that there are too many local initiative owners, whose priorities compete for budget, and whose personal agenda prevails over collective agenda?
Does it seem that legacy resource management/sharing and skill set capacity allocation are being applied to agile (adaptive) ways of working?
Is executive management disengaged from strategic discussions that define value?
Does executive management set strategic priorities?
Is there a lack of synergy between business strategic goals and technology strategic goals?
Is there a lack of effective collaboration among technology teams, and between business and technology?
Are people still confused with how to focus on products in an environment of portfolio-to-program-to-project management?
Is there a confusion between portfolios of true-real products and traditional budgeted work, loosly called “portfolios”?
Is there a misalignment between strategic goals, product roadmaps and product backlogs?
Is there a confusion between outputs and outcomes, defined by short-term and long-term plans?
Is there a confusion between true product/feature teams and component/application/delivery teams?
Is there a gap between financial decisions/costs and product prioritization decisions?
Are there challenges in identifying meaningful metrics and separating them from vanity (gaming) metrics?
Is there confusion about what should be included in executive reports?
Is there a confusion when to apply: Scrum, XP, Large Scale Scrum, Team Kanban, Enterprise Kanban?

AI-supported Org Design

alexey-krivitsky — Tue, 15 Apr 2025 00:00:00 +0000

AI, of course, can be used to improve the performance of individual single-skilled specialists, and this is what we see as of 2025, but there is a large landscape. Let me share.

AI-Supported Org Design (“AI OD” for short) will be becoming a hugely impactful topic affecting all of us and all the organizations in which we work.

AI OD is the strategic practice of applying AI (agents and other upcoming innovations) to continuously inform, accelerate, and personalize how an organization is structured, how it evolves, and how its people learn.

It’s not about replacing managers or employees (!) —it’s about empowering us to design adaptable, resilient orgs with fewer structural overhauls and more intelligence baked into the day-to-day.

☝️ The core organizing principle: AI Makes Versatile Teams Viable.

☝️ The core operating principle: With Multi-Learning as the Engine.

How do these principles differ from applying AI to get individual performance gains? Let me unpack this slightly.

Strategic AI Application

If we unpack these two principles, then we can see that this is all about applying AI to support an organization’s development direction and accelerate its evolution to gain high performance and other competitive advantages. That is a strategic AI application.

Some guides and practices to focus on here:

👌 #1: Multi-Learning as the Engine: Especially in Adaptive Topologies (see Org Topologies Primer for details), learning—not just delivery—is the primary currency. AI enables this by making the unknown known and the unlearnable learnable and with ease. Sample scenarios:

A backend developer shadows a customer support session and begins contributing to onboarding scripts/
A frontline support agent learns enough Python to automate common diagnostic steps, reducing ticket escalations and easing the load on developers/
An end-to-end team includes privacy review and data protection steps in their regular sprint workflow—not because they were forced to, but because someone on the team got curious, shadowed legal, and brought that knowledge back in.
A delivery manager starts using AI tools like Cursor or GitHub Copilot—not to replace anyone, but to better understand how her teams are using it, what it’s good at, and what the current limits are.

👌 #2: Learning Becomes the Flow: AI agents will suggest relevant prior work and recommend 5-minute learning prompts when patterns emerge. AI agent says to a team:

“Team X solved this two sprints ago.”
“Want to see how testing was solved in a similar sprint?”

👌 #3: Matching of Work-to-Skill in Real-Time: Rather than static org charts or disruptive reshuffles, AI supports the continuous alignment of skills to work based on live data and evolving interests, and when multi-learning is too expensive, AIs will suggest micro-reteaming without major upheaval as a temporary, quick-fix solution.

That’s what Org Topologies offers as a field guide for leaders in this disruptive era of AI we all happen to live in, in collaboration with Roland Flemm and Craig Larman.