团队自治管理工作交流会_独立，自治和太多小团队

团队自治管理工作交流会

This article was originally published on my website — https://kislayverma.com/organizations/independence-autonomy-and-too-many-small-teams/

本文最初发布在我的网站上-https: //kislayverma.com/organizations/independence-autonomy-and-too-many-small-teams/

Sign up on the mailing list to receive my weekly newsletter on software, teams, and books right in your inbox.

在邮件列表中注册，以在您的收件箱中接收我有关软件，团队和书籍的每周新闻 。

“The two pizza team” paradigm has become really popular in the context of organizing software teams. The idea is to have small, self-reliant teams working independently to solve problems. The “two-pizza” refers to the guidance to keep the team small enough that we need not order more than two pizzas to feed them.

在组织软件团队的背景下，“两个比萨饼团队”范式已变得非常流行。 这个想法是让独立的小型团队独立工作以解决问题。 “两个比萨饼”指的是使团队保持足够小以至于我们不需要订购两个以上的比萨饼来喂养他们的指导。

These teams are all around us today, but we are not seeing the kind of productivity or shipping velocity that we expected to see. Most developers, especially in larger organizations, complain about meetings, the burden of communication, the slow pace of change etc. Startups often sell themselves to potential candidates by touting their agility. But why should larger companies be slow if everyone is using the same “empowered team”/”autonomous team” model for organizing themselves?

这些团队今天都在我们身边，但是我们没有看到我们期望看到的那种生产率或运输速度。 大多数开发人员，尤其是大型组织中的开发人员，都在抱怨会议，沟通负担，变更步伐缓慢等。初创企业经常通过吹捧他们的敏捷性而将自己推销给潜在的候选人。 但是，如果每个人都使用相同的“授权团队” /“自治团队”模型进行组织，那么大型公司为什么会变慢？

I argue that we have lost the original intent of the “two pizza teams” (aka autonomous teams). The way we are organizing and scaling teams as companies grow larger is exactly opposite to the spirit of the idea, and this is making the already difficult problem of keeping teams motivated and agile even more difficult.

我认为我们已经失去了“两个比萨饼团队”(又名自主团队)的初衷。 随着公司规模的扩大，我们组织和扩展团队的方式与这种想法的精神恰恰相反，这使保持团队的积极性和敏捷性这一本已困难的问题变得更加困难。

为什么有两个披萨队 (Why two pizza teams)

The concept of the “two pizza”/”autonomous” team arose from attempts to minimize communication between multiple teams and empowering a single team to be in complete control of delivering customer value.

“两个披萨” /“自治”团队的概念源于试图最大程度地减少多个团队之间的交流并赋予单个团队完全控制交付客户价值的能力。

Before this idea gained popularity, the most common way of organizing teams was in terms of Backend, UI, DBA, Ops etc.. Building any feature required a lot of communication, collaboration, and alignment between all these groups.

在这个想法流行之前，组织团队的最常见方法是在后端，UI，DBA，Ops等方面。构建任何功能都需要在所有这些小组之间进行大量的沟通，协作和协调。

The notion of a small team which had all the skills required to solve a single specific problem was intended to solve this problem. A single team would be given the entirety of the problem statement and the tools it needed to solve it. This would ideally remove the problem of aligning multiple teams around shared roadmaps and delivery schedules and allow the team to own the problem solving process end-to-end.

具有解决单个特定问题所需的全部技能的小团队的想法旨在解决此问题。 将为一个团队提供完整的问题陈述及其解决问题所需的工具。 理想情况下，这将消除使多个团队围绕共享路线图和交付时间表进行协调的问题，并允许团队拥有端到端的问题解决流程。

There are two core concepts underlying the two-pizza team — mission and independence. Ideally, end-to-end means all the way to the customer or the business. Hence, every autonomous team is expected to generate direct business value all by itself, without a lot of overlap with other teams. Additionally, the team should be able to meets its goals independently (i.e. without reliance on or interference from other teams) This reduces the cross team communication overhead because its members have all the skills needed to solve the problem.

两个比萨饼团队具有两个核心概念-使命和独立性。 理想情况下，端到端意味着一直到客户或企业。 因此，每个自治团队都有望独自产生直接的业务价值，而不会与其他团队产生很多重叠。 另外，团队应该能够独立地实现其目标(即不依赖其他团队或没有其他团队的干扰)，这减少了跨团队的沟通开销，因为其成员具有解决问题所需的全部技能。

什么地方出了错 (What went wrong)

Somewhere along the line, we forgot about “reducing communication” just started fixating on assigning independent teams to problem statements that were essentially tiny slices of business problems. As the problem space gets more finely sliced in hopes of achieving scale at each step, so does the number of teams. e.g. What might have been a “Data Delivery Team” charged with delivering fresh data to customers unfortunately becomes “Data ingestion Team”, “Data processing Team” and “Data Release Team” (real world example).

