"More with LeSS" is one of the LeSS principles and is at the heart of LeSS. It means to have more responsible teams by having less (fewer) roles and less (fewer) installed processes, as more roles and installed processes lead to less responsible teams. In fact, Scrum has
I have been organizing and facilitating the sessions of "practicing systems thinking together" for a while. The purpose is to improve the capability of practicing systems thinking together. Over time, I find it become akin to coding dojo. "A Coding Dojo is a meeting where a bunch
It seems that product development organizations care about productivity the most. This is reflected by the common misunderstanding about adopting agile development for higher productivity while agile development is about flexibility and adaptiveness. In this article, we will take a look at why focusing on productivity is often not a
The previous article talked about how to introduce systems thinking in product learning, and this one is about introducing systems thinking in process learning. In contrast to product learning, practicing systems thinking in retrospectives has been more widely advocated. However, it is rarely sustained in my experience - when introducing
A few years ago, I wrote about "how does LeSS optimize organizational ability to learn?". I saw the potential of practicing systems thinking to enhance both product and process learning, but lacked the concrete steps to make it happen. Now, I gather more thoughts and experience, thus mean
This is an interesting quote by Bas Vodde - "we should maximize dependencies between teams". As it seems contradicting with our conventional thinking, we shall elaborate on it in this article. Independent teams? Isn't feature team supposed to deliver features independently? Yes, it is. As illustrated
During the past half year, I have seen the similar situation at least three times in various organizations. This probably means that it is worth an elaboration. "Component Product Manager" We know of component team, but what on earth is "component PM (Product Manager)"? Doesn'
A bunch of teams are responsible for various domains, be it systems or services. Each domain team has its own backlog. For example, in an e-commerce company, there are domain teams responsible for website, OMS (Order Management System), WMS (Warehouse Management System), payment system, etc. They develop features from those
There are a few teams each having its own PO (Product Owner), is there a need for an overarching PGO (Product Group Owner)? I have recently encountered two different configurations, and let's explore them one by one. 1. Teams are responsible for elements in the product In the
"We have 5 teams. We are doing LeSS, and we have 3 APOs (Area Product Owners)." Wait, this is NOT LeSS! Motivated by this kind of common misunderstanding, I am writing this article to describes the different rules in LeSS and LeSS Huge, and why they are different.
In the previous two articles, we explored the limits from PO (Product Owner) on clarification and prioritization respectively. In this article, we shall look at the limit from teams. Team's capability on development Similar to the limit from PO, we are also limited by team's capability
In the previous article, we explored one of the two limits from PO - the fake limit on clarification. In this article, we shall explore the other limit from PO - the real limit on prioritization. Real limit on prioritization Besides the limit on clarification, the other limit is PO&
What are the limits to one PBL (Product Backlog)? Two major areas are from PO (Product Owner) and team, respectively. We shall first focus on the limits from PO. When people claim that it is impossible for one PO to manage one PBL shared by many teams, there are actually
The previous article was written in an analytical manner, while in this article I will supplement it with an experience during the time of Nokia Networks. As it happened more than ten years ago, some details may not be as accurate as I would like them to be, but I
Recently, I ran across my old article "PO on team or PO on feature?" written about ten years ago, and found that it could be connected to the topic of limits to one product backlog. My thinking at that time touched some factors, but was still vague. Over
[RA = Requirement Area; PBI = Product Backlog Item.] In LeSS Huge, there is an additional scaling technique called RA. How to define RAs has confused many practitioners. This article tries to open a perspective. By which dimension? By which dimension do we define RAs? We know that RA is customer centric.