Doug+Dockery

事实上，“部署敏捷”与“变敏捷”完全是两回事，仅仅部署敏捷并没有多少实际价值。

时至今天，相信大家都已经听说过“敏捷”这个词。许多公司甚至很可能已有专门的敏捷团队。大多数软件驱动的公司希望通过从事敏捷（doing agile）开发来协助解决重大的业务和组织结构问题：诸如各种未兑现的承诺、不尽如人意的质量、缺乏可视性、成本过高、协作性差，以及创新进度缓慢等等。但很可惜，有许多公司发现他们并没有从敏捷投资中得到预期的结果。

事实上，“部署敏捷”与“变敏捷”完全是两回事。坦白来讲，仅仅部署敏捷并没有多少实际价值。

这并非敏捷团队的错。公司战略与执行不一致，导致团队成果与预期南辕北辙是见惯不怪的事情。这些公司一般在组织架构中存在巨大的“脱节”。那些知道如何弥补这一脱节的公司可以确保正确的投资，并以正确的方式组建。但更重要的是，他们可以定期以较低成本改变正在创建的产品，以紧跟市场需求，在开发过程中创造最大价值。这是在规模上实现打造真正的敏捷企业的保证，但要如何实现呢？

对Scrum的迷惘

在提供企业咨询时，我通常会提出以下三个问题：你的团队结构怎样？团队的工作流程怎样？你会怎样计划？ 典型答案都会关注团队数量、角色、技术、流程、估算故事价值、sprints长度等等。我们总能改善团队层面的行为准则，但那又如何？每家公司都可以有Scrum团队，但绝对不可以迷信Scrum框架会解决公司所面临的重大问题。……