在这条线的某个地方，我们忘记了“减少沟通”，而是开始专注于将独立团队分配给问题陈述，而这些问题陈述实际上只是业务问题的一小部分。 随着问题空间的划分越来越细，希望在每个步骤都实现规模化，团队数量也随之增加。 例如，原本负责向客户交付新数据的“数据交付团队”可能变成了“数据获取团队”，“数据处理团队”和“数据发布团队”(实际示例)。

This causes problems with both the core tenets of the autonomous team philosophy.

这会导致自主团队理念的两个核心原则出现问题。

The mission is diluted because most of the teams are now working on problems which are subsets of the original problem and as such not valuable in themselves. The success of a team can no longer guarantee the improvement of at least one business metric. The team’s work is not tied to a business objective any longer, so it gets tied to tightly defined execution scopes.”Data ingestion team” is supposed to pull in data, that’s it. While the team is still allowed to do this however it wants, succeeding in its objective will not mean that fresh data is being delivered to the customer.

任务被淡化了，因为大多数团队现在都在处理问题，这些问题是原始问题的子集，因此本身并不有价值。 团队的成功不再能够保证至少改善一项业务指标。 团队的工作不再与业务目标联系在一起，因此与严格定义的执行范围联系在一起。“数据提取团队”应该提取数据，就是这样。 尽管仍然允许团队按照自己的意愿进行操作，但成功实现目标并不意味着将新数据传递给客户。

Autonomy is diluted as a direct fallout. Where a single team could have come together to solve problems of data delivery, now multiple teams with different managers and different roadmaps must come together to deliver anything to the customer. This creates exactly the kind of coordination overhead that these small teams were created to solve in the first place.

自治被稀释为直接后果。 在一个团队可以聚集在一起解决数据交付问题的地方，现在必须由具有不同经理和不同路线图的多个团队聚集在一起，才能向客户交付任何东西。 这恰好创建了这些小型团队最初要解决的协调开销。

Coordination, also known as alignment, communication, shared roadmap, Gantt chart and many other positive sounding names, is the arch-enemy of the autonomous team.

协调，也称为对齐，交流，共享路线图，甘特图和许多其他正面的称呼，是自治团队的头号敌人。

We have lots of small teams with lots of independence and no direct impact that keeping everyone pointed in one direction has become a nightmare. Program Managers paper over the ever-increasing complexity involved in coordinating priorities, efforts, and timelines, with developers and managers increasingly wash their hands of the whole business of communicating with other teams.

我们有许多具有独立性的小型团队，并且没有直接影响，使每个人都指向一个方向已成为噩梦。 计划经理指出了协调优先级，努力和时间表所涉及的日益复杂的问题，开发人员和经理越来越不愿与其他团队进行沟通。

We took a good idea too far. The current “small” team is certainly small, but we forgot the part about reducing communication. Instead we are now offered “small, highly collaborative” teams as some sort of new ideal, as if high collaboration is something to be desired during execution.

我们采取了一个好主意。 当前的“小”团队当然很小，但是我们忘记了减少交流的部分。 相反，现在我们为“小型，高度协作”的团队提供了某种新的理想，好像在执行过程中需要高协作。

This is a huge blind spot for organizations. The implicit goodness of small teams (devoid of any of the original context) is now internalized to such an extent that deep collaboration between small teams is considered a good thing in the organization. Team productivity and motivation keeps falling even as their sizes increase. And somehow we still believe this way of organizing work among teams is efficient, and something else must be causing the diminishing productivity.

这是组织的巨大盲点。 小型团队的隐性优势(没有任何原始上下文)现在已被内部化，以至于小型团队之间的深度合作被视为组织中的一件好事。 即使团队规模扩大，团队的生产力和动力也会不断下降。 而且我们仍然以某种方式认为，在团队之间组织工作的这种方式是有效的，并且必须有其他原因导致生产率下降。

合作不好 (Collaboration is not good)

Collaboration is a great idea during ideation and brainstorming. It helps in getting a lot of input from lots of different people and can help us discover new aspects which we may not consider ourselves. It can expose other approaches to solving the problem, or even some versions of this problem that have already been solved by others. Broad stroked collaboration between people and systems is how we build something that is greater than the sum of its parts.

在构思和集思广益期间，协作是一个好主意。 它有助于从很多不同的人那里获得很多意见，并可以帮助我们发现我们可能不认为自己的新方面。 它可以提供解决问题的其他方法，甚至可以提供其他人已经解决的某些版本的问题。 人与系统之间广泛的协作是我们构建比其各个部分之和更大的东西的方式。

