LeSS – core values and principles

Agile is about stepping back from the documentation and focusing more on teams and the project itself. It’s about fast delivery and hitting the goals as effective and efficient as possible. However, what happens if we are working on a large-scale project where we need

to pass the information, documentation and requests from one internal department to another? We have to interact with the business inside the business, rather than just the development team and the customer. This is where the idea of the LeSS framework came.

LeSS is a simple Agile framework that helps managers and organisation to apply and go agile, having multiple teams working simultaneously on large scale projects. The LeSS framework stands among others due to its flexibility and adaptability to different team size.

According to LeSS official website, this framework can be defined as a “scrum applied to many teams working together on one product.” (The LeSS Company B.V, 2021). Since this framework takes scrum as its basis, it’s better to introduce the scrum concept first. Scrum is another framework developed for project managers to emphasize transparency, adaption and inspection. It simply helps teams work together to achieve the common project goal and to deliver the project successfully. Scrum provides project managers with a set of tools, meetings and roles for teams to structure project and work accordingly. As other frameworks focused on agile mindset, scrum’ main goal is to utilise agile principles by focusing on sustain delivery of projects with different complexity. LeSS’ creators took scrum as a basis and developed a framework that is scaling scrum across multiple teams that are working together on the project. Following other scaled agile frameworks, LeSS’ main priority is also to reduce the complexity and waste of time during the product/project delivery.

Craig and Bas, founders of the LeSS, from 2002 were working on developing the framework that will allow now only small teams to follow scrum and agile mindset in large scale projects (The LeSS Company B.V, 2021). They have developed now only one framework, but actually, two different frameworks that organisations, depending on the team size, can adopt in different project domains – smaller LeSS and LeSS Huge. Smaller LeSS framework according to founders can be used in smaller teams of up to 8 people; then there is a need to transform and apply the second LeSS Huge framework. The logic behind the transition is that the single Product Owner simply cannot guarantee the quality and delivery of the entire product since the product backlog becomes too large to scale and work with. At first, we are going to look into the small LeSS framework principles and summary.

Figure 4

The LeSS Company B.V. (2021). LeSS Framework [Digital image]. Retrieved April 10, 2021, from https://less.works/img/framework/less-framework.png

A smaller LeSS framework is used for teams of up to eight people. This framework is designed for only one product owner who is overseeing the product backlog that his/her team is working on. The crucial aspect of this framework is rooted in the agile mindset – a cross-functional full-stack team that works together in a shared environment to create and finish assigned items. To maintain transparency and ongoing delivery, LeSS implements sprints that have to be attended by all teams participated in the project. The product owner and/or product leader should prepare for the sprint and outline major items to line up on the table during the sprint meeting. They have to assign priorities and dependencies and explain why they believe that it’s the right order. Then each item is divided between the teams and they are working separately and together during the product backlog on them.

The product owner here has to make sure that each team is choosing items not only based on their interests, but also according to their strengths and best abilities. Scrum Master, though, has to make sure that a single team won’t end up having a bunch of high priority items, so the project goes evenly, and the risks are under control. There is always a need to distribute power accordingly. As a result of the first sprint, each team has their priority items to create spring backlogs and track the progress till the next sprint.

Figure 5

The LeSS Company B.V. (2021). LeSS Sprint Planning [Digital image]. Retrieved April 10, 2021, from https://less.works/img/framework/less-framework.png

As can be seen on the Figure 5 above, after the first sprint there is a clear picture of teams and items they are holding. It may occur that multiple teams are holding very related to each other items. In this case, following small LeSS framework, these teams are going to run the second sprint meeting to go over common tasks to uncover the shared work to be done.

Following this session teams are eliminating misunderstanding and overlapping work so as a result on the next sprint no one will come up doing the same thing over the product backlog.

After the sprint planning stage, teams start to work towards developing assigned items. As it was mentioned above, the key here is a shared code environment, which again created transparency and visibility over the progress and helps teams and leaders/managers to keep up with changes. Every day during the project lifecycle teams hold the sprint meetings till the end of the project/deployment. As it can be seen from the flow of small LeSS, this framework/approach is based on the daily iterations and sprint meetings to connect different teams that are working on different items to deploy the final product. Due to Product Backlog Refinement (PBF), there is a possibility to split bigger items into larger

parts and estimate risks and duration for the whole butch based on each part. Multi-team PBR is an original side of the LeSS framework since it requires multiple teams to gather in the same room to run a big workshop to split big items and clarify them in more details so the product owner can create real estimations and evaluate associated risks accordingly.

All these seem to be great and scalable, but it’s hard to imagine how to scale smaller LeSS if you work in a project where you manage, for instance, twenty different teams at once. This is where Craig and Bas came with a framework “LeSS Huge”, that supports the division of the teams around the requirements areas (areas of the major customer’ concern). Example of “requirements areas” can be described as following (The LeSS Company B.V, 2021):

- Imagine your product is a “Trading Platform”.

- Then customer clarifies that his main areas of interest or as we call them in LeSS Huge “requirement areas” are:

o Trade Process.

o Asset Division Process.

o Deploying to new African Market.

o Deploying to new Asian Market.

After defining these requirement areas, we have to add them to the product backlog. For instance, following the example from above, we can create multiple Area Product Backlogs like “deploying to Market A” and “deploying to Market B” and different teams can focus on these backlogs. However, it doesn’t mean that after separation into different areas each area will be held in a separate sprint window. Quite opposite, in the LeSS Huge we have one produce-level sprint to help to maintain continuous integration and development. Since we have a new component, requirement areas, then a new role is introduced – Area Product Owner. If we recall agile, it’s like a team leader that is assigned and focuses on its Area Product Backlog. And since we have different areas, it’s only logical if we will have different Area Feature Teams that will be assigned to one Requirement Area. Following the introduced example earlier, the team in LeSS Huge could be summarised as follows:

