Large-Scale Scrum (LeSS)

LeSS was created by Craig Larman and Bas Vodde, drawing heavily from their extensive experience coaching large product development organizations. Their work began in the early 2000s, culminating in the publication of several books, including "Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum" (2008) and "Large-Scale Scrum: More with LeSS" (2016). LeSS emerged from a desire to apply Lean principles and Systems Thinking to large-scale product development, recognizing that many scaling frameworks inadvertently reintroduce traditional hierarchical structures and roles that hinder agility.

The primary purpose of LeSS is to enable multiple Scrum Teams to work together effectively on a single, integrated product. This addresses common challenges in larger organizations, such as fragmented product backlogs, conflicting priorities, lack of shared ownership, and communication overhead. By emphasizing a whole-product focus, LeSS helps organizations align all teams towards a common goal, reduce waste, improve transparency, and accelerate learning and adaptation.

LeSS is important because it offers a minimalist, Scrum-centric approach to scaling. Unlike some other frameworks that introduce many new roles, artifacts, and events, LeSS strives to keep the organizational structure as flat as possible, relying on the existing Scrum roles (Product Owner, Scrum Master, Team) and events, with minor adjustments for coordination. This focus on simplicity and adherence to Scrum's core principles makes it appealing to organizations that want to scale without losing the essence of Agile.

Within the wider knowledge graph of Agile, LeSS stands as a prominent "Scaling Agile" framework. It builds directly upon the principles of Scrum and Lean Software Development, advocating for Feature Teams and a strong Definition of Done. It contrasts with more prescriptive or hierarchical scaling models like Scaled Agile Framework (SAFe) by emphasizing organizational de-scaling and fewer specialized roles. LeSS shares some philosophical common ground with Nexus and Scrum@Scale in its commitment to Scrum's core, but offers a more comprehensive organizational design for larger product groups.

The fundamental workflow in LeSS revolves around a single Product Backlog and a single Product Owner for the entire product. All Scrum Teams pull items from this shared Product Backlog. This ensures a unified product vision and eliminates conflicting priorities that often arise with multiple product backlogs. The Product Owner works closely with all teams and stakeholders to refine the backlog and ensure clarity.

LeSS maintains the standard Scrum events, but some are adapted for the multi-team environment:

• Sprint Planning Part 1 (Overall Planning): All teams and the Product Owner meet to select Product Backlog Items (PBIs) for the Sprint. Teams discuss and clarify items, and then each team selects the PBIs they will work on.
• Sprint Planning Part 2 (Team Planning): Each individual Scrum Team conducts its own Sprint Planning Part 2, detailing how they will implement their selected PBIs. Representatives from other teams may attend to coordinate dependencies.
• Product Backlog Refinement (PBR): This is an ongoing activity involving the Product Owner, teams, and stakeholders. In LeSS, multiple PBR sessions may occur, some involving representatives from several teams (Overall PBR), and others specific to individual teams.
• Daily Scrum: Each Scrum Team conducts its own Daily Scrum. Teams are encouraged to send representatives to other teams' Daily Scrums or use other informal coordination methods to manage dependencies.
• Sprint Review (Overall Review): All teams, the Product Owner, and stakeholders participate in a single, integrated Sprint Review. This ensures a holistic view of the increment and facilitates feedback on the entire product.
• Sprint Retrospective: Each Scrum Team holds its own Retrospective. Following this, an Overall Retrospective is held, involving the Product Owner, Scrum Masters, and representatives from each team, to discuss systemic issues and improvements across the entire product group.

LeSS emphasizes the use of Feature Teams, which are cross-functional, cross-component teams capable of delivering end-to-end customer value. This minimizes dependencies and promotes collective code ownership. The Definition of Done is crucial in LeSS; it must be shared and applied by all teams to ensure a truly integrated, shippable product increment at the end of every Sprint.

In LeSS Huge, where there are more than eight teams, the concept of Requirement Areas is introduced. Each Requirement Area has an Area Product Owner, who works with a subset of teams and acts as a proxy for the main Product Owner for their specific area. However, there is still only one Product Backlog and one overall Product Owner, maintaining the whole-product focus.

Benefits

• Simplicity and Transparency: LeSS maintains a lean structure, reducing organizational complexity and increasing visibility into product development.
• Whole-Product Focus: The single Product Backlog and Product Owner ensure all teams are aligned towards a common product vision and customer value.
• Enhanced Adaptability: By empowering Feature Teams and promoting frequent feedback loops, LeSS enables organizations to respond quickly to market changes.
• Improved Quality: A shared, rigorous Definition of Done across all teams drives higher quality and reduces technical debt.
• Reduced Waste: Eliminating unnecessary roles, handoffs, and component teams streamlines the development process and reduces non-value-adding activities.
• Increased Learning and Collaboration: Cross-team coordination and the Overall Retrospective foster knowledge sharing and continuous improvement across the entire product group.

Limitations

• Significant Organizational Change: Implementing LeSS requires a deep cultural shift and a willingness to de-scale management layers and traditional structures.
• Strong Product Owner Required: The single Product Owner role is demanding, requiring excellent communication, prioritization, and stakeholder management skills.
• Initial Learning Curve: Teams and management need time to adapt to the LeSS principles, especially moving from component teams to feature teams.
• Not for Small Organizations: LeSS is designed for scaling, so it may be overkill for organizations with only one or two Scrum Teams.
• Requires Commitment: Successful adoption requires sustained commitment from senior leadership to support the necessary structural and cultural changes.

Common Mistakes

• Treating LeSS as a Process, Not Principles: Mechanically following rules without understanding the underlying Lean and Systems Thinking principles often leads to failure.
• Creating Component Teams: Resisting the shift to Feature Teams and maintaining specialized component teams reintroduces dependencies and slows down value delivery.
• Weakening the Product Owner Role: Fragmenting the Product Owner role or having multiple Product Owners for a single product undermines the whole-product focus.
• Ignoring the "De-scaling" Aspect: Failing to remove unnecessary management layers or roles, thus adding complexity instead of simplifying.
• Insufficient Coaching and Training: Underestimating the need for experienced LeSS coaches and continuous learning for teams and management.
• Lack of a Strong Definition of Done: Without a rigorous, shared DoD, teams may produce "done" increments that are not truly shippable or integrated.

Real-world Examples

LeSS has been successfully implemented in various industries globally, including telecommunications, finance, automotive, and software product development. Companies like Ericsson, BMW, and JP Morgan Chase have publicly shared their experiences with LeSS, often highlighting improvements in product quality, time-to-market, and employee satisfaction. For instance, a large financial institution might use LeSS to coordinate multiple teams developing a complex trading platform, ensuring all components integrate seamlessly and deliver value to end-users every Sprint. A telecommunications company might apply LeSS to develop new network features, with different teams focusing on various aspects of the infrastructure and user-facing applications, all contributing to a single, shippable product increment.

Best Practices

• Start with Principles: Ensure a deep understanding of LeSS principles (Scrum, Lean, Systems Thinking) before implementing rules.
• Invest in Coaching: Engage experienced LeSS coaches to guide the transition and provide ongoing support.
• Empower Feature Teams: Actively work to form and support cross-functional, cross-component Feature Teams.
• Strengthen the Product Owner: Provide the Product Owner with the authority, support, and skills needed for the demanding role.
• Foster a Strong Definition of Done: Continuously improve and enforce a comprehensive, shared Definition of Done.
• Focus on Continuous Improvement: Utilize both team and Overall Retrospectives to identify and address systemic impediments.
• Lead by Example: Senior management should actively participate in and champion the LeSS transformation.