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 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:

1. Optimize the system? You’ll sub-optimize some components
2. Optimize the components? You’ll break the system
3. 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?

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:

1. 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.
2. 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.
3. 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.

1. 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?
2. 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?
3. At your company, are products defined by a technology managers and architects, or business people? What impact does it have on customer centricity?
4. Do multiple back-end applications get integrated into a single product way too late in a process, resembling a classic waterfall?
5. Does it feel that coordination between so many, so-called, products is unexplainably hard, time consuming and expensive?
6. 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?
7. Does it feel that product managers and products owners, “manage and own” in spirit only, and are, mostly, disempowered?
8. Do you feel that technology people lack basic understanding of business, whereas business people have lost their trust in technology?
9. In your organization, does technology dictate “what agile is” and expect business to follow?
10. 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?
11. Does it seem that there are too many local initiative owners, whose priorities compete for budget, and whose personal agenda prevails over collective agenda?
12. Does it seem that legacy resource management/sharing and skill set capacity allocation are being applied to agile (adaptive) ways of working?
13. Is executive management disengaged from strategic discussions that define value?
14. Does executive management set strategic priorities?
15. Is there a lack of synergy between business strategic goals and technology strategic goals?
16. Is there a lack of effective collaboration among technology teams, and between business and technology?
17. Are people still confused with how to focus on products in an environment of portfolio-to-program-to-project management?
18. Is there a confusion between portfolios of true-real products and traditional budgeted work, loosly called “portfolios”?
19. Is there a misalignment between strategic goals, product roadmaps and product backlogs?
20. Is there a confusion between outputs and outcomes, defined by short-term and long-term plans?
21. Is there a confusion between true product/feature teams and component/application/delivery teams?
22. Is there a gap between financial decisions/costs and product prioritization decisions?
23. Are there challenges in identifying meaningful metrics and separating them from vanity (gaming) metrics?
24. Is there confusion about what should be included in executive reports?
25. Is there a confusion when to apply: Scrum, XP, Large Scale Scrum, Team Kanban, Enterprise Kanban?

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.

In the last months, I’ve had many conversations in the LeSS community as well as in the product I work for, about Requirement Areas. From those discussions, I’ve discovered new ways of explaining them. Here, I’d like to share some of these.

What are Requirement Areas?

Requirement Areas is a grouping of items on the product roadmap used to create a view on the Product Backlog. This view helps us structure the teams accordingly.

Then what is the product roadmap? A product roadmap is a high-level view of the Product Backlog. In the LeSS books, Craig and I talk about items in the backlog that can have ancestors. Nowadays, I refer to items that have ancestors as “roadmap items”. Together they form a high-level view of the Product Backlog, which is usually referred to as the Product Roadmap. Requirement Areas is a grouping or categorizing items on the product roadmap that we use for structuring the work.

Why Requirement Areas?

The original reason for starting this grouping, which began about 20 years ago with the first LeSS Huge adoption, was to support the Product Owner in keeping an overview of the development and prioritization. By having a grouping, we can create a view of the Product Backlog according to this categorization and structure the teams and PO around this. This enables us to scale from roughly 8 teams to any size product development.

Requirement Areas also give other benefits since they help in facilitating multi-team events. An area is always between 4-8 teams, so the multi-team sessions always have a reasonable amount of people to use practices as mixed-up groups in multi-team Product Backlog Refinement.

How to create Requirement Areas?

Creating Requirement Areas is not hard. The hardest part is that they are different from structures that people are used to. To create them, you need to understand what the main functionality will be the focus in development for the next year(s): the product roadmap. When you have that, do the following:

1. Group related items in the roadmap that are related to affinity.
2. See if you can think of a name.
3. Imagine how many teams would be required to work on these.
4. If the number of teams is smaller than 4, go to step (1) and redo the grouping or combine categories.
5. If the number of teams is larger than 8, consider splitting the category or revisit (1) and try again.

Notice: The key factor that defines an area is the number of teams working there because the purpose of areas is to structure the work. Never have areas smaller than 4 teams.

What are not Requirement Areas?

There are a couple of common mistakes when using Requirement Areas. The biggest one is to have small areas (smaller than 4 teams). This is resolved by adding two small ones.

Other common misconceptions are:

• Confusing them with Product Areas. A Product Area is a grouping of functionality in the product and not a functionality in the roadmap. This difference is significant! Your product might have a large amount of functionality related to “financial reporting” but when you do not plan to build new functionality in financial reporting, then you would never have a Requirement Area for that. For creating areas, look at the roadmap, not the product.
• Using the Product Architecture for creating Requirement Areas. A Requirement Area is a grouping in the roadmap, not a split based on architecture. When you split based on architecture and structure teams accordingly, that is referred to as Development Areas. These are not recommended because all the component team dynamics will manifest in development areas.
• Requirement Areas are often viewed as separate Products. Organizations frequently transition from many small products to one large product when adopting LeSS. During this process, they often confuse Requirement Areas with what they previously called a Product. This situation aligns with the misconception (2) but is common enough to warrant explicit mention.

There is a lot more to say about Areas, but for this blog, I’ll leave it here. More in the next blog.