Imagine you have 3 agile teams working with Scrum and now you want to scale. Scrum is not enough anymore. Well, what's the next step? Various frameworks can be applied for this, including SAFe SAFe, Nexus, and many more. Today, we'll take a closer look at LeSS.
LeSS is SCRUM (definition)
The Scaled Agile Framework LeSS framework attempts to apply the principles and ideals of Scrum in a large enterprise context as simply as possible through defined rules and guidelines. Due to its simplicity, LeSS has received the definition or label of a "barely adequate" framework - but that is not to cast it in a negative light.
7 Advantages of the LeSS Framework
The fundamental focus of LeSS is not to create a new framework, but instead, apply Scrum principles to many teams.
Some of the benefits that can be achieved with LeSS are:
- Lower implementation costs by implementing practices that teams are already using in Scrum.
- A product ownerwho understands the framework and principles and then bridges the gap between the business and technical teams
- Fewer people to deliver a product . LeSS does not add exponentially more roles and overhead.
- It provides a complete product view in the focus area
- The teams are in direct contact with the customer and other stakeholders
- Continuous improvement is enabled through regular retros and other meetings, which are fundamental processes of the Agile Manifesto
- For many organizations, the LeSS approach to scaling Scrum teams may be the next logical step in their journey to Agile scale..
Before we go any deeper, a quick note. We recently had 11 international senior agile practitioners as guests in one of our webinars, asking one question: How do you scale agile methods the right way?
The result of this is the following fantastic video recording that answers some of the key questions when scaling agile, for example:
- Should you start your agile transformation rather bottom-up or top-down?
- How do you align leadership on a common goal and vision?
- How do you choose the right agile framework – and why is that actually not that important?
My recommendation: take a look! The video is rather long, but every single minute is worth it.
How is LeSS structured? A definition
By definition, Large Scale Scrum is built on principles, frameworks, guides and experiments. The figure showsit. Let's explain with an example:
Principles: Team X is developing a cell phone. The principle of acting transparently is important to them. Therefore, on the one hand, they work transparently and make regular dailies. In addition, they want to find out exactly where the materials come from that are important for cell phone production to be able to transparently communicate this to customers later. In other words, transparency through and through.
Framework conditions: At the same time, they are continuously working to create the framework that the SCRUM framework sets as an ideal with the agile values: Openness, Courage, Respect, Focus & Commitment. agile values pretends: openness, courage, respect, focus & commitment.
Guidelines: Guidelines for development are the product vision, the technical requirements for the product, but also the way the team works together.
Experimentation: When uncertainties arise, you are in the experimentation area, which is about testing and trying things out. For example, when we want to develop a new feature or tap into a completely new target group. figure shows)
The 10 LeSS principles
LeSS defines 10 principles. They help - if we stick to our example - to develop a cell phone that most closely matches the customer's values and ideas. Here is the list of the 10 principles at a glance:
- Large-scale Scrum is Scrum: The cell phone can be developed not only by one, but by several teams, so that the customer is satisfied and the development time is reasonable
- Empirical process control: Based on short-term experience, individual functions of the cell phone are continuously adapted and constantly revised
- Transparency: our team X decides to openly share weekly team goals in their internal platform from now on. This helps enormously in understanding what everyone is actually working on.
- More with less: Basically, experiment with new ideas and learn from them before establishing inert rules that add "ballast."
- Whole product focus: Teams have an even greater tendency to sub-optimize their goals than individuals do. Therefore, the biggest challenge for teams is to integrate their work into a product. The "Purpose" of the entire product should therefore be as clear as possible. The teams and individuals are thus empowered to define appropriate sub-goals themselves as needed.
- Customer focus: Only teams that work directly with the customer can maximize the real value of the product. Unfortunately, organizations have a tendency to decouple teams from the customer once they start growing. To counteract this, for example, customers are regularly invited to team meetings to provide feedback.
- Continuous improvement towards perfection: LeSS is a profound change for many organizations. Note that it does not automatically mean improvement. LeSS empowers the organization to start getting better - and from then on you should continuously optimize. LeSS is a process!
- Lean Thinking: Above all, LeSS emphasizes seeing the place of action itself (Gemba), the three-stage learning concept ShuHaR(Shu = imitate, Ha = vary, Ri = define own rules) and respect for people.
- Systems thinking: all actions, changes and improvements should always be thought of systemically or in accordance with the system in order to achieve the goals. Example: If I theoretically offer financial bonuses in one team - what does that mean for other teams (i.e., the rest of the organizational system)?
- Queuing theory: The basic idea is that in the software world we build up a lot of invisible queues (e.g. requirements documents, untested software) and hardly care about the optimal handling of these queues. Did you know, for example, that when you increase the utilization of a resource from 50% to 90%, the waiting time for new tasks does not roughly double, but rather multiplies? So define WIP limits (work-in-progress), avoid multitasking and large work packages.
The LeSS frameworks
LeSS offers two configurations: Basic LeSS for two to eight teams (10 to 50 people) and LeSS Huge for more than eight teams (50 to 6,000 people and more).
Source: Less.works
It is recommended to start with Basic LeSS to experiment, gain experience, and receive feedback before moving directly to LeSS Huge. There are two suggested approaches for implementing LeSS Huge:
- Start with one requirement area at a time within the larger product and focus only on that at first
- Or gradually expand the scope of work of the team, the Definition of Done and the Product Definition
In this way, a company can build team experience with LeSS, expand in one product area, achieve initial success - and get management support before scaling LeSS across the enterprise.
By the way, talking about agile transformation... one quick hint: Do you want to make sure that you are setting the right priorities in your agile transformation ?
Fill out our agile maturity assessment for your agile transformation – it only takes 3 minutes! You will even get a benchmark based on the more than 300 participants we already have. Have fun 🙂
Roles and planning in LeSS
Basic LeSS focuses on the team and the key Scrum roles:
- The Scrum Product Owner, who is responsible for the product vision and direction.
- the Scrum development teams, who are responsible for product creation and delivery
- the scrum master who supports the team in continuous improvement
- the role of the manager and how he or she supports the team in removing obstacles or "impediments" to continuous improvement and autonomy (extension to Scrum)
Huge LeSS complements Basic LeSS with the following roles:
- The Regional Product Owner of LeSS Huge supports Product Owners and is critical to connect business requirements (financials, etc.) with development teams.
- The Area Product Owner specializes in customer-facing tasks and acts as a product owner for product-facing feature teams.
Most Agile Coaches and Scrum Masters run in circles...
...fixing superficial symptoms. Time to use psychology to foster sustainable mindset change.
Meetings in LeSS
The Scaled Agile Framework Product backlog refinement (PBR) meeting
PBR meetings extend sprint planning across focus areas through a series of parallel LeSS sprint executions. The ongoing cadence of these meetings is required in each sprint to understand, discuss, and refine elements and prepare for future sprints. The main activities of PBR meetings are:
- Creation of Epics - i.e. clustering of large topic areas that fit together; in our example, this would be the grouping of sprints from the Design & Usability team.
- Clarifying and answering open questions: everyone should have an equal understanding of the product and the client's and colleagues' ideas
- Estimating the size of the user story, risks, dependencies: Quasi derivation and detailed planning of the individual topics
The Scaled Agile Framework Sprint Review
Equivalent to Scrum: The Sprint Review is a meeting at the end of a Sprint to assess the completed work in relation to the set Sprint goal. This is about the product itself. Progress is made visible and new areas for action are identified. It makes progress transparent with regard to the product and the goal.
The Retrospective
Similar to Scrum: The retrospective is a meeting that deals with the collaboration of the team. Improving how the team works together and therefore around improving processes and content. It is also about the interaction between individual developers, the work of the Scrum Master and the communication with the Product Owner. Thus, the retrospective is an important part of a continuous improvement process (CIP).
In Large Scale Scrum, it is sometimes recommended to conduct a "Retro of Retros" - i.e. superordinate across many teams.
Large Scale Scrum – Scrum Master Ratio
How many teams should one Scrum Master have? One may argue that one team per Scrum Master is best - although there are still some disadvantages disadvantages. Generally, the large scale scrum master ratio is 1:1 till 1:3 - one scrum master has one or a maximum of three teams.
When is Large Scale Scrum LeSS the right Agile method?
Large Scale Scrum can be used if you are already working with SCRUM and want to scale Scrum, but also to find the balance between self-organization and rules.
Bas Vodde once said that he and Craig Larman believe that LeSS is a very good approach because it hits exactly the "sweet spot" between as many specifications as necessary and as few as possible.
Much like Scrum itself, it is just a process framework that can still be highly customized and varied by the teams that use it. This argument seems plausible.
Illustration: Sweet spot
In comparison: Large Scale Scrum versus Scrum
LeSS builds on Scrum to support its use in a larger context and to scale it across larger organizations and beyond the one team. So an either or question does not arise. LeSS is the extension of SCRUM. Thus, to implement LeSS, you always need SCRUM. It makes sense to introduce SCRUM first and then switch to LeSS.
In comparison: Large Scale Scrum versus Scaled Agile Framework SAFe®
Although LeSS is becoming more popular in organizations with large software development teams, other scaled agile frameworks such as Scrum of Scrums or Scrum @ Scale have also gained traction. One of the leading frameworks is the Scaled Agile Framework® (SAFe).
There are many similarities between Large Scale Scrum and the Scaled Agile Framework SAFe®. For example, both start with scaling a Scrum team and incorporating principles such as lean thinking, continuous improvement, and customer focus.
3 Core differences between Large Scale Scrum and Scaled Agile Framework SAFe®.
- Organization: LeSS focuses on simplifying the organizational structure by remaining flexible and adaptable.
- Roll: SAFe has additional roles (some say more “overhead” because of this), including Release Train Engineer (RTE), Solution Train Engineer (STE), and Epic Owners.
- Implementation: the Scaled Agile Framework SAFe® includes processes, artifacts, and organizational changes that some organizations may not be able to adopt. So you always need to look at which framework fits you and your organization.
For a successful implementation of Large Scale Scrum...
Successful adoption of Large Scale Scrum requires breaking with time-honored assumptions and changing the corporate structure - with all the explosive "boss-level" potential and "loss of face" that comes with making the appropriate change.
The precondition is therefore that everyone is ready for this change - see also the Change management model according to Kotter or our article (based on existing agile frameworks) on what makes a good agile transformation roadmap,.
Create an attractive vision to work towards - and start many change projects at once, in the spirit of experimentation.
When the initial goal is achieved, the change is done and the organization adjusts to a new status quo until the next change is imminent.
This classic approach is similar to the sequential and "big-batch" approach to software development (Illustration), where change is an exception that is tightly managed by many change control bodies.
In LeSS adoptions, there is no change initiative, so there are no change managers. In LeSS, change is continuous through experimentation and improvement - change is the status quo.
What are the steps for a successful implementation?
1. Shift, adapt or change the team culture
We recommend starting with a Scrum team first, until the team and the organization have gained enough experience about the new agile culture and the responsible decision makers initiate the next step. This also reduces the risk of a misguided development.
2. Improving collaboration within teams
Scaled work by multiple teams on a product requires the adoption of agile practices. Practices that make it easier for teams to coordinate with each other are especially important. The early teams still have a lot of experimentation to do as trailblazers for the rest of the organization.
Once the teams are truly decoupled from the rest of the organization, they can correspondingly make rapid progress in doing so. This can be done quicker and with less risk within a manageable framework.
3. Changes to the corporate structure
Further growth of the agile organization means restructuring across all levels. At this point at the latest, the initiator of the change must involve management. All levels between teams and top management are challenged - and the organizational structure becomes very lean. This is probably the most "painful" part of the process, especially for management.
4. Shift in corporate culture
Applying the Scrum and LeSS frameworks and appropriate agile practices across the enterprise results in an organization-wide learning of the agile culture. The process never stalls because there is no such thing as an optimal agile organization.
An Agile transition with Scrum, LeSS and LeSS Huge requires a far-sighted strategy. It should therefore be accompanied with appropriate consulting and training.
By the way, if you are still looking for a suitable retro board, our article can help you with the topic: Comparing the 6 best retrospective boards
