以联邦组织为例。当彼得•德鲁克(Peter Drucker)在20世纪40年代研究通用汽车(General Motors)时，他发现这家拥有数十万员工的公司在Hseih测试中的表现比大多数公司都好。德鲁克发现并记录的秘密公司的概念就是他所说的“联邦组织”——将公司分割成尽可能小的业务单位，同时保留一个提供服务的核心。例如，托管托管服务、测试环境、获取和提供软件和硬件的过程，这些过程实际上加快了交付过程。这与改变IT以支持专业(如营销团队、会计等)不同，而是改变组织以使其更加敏捷。这种变化可能以缓慢的速度发生，或者需要一场危机，就像IBM在创建个人电脑部门时所做的那样。
[相关:引入可伸缩的敏捷框架］
考虑文化和价值观，而不是大爆炸的重启。在传统的将工作推给团队的管理模式下，敏捷工作的许多要素——比如限制正在进行的工作和以短增量的方式进行计划——完全崩溃了。提供指导和文化，人们可能会“明白”，但过程不能弥补糟糕的决策。正如我的同事Michael Bolton喜欢指出的那样，“如果您发现自己陷入了困境，那么您的流程模型不会拿起铲子。”
这让我想起了公司的工作领先的敏捷，详细载于“比较扩展框架严格地说，领导敏捷并不提供一个“框架”。该公司关注的不是流程和计划，而是高管培训，帮助推动决策，从而改变人们对提供服务的看法。
让数以千计的小团队繁荣起来。在产品开发流程的原则，作者Don Reinertsen提供了他对大型项目的研究，显示随着项目变得更大，时间下滑的百分比趋于增加。首先，它们也需要更长的时间。一个更大的数字中，一个更大的百分比意味着更大的下滑。然而，在每一个八位数或九位数的大型资本项目中，都有十几个有机会获得成功的小项目。将软件开发团队组织为价值流，给他们适当大小的问题，并开发一种他们可以全部部署的方式，而不需要阶段性的强化冲刺。Web服务是一种常见的方法;它似乎在亚马逊工作．
例如，使用精益管理方法，组织的每个层次都可以通过一个带有列的板来可视化工作流程。每个级别都可以在董事会面前讨论每天的工作，在时间盒中计划工作，并定期开会评估绩效。在不同级别审查董事会之间的差异，可能会导致原本可能无法发现的问题浮出水面。
以上方法均为持续改进方法。他们现在就可以开始。他们的规模。他们也不会吓到高管们，因为高管们的支持是任何变革取得成功的必要条件。
反思我们的示例
更广泛的科技行业都痴迷于苹果这样的公司，它们大多采用新创意，并让它们获得商业成功。说到敏捷扩展，我们最好看看3M公司，这家公司曾经被称为明尼苏达矿业公司。是的，如果你还记得软盘的话，就是在你年轻的时候为你制作软盘的那家公司。3M公司衡量其专利的年龄，并制定了创造新专利的政策，投入资源以取得商业成功，并在市场变得过于陈旧之前放弃市场。
这些团队可能比传统的敏捷“小团队”要大一些;经营一家制造厂需要20多个人。他们所拥有的是一个有多个部门的联邦组织，每个部门都有一个可以不断放大的整体工作视角，能够对变化做出反应，对客户价值和技术卓越的关注。
我并不是想过度赞扬3M。然而，它似乎为敏捷组织的样子提供了一个令人信服的论据。所以忘记规模。问问自己敏捷组织应该是什么样的，以及如何朝着这个方向前进。
即使只有一两英寸。在那一寸土地上寻找荣耀，为那一寸土地自豪。告诉我们进展如何。
这篇文章，“敏捷能扩展吗?它重要吗?”最初发表于首席信息官 ．