LeSS Newsletter - August 2023August 24, 2023
For those on the Northern Hemisphere, I hope you had a wonderful summer break! The next half a year is going to be an exciting one as we have the LeSS conference in Berlin coming. In this newsletter, we include information about the Berlin LeSS conference, introduction of our CEO, some updates on LeSS pages and images, and some complexity food for thought:
We are delighted to announce that our speakers' program is now complete and brimming with exciting content.
Alongside insightful talks from industry experts, engaging panel discussions, and in-depth workshops, we'll feature an Open Space format, allowing for interactive collaboration and spontaneous discussions. Meet and discuss with LeSS Trainers, Coaches and also fellow practitioners who are part of a LeSS adoption.
Whether you're just beginning your journey with Large Scale Scrum or a seasoned expert, our packed program promises something for everyone. Don't miss this unique opportunity to learn, network, and grow.
The world of LeSS is calling. Go to http://less2023.works to register; we can't wait to see you there!
There has been no major update to the LeSS rules as we found no way to improve and simplify them... however...
New: Why LeSS?
We have identified many pages on the less.works site that would benefit from being updated. They do not always reflect our latest experiences and sometimes the writing can be improved and simplified. The one that stood out as the most urgent was the "Why LeSS?" page. We've entirely revamped that. A preview of this is:
LeSS is an organizational system for product development aimed at maximizing an organization’s adaptiveness. With adaptiveness (or agility, the original intent of agile development) we mean optimizing towards:
- Ability to change direction with relatively low cost, primarily based on discovery through frequent delivery, for…
- Maximizing value delivered to customers and end-users.
LeSS is the result of two decades of Go See, systems thinking, and experimenting to achieve organizational adaptiveness.
You can find the whole article on the LeSS Site section at Why LeSS.
New: LeSS event images
We have made an important update to many of the LeSS graphics used in the Large-Scale Scrum book and are often used in training. Before sharing these images, let us explain why these updates were done.
While writing the Large-Scale Scrum book, we created a bunch of images related to the LeSS events such as Sprint Planning and Product Backlog Refinement. We had a lot of discussion around how to show them in a way that they can be applied in most contexts. In other words, we optimized the image not to the simplest and most common way of working but towards a generic description that can be adjusted to different contexts in the spirit of letting people own their way of working versus renting it. That backfired. The unfortunate side-effect of that decision has been that some LeSS adoptions ended up with either (1) tweaking the event to be closest to what they already had, thus minimizing the amount of change, or (2) tweaking the event to solve all speculated problems thus making it more complex than it needs to be.
A great example of this is the Product Backlog Refinement. The Large-Scale Scrum book included a picture and description of a two-step Product Backlog Refinement with first an 'overall' refinement followed by a multi-team Product Backlog Refinement. We tried to explain the Overall Product Backlog Refinement should be an exception and the single-team Product Backlog Refinement should be avoided. In the years since we wrote the book and created these images, two things happened (1) we encountered much too complicated refinement structures that usually led to teams working more isolated and having less cross-team learning, and (2) we learned that just having one Multi-Team Product Backlog Refinement is likely the best starting point for most contexts.
Therefore, we simplified the book images to reflect simple and recommended ways to start. With experience, your product can always change the structure of the events to solve certain context-specific problems. The main images that have been updated are:
Greetings to the LeSS Community,
I am Bastiaan van Hamersveld, and I'm thrilled to collaborate alongside Craig, Bas, and the dynamic members of the LeSS community!
Since I graduated from University, alongside Bas, I have been a Software Engineer by heart. Throughout my journey I have been working at/with various Product Development companies, some of which I proudly (co-)founded.
My agile journey began in earnest in 2007 when I embraced the role of a Scrum Master. In that capacity, I, alongside a committed team, transformed a traditionally waterfall-driven organization (with over 100 teams) into an agile entity, reducing delivery cycles from a year to just a month. This took almost 5 years to pull off.
And boy, have I wished to have the knowledge I am learning these days from the LeSS courses, trainers & coaches, and the community members. It would still have been a multi-year transition with challenges, but such knowledge would have streamlined our transition, providing coherent principles and systemic thinking for the executive leadership. (Before anybody asks, the first LeSS book, I only discovered in 2010 🙄)
My vision for LeSS entails strengthening the brand's presence, ensuring that decision-makers recognize 'LeSS' as a viable option and know where to locate the right coaches/trainers.
I aim to forge new partnerships, as well as amplify the affiliation individuals and companies feel toward LeSS and its ecosystem.
The LeSS Company is also there for the trainers and candidate trainers, I have gathered already quality inputs, which we will pick up. Do reach out to me with questions and feedback, especially candidate trainers.
Perusing recent conferences, I've noticed a conspicuous absence of LeSS-centric discussions. Surely, our LeSS enthusiasts aren't reticent, are they? 😉
As the LeSS Community flourishes, I'm here to accelerate its growth, branching out into diverse regions. If you're leading or aspiring to establish a local LeSS community, let's collaborate to make it a reality!
I'm convinced that LeSS offers countless product development companies the ideal trajectory. The essence of LeSS — descaling, simplification, adaptiveness, continual learning, and prioritizing people — appears straightforward, yet it's profound.
Join me in advancing LeSS further, shaping a more promising tomorrow.
Looking forward to our journey together,
A couple of months ago, I was introduced to complexity bias. This is the tendency for people to prefer a complex solution over a simple one. Obviously, this peeked my interest as with LeSS we try to aim for simple ways of working yet many organizations consistently make things more complicated than it needs to be. SAFe recently released yet another new version and, to me, it seems to continuously increase in complexity. If people really have a bias towards more complex solutions then how can we cope with that while helping organizations improve their product development?
Before concluding anything, I wanted to explore the topic a bit more. Cognitive biases became better known through the work of Nobel Prize winner Daniel Kahneman and his 2012 book "Thinking, Fast and Slow". In the book, he defines two systems for thinking, fast and slow, and explains how people think fast, save mental energy, by applying thinking shortcuts. These default thinking shortcuts are called cognitive biases and wikipedia lists hundreds of them but complexity bias is not listed there. Complexity bias also raises a question... how can people prefer a complex solution as a way to save mental energy? That feels like a contradiction.
I stumbled on this post, "Complexity Bias: Why We Prefer Complicated to Simple," which helped me understand the contradiction. People prefer complex solutions as a way to avoid having to understand the problem. Hence it saves mental energy. That makes sense and also reminds us again why LeSS emphasizes Systems Thinking. Better understanding of your development system, which takes more mental energy, can lead to simpler ways of working.
The previously mentioned article also quoted Edsgar Dijkstra, which is someone who has influenced my thinking about software development quite a lot.
But before above rosy future will have been reached, some hurdles have to be taken. Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.
I was unaware of this Dijkstra quote and decided to figure out where it came from. It turned out it came from a note written bij Dijkstra called "On the nature of Computing Science" from 1984. It is as typical Dijkstra as I can imagine. While I can't agree with his love for applying mathematics to software development, I do enjoy his fatalistic thinking. The same article concludes his philosophizing on the future of computer science with:
One can get credit for some complicated concepts one has introduced, it is hard to get credit for the discovery how some established but complicated concepts had better be avoided: those unaware of these concepts won't notice your discovery and those with vested interests in them will hate you for it. Hence my urgent advice to all of you to reject the morals of the bestseller society and to find, to start with, your reward in your own fun. This is quite feasible, for the challenge of simplification is so fascinating that, if we do our job properly, we shall have the greatest fun in the world.
I'd say that is as relevant in 1984 as it is in 2023. Thus, Two cheers for Elegance.
Videos and webinars:
- BMW Groups Autonomous Driving Q&A Session with Konstantin Ribel & Michael Mai at Sydney Scrum User Group
- Maximizing Dependencies with Interdependent Teams, NYC meet-up group - Bas Vodde
- Kent Beck On The FIRST Testing Frameworks, TDD, Waterfall & More | The Engineering Room Ep. 16 - Dave Farley
- I Couldn't Believe THIS About Mob Programming... - Dave Farley
- Is A Divide Between Product Discovery and Delivery Really That Harmful? - Ben Maynard chatting with Viktor Grgic
- Get a Grip on your Agile Transformation - Alexey Krivitsky and Roland Flemm
- Flat vs Hierarchical Backlogs - Gary Hansen
LeSS Conference 2022:
We hadn't shared the recorded talks from the LeSS Conference 2022 yet. Here are some of them:
- From Tribes with Dedicated PO to One Product Backlog – John Kop & Roy Klein
- Team Knowledge Modell (TKM) – Mark Bregenzer
- More with Less – Craig Larman
- Maximizing Dependencies with Interdependent Teams – Bas Vodde
- How Structure ate Culture in a misused LeSS Huge at an Automotive Giant – Denis Sunny
- Flip experience - journey there and back again? – Jakub Gros, Roman Kohoutek
- Critical Organization Design Guidelines – Cesario Ramos
- How to find a true Product Owner – Robert Batůšek
- Inspire Agile Transformation from Bottom-Up – Sofia Pelzl
- Complexity Bias: Why We Prefer Complicated to Simple
- Thinking About Code Review - Kent Beck
- Still using feature branching? Try trunk-based development instead - Denis Kranjcec
- Agile and the Long Crisis of Software - Miriam Posner
- The Agile Manifesto Principles Explained - Dhaval Panchal
- Following FTAM By Expanding DoD VS. Becoming A Hostage To Traditional Org Structure - Gene Gendel
- The SAFe Delusion
- Organizational design models in the evolution of managerial thinking (part 1) - Alexey Krivitsky
- On Productivity of Middlemen and Handovers - Robert Batusek