However, once we reach the execution phase, collaboration is extremely costly. Collaboration means that two people or teams cannot just focus on doing their jobs, they also have to worry about when the other person is going to finish theirs and how they are going to synchronize with each other to hit the finish line.

但是，一旦我们进入执行阶段，协作的成本将非常高。 合作意味着两个人或团队不能仅仅专注于完成工作，他们还必须担心另一个人什么时候才能完成他们的工作，以及他们如何彼此同步才能达到终点。

I can quote any number of engineering principles to refute the deification of collaborative teams which seems to be the norm today.

我可以引用任何数量的工程原理来驳斥协作团队的尊严，这似乎是当今的规范。

In general, it is assumed that multithreading improves the performance of a system. This is completely true if each thread can execute completely independently on its own core without talking to any other thread or sharing any data. However, the moment we end with some shared state or more threads than CPUs, the synchronization overhead can quickly outstrip all the performance gains from using the technique.

通常，假定多线程可以提高系统的性能。 如果每个线程可以完全独立地在其自己的内核上执行而不与任何其他线程交谈或共享任何数据，则完全正确。 但是，当我们以某种共享状态或比CPU多的线程结束时，同步开销可能很快超过使用该技术获得的所有性能提升。

Amdahl’s law puts a finite upper limit on the increased output when an extra worker is added into the mix. The well-known problem is that every extra worker imposes non-parallelizable, exponentially increasing communication overhead. At some point, adding another worker makes things worse rather than better.

当增加额外工人时， 阿姆达尔定律对增加的产量设定了有限的上限。 众所周知的问题是，每个额外的工作人员都会施加不可并行的，成倍增加的通信开销。 在某个时候，增加另一个工人会使事情变得更糟而不是更好。

“9 developers cannot finish a 9 month project in one month” is a well-known idea in software management. And yet we see managers trying to grow and manage their teams in isolation. Why is that?

“ 9个开发人员不能在一个月内完成一个9个月的项目 ”是软件管理中的一个众所周知的想法。 但是我们看到经理们试图孤立地发展和管理团队。 这是为什么？

My hypothesis is that we see individual teams delivering quickly and we interpret this to mean that adding more members to these teams will further scale the output. In a world where we examine teams by isolating them from the overall system context, it is very easy to confuse independent with autonomous.

我的假设是，我们看到各个团队的交付速度很快，我们将其解释为意味着向这些团队添加更多成员将进一步扩大输出。 在一个我们通过将团队与整个系统环境隔离开来检查团队的世界中，将独立与自治相混淆很容易。

独立不是自主权 (Independence is not Autonomy)

In a highly collaborative setup, the correct way of looking at the organization is like a factory floor. Theory of constraints tells us that the only way to increase output in this situation is to broaden the bottlenecks and widen the entire “flow of work” from conception to final delivery to the customer.

在高度协作的设置中，查看组织的正确方法就像是工厂车间。 约束理论告诉我们，在这种情况下增加产量的唯一方法是扩大瓶颈，扩大从构思到最终交付给客户的整个“工作流程”。

But when we look at each step individually and out of context of the rest of the “pipeline”, “delivery” takes on a very different meaning. It just means “out of my door”. Any attempts to improve output with such a perspective will only create local maxima which means nothing for the final output — it might even be detrimental.

但是，当我们单独查看每个步骤并且脱离其余“管道”的上下文时，“交付”具有非常不同的含义。 它只是意味着“走出我的门”。 任何从这样的角度来改善产出的尝试都只会产生局部最大值，这对最终产出毫无意义，甚至可能是有害的。

This is where we end up with too many small teams which are only looking at their little slice of work. That is what they are incentivised to do. If the outputs of our teams are arranged sequentially, they are not autonomous in delivery, no matter how independent they might be in their day to day work.

在这里，我们最终会有太多的小团队，只看他们的一小部分工作。 这就是他们被激励去做的事情。 如果我们团队的产出是按顺序安排的，那么他们在执行工作时就不会独立自主，无论他们在日常工作中有多独立。

Anyone who has managed a supply chain can tell, independent teams organized in a sequential manner MANDATE a lot of communication and feedback. The lines of communication have not been removed by the creating small teams — they have been multiplied manifold. What’s worse, communication is happening at team boundaries where it is actually the weakest (the communication overhead in microservices springs to mind readily).

管理过供应链的任何人都可以告诉以顺序方式组织的独立团队，需要进行大量沟通和反馈。 建立小团队并没有消除沟通的界限，它们已经成倍增加。 更糟糕的是，通信发生在实际上是最弱的团队边界( 微服务中的通信开销很容易想到)。

Without an autonomous mission, independent teams are forever shackled by the communication overhead.

没有自主任务，独立团队将永远被通信开销所束缚。

