LeSS Newsletter - June 2026
01-07-2026Hi 👋
How’s your AI journey going? The numbers keep saying the same thing: MIT’s Project NANDA found 95% of generative AI pilots show no measurable return, and RAND puts overall AI project failure above 80%. The problem is rarely the model, it’s the system around it: unclear ownership, no way to scale what works, decisions stuck in five layers of approval.
AI doesn’t fix your organisation, it amplifies what’s already there: the queues, the silos, even how carefully people trust an answer. That’s this month’s thread, from organisational design down to our own cognition.
This month’s ideas, ready to put into practice:
- 🧩 Product Development Work Categorization by Bas Vodde
- 🧠 Cognitive Surrender: what AI is doing to our own thinking
- ☕ CafeTalk 12: From Silos to Learning, with Jurgen de Smet
- 🤖 Which Agile Coach tasks will AI eat first? by Gene Gendel
- 🎬 A LeSS Story, Episode 4 by Robert Briese
- 📚 LeSS Case Study: Royal Bank of Scotland by Ben Maynard
Enjoy, and keep learning!
Bastiaan van Hamersveld
CEO at less.works, email: bastiaan@less.works
Product Development Work Categorization
🧩 It is easy to build a product. It is hard to build a lasting, maintainable one.
After four years running the Wärtsilä Holistic Agreements Lifecycle Ecosystem product in a LeSS structure with 10 teams on one Product Backlog, Bas Vodde shares the work categorisation his teams use to make all of product development visible, not just new features.
The framework splits work into six types, from reactive maintenance (bugs) to proactive maintenance (internal improvement) to product enhancements, crossed with whether it’s a planned roadmap item or smaller emerging work. Labelling everything that isn’t a shiny new feature as “maintenance” hides more than it reveals, and that blind spot gets more expensive the faster teams (and AI) can generate new work.
What you’ll learn:
- Six types of product development work, and what happens if each is neglected
- Why lumping everything into “maintenance” hides where your effort actually goes
- How to combine work type with roadmap-vs-emerging to see the full picture
- Concrete tips for keeping a healthy mix on the Product Backlog
Cognitive Surrender: What AI Is Doing to Our Own Thinking
🧠 You trust the AI’s answer even when it’s wrong, and you feel more confident about it, not less.
A new Ars Technica report covers a Wharton School study of 1,372 people across more than 9,000 trials, introducing what the researchers call “Tri-System Theory,” a third layer of reasoning that sits outside the brain entirely: the AI itself. When the AI was accurate, 93% of participants trusted it. When it was wrong, 80% still trusted it anyway, and those who followed the faulty AI still felt more confident they’d gotten the right answer.
The researchers call this pattern “cognitive surrender,” and it lands closer to home than it looks. If AI can quietly override an individual’s own judgement, it can just as easily override a team’s. The same organisational design questions this newsletter keeps coming back to (who decides, who checks, who owns the outcome) apply just as much to a single mind as to a whole product organisation.
🧠 Read the article → 📄 Read the Wharton paper directly →
Video: CafeTalk 12 - From Silos to Learning: Why Product Companies Win with AI
☕ Why does AI make some organisations faster and others just... more broken, faster?
In this second conversation with Jurgen de Smet, Bastiaan digs into why traditional, siloed organisations don’t get less broken with AI: they get more broken, because every existing handoff and queue now has to absorb 10-20× more output. Product organisations that already integrate continuously and share one Product Backlog don’t have those queues to begin with, so they’re the ones who actually compound the benefit.
You will learn:
- Why AI amplifies existing organisational bottlenecks instead of curing them
- Larman’s Laws, and why organisations are wired to protect the status quo
- A real example: how one company cut a 30-minute build pipeline to under 5 minutes, and used AI as a live PRD interviewer across six parallel teams
- Why 40-60% of “AI work” is really just overdue technical debt cleanup
What Type of Agile Coaches and Scrum Masters Will AI Eat for Lunch?
🤖 If a role is poorly defined, replacing it with a bot becomes easy. So what actually survives?
Gene Gendel draws a sharp line between the mechanical parts of Agile coaching and Scrum Mastering (status reports, burndown charts, tooling questions, ticket audits) and the deeply human ones: navigating politics, coaching leadership through real behavioural change, building trust across teams.
The mechanical half is already being absorbed by AI, often more efficiently than any human ever did it. The irony, as Gene puts it, is that those responsibilities only became vulnerable because the roles were watered down to ceremony-policing and status reporting in the first place.
What you’ll learn:
- Which Scrum Master and Agile Coach tasks AI already does better than humans
- Why some responsibilities (trust, politics, mindset change) are out of AI’s reach
- Why a poorly-defined role is the real reason it looks replaceable
A LeSS Story, Episode 4: One Product Backlog, One Direction, Real Adaptability
🎬 What truly makes LeSS different when multiple teams build one product?
In the final episode of Robert Briese’s animated LeSS Story series, the focus lands on one of LeSS’s core design choices: one Product Backlog for the whole product, with one real Product Owner accountable for value. Instead of team-level priorities and go-between “team Product Owners,” developers work directly with customers and stakeholders, and the whole organisation optimises for the product, not the parts.
What you’ll learn:
- Why one Product Backlog enables whole-product thinking
- How LeSS avoids local optimisation and competing team priorities
- Why direct collaboration beats intermediaries
- How Sprint Review and Retrospective work at scale without adding layers
This closes out the 4-part animated series about important parts of LeSS.
👀 Watch the video! ➔📽️ Find all LeSS Stories videos →
LeSS Case Study: Royal Bank of Scotland
🔍 How do you scale Scrum across three cities on two continents without losing the plot?
This LeSS case study takes you inside a large-scale OTC Derivative and Collateral Management platform delivery at Royal Bank of Scotland, led by Ben Maynard. Multiple Scrum teams, split across the UK and India, had to be shaped into real cross-functional feature teams, while proving out ideas like the Temporary Fake Product Owner, Overall Retrospectives, and Multi-Team Product Backlog Refinement along the way.
What you’ll learn:
- Why component-team structures were rejected in favour of real feature teams
- How Overall PBR and Multi-Team PBR kept a shared Product Backlog usable at scale
- What the Temporary Fake Product Owner role solved, and why it’s temporary by design
- Why making Undone Work explicit mattered as much as the Definition of Done
A candid, detailed account of the false starts and real wins in scaling Scrum across distance and regulatory pressure.
🍿 Read the case study → 🧑🎓 Explore more case studies →
