Be More Agile with LeSS, Part 2: What is LeSS?

A series on how LeSS can help you lessen work problems and boost your team productivity.

In this multi-part blog series, I will share useful lessons learned from the Large-Scale Scrum book and the four-days Certified LeSS Practitioner training.

• Part 1: Why Agile?
• Part 2: What is LeSS? (this post)
• Part 3: Why LeSS? Why Not Others?
• Part 4: Agility Requires ‘Respect for People’
• Part 5 (final): Lean Thinking

In the part 1, we’ve discussed what Agile is and why it’s quite revolutionary. It’s also noted that LeSS (one of the popular agile approaches) will act as the triggers to instill better habits; habits which will hopefully lessen your work-related frustrations.

You might have brilliantly asked, “Okay, I agree that agile is better than waterfall, but why LeSS? Why not other options?”

In order to get the ‘why’, we need to understand the ‘what’ first. This post will let us see the whole surface of LeSS by understanding the dynamics of its roles.

Roles and its dynamic is only a part of framework (the yellow circle). The framework is only a part of LeSS.

But, before we take a look on its surface, let’s begin with the end in mind…

Three key takeaways from LeSS

Here are the key takeaways you’ll get from LeSS:

1. Always bring real data. Without real data on our hands, how can we inspect and adapt our move properly?
2. A successful product needs strong teams. They’re capable, have a strong bond, and brave enough to talk about their issues. They’re also close with the users.
3. A successful product also needs strong product leaders. They direct the product and deal with the stakeholders.

Now, let us flesh out those three points with LeSS’s contexts.

What is LeSS?

LeSS was first experimented with by Craig Larman & Bas Vodde in 2005. So it’s one of the oldest scaled Agile frameworks for multi-team collaboration. It has four roles, each with distinct-yet-connected responsibilities.

Teams

The closest role to users is the teams. Teams are the main value generator. By shaping the product, they maximize its value in the eye of the customers, thus, bringing in more money to the organization. To be successful, they need to be competent enough to bend the product up to their will and also interact directly with the users.

Each team has the complete capability to understand users and bend every element of the product (functionality, visual design, copywriting, etc.), so that they can maximize users’ satisfaction. This, however, is the aspiring ideal state. Not mandatory since the start.

It’s not acceptable for the team members to work in a silo (not discussing and collaborating on the work). Organization sees one team as one unit that has the complete capability to successfully solve a user’s problem by modifying the product. One can not fail as an individual, only as a team.

Delivery estimation comes only from the one who designs, builds, and delivers the solution: the team. And, unlike in the waterfall approach, agile sees estimation as a moving target. Throughout time, as the design becomes clearer and technical issues emerge, stakeholders need to keep updated with the newest estimation. This will create a culture of zero tolerance for a late surprise. The stakeholders, however, are expected to keep treating an estimation as an estimation, not a deadline or commitment.

With the continuous estimation update from the teams, stakeholders have an accurately sourced reference point. Obviously, it’ll be useful in navigating business decisions, pivoting the roadmap, and managing commitments with external parties. Less risk of sudden mass resignation, since there’s no more upfront deadline decision and inhumanely rallying the employees to deliver.

But as a multi-team endeavor, how can the teams align themselves? How to reduce redundancy (two teams unknowingly working on the same thing)? Will they have a civil war to decide what features to build?

Of course not. Luckily in LeSS, we have one — and only one — Product Owner (PO).

Product Owner

PO prioritizes what problem the teams need to solve now. This prioritization is manifested in a form of a queue called Product Backlog. As all teams will first focus on the problems sitting at the top of Product Backlog, and there’s only one Product Backlog acting as a single source of truth, alignment will come naturally.

Where’s the source of user problems to be put in the Product Backlog? There are several:

1. Teams
   As someone who builds the product, and even more, interacts directly with the customers, a team member might have a bunch of product-related ideas. Thus, the PO needs to routinely spend time talking with the teams.
2. Themselves
   The PO could also investigate a user problem, triggered solely by their own curiosity.
3. Stakeholder
   As someone who’ll be heavily impacted by the success (or failure) of the product, any stakeholder could lobby PO to focus on a certain user problem or feature they perceived as the most urgent one.
4. The PO Team
   For a huge product — like Jago Bank — LeSS introduced the role of Area Product Owner (APO). PO and their APOs form a “PO team.” As someone who helps the PO in a specialized user-centric area of the product, an APO could provide any insights or propose a user problem to focus on.

However, it’s important to note that PO is not a Project Manager:

• PO will not break down the work into tasks,
• PO will not assign tasks to the team members, and
• PO will not monitor the task-level progression.

PO’s job — to maximize the value of the teams’ output by prioritizing what problems the teams should solve first — is already hard. As professionals, they couldn’t prioritize based solely on intuition. And providing empirical data to back up our decision takes a lot of time and energy, not to mention dealing with a lot of pressure from various stakeholders and external parties. Saying ‘no’ is not an easy task.

If the PO only manages teams’ focus, who’ll manage the teams? The team themselves. They are self-managed.

Then, who’ll coach the teams to manage themselves? Who’ll drive the journey of LeSS adoption while maintaining a healthy communication flow between PO, stakeholders, and the teams? Who’ll help them see the whole?

