LeSS
Infobip‘s engineering department has always been organized around agile methodologies. We are strong believers in iterative development, feedback loops, and small increments that brings value to customers. However, we realized that we need business agility on a company level, the possibility to change the direction of the whole company. The problem with how we were using Scrum / Kanban was the fact that teams were working only on their own projects and their backlogs.
Why LeSS?
Significant growth in our engineering department in the past few years has pushed us into adopting a new organizational setup. Usually, IT companies try to build their organizational setup around Scrum, with single team backlogs and one product owner per team. This isn't sustainable when you reach 800+ engineers grouped in 100+ teams with ~70 product managers. Prior to LeSS, our teams were grouped in divisions, based on technology stack/layer.
If a product was important for the company, only one development team could contribute directly to this product. Unfortunately, other teams could offer limited help.
Challenges we had at Infobip‘s scale:
We were getting slower as we scale
Initiatives that required a lot of teams to collaborate took a longer and longer time to finish
A lot of synchronization between teams needed
Multiple backlogs, multiple product managers, unsynchronized sprints
Prioritization happens on a single team's backlog (local optimization)
Component teams – hard to prioritize and contribute cross-team
A lot of responsibilities for TLs (tech+org+people)
If we wanted a new feature that needed to be implemented on multiple microservices, then we needed to use multiple teams and do a lot of communication and orchestration between teams. In the end, it was harder to achieve company goals because they need a lot of reprioritization and orchestration. We realized that we needed to change something in our process.
Enter LeSS
After analysis and investigation of different Agile Scaling frameworks, we realized that we need an agile framework such as LeSS. The LeSS framework was based on Scrum which was a good fit for us, it had one backlog per product (not per team!) and a lot less procedural overhead compared to other frameworks.
We decided to adopt LeSS as our new organizational setup, along with some additional changes like a new job architecture which removed the team lead role.
LeSS is Scrum scaled
LeSS is an agile framework based around long-lasting feature teams working together on product backlogs. The product backlog contains tasks / epics for one company product and all development teams who work together on this product belong to one Requirement Area. Yes, Requirement Area is a set of development teams working on one product backlog. Development teams should be self-managed and ideally co-located. So, you may ask, How did our organization change to better fit LeSS?
Development teams are focused on the product backlog instead of team backlog;
The Team backlog still exists, but all tasks on it should make a reference to product backlog items;
The Product backlog usually contains epics, larger important initiatives, while the team backlog contains development tasks;
The Product backlog enables us to focus on the most important initiatives from a product perspective, not from the team's perspective.
Adopting LeSS means that teams will be focused on product priorities instead of their own team priorities. It also means that development teams will need to have knowledge about the whole product because teams do not work on a single component (ex. Microservice), instead they tend to share work on the component between multiple teams having in mind the whole product. This organization agility enables business agility because we can put most engineers (teams) on the most important product features.
Additionally, LeSS is a huge driver of the learning process. Since each team is self-managed, responsibility of team organization, communication, and development is on each individual. Development teams are not component teams, they are product feature teams. It means that each team needs to learn the whole product domain and technologies used on a product.
Does it mean that I will need to know everything about a product?
Of course not. Like T-shape developers, we are looking for T-shape teams and individuals. That means that each team will be specialized in some product area (ex. Billing, reporting, routing..) and will be responsible for those components in the production environment (component guardians), but also teams and individuals need to understand the whole product and tech stack up to the point that they can contribute to it.
LeSS day-to-day
Since LeSS is in its essence Scrum scaled, you can expect the same rules and the same ceremonies, but with some additional events.
Each engineer works in a team, there is no difference compared to Scrum teams.
Development teams are long-lasting teams focused on features and not (only) on components;
We don’t have a dedicated team leader, instead we practice self-managed teams.
We have a role of Engineering manager who is there to help everything regarding the organization, product development and, of course, your personal growth.
Just like Scrum, we have sprints, planning and reviews, but there is a difference.
We have two separate planning events and reviews.
Overall planning is done at the product level where we talk about product backlog and important product initiatives. Each team sends one team representative to this overall planning, alongside Engineering Managers and Product Managers. After overall planning is done, and we know the focus for the next sprint, we have team sprint planning with team backlogs. Team planning and backlog priorities have to be in line with product planning and product priorities. This is how we avoid local optimization, teams should focus on the bigger picture, on the product backlog.
Reviews are done in a similar manner - First, we make team reviews, and then team representatives are a part of the product review. We also do Product Backlog Refinement meetings where we discuss new items, where the specification is not clear enough. So for engineers, LeSS looks like a Scrum with few additional sprint events.
Grouping teams in Requirement Areas
One of the main features of LeSS is grouping the teams in Requirement Areas, which is done based on the business/product perspective. For example, we have grouped all teams related to billing in a single Billing RA, so the changes to our billing can now be done within the single organizational unit which reduces handover and synchronization:
The whole RA shares one backlog and has one product manage
Teams in RA have synchronized sprints together, with two levels of planning - one level on the RA level, and then team members take their tasks in additional team planning
The teams should ideally be feature teams, which means that they consist of people who can deliver complete feature even if it spreads through multiple components, as opposed to component teams.
Based on that, here‘s how our structure looks now:
Business and Requirement areas
One backlog per RA
Product manager on RA level
Engineering manager leading RA as line manager of all members
Feature teams - easier prioritization and end-to-end feature ownership
Self-managed teams (no TLs)
Last updated
