LeSS Newsletter September 2026

Hi 👋

Most improvement work rests on a comfortable assumption: make the parts better and the whole will follow. This month, almost everything we came across says the opposite. AI didn’t break the software, it moved the cost onto the reviewers. Teams can be thoroughly agile while the organisation still cannot change direction. And Requirement Areas drawn around your modules quietly rebuild the component teams you thought you had left behind.

The counter-example leads this issue: GROOVE X grew to 120 people with no managers and no departments, because somebody designed it that way.

Optimising the parts is not the same as designing the whole. The bill for the difference always arrives somewhere you weren’t looking.

This month’s ideas, ready to put into practice:

• 🎉 Welcome Aki Enomoto, a new Certified LeSS Trainer, with the GROOVE X case study behind it
• 🧭 Requirement Areas Are Not Around Product Modules by Yi Lv
• 🗿 Global LeSS Conference Japan: nearly sold out, plus a teaser for Bas Vodde’s talk on team spill-over
• ☕ CafeTalk 15: Why Agile Teams Don’t Make an Adaptive Organization with Wolfgang Steffens
• 🤖 When AI Writes the Code, the Cost Moves by Bastiaan van Hamersveld

Enjoy, and keep learning!  

Bastiaan van Hamersveld
CEO at less.works, email: bastiaan@less.works

Welcome Aki Enomoto, Certified LeSS Trainer, and the GROOVE X Story Behind It

🎉 A new Certified LeSS Trainer, and a case study that explains exactly what he spent eight years learning: how to scale to 120 people without managers or departments.

We’re glad to welcome Aki Enomoto as a Certified LeSS Trainer. His certification rests on something you can read for yourself: he is the author of the GROOVE X case study, the Japanese robotics company behind the LOVOT home robot, where he has worked since the LeSS adoption began in June 2017.

GROOVE X set out to be a company with no managers and no divisions in product development (the CEO stayed on as the single Product Owner), and it held that shape while growing from one team in 2016 to twenty teams and 120 people by 2019. The adoption took roughly two years and was deliberately gradual rather than a big-bang transformation.

What the case study covers:

• Merging around ten separate backlogs into one customer-centric Product Backlog, which meant throwing away the component-based items and rebuilding from scratch
• The move from component teams to feature teams, completed by the end of 2019, and why changing structure without redesigning the items creates a bottleneck instead of flow
• One-week Sprints synchronised across all teams, with multi-team refinement, overall retrospectives, and bazaar-style Sprint Reviews
• Technical excellence as the backbone: end-to-end automated tests on real hardware, pair and mob programming, continuous integration with canary releases
• The people experiments: no performance appraisals, teams doing their own hiring, a “gardeners” group for organisational impediments, and a peer-based bonus system
• Where it got hard: hardware and software move at different cadences, so the hardware side stayed partly component-based

The honest lesson running through it is that culture came first. GROOVE X was already flat, co-located, and experimental before LeSS arrived, which is why the adoption felt natural rather than disruptive. A useful counterweight to the idea that structure alone will do the work.

Congratulations, Aki, and welcome to the trainer community.

🤖 Read the GROOVE X case study →

Requirement Areas Are Not Around Product Modules

🧭 If your Requirement Areas map onto your product’s modules, you haven’t escaped component teams, you’ve just renamed them.

Writing on the Odd-e blog, Yi Lv puts his finger on a mistake that looks reasonable right up until it calcifies: organising Requirement Areas around the parts of the product rather than around the changes the product needs. Modules are the baseline, what already exists; areas exist to organise change. Confuse the two and you quietly rebuild ownership boundaries, and with them the dependencies LeSS was meant to dissolve.

He works it through with WeChat (Moments, Channels, Contacts) and the problem shows up fast: value doesn’t distribute itself evenly across modules, and the work that matters most tends to cut straight across them. An “AI-powered” area, grouped by initiative rather than architecture, holds its shape far better.

What you’ll learn:

• Why modules describe the baseline and areas organise change, and what goes wrong when that distinction blurs
• How module-shaped areas recreate component-team dependencies under a new name
• Why “teams are stable, but areas are dynamic”: areas should follow value as it moves, and be redrawn when it does
• Better things to group areas around: roadmaps, initiatives, product goals, not the architecture
• Why collective ownership beats dedicated module ownership, even though it makes people uncomfortable

📰 Read why areas follow change, not structure →

Global LeSS Conference Japan: nearly sold out

🗿 8–9 October, Tokyo. Seats are nearly gone, and the room is filling up with practitioners from across Asia.

One talk to arrive early for: Bas Vodde on the secret measurement of healthy team dynamics.

Measuring team spill-over is a great way of quickly evaluating team dynamics. Most people mistake spill-over as a metric for predictability. It is absolutely not! Instead it is a great in-Sprint WIP measure that can be measured relatively easily, and improvements usually have a direct impact on team dynamics and learning. In this talk, Bas will explain what the metric is, what causes it, what harm it causes, and why it is probably the most important metric to have for improving teams and learning in your organisation.

Also on the programme: a keynote from Kaname Hayashi, founder and CEO of GROOVE X, the company whose LeSS adoption opens this newsletter.

🗳️ Grab one of the last seats →

CafeTalk 15: Why Agile Teams Don’t Make an Adaptive Organization

☕ You can make every team agile and still have an organisation that cannot change direction.

In this CafeTalk, Bastiaan van Hamersveld talks with Wolfgang Steffens, founder of Kaikaku, about the organisational foundations that agile transformations keep skipping: why management commitment still decides the outcome, why organisations keep optimising single teams instead of the whole system, and how structure quietly stops capable teams from working on what matters most.

The thread running through it: adaptability is not really about making teams faster. It is about designing an organisation that can point its capabilities at the most important customer and business problems.

What you’ll learn:

• The difference between agile teams and an adaptive organisation, and why the first does not add up to the second
• Why Scrum exposes problems rather than solving them, and what that asks of management
• Shu-Ha-Ri, and why organisations are so tempted to skip the basics
• Two practical tools for organisational change: the Org Topology Map and the Feature Team Adoption Map
• How domain boundaries and management structures manufacture local optimisation, so feature teams can look highly productive while the organisation still cannot adapt
• Why AI raises the value of broad, end-to-end product and customer understanding

👀 Watch the CafeTalk →

When AI Writes the Code, the Cost Moves

🤖 A year of production data, 3.52 million code changes: AI-generated code isn’t breaking anything. It’s quietly moving the cost somewhere your metrics don’t look.

A new study, Characterizing the Quality Profile of AI-Generated C++ in Production, tracked 3.52 million changes across a 10.5-million-line brownfield codebase for a year. Correctness held up; reverts even went down. But coupling burden rose 1.15×, copy and allocation overhead 1.39×, and AI changes drew 1.92× as many blocking review threads and needed 1.24× as many reviewer iterations.

On the LeSS blog, Bastiaan reads it as an organisational design finding rather than a tooling one: generation got cheaper, review didn’t, so the queue moved, and an organisation that measures output per developer will register that shift as an improvement.

What you’ll learn:

• Why the study’s own phrase, cost shifting “from acute reliability failures to chronic maintenance”, describes exactly the kind of cost no dashboard raises an alarm about
• How extra coupling in the code becomes extra coordination between teams, and why feature teams change what that coupling costs you
• What fixed it in the study: not a stricter gate, but targeted feedback (31% better efficiency, 11.1% fewer static findings), the same short-loop logic behind pairing, mobbing, and a real Definition of Done
• Three questions to ask your own product group: where did the work go, what are we measuring, and is our structure amplifying this?

📰 Read: the cost didn’t vanish, it moved →