LeSS class with Bas Vodde

The definition area of LeSS might appear familiar to our class attendees. The core consists of foundations, thinking models and principles. Around them, the LeSS framework - rather frameworks, because there is a LeSS Huge version for very large adoptions - provides the necessary constellations and boundaries. The outer ring contains numerous - around 600 - experiments, and guidance when and how to try them. LeSS with a range of teams working on the same product might just look like this.

Some special considerations of LeSS are not obvious, and should be emphasized:

• LeSS still talks about a potentially shippable, rather than releasable product increment. 
• Inter-team synchronization is primarily done by the teams themselves, rather than Product Owners or Scrum Masters.
• A Definition of Ready is considered as harmful.
• The development team in LeSS is just called team. The concept of a Scrum Team does not apply to LeSS, because not every team is supposed to contain their own Product Owner.
• The Product Owner is more concerned with prioritization than clarification.
• The teams work closely with clients and stakeholders.
• User Stories might be applied on high Product Backlog level, but the team’s Sprint Backlogs may contain components or tasks.
• LeSS is talking about Sprint Planning I & II as separate meetings.
• Teams commit to their Sprint Backlogs after Sprint Planning 2
• The only additional meeting is the Overall Retrospective, where the learning experiences of the Sprint are collected and examined together.

The ingredients and practices of LeSS might appear familiar to some. This is no miracle, because the LeSS experiments are a collection of numerous experiences throughout several years of scaled Scrum adoptions. And there are risks and side effects. LeSS requires a massive organizational restructuring to start with. The line organization follows products and sites, not functional specializations and hierarchies. A consequent LeSS adoption contains the reorganization based on cross-functional teams. Each team is basically able to deliver potentially shippable product increments with a minimum of coordination effort to other teams. The role of Product Owner is even more distinctly located at the business side, while team managers might take care about organizational and disciplinary aspects. Everything is focused on providing the best possible environment for self-organizing, product oriented teams.

In addition to the foundations and structure of LeSS, the class dealt with adoption challenges. The desired range and maturity of a product teams can’t be reached over night. Some teams work on a partial aspect of the whole product, particularly concerning very large and complex products. Many teams are not - yet - able to deliver real potentially shippable product increments at the end of each Sprint. Supporting tools and measures are part of the LeSS experimentation guides. In reflect, I recommend the LeSS class to ScALeD supporters, critical SAFe users, DAD-followers, Nexus fans and anyone, who - unfortunately - has to deal with the scaling of agile approaches, because a single team is not enough in their context.