![\"How_to_achieve_more_with_LeSS\"](\"http:\/\/leanmagazine.net\/wordpress\/wp-content\/uploads\/How_to_achieve_more_with_LeSS-1024x536.jpg\")
<\/p>\n<\/p>\n
\u201dLarge- Scale Scrum\u00a0(LeSS)<\/strong> is a framework for scaled agile and scaling Scrum.\u201d<\/em><\/p>\n \u201cWe never wanted to create a framework,\u201d says Bas Vodde. \u201cThat might sound strange, but Craig and I like working with organizations and teams on practical problems. We both believe in empiricism or empirical process control, where teams own their own ways of working, experiment, learn and improve. So the idea of a process or even a framework always felt counter to what we wanted to do: focus on experiments that worked within a certain context.\u201d<\/span><\/p>\n Accordingly, LeSS was not developed but it evolved. As a matter of fact, it was only in 2014 that the partners Bas Vodde and Craig Larman started to use the name LeSS and created the LeSS Framework rules. Before that, LeSS was rather a collection of experiences documented in experiments\u2014stuff they had tried while working with lots of large-scale product development groups. In this context, they learned to focus on increasing transparency, reducing organizational overhead and increasing the ownership and meaning of the work of the teams.<\/span><\/p>\n Large parts of these conclusions can be found in the books <\/span>Scaling Lean & Product Development<\/span><\/i> (2008) and <\/span>Practices for Scaling Lean & Agile Development<\/span><\/i> (2010). But after listening to the feedback on their books Vodde and Larman realized that they also needed to address readers who were new to agile and scaling, and who requested clear starting points. In the process of writing this forthcoming book \u2013 <\/span>Large-Scale Scrum: More with LeSS<\/span><\/i> \u2013 they have had to resolve the conflict between providing more rules\/prescription and leaving the ownership fully to the teams, so they could experiment, learn and improve within their own context; they described this conflict as \u201d<\/span>the process owning the process<\/span><\/i> or <\/span>the team owning their own process<\/span><\/i>\u201d. <\/span><\/p>\n \u201cWhen you provide a lot of processes and guidelines to teams, then they will follow them without understanding the original purposes, without thinking and then they become useless\u2026 or even harmful,\u201d says Bas Vodde. \u201dSo, suddenly we realized that Scrum resolved this conflict by providing a small amount of Scrum rules. When you explore these rules and think about them, you realize most of them focus on creating feedback and providing transparency. This enables teams to take more ownership. Our conflict was resolved!\u201d<\/span><\/p>\n And so the LeSS rules were created \u2013 three pages of them \u2013 which increase transparency and ownership at scale. <\/span>\u201dThe rules are simple to understand but hard to adopt,\u201d says Bas Vodde. \u201dThey also tend to <\/span>be disruptive to organizations.\u201d<\/span><\/p>\n From a bird\u2019s-eye view, LeSS consists of four parts: 1) Principles<\/strong>, 2) Rules<\/strong>, 3) Guides<\/strong>, and 4) Experiments<\/strong>. The experiments were there first, as the mindset of experimenting, inspecting-adapting and continuous improvement is the very essence of LeSS. The rules describe two frameworks: basic LeSS (2-8 teams) and LeSS Huge (8+ teams). The guides explain how to implement the rules within different types of organization.<\/span><\/p>\n The 10 Principles are listed as the first part of LeSS, but actually came about last. These now consist of three types of principles. The first type are Scrum-based principles, such as \u201cTransparency\u201d, \u201cEmpirical process control\u201d or \u201cLeSS is Scrum\u201d. The second type are not exactly principles but more bodies of knowledge, such as lean thinking and systems thinking. The last type are LeSS-specific principles, such as \u201cCustomer-centric\u201d, \u201cWhole product focus\u201d and \u201cMore with LeSS\u201d.<\/span><\/p>\n Multiple Scrum teams vs Multi-team Scrum Tailoring Down vs Scaling Up Why is tailoring down harmful? Well, most of the tailoring down decisions are made at the beginning of a project. At this moment, the amount of in-depth knowledge of the product, market, or methodology is very low and people are likely to make the safe decisions to keep more roles, processes, and artifacts than they need.<\/span><\/p>\n More or less \u2018agile\u2019 Grounded in years of scaling experience \u201cThe basic LeSS rules explain how to apply Scrum to multiple teams by clarifying how the roles, events and artifacts scale,\u201d says Bas Vodde. \u201cLeSS \u2013 unlike Scrum \u2013 also has rules for organizational structure. Craig and I have seen over and over again that if the organizational structure isn\u2019t affected then the Scrum\/LeSS adoption will be shallow or even fail. So, we\u2019ve added several structural rules such as dedicated, co-located teams, majority of feature teams and full-time ScrumMasters.\u201d<\/span><\/p>\n As Bas Vodde sees it, the strength of LeSS is that it takes a minimalistic approach to being a scaling framework. It doesn\u2019t to add any unnecessary complexity and instead is as small, flexible, agile, and lean as possible. <\/span><\/p>\n \u201cWe often say that \u2018LeSS is for scaling development and descaling the organization\u2019. This seems like a contradiction, but isn\u2019t. LeSS dramatically increases team\u2019s responsibility leading to less traditional roles, processes and artifacts. This leads to simpler organizational structures.\u201d<\/span><\/p>\n The beauty of this organizational descaling is that it leads to less complexity with fewer roles, fewer artifacts, and fewer processes. <\/span><\/p>\n \u201cThis results in more responsibility to the teams, more thoughtful and meaningful work, more ownership, passion, and improvement,\u201d says Bas Vodde. \u201cMore outcomes. Hence, this principle is named: More with LeSS!\u201d<\/p>\n Two LeSS books are currently available: Scaling Lean and Agile Development<\/em> <\/strong>and Practices for Scaling Lean and Agile Development<\/strong>\u00a0<\/em>\u2014 both by Bas Vodde & Craig Larman. Their third book, Large-Scale Scrum: More with LeSS<\/em><\/strong>, will be published next year.<\/span><\/p>\n On the web, the LeSS meeting point is <\/span>http:\/\/less.works<\/span><\/a> where two certified training programs are currently available: Certified LeSS Practitioner<\/em><\/strong> and Certified LeSS for Executives<\/strong><\/em>.<\/span><\/p>\nWIKIPEDIA<\/span><\/i><\/h3>\n
First there was experimentation, empiricism and experience. Then there was structure, standards and system tuning. The LeSS Framework grew from the fertile soil of case stories from scaling gurus Bas Vodde and Craig Larman.<\/em><\/strong><\/h4>\n
![\"Bas](\"http:\/\/leanmagazine.net\/wordpress\/wp-content\/uploads\/Foto-Bas-Vodde-200x300.jpg\")
\nBas Vodde on the difference between LeSS and other frameworks <\/strong><\/h4>\n
\n<\/b>Most scaling frameworks take a multiple Scrum Teams approach to scaling. The key question they ask is: \u201cHow can we get multiple agile (scrum) teams to work together\u201d. LeSS, instead, takes a multi-team Scrum approach. The scaling question that LeSS asks is: \u201cHow can we apply Scrum when we have multiple teams?\u201d This leads to completely different decisions about how you scale up.<\/span><\/p>\n
\n<\/b>There is an important distinction between tailoring down and scaling up. The traditional safe approach towards processes is to provide too many processes and then ask people to remove what they don\u2019t need \u2013 they tailor it down to their process. The agile approach, on the other hand, is to scale up and provide the minimum amount of process and ask people to add to that <\/span>only<\/span><\/i> when they must. <\/span><\/p>\n
\n<\/b>LeSS avoids weakening the Agile values and principles while scaling up, dealing with more complexity and traditional organizations. We still want shippable product increments every iteration. We still want to be able to change direction at any time. We still want face-to-face communication and close cooperation with customers. We still want empowered self-organizing teams and emerging architecture and design. Some scaling frameworks relax the agile values and principles while others don\u2019t. LeSS doesn\u2019t.<\/p>\n
\n<\/b>LeSS has been around for a long time. The rules, guides and name are new, but they are based on over a decade of experimenting with large-scale agile development in many different kinds of companies building a large variety of products.<\/div><\/span><\/p>\nRead more<\/i><\/b><\/h4>\n
Read the article in Lean Magazine on Issuu<\/h2>\n