In the previous article, we introduced the basic structure of the Less framework and explained the difference and connection between Less and scrum. In the first article, we mentioned that the Less Huge framework needs to be used for management when the team size exceeds 8. In this section, we will introduce the basic properties of the Less Huge framework by comparing Less and Less huge.
Roles
In less, we have emphasized that in the framework, we hope that there will be only one product owner to plan and manage products uniformly. If the size of the team has exceeded 8, it seems difficult for a product owner to manage such a large range of product directions and content. Therefore, the concept of APO (Area PO) has been added to less huge, that is, the person in charge of domain products. I need to reiterate that although the role of domain product person is added, PO is still the owner of the product. As the name suggests, domain products The person in charge is responsible for product management in a certain field. He is responsible for the management of the product to-do list in this field. However, as a whole, he still has to follow the PO product planning and requirements. From another perspective, PO and APO form the product The management team can better manage the products of more than 8 teams through this operation mechanism.
Artifact
Now that the role of the domain product leader is added, it will inevitably have an impact on the artifacts. The domain attribute is added to the product to-do list. Here is one point that needs everyone’s attention. The description here is to increase the domain attribute instead of increasing the domain. The product to-do list, which means that there is still only one product to-do list, but the view of the domain is increased through the domain attribute. I hope readers can savor this point carefully and understand the meaning of this design.
less huge conference management
The first thing that needs to be explained is that less huge and less follow the basic principle of common sprint delivery of common product increments, but there is no mandatory requirement for planning meetings, review meetings and retrospective meetings. Teams in different fields can plan, review and review together when needed, but there is no mandatory requirement, because less feels that such a mechanism will increase complexity, the simplest example, so the coordination of team representatives to plan meetings and conference rooms together is very Difficulty (and this is clearly different from the SAFe framework).
Why use less huge
From the above description, we know that less huge has made adjustments to roles and artifacts, but why do such changes need to be made when the size of the team exceeds 8, and what problems will it bring if no adjustments are made?
1. The complexity of the product to-do list increases. In fact, it is not difficult to imagine that when the size of the team is too large, the content of the product to-do list will be very correct. It is very time-consuming and inefficient to rely on a product owner for planning and management. Yes, so APO needs to help the product owner to sort out and manage to meet the goal of rapid iteration;
2. The team size is too large. When the team size is large enough, the product owner needs to connect with multiple teams, and the personalized communication needs of different teams , So that the product owner can’t deal with it, it requires AAPO to replace the product owner for docking. At the same time, APO can focus more on specific areas, gradually generate your professionalism and improve work efficiency; 3. Team response is slow when the team size is too large After all, the response speed of the team will become sluggish, which is similar to the evolution of the organizational structure. If it is a start-up company with a simple and flat organizational structure, when the team develops better and better and the scale gradually becomes larger, it will naturally evolve a lot Departments and teams, and then there are many management and auxiliary roles to promote organizational activities, the generation of APO is also the same, but less still emphasizes as simple as possible, and does not want to increase the complexity of the organizational structure due to the introduction of APO;
to sum up
So everyone should be clear from this paragraph that less huge can be understood as more less teams working together. Each field is a team managed by the less framework, and different less teams are managed and coordinated through PO and scrum master. In less, we said that a scrum master can serve 1-3 teams, which requires relatively high maturity of the team. In addition, in less huge, in order to ensure that teams in different fields can learn and cooperate better It is recommended that the team responsible for the scrum master can cover different business areas, which can better promote the better operation of the less huge mechanism and play the value of the scrum master. Through the introduction of recent articles, readers should be able to feel that the structure of less is relatively clear. In addition to the above content, what other content of less needs your attention? Continue the discussion in the next article!