自治是面向客户的架构 (Autonomy is a customer facing construct)

What happens if we organize our independent teams by problem statement rather than function? A team that is authorized to solve a customer problem using any means at its disposal in essence owns the entire “pipeline” of tasks that need to be done. There is no cross-team collaboration and communication required for this team to do its job. This team not only operates independently, it also delivers value to the customer independently.

如果我们通过问题陈述而不是职能来组织独立团队，会发生什么？ 一个有权使用任何可能的手段来解决客户问题的团队，实质上拥有需要完成的全部“管道”。 该团队完成工作不需要任何跨团队的协作和沟通。 这个团队不仅独立运作，而且还独立地为客户提供价值。

A team is autonomous when it “delivers value to the customer” independently. In his novel “Goal“, Eliyahu M. Goldratt highlights this beautifully by having his protagonist (who is plant manager) define his success to mean increased sales. Sales is usually not the problem of the manufacturing team, but the novel highlights how defining a customer facing “global” goal transforms the poorly performing plant.

当团队独立地“为客户提供价值”时，他们是自治的。 Eliyahu M. Goldratt在他的小说“ Goal ”中，通过让他的主角(工厂经理)将他的成功定义为成功来表示销量的增长，来突出显示这一点。 销售通常不是制造团队的问题，但小说强调指出了如何定义面向“全球”目标的客户如何改变业绩不佳的工厂。

Scaling this team will directly add more business value because the new resources will be (should be?) deployed in the most optimum way within the team’s pipeline. This is no different from the previous situation of task owners creating local maxima, but because the team owns the final customer problem, even a local maximum is a win for the customer.

扩展该团队将直接增加更多的业务价值，因为新资源将(应该是？)将以最佳方式部署在团队的渠道中。 这与任务所有者以前创建局部最大值的情况没有什么不同，但是由于团队拥有最终的客户问题，因此即使局部最大值也可以赢得客户。

This is what the original “two-pizza” team was intended to do. Not merely to execute independently, but to deliver customer value independently. The core idea behind autonomy is not arranging teams to maximize outputs of steps in the value chain, but defining value chains in such a way that a single, tight-knit team can be unleashed upon it. Every team has to define its output in terms of customer success because that’s how the organizational boundary is drawn.

这就是最初的“两个比萨饼”团队的目的。 不仅要独立执行，而且要独立交付客户价值。 自治背后的核心思想不是安排团队以最大化价值链中步骤的产出，而是以这样一种方式定义价值链，即可以释放一个紧密联系的团队。 每个团队都必须根据客户的成功来定义其输出，因为这是绘制组织边界的方式。

扩大自治团队 (Scaling an autonomous team)

The problem of scaling teams applies recursively, no matter the paradigm we choose to apply. Let’s say we have autonomous teams and all that, now how do we scale their output to achieve ever larger objectives?

无论我们选择采用哪种范例，扩展团队的问题都会递归地应用。 假设我们拥有自治团队等等，现在我们如何扩展他们的产出以实现更大的目标？

This is a central problem faced by large organizations. In the early days of a company, domain experts emerge and lead small teams that solve specific customer problems. Since the size of the company is small, having direct customer impact is typically not difficult.

这是大型组织面临的核心问题。 在公司成立之初，领域专家应运而生，并带领小型团队解决特定的客户问题。 由于公司规模较小，因此直接影响客户通常并不困难。

However, as the organization grows large in scope, size and ambition, each little team is now expected to deliver more and more. This typically means growing team sizes by adding more members. Then each team starts internally splitting into separate sub-teams, and we are back to independent teams rather than autonomous teams.

但是，随着组织范围，规模和野心的扩大，现在希望每个小团队都能交付更多。 这通常意味着通过添加更多成员来扩大团队规模。 然后，每个团队开始在内部拆分成独立的子团队，然后我们回到独立团队，而不是自治团队。

How can we scale our teams to deliver on more and more ambitious goals while retaining their autonomous nature? I will offer some opinions on this in the next post.

我们如何在保持自身自治性的同时扩大团队规模以实现越来越雄心勃勃的目标？ 我将在下一篇文章中对此发表一些意见。

Read Next : How to use Agile for more than just great execution

阅读下一篇 ：如何使用敏捷不仅仅是出色的执行力

Join the mailing list if you want to hear more from me on software architecture and team building. I also publish a weekly newsletter covering what’s fresh on the blog and cool things from the tech internet.

如果您想了解我对软件体系结构和团队建设的更多了解，请加入邮件列表 。 我还发布每周新闻简报，内容涵盖博客上的最新内容以及技术互联网上的精彩内容。

翻译自: https://medium.com/swlh/independence-autonomy-and-too-many-small-teams-6cf0413d1277

团队自治管理工作交流会