Aug 09, 2020 21:00:00

Amazon's ``two-pizza rule'' that explodes productivity has become a skeleton at many development sites

Amazon was able to expand its business according to the rule set by CEO Jeff Bezos `` All teams in the company must be the perfect number to eat two pizzas ''

It is said . The two-pizza pizza rule is often used in software development, but despite being a small team, many developers at large companies complain that 'productivity does not increase'. It is said that there is. Developers Kislay Verma points out that simply using the two-pizza rule doesn't make sense.

Independence,autonomy,too many small teams | Kislay Verma
https://kislayverma.com/organizations/independence-autonomy-and-too-many-small-teams/

The basic idea of the two pizza rule is that 'a team large enough to share two pizzas saves extra time and is most efficient.' Large teams with lots of people need to communicate and plan across the board, but smaller teams with the ability and the power to make such communications You can move quickly with minimal time.

Essentially, the important point of the two-pizza rule is 'mission' and 'autonomy'. If you have a lot of teams with the two, each team can tackle the issue end-to-end. This is what creates 'quickness'.

However, in the case of large companies, even if each team is small, it does not have the above characteristics, and the 'two-pizza rule' is a mere skeleton.

Verma thinks that the reason why the two-pizza rule has disappeared is that the perspective of 'reducing communication' was lost at some point during the organization. From the viewpoint of 'reducing communication', there should be only one team involved in problem solving, but if this viewpoint is lacking, it may be judged that 'three teams are assigned to solve one problem'. There is.

For example, if one team takes full responsibility for solving an issue, the team's goals are tied to business goals. However, if there is a “data capture team”, a “data processing team”, and a “data disclosure team” in solving problems, the goal of each team is to “complete the task” rather than the overall business goal. I will. And with each team becoming one of the cogs, more reporting is done and team autonomy, productivity and motivation are lost. This is the blind spot of large companies.

It is said that

collaborating when formulating an idea is basically good from the viewpoint of thinking from various viewpoints, but on the other hand, collaborating in the 'idea solidification and execution phase' is very expensive. That. Collaboration at the execution stage can help teams and individuals to focus on their work and keep them in line with others.

According to Amdahl's law , 'when multiple processors are used for calculation, there is an upper limit at which the performance will not be improved even if additional processors are added.' If this is applied to the development site, even if a team that starts work in parallel with the issue is added, there is an upper limit that communication increases exponentially, work cannot be parallelized, and efficiency does not increase, there is, From the point in time, it can even happen that 'adding more people makes the situation worse, not better.' In fact, the phrase 'a job that one developer takes nine months cannot be done by nine developers in a month' is often heard at management sites, Verma said.

Based on the above, when setting up collaboration within an organization, it is important to 'expand the bottleneck and expand the workflow from conception to customer provision' based on the theory of constraints . thing. The theory of constraints is a method of solving problems by focusing on 'constraints (bottlenecks)' based on the assumption that 'the performance of any system is limited by a few factors'. It requires the end-to-end work of the team, widening the bottleneck.

The two-pizza rule is easy for small companies to implement, but Verma says the larger it gets, the harder it becomes. When the work from conception to delivery to customers is divided, each team needs communication and feedback, and even though they are independent work, the task of finally delivering the product to the customer is autonomous. It cannot be. And without being able to work autonomously, Verma pointed out that developers would be bound by the demands of communication forever.