敏捷经济学：3D尺度

当我们开始谈论扩展时，我们说组织正在寻找解决方案。痛苦是分娩缓慢。这种治愈方法似乎正在成功地带动敏捷性，从而将团队扩大到团队，组织或整个公司。

我们知道，小型组织（无论是否敏捷）通常比大型组织（痛苦不堪）的交付能力更好。随着组织的成长，由于专业化，会有更多的沟通途径，团队之间的更多依存关系。很难快速获得答案，事情会卡住或掉下来，并且不会被捡起。

他们越大

这并不是说他们没有在敏捷解决这个问题之前就尝试过。但是，提高效率的道路上有两个障碍。传统的基于层次结构的组织使用命令和控制来消除浪费并提高生产率。

但是，命令和控制方法有一个隐含但错误的假设：您的老板比您了解更多。如果您有任何疑问，老板会给您。如果老板发现您正在做的事情比您应做的重要，她会引导您去做更重要的事情。如果您需要其他小组的帮助，老板会解决。

在高独立性的组织中，当团队专门研究某项东西（技术，领域，角色等）时，他们会不断提高对精通其他主题的其他团队的依赖。交付某些东西的唯一方法是将所有内容组合在一起，并且需要专门的团队，我们需要大使和谈判代表，而这些通常都是老板。

最后，当团队专门化时，他们的目标是更好地完成工作，这可能（通常不是）与组织的最终目标相关。团队尝试优化流程以获取收益，有时会与其他团队合作。

考虑一下单独的开发团队和测试团队，在这些团队中，鼓励开发人员推送更多的代码（这被认为是有生产力的），而不是测试团队可以吞咽的更多。这会导致错误回程，团队之间的敌意以及产品被延迟。

在知识经济中，“工人”比老板了解更多。他们不需要“老板”来做传统的老板事-毕竟，如果我们可以将某些事情委派给老板，那是因为团队不知道该怎么做，而且因为老板也不知道，就像她只是团队中的另一个成员一样。他们会找出问题并解决。

（是的，我不讨论老板今天的意思，以及他们实际的工作。今天不是。）

敏捷原则与交付能力相关。如果团队具有足够的力量和独立性，他们可以解决自己的问题。

这就是扩展的真正机会。

为了尽早并经常交付，我们需要将决策权下放到团队级别。这样，我们消除了经理的瓶颈，让团队来处理经理过去要解决的问题。

假设我们有一个低级的产品负责人，他花时间在两个团队中，还“寻找”时间与客户见面，进行研究并尝试一些UX。你知道，一个女超人。

您通常会发现PO成为交付的瓶颈。产品知识在于他。因此，她掌握了所有答案。团队正在等待她告诉她她想要什么，以便他们可以构建它。

但是我们的采购订单太忙了。她没有为团队“喂食”。这些团队不知道该怎么办。

如果团队（通常是开发人员和测试人员，还包括运营，支持人员以及团队中的任何人员）了解他们的业务，了解他们的软件并被允许冒险（有时会失败），那么他们现在可以决定将什么推向产品。我们只是“扩展”了产品所有者的角色。

当然，这并不容易。团队将做出错误的决定。他们的想法与PO不同。

如果PO赋予团队决定的能力，则她需要接受。如果没有，团队将返回“给我喂食”模式。毕竟，他们为什么要浪费时间做PO将重新定义的事情？

但是，如果采购订单了解她的想法也并非一直有效，并且团队了解根据反馈意见改变主意是工作的一部分–那时您就消除了瓶颈。

缩放与过程无关，更好的过程与治愈无关。如果我们专注于敏捷原则，并确保这些原则能够实现，那么我们就可以扩展交付能力。

那不是我们真正想要的吗？

翻译自: https://www.javacodegeeks.com/2016/06/agile-economics-scale-3d.html