- Product Owner.

- Product Owner Team:

o Four Area Product Owners.

- Four feature teams in area A.

- Four feature teams in area B.

- Six feature teams in are C.

Figure 6

The LeSS Company B.V. (2021). LeSS Huge Framework [Digital image]. Retrieved April 10, 2021, from https://less.works/img/less-huge/less-huge-framework.png

All other processes are the same as in the smaller LeSS framework. Both frameworks are sharing the same process for one product backlog, same statuses (done, ready, pending), one product owner, one sprint. However, due to the new Requirement Area in Less Huge, there is a need for new roles as described above, such as area product owners, area feature teams. And this brings area product backlogs, which creates a need for parallel meetings attached to the Area to ensure continuous team integration and project delivery. To finish the LeSS overview, it’s good to mention the main principles this framework is based on (The LeSS Company B.V., 2021):

1. Large-Scale Scrum – LeSS is not redesigning the Scrum, it simply applies the principles of scrum in the context of large-scale organisation.

2. Empirical process control – to create transparency and share the control over the processes, product and design, the LeSS stands for the situational approach of adopting the Scrum rather than following a book-stand approach.

3. Transparency – LeSS stands for short development interactions that help to focus on the timeline and “done’ items bringing teams together to work on the common goals.

4. More with less – LeSS stands for learning without diving deep into the process definition; wasting fewer resources by lean thinking; sharing ownership with less division by roles or/and artefacts.

5. Whole-product focus – LeSS main requirement is to have one product backlog, one product owner, one sprint and one product increment – following this framework we are focusing on delivering the whole product rather than parts of it.

6. Customer-centric – customer’s feedback and interaction both play a huge role in the LeSS framework.

7. Continuous improvement towards perfection – sprint meetings and continuous improvement to product/project create higher perfection in terms of delivering customer-centric product.

8. System thinking – LeSS stands for overseeing and optimising the whole system rather than parts of it. Here it’s again more about putting “doers” in the “customer’s shoes” – they pay for the result, not for the steps that brought the result.

9. Lean thinking – supports managers in “leading and teaching” rather than

“controlling and dividing”. Everyone respects each other.

10. Queuing theory – prioritising the right item at the right time and putting the right team for efficient and effective delivery.

Keeping in mind the main principles LeSS stands for, and comparing it to earlier described SAFe, we can see that both of them share the same principles of continuous improvement, development in small iterations, sharing risks and responsibility among the team, and customer-centric process of delivery of a solution. LeSS, in comparison with SAFe, though, simplifies the roles what makes it a less complex framework to apply. I would say that in terms of preparation and learning needed for successful adoption of the framework, LeSS Huge or LeSS Small are both winning over the SAFe, which definitely requires courses and training before adoption.

1.3.1 LeSS – outlined benefits and drawbacks

According to the subchapter above, we can say that the fundamental focus of the LeSS framework is to apply principles it stands for to multiple teams that are going to work together with a common goal of delivering a complete customer-centric solution. In the following paragraph, I am going to outline the benefits of LeSS as a framework by own and compared it to previously discussed frameworks.

Due to simplified ownership and having only one product owner there is a higher understanding of the framework and principles what then helps to shorten the gap between IT and the business world. Following the same principles of having fewer roles than for instance in SAFe, LeSS brings the opportunity to deliver the product having more scattered resources and overhead costs. We have also discussed that in larger organisations we can

apply LeSS Huge that introduces the new term “Requirement Area”. With help of areas, the product owner can have a bird-view over the entire product (and in case it’s a big product, then this view even enlarges to the area of focus dashboard). LeSS is also stepping back from the “old-school” model where only project owners and stakeholders talk with customers. In the LeSS framework teams have the power to be in direct contact with both the customer and the stakeholder. This helps to shorten the gap and misunderstanding in requirements and speed up the delivery. Due to focusing on the product itself rather than the project or team, LeSS is known for higher-performing product deliveries and customer satisfaction. Applying LeSS is also known to be a “comfortable way of going agile”, due to its Scrum roots. Companies, in general, do not have to invest in onboarding as much as in applying SAFe. Overall, as it can be seen from the above, LeSS is a comfortable and easier way to go agile if you have multiple teams and a higher organisation structure. It values the identical agile and scrum principles as major scaled agile frameworks, thus the benefits of applying are quite common among them all.

However, even in a more straightforward approach, there might be a drawback to consider.

LeSS is based on Scrum principles and approaches, thus, in case your team is not familiar with Scrum methodology, it will be a tough task to implement this framework. In this case, the benefit of less training and prerequisites won’t apply, since the organisation will have to invest in Scrum onboarding first to unlock the full potential of LeSS. Another benefit that was discussed above is having a one, and only one, product owner, which could be seen as a drawback. One can find it hard to manage multiple cross-functional teams and coping with a great number of sprints and updates. Especially, if we are talking about the corporate environment, where the hierarchy is strictly opposite - one cannot have that amount of responsibility since it becomes too hazardous.

The bottom line is that LeSS will be a suitable framework to choose in the organisation where Scrum is a familiar word. So, I see LeSS rather as the second step to take when teams enlarge, and they need to scale their scrum practices further. Following LeSS companies will achieve balance between “paperwork” that needs to be done due to legislative perspective;

and agile mindset delivery that frames the scaled agile frameworks such as LeSS. This is why we do not have many new roles as in SAFe, we rather focus on adopting well-known scrum approaches to a larger team(s).