More with LeSS
The More with LeSS principle is at the heart of LeSS. It’s the realization that the disadvantages of the complex organizational solutions that are used for complex product development are often worse than the problem they try to solve. Complex product development doesn’t require complex solutions. It requires a deep understanding of the essence of the problems, which can then be solved with simpler solutions.
LeSS can be viewed as a scaling framework for product development, but can also be viewed as a descaling framework for organizations. It attempts to remove organizational complexity by solving problems in product development in a different and simpler way. Note that simpler doesn’t mean easier, especially in the short run. Even though LeSS is simple, it is exceptionally hard to adopt well in organizations.
LeSS attempts to define the barely sufficient needed for large-scale development. It avoids adding additional roles, artifacts, or processes, as it realizes the drawbacks of these additions.
A role is a set of responsibilities or tasks assigned to an individual. Most often, these are not newly-invented responsibilities or tasks. Thus defining a new role means these responsibilities are removed from somewhere else. In product development, most commonly they are removed from the teams.
More roles lead to less responsible teams.
A process is a description of how work needs to happen. It is a way of sharing knowledge. But! … it also leads people to stop thinking. The interpretation of installing a process is that there is no further need to think about how to do the work, as that thinking has been done by the people who defined the process. It’s following over changing (and learning), and it’s renting over owning knowledge. . So defining many processes takes away the ownership of how to do the work from the teams. And teams without ownership will not improve.
More installed processes leads to less ownership in the teams and no continuous improvement.
An artifact is information or knowledge that is formalized and recorded. In traditional product development, a lot of artifacts are produced as a method for communication. Most of these are keeping the teams away from the actual customer or user, as they believe or have been told that they can refer to the artifact instead. This might seem good, but in practice the artifacts remove the customer understanding and purpose from product development for the teams, and prevent empathy.
More artifacts leads to less customer-centric teams.
Keeping More with LeSS in mind allows us to think differently about product development.
Instead of asking “How can we do X in an agile way?” where X is a current practice or organizational structure, we first first ask the question “Why did we do X anyways?” to see if we can find a better solution to the original problem. For example, “How do you do program management in an agile way?” is a traditional scaling question, whereas, when keeping the More with LeSS principle in mind, we ask, “Why do we have program management in the first place?” That leads us to the realization that programs (large projects) are a way of organizing work, which can be organized differently. For example, with more of a product focus, working towards continuous delivery, and with adaptive planning, that all leads to being able to manage product development without programs.
The same way of thinking applies to other organizational complexities, gradually making organizations simpler.
References: