LeSS is more
I had the opportunity to join a Certified LeSS Practitioner class by Bas Vodde in mid September. I wanted to be able to understand and evaluate LeSS better, and wanted to take a next step to adopt and spread LeSS concepts. Hold it, what is LeSS? The class is very clear about that. LeSS is Scrum. To be exact, the consequent application of Scrum principles and rules to a scaled environment. This is a quite similar approach to our ScALeD principles. This applies to further foundations of LeSS and Scrum like Lean, System Thinking and, yes, people. Just like Scrum, LeSS is easy to explain and hard to adopt. It offers no blueprints, or a model that needs to be tailored to the own context. It merely provides the starting point for an effective scaled application of Scrum.
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.
About the author
Andreas Schliep is a founding member and executive partner of DasScrumTeam. He is a Scrum coach and trainer. He studied at the technical university of Bremerhaven, and worked as a software developer, project manager, team lead and group lead. Andreas has worked with Scrum since 2003. He became a full-time Scrummer in 2006.
Since then, he has helped to introduce and improve Scrum and agile practices in numerous companies all over the world. His favorite topics are quality management and scaling.
- Experienced ScrumMaster, Product Owner, Coach and Trainer
- Introduced Scrum at WEB.DE
- Coaching of internationally distributed teams
- Transition from RUP to Scrum at UOL Brazil
- Scrum Trainings and Coaching in Germany, Switzerland and Austria
Always up to date with the DasScrumTeam newsletter.
The best in terms of Scrum. Once a month. Every month.