Leveraging LeSS principles, roles, guides, and experimentation

Detailed in their book, Large-Scale Scrum: More with Less, Larman and Vodde describe the LeSS framework as consisting of numerous LeSS rules and LeSS guides. This book will not cover all of them. Instead, you will obtain an understanding of how LeSS works in a generalized sense. For more information, please refer to Larman and Vodde's books and website. In their books and their website (https://less.works/), Larman and Vodde provide a wealth of knowledge on the use of LeSS rules and LeSS guides. Figure 10.1 shows the relationships between LeSS principles, frameworks, guides, and experiments:

Figure 10.1 – LeSS complete picture

The LeSS principles establish the core upon which LeSS is built. The Less and LeSS Huge frameworks are next, establishing the rules and foundations for empiricism and whole-product focus with Scrum on a large scale. The guides potentially extend the rules of the frameworks on a situational basis. And experimentation is ultimately how LeSS teams determine the value of specific LeSS Guides and other practices in support of their unique product development needs. Let's take a closer look at each of these four elements.

Applying LeSS principles

LeSS principles guide decision making on the use of LeSS rules. As a general definition, principles outline the underlying or guiding theories and beliefs behind a certain way of life. In the context of this book, principles outline a belief system that defines how we conduct product development work. With this understanding, LeSS principles include the following:

• Large-Scale Scrum is Scrum: Learn how to apply the principles, roles, elements, and purpose of Scrum in a large-scale context.
• Transparency: Provide visibility in context with the definition of Done and the artifacts and events of Scrum.
• More with Less: We don't need more roles, artifacts, or processes; instead, LeSS funnels personal responsibilities and ownership to the lowest possible levels.
• Whole-product focus: No matter how many Scrum teams there are, there is only one Product Backlog, one Product Owner, one shippable product, and one Sprint.
• Customer-centric: Evaluate value from the eyes of the paying customer and eliminate everything else as forms of non-value-added waste.
• Continuous improvement toward perfection: While perfection is never truly achievable, it's always the goal, that is, frequent deliveries of potentially shippable products, with lowest costs, no defects, adding only customer value, and no external impacts.
• Lean thinking: This is as defined in Chapter 5, Lean Thinking, and Chapter 6, Lean Practices in Software Development.
• Systems thinking: This is as defined in Chapter 3, The Scrum Approach.
• Empirical process control: As noted in The Scrum Guide, use observation and experimentation to constantly learn and improve and allow complete transparency with inspection and adaption to improve the product.
• Queuing theory: Consistent with the concepts you learned in Chapter 4, Systems Thinking, on Lean development, LeSS applies queuing theory to the R&D domain.

LeSS principles provide the necessary context to appropriately apply LeSS rules and LeSS guides. In the next subsection, you are going to learn about LeSS rules.

Implementing LeSS rules

LeSS implements a set of 42 rules that form the foundation of the LeSS framework. The rules must be in place to support the empirical process control and whole-product focus of the LeSS framework.

LeSS framework rules are mapped to the elements of structure, products, and Sprints within the two LeSS frameworks, LeSS and LeSS Huge. The following list provides some examples of mapping LeSS rules to the LeSS and LeSS Huge frameworks:

• The LeSS framework applies to products with two to eight teams.
• LeSS Huge applies to larger products where one Product Owner cannot maintain complete visibility over its entire scope. Avoid applying LeSS Huge to smaller product groups as it will result in more overhead and local optimizations.
• All LeSS rules apply to LeSS Huge unless otherwise stated. Each requirement area acts like the basic LeSS framework.

These are only three of the 42 defined LeSS framework rules. The entire list of rules is maintained at the leSS.works website, on the rules web page : https://less.works/less/rules/index.

Employing LeSS guides

LeSS guides are less strict than LeSS rules in that they offer recommendations based on years of experience of implementing and using the LeSS framework across numerous entities and industries. Readers can learn more about successful LeSS adoptions at the leSS.works website, on the case-studies webpage: https://less.Works/case-studies/index.

As noted previously, Larman and Vodde make it clear that development processes cannot be strictly enforced and that any development methods must be applied situationally in context to be useful. Also, some experimentation is necessary to figure out the best way to apply predefined methods to inspect and adapt them to the team's current needs.

While the guides have proven useful elsewhere, each organization must apply them appropriately as an experiment to see whether and how they would work in their unique development environments and situations.

LeSS guides span elements of Adoption, Customer Value, Management, Scrum Masters, Product, Product Owner, Product Backlog, definition of Done, Product Backlog Refinement, Sprint Planning, Coordination and Integration, and Review and Retrospective. As of this writing, Larman and Vodde offer 103 LeSS guides.

Understanding experimentation

We've already discussed the importance of experimentation in the preceding guides section. The main point to be made is that experimentation is very situational and that some experiments may not be worth trying. In other words, one or more of the development teams may have used a specific development technique or procedure successfully in previous Sprints, but that does not at all guarantee they will be useful in future Sprints.

Similarly, some of the LeSS guides may be useful in certain situations while others may find a useful application across the entire development lifecycle of a product. Both Ken Schwaber and Jeff Sutherland make the point in their Scrum Guide that learning Scrum is easy but mastering Scrum is very hard. Larman and Vodde make the same statement about LeSS. So, let's revisit how mastery is achieved.

Revisiting Shu-Ha-Ri

As noted in previous chapters, many Agile advocates ascribe to the Japanese martial arts principles of Shu-Ha-Ri. Alistair Cockburn is credited by Martin Fowler as being the first to apply this learning and mastering analogy to software development. Larman and Vodde similarly promote this model of learning and define the Japanese expression of Shu-Ha-Ri to mean the following:

• Shu: Follow the rules to learn the basics.
• Ha: Break the rules to understand the context.
• Ri: Master and find your own way.

So, in other words, you first learn, then experiment, and finally, with practice, evolve to a higher level of understanding in your use of the underlying principles. Mastery only comes with time and practice. With this understanding, let's get into the details of how to go about implementing LeSS.