Frameworks like Scrum for a team context and LeSS for a “Team of Teams” context can help us develop better products for the market. But what do we mean by the “market”? And what is the goal of these frameworks? It’s not uncommon for these frameworks to be implemented without really changing anything. Project phases are divided into sprints, teams sit in Scrum Sprint Plannings and Reviews, while the Product Owner goes over the DoD and shares user stories. Customers are rarely seen during a review, and so the question arises: What do Scrum and/or LeSS actually help with? Is it about delivering more in a shorter amount of time—being more efficient? A company’s success towards becoming more agile is usually measured by KPIs: How many teams work according to Scrum, how many Kanban boards exist, and similar metrics. What is still missing, however, is the customer.

Introducing agility only at the team level usually won’t work, because it is only a local optimization. If teams continue being buried under issues that they cannot determine, then local optimization won’t have any real benefit. A company needs to understand what business agility means. It doesn’t mean having twenty Scrum teams. It’s more about bringing the customer products that they really want and need, at the right time, with the right quality.

The three Rs

The right product, the right time, right for the customer—the three Rs are critical for understanding agility’s focus. The right product means: this specific product has an effect on the customer. It satisfies a customer’s needs.

For example: The Christmas season approaches and customers need gifts for children, grandchildren, partners, etc. Gifts should make the recipient happy. A classic Christmas gift is a chocolate Santa Claus. What makes this gift pleasing? It fulfills a need for pleasure, relaxation, and sugar. Chocolate is the right product for this particular need. Is it possible to cut back on the first R? For instance, what if instead of sweet milk chocolate, we give sugar-free chocolate with a 99% cocoa content? Without a doubt, this variant may be healthier. But for the context described, chocolate isn’t bought with the focus of being healthy, but to satisfy a need for something sweet. Sugar-free chocolate wouldn’t be the right product.

Hypothesis: We must not jostle the first R. No one buys a product that isn’t right, or at least, far less in this context. What about the second R: the right time? Chocolate shaped like Santa Claus, nicely wrapped, only makes sense around Christmastime. The chocolate product isn’t affected, so at the second R, the company may decide to roll out the chocolate later in a different form and the chocolate will still fulfil its purpose. For more specific Christmas products, like gingerbread, the timeframe is much more limited and therefore the second R also shouldn’t be compromise.

The third R addresses efficiency: How does the product reach the customer, and in what quality? A company can decide which customer segment it wants to address: the price-conscious, the premium segment, or another group. At this point, there’s still some leeway with the third R. If a company optimizes its processes for efficiency first without finding out if effectiveness is given, then they run the risk of delivering the wrong product ‘right’ to the customer. Top-quality (‘Right’) sugar-free chocolate Santas delivered to the customer after Christmas don’t sell.

Agility focuses on the customer in order to develop products that will have an effect on them. Deliver the right product, at the right time, right for the customer.

Customer-centric in the LeSS framework

LeSS serves this circumstance with its seventh principle: "Customer-centric". The viewpoint of LeSS is that a single (Scrum) team can organize itself around the customer and it will benefit more easily than multiple teams. If a product needs more than one team to deliver to the customer, then it needs a different approach to ensure customer-centricity. It’s important that the Product Owner is one person, so that there is a single point of truth while making decisions about the product. If teams and their members move too far away from the customer, then there’s a risk that they’ll lose sight of the right product—the first R. Every team member needs to understand what the particular product or feature is being developed for (the “why”) and what benefit it provides to customers.

Developing a product across multiple teams can be managed in different ways. Let’s stick with our example of Christmas sweets and expand it a little. Imagine chocolate Santas and various filled pralines together in a gift box. A chocolate Santa Claus usually consists of a hollow chocolate body wrapped in foil with a Christmas print. In the case of pralines, a filling like nougat is added. For this product, teams could be structured accordingly: One team develops the chocolate, another does the filling, and the third works on packaging and printing. This kind of division is called component teams. Their mysterious charm is being very efficient: In the Christmas chocolate team, there are only people who specialize in hollow chocolate forms; they can do it perfectly. At the end of a sprint, the goal is to present a product to the customer. Development and deployment of chocolate Santas is at full speed, and the team is able to deliver them at the end of the sprint. However, the packaging team faced several challenges during the sprint and doesn’t have any packaging to contribute. They also didn’t completely understand exactly what the packaging was for. The customer focus wasn’t pushed to see the end customers—the people buying the Christmas chocolates. Instead, they only thought about the team that needed the packaging. Because of this, the product cannot be delivered, putting the second R at risk.

Component teams (teams streamlined for efficiency) aren’t the best choice for focusing on the first R. One solution from the context of LeSS is using end-to-end feature teams. These are teams that deliver just one feature, a partial product, end-to-end to the customer. In our example, what might this look like?

In our chocolate Santa team, people move to the filling team. From the packaging team, people move to the chocolate Santa team and filling team, which then becomes the praline team. Now, the teams prepare chocolate Santas with packaging and printing, while the praline team creates chocolates, filling, and packaging for the pralines. This way, teams can take end-to-end responsibility for their own features and subproducts and can present them to the customer without being dependent on other teams. Communities of Practice (CoP) can be established and guarantee an exchange of people with the same expertise.

Conclusion

Always having the customer in focus requires an understanding of what happens first and what happens after. You require an understanding of the three Rs and what they mean. You need to realize that it’s important to get the right product to the customer first before you can task yourself with how to do it efficiently. If a product requires more than one team, efficiency is often looked at first. The path that’s often taken is establishing component teams, which can result in none of the teams really understanding what the actual product is and sticking with the above example, can then lead to only packaging or chocolate being delivered. Putting customers at the center of everything you do can be achieved by establishing teams responsible end-to-end for a portion of the product. They need to be able to directly test features with the customer, gather feedback, and bring about improvements. You need to strike a balance between local optimization, which can affect feature teams, and a complete overview. LeSS addresses this factor with the principle of “Whole Product Focus”. We’ll discuss this in the next section of this column.

Links & Literature

[1] Mezick, Daniel: “The OpenSpace Agility Handbook”; Freestanding Press, 2015

[2] https://www.scrum.org/resources/online-nexus-guide

[3] https://less.works

[4] https://www.scaledagileframework.com

[5] http://www.scrumguides.org/scrum-guide.html