LeSS Newsletter - March 2026
31-03-2026Hi 👋
Across the last few months, one pattern has become hard to ignore: AI is speeding up software delivery, and in many teams the bottleneck is shifting from coding to clarity, product thinking, and shared understanding.
Recent reporting and industry analysis point to the rise of AI coding agents, faster implementation cycles, and a growing need for stronger decisions about what to build, why it matters, and how teams learn together rather than just produce more output.
That makes this month’s selection especially timely: from outcome-driven backlogs and knowledge as a learning system, to the hidden cost of AI-generated code, myths of software management, and practical LeSS adoption at scale.
What’s inside this month?
- 🎯 Outcome-Driven Product Backlog (at Scale) by Krzysztof Niewinski
- 🇯🇵 LeSS2026 Tokyo Conference opened Ticket Sales! 👈
- ✍️ What Leaders Get Wrong About Knowledge? by Wolfgang Steffens
- 🌅 The hidden cost of AI generated code by Addy Osmani
- 📖 Myths of Software Management by Robert Briese
- ☕ CafeTalk - Why Engineers are reluctant to talk to the customer? with Viktor Grgic
- 📚 LeSS Case Study: BASE telecom by Jurgen de Smet
Enjoy, and keep learning!
— Bastiaan van Hamersveld
CEO at less.works, email: bastiaan@less.works
Outcome-Driven Product Backlog (at Scale)
🎯 Many "Product Owners," zero accountability for outcomes 🤔
This article explores a shift that can be transformative in multi-team product development: moving from a feature backlog to an outcome-driven backlog. Instead of asking one Product Owner to manage hundreds of tasks across many teams, the focus shifts to something far more meaningful: business problems, customer behavior, and measurable outcomes.
Drawing on real experience at G2A, the article shows how one broadly defined product, one real Product Owner, and multiple teams can work effectively together, not by scaling feature management, but by changing what the backlog actually contains. The Product Owner prioritizes opportunities and outcomes, while teams explore, test, and iterate on solutions.
What makes this especially worth reading is that it connects LeSS thinking with modern product practice in a very practical way. You can see the link to one Product Owner, one broad product, less local optimization, and teams focused on customer value rather than handoffs and output.
👉 Recommended reading: a strong article for anyone exploring how LeSS, Product Ownership, and Product Discovery can come together in a truly multi-team environment.
Ticket sales LeSS2026 Tokyo started
🌅 The 2026 Global LeSS Conference in Tokyo is now open for registration.
On 8-9 October 2026, the global LeSS community comes together in Japan for a special joint edition with LeSS’ Yoaké ASIA. This year’s theme, A Dawn for Adaptive Organisations, speaks directly to the moment many organisations are in now: feeling the pressure of AI, speed, and uncertainty, while searching for clearer ways to design for learning, resilience, and flow.
Tickets are now on available from ¥33,000 ($207/€180), and the Call for Proposals is still open, so this is the right moment both to join and to consider contributing your experience.
In Tokyo’s Toyosu area, there is plenty to explore beyond the conference, from early sushi breakfasts at Toyosu Market and the Edo-style food streets of Senkyaku Banrai to the immersive art of teamLab Planets, waterfront walks with views of Rainbow Bridge, and easy access to the rest of the city by water bus. Plenty of reasons to extend your stay.
👉 Join us in Tokyo for two days of serious learning, deep exchange, and a memorable corner of the city to explore around it.
🎟️ Get tickets → 🎤 Submit a proposal →
What Leaders Get Wrong About Knowledge
🧑🍳 Leaders optimize for expertise; real advantage comes from shared learning.
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?
The hidden cost of AI generated code
🤖 AI can generate code faster than teams can truly understand it.
That is the sharp warning in Addy Osmani’s recent piece on “comprehension debt”: the hidden cost that builds up when more code is produced than people genuinely understand. The tests may be green, the pull requests may keep flowing, and the dashboards may still look healthy, but underneath that, a dangerous gap can grow between what the system does and what the team can confidently explain, change, and improve.
Why does this matter so much to the LeSS community? Because LeSS has always pushed in the opposite direction of shallow specialization and fragmented ownership. LeSS is built around whole-product focus, feature teams, shared code, one Product Backlog, and continuous learning across the system. In other words: more shared understanding, not less. More product knowledge in the teams, not outsourced understanding in silos, handovers, or tools.
That is exactly why this article is worth reading. It gives language to a risk many organizations are about to amplify: if AI is used mainly to generate more output, while real comprehension falls behind, then teams may look faster while actually becoming weaker. In a LeSS adoption, that matters enormously. Feature teams only work well when people build broad understanding, collaborate across specialties, and develop the ability to reason about the product as a whole. Without that, “speed” quickly turns into local optimization, fragile decisions, and hidden system risk.
There is also an important reminder here for leaders. AI does not remove the need for learning, shared ownership, or strong engineering judgment. If anything, it makes them more important.
The scarce capability in an AI-shaped product organization will not be the ability to generate code. It will be the ability to understand what is being built, why it is built that way, and how changes affect the larger system.
Why read this article?
- It explains a hidden risk behind AI-assisted development in a clear and practical way
- It reinforces why shared understanding matters more than ever
- It connects directly to LeSS ideas such as feature teams, shared code, whole-product focus, and continuous improvement
- It is a useful read for developers, managers, coaches, and leaders thinking seriously about AI in product development
👉 Recommended reading: Addy Osmani’s piece is an excellent prompt to ask a deeper question in your organization: are we using AI to increase learning and understanding, or only to increase output?
Video: Myths of Software Management
🏗️ What if some of the most common ideas in software management are simply wrong?
In this thought-provoking talk, Craig Larman takes aim at a number of widely repeated assumptions in product development, scaling, and organizational design. Drawing on themes from earlier LeSS conference talks, he revisits topics such as ownership of change, the weak evidence behind much management advice, the human side of collaboration, and the growing impact of AI on roles in software development and HR.
At the heart of the talk is one major myth: the widespread misunderstanding of Conway’s Law. By going back to the original paper, Craig shows how far modern interpretations have drifted, and why Conway’s actual message points not toward rigid structures or architecture-driven teams, but toward flexibility, evolving design, and organizations that can truly adapt.
This is a rich and stimulating session for leaders, managers, coaches, and practitioners who want to challenge conventional thinking and better understand what really helps organizations scale, learn, and improve in an AI-shaped future.
In this talk, you’ll hear about:
- why people need to want change before change can succeed
- why much management advice deserves healthy skepticism
- how AI may reduce the need for narrow specialist roles
- why multi-learning developers may matter even more in the years ahead
- what Conway’s Law actually says, and what it does not
- why flexibility matters more than locking teams to architecture
- how popular interpretations like “inverse Conway” have drifted from the original idea
👉 Watch the video and rethink some of the assumptions that shape modern software organizations.
Video: CafeTalk - Why Engineers are reluctant to talk to the customer?
🧩 Why do developers often hesitate to talk to customers or other teams?
In this conversation with Viktor Grgic, we explore the deeper reasons behind this common challenge in LeSS adoptions. Many developers are shaped by years in component teams, where efficiency meant focusing on coding, not solving customer problems. But feature teams require a fundamental shift: from optimizing for individual efficiency to optimizing for end-to-end product value.
💡 What’s inside:
- Why developers often resist direct customer interaction
- How component-team thinking shapes beliefs about efficiency
- Why feature teams require a shift from coding to problem-solving
- How lack of clarity from management reinforces old behaviors
- Why understanding the customer improves technical design quality
- How Scrum Masters and coaches can support this transition
- Why collaboration across teams is essential for real product delivery
- How career growth as a developer benefits from customer understanding
A practical conversation for leaders, Scrum Masters, and coaches working to help teams move beyond component thinking toward true product focus.
Click to play! 👆
LeSS Case Study: BASE telecom
📡 What does a real LeSS adoption look like inside a telecom company?
This case story from BASE telecom is a valuable watch because it shows a real transformation, not a neat theory. Starting from a traditional environment of silos, fixed-price contracts, escalations, and project thinking, BASE began shifting toward a more agile, product-focused way of working.
What makes this story especially worth your time is its honesty. It covers the real goals behind the change, reducing time to market, increasing business agility, and doing more with the same budget, as well as the messiness that came with it: organizational tension, contract changes, removing the PMO, flattening management, and learning how to work in a very different way.
For anyone interested in LeSS, this is a strong example of what adoption really means. Not installing a framework, but changing how the organization is designed, how work flows, and how people learn to respond to change together.
👉 Watch this case to see how deep organizational change can create faster learning, less escalation, and a stronger ability to adapt.
🍿 Watch the video → 🧑🎓 Explore more case studies →
