Over the past few years working in the software industry as a developer, I've often heard about LeSS (Large-Scale Scrum). At first, I saw it as something distant to me. My team wasn't very big, so I assumed LeSS was just another framework designed to improve product development at scale — something only large organizations would care about.

Fortunately, I've had the opportunity to join a multi-team Scrum environment that is currently adopting LeSS. This has sparked my curiosity and eagerness to better understand how LeSS works in real-world practice.

So, I joined a Certified LeSS Practitioner (CLP) course, and I'd like to take this opportunity to reflect on what I've learned in this blog post — hopefully more to come.

What is LeSS ?

Large-Scale Scrum (LeSS) is an organizational design system for Agile product development with multiple teams working together on the same product.

Let's zoom in a bit on the definition of LeSS.

It's for Agile product development.

So, to be ready to adopt LeSS, your organization should at least embrace Agile principles — valuing collaboration, flexibility, and iterative delivery — or at the very least, be open to adopting an Agile framework like Scrum.

LeSS is about changing the organizational structure

This is the key: if the management team — or even just the person with the authority to change organizational processes (at least within one department) — doesn't support the LeSS adoption, then no matter how strongly you believe it's the right approach, it simply won't work.

One sentence I heard from Bas Vodde (the trainer and co-creator of LeSS) during the course stuck with me: "It cannot be done from the bottom up."

To make this more explicit: in many organizations today, we operate with clearly defined roles, departments, and hierarchical steps in the org chart.

In LeSS, however, the structure is radically simplified — there are only Product Owners, Scrum Masters, and cross-functional Teams. There are no separate roles like Project Managers, DevOps teams, Security teams, Operations, Development Leads, Business Analysts, UX/UI Designers, or Testers.

Now you can see why a LeSS transformation is nearly impossible to drive from the bottom up — it requires a fundamental shift in how the entire organization is structured and operates.

It's about multiple teams working together on the same product.

What's interesting here is that the definition of "product" in the LeSS context is broader — or sometimes even narrower — than what we might typically imagine.

In LeSS, a "product" isn't just a set of features or a specific application — it can span across systems, components, or customer-facing services that together deliver value to the customer.

For example, in the banking industry, we often talk about separate products like credit cards, loans, or wealth management. However, if we shift our perspective, all of these offerings serve the same purpose: delivering financial services to customers.

From this broader view, the organization might consider everything as one single product. This means having one unified Product Backlog instead of separate ones, enabling multiple teams to work together to maximize customer value across the entire service.

What is the goal of LeSS?

Contrary to common assumptions, LeSS isn't designed to boost team velocity, efficiency, or productivity.

Instead, the primary goal of LeSS is to enhance organizational flexibility and directly deliver value to customers.

Let's explicitly dive into both goals, starting with flexibility.

In LeSS, teams are cross-functional, meaning each team has the ability to handle all aspects of delivering a product feature — whether it's development, testing, UX, or deployment. Over time, teams build the skills needed to deliver value to customers.

This setup contributes directly to one of the core goals of LeSS: organizational flexibility. In this context, flexibility means the ability to adapt quickly to change, shift priorities based on customer needs, and reallocate work across teams — without being blocked by rigid roles or team boundaries.

This approach also reflects the LeSS principle of "people over roles", which is based on the belief that people are capable of learning new skills within a reasonable amount of time.

One important idea to remember is this:

"The team has all the skills — but no single person needs to know everything."

Because teams are capable of handling a wide range of work, the Product Owner doesn't need to assign specific features to specific teams. Instead, they focus on prioritizing the Product Backlog — and any team can pull in the highest-priority work.

An additional benefit of this structure is that the organization becomes more resilient to turnover. Knowledge is shared across teams rather than siloed within individuals or component teams, reducing risk and maintaining continuity even when someone leaves.

another goal is deliver value to customers, why is this a goal ?

I used to believe that I was delivering value to customers every sprint. It felt like we were making progress — feature by feature, release by release.

But after attending the course, I began to pause and reflect more deeply. A few questions quietly surfaced in my mind:

• Am I truly delivering what the customer needs?
• Does this feature actually help solve a real problem?
• Do I genuinely understand who my customer is?

Or have I, perhaps unknowingly, been delivering what the organization assumes is valuable — features that may not have been validated, possibly suggested with the best of intentions, but without real insight into the customer's world?

LeSS — at least from my perspective — provides a possible solution to these problems, when there's only one Product Backlog, one Product Owner, and every item is clearly prioritized, it becomes easier to stay focused on what really matters.

The idea is simple: the top item in the backlog should be the one that gives the most value to the customer.

If you're someone who is looking for a framework to improve your organization's sustainability — where the organization is driven by its people and where flexibility and customer value come first — then LeSS might be the right fit.

Remember, the goal isn't to prioritize velocity, efficiency, or productivity above all else. The real focus is on adaptability and delivering real value to customers. That's what leads to long-term, sustainable improvement.

Speaking from a product developer's perspective — I'd love to work in an organization like that.

And speaking from a management perspective — I'd love to see real customer problems being solved and my team feeling truly satisfied and fulfilled in their work.

If you've made it this far and still have questions that haven't been answered in this post — don't worry, I completely understand. That's exactly why I took the course myself.

There's still so much more to explore, and I haven't covered everything here. Over time, I plan to share more thoughts and reflections as I continue learning — both to deepen my own understanding and to connect with others who are also curious about LeSS.

In future posts — driven mostly by my own curiosity — I hope to write about:

• Systems thinking
• Self-managing teams
• The definition of "product"
• LeSS Huge
• The Definition of Done
• How to adopt LeSS in practice

Stay tuned, and thank you for reading!

Please keep in mind, everything I've shared here is based on my personal understanding after taking the course. Some parts might not fully align with the official LeSS perspective, and I'm open to discussion or corrections.

If you're truly interested in LeSS, I highly recommend taking the course yourself or exploring the official resources at less.works.