like Scrum, LeSS is not a process or a technique for building products. Rather, it is a framework within which processes and techniques can be adapted to meet the needs of the particular situation.

The job of managers is to build an environment in which teams continuously deliver and continuously improve.

Here is the perfection vision for LeSS that we use: Create organizations able to deliver or change direction at any time without additional cost.

Attempting to change an organization’s culture is a folly, it always fails. People’s behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.

One Product Owner, two to eight Teams, a Scrum Master for one to three Teams. Crucially, these Teams are feature teams—true cross-functional and cross-component full-stack teams that work together in a shared code environment, each doing everything to create done items.

Prefer adopting LeSS in one product group1 really well over applying LeSS in many groups poorly.

When following the team-based structure, the question will no longer be “Which individuals do we need?” but will become “Which teams do we need?”

Instead we want more responsible Teams by having less (fewer) roles, we want more customer-focused Teams building useful products by having less artifacts, we want more Team ownership of process and more meaningful work by having less defined processes.

(RULE: The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders.)