Well, that sounds like a job for the Scrum Master (or Agile Coach)!

Scrum Master

A little bit of context first: LeSS is heavily influenced by Scrum (another agile framework), where the creators designed it as the multi-team version of Scrum. Even though LeSS is not Scrum and even disagrees with some parts of the Scrum Guide, it still maintains the role of Scrum Master (SM). However, DKatalis prefers to give a new name to Scrum Master: Agile Coach. The reason is to frame the focus beyond the framework (Scrum/LeSS). So, from now on, this post will refer to this role as Agile Coach, even though the illustration from the LeSS book is still calling it ‘Scrum Master’.

Agile Coach is neither the team’s admin nor cheerleader. An Agile Coach is someone who focuses on organizational and team culture. To do their job properly, they must be brave and humble enough to speak with high-level stakeholders (such as the CEO). The LeSS website has summed it up nicely:

Scrum Masters (Agile Coaches) are guardians of transparency. But most large-scale product development has a persistent haze hovering over it. Clearing the haze, that is, creating transparency, is a hard and thankless job in an organization’s political jungle.

Having organizational & team culture as their focus, it’s not mandatory for an Agile Coach to master the hard skill of product development. This leaves room for the next LeSS role: the Managers.

Managers

If the teams are self-managed, do they still need a manager? Well, yes and no. The teams don’t need anyone to break down the work and assign/monitor the task. But, they still need a capability builder.

People used to map engineering managers to LeSS’s role of Managers. It might be the case, but it’s not limited to them. As we already know, every team should have the complete capability to design, build, and deliver a solution (end-to-end/consumer-centric). Thus, any expert in a part of those processes could fill the role of Managers, such as designer manager, user research manager, or copywriting manager.

But, not only technical expertise, the ability to teach is also the key. Being a smart expert is not enough if you can’t help the members of the teams successfully improve their capability. Managers are not the doers, they are the doers’ capability builders.

This graphic below illustrates the interesting dynamic between managers, teams, and users. It shows how important the role of Managers is to the success of the organization, as rising teams’ capability will directly increase the value consumed by the users.

And this one shows the focus of those four roles.

Now, let’s briefly touch on the events in LeSS, so that we can visualize the dynamic of its role more.

A Brief Explanation of LeSS’s Events

You can see this from the graphic above: as the product is quite huge, the PO needs three APOs to help. Each top priority item in the Product Backlog is represented in the corresponding Area Backlog.

Then, at the start of every sprint (the sprint length is mostly two weeks in DKatalis), the teams from each requirement area are taking the most important items from the Area Backlog. The amount is up to the team — as they’re the ones who estimate. Sometimes one team can deliver the items taken. Sometimes they need to collaborate with other team(s), which could be from the same area, or cross area requirements.

In the middle of the sprint, the teams meet APO in the event called Product Backlog Refinement. Stakeholders, customers, or subject matter experts could also be invited. The goal is to go over the upcoming items that may be taken in the following sprints in greater detail.

At the end of the sprint, the teams from each requirement area will conduct a Sprint Review with each APO, and possibly, stakeholders or customers. They will inspect the result of the team’s work, discuss the recent value of the product, and maybe, decide the new direction of the product (which will be reflected on the Product Backlog & Area Backlog). This event is crucial to increase teams’ sense of ownership and to teach them to interact directly with the users.

Immediately after the Sprint Review, each team will conduct a Sprint Retrospective session. There, they’ll raise up any issue related to how they work, revise working agreements, and agree on improvement action(s). They will also take notes on any unsolvable issue related to the APO, PO, another team, or another area requirement. Following the team retrospective, there will be the area level retrospective (Overall Retrospective) where they can discuss the things they couldn’t solve in the team retrospective. Without retrospectives, teams couldn’t improve. If the team are not improving, the product won’t.

At last, the sprint is concluded and immediately continued by the next one.

The updated three key takeaways from LeSS

Let’s revisit the three key takeaways I’ve spilt in the beginning, and add them with the contexts from LeSS:

1. Empirical process control. Without product usage data in sprint review, the product can not adapt to reality. Without the team(s) being open in retrospective, the team can not adapt to reality. Always bring real data.
2. Team, team, & team. A successful product needs strong teams. They’re capable, have a strong bond, & brave enough to talk about their issues. The closer the teams are to the users, the better product direction PO could give — simply because the PO has more time & energy.
3. The PO team. A successful product also needs a strong PO team. They direct the product. They also deal with the stakeholders.

Now that we’ve understood the basics of LeSS, I finally can elaborate on my opinion on why LeSS is a better fit framework for DKatalis, compared to other alternatives. We’ll explore more in the next post.

If you’re a Katalis and interested in Agile but not working close to product development, LeSS might be too much for you. But don’t worry, feel free to contact Shirley Rompis, Rizki Yogaswara, or Ricky Saif to discuss several other options. Your work might be even closer to constructing a bridge than coding software, but many tactical practices in Agile approaches might still be beneficial to adopt. You still can increase your agility, even if you work on duplication projects.

Do you enjoy working in an agile environment with effective workflow and less friction? Then, you’re already a Katalis at heart! Join us 🤙