“部署敏捷”是不是“真敏捷”？

Doug+Dockery

一个敏捷企业必须深谙只有将战略、能力及文化结合起来，才能实现真正的机构转变。

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

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

对Scrum的迷惘

在提供企业咨询时，我通常会提出以下三个问题：1.你的团队结构怎样？2.团队的工作流程怎样？3.你会怎样计划？典型答案都会关注团队数量、角色、技术、流程、估算故事价值、sprints长度等。我们总能改善团队层面的行为准则，但那又如何？每家公司都可以有Scrum团队，但绝对不可以迷信Scrum框架会解决公司所面临的重大问题。事实上，如果你所做的一切只是依赖这些单独的Scrum团队，其结果可能比瀑布开发模式更糟糕。

让我们潜心思考一下。如果你的敏捷团队的成员认为用瀑布开发模式更好，其中可能的原因就是：在瀑布模式中，当我们对工作所知甚少时，我们会预先作出决策。经验告诉我们项目将会推迟且超出预算，但我们会知道构建的内容，因为范围是固定的。与之相比，被称为“自然法则下的Scrum”（Feral Scrum）的优化团队能够快速交付软件，而他们则只在Scrum模式下埋头做着自己的工作。有时，他们与组织的唯一联系就是唯一一个跟其他模式共享的产品负责人。他们投入许多资源进行开发，但我们不知道他们要交付的产品是否就是我们目前真正需要的。

首要问题

我们先不谈出色的团队执行未能解决我们的业务问题，让我们来看一下如何计划工作和安排人员。这时候，我们就要谈到项目章程、业务案例、资金和资源审批。我们会讨论他们计划的频率、参与人员以及需要花费的时间和精力。

一位客户曾告诉我他们的年度计划批准了商业智能团队的71个项目，并且该71个项目目前全部仍处于活跃状态，“因为管理者需要看到整个系统进展”。其中有一半的项目是从上一年度顺延下来的。更致命的是，他们告诉我预期今年内不会有一个项目能够完工！

通过实施看板方案，我们能够解决这个“进行中”的工作问题。按照对业务的价值划分项目优先等级，列出项目必须完成的步骤，以及限制“正在进行中”的工作量。只有在当前的工作完成后，团队才能接新的工作。一转眼，项目交付变成可预测了，我们只构建最具有业务价值的部分。我们已经解决了我们的问题，对吗？答案当然是否定的。

成为敏捷企业

市场每天千变万化，新的客户需求层出不穷。一家公司的生存有赖于能够定期、以较低的成本改变项目组合，以紧追新的业务变化。想要缩短企业选择最佳方案的时间，并不断交付予客户，我们就需要解决战略与团队工作之间的脱节问题。

答案就是细分举措，让团队与不断变化的优先重点保持一致、自动化进度报告和选择能够推动持续改善的指标。其中的核心就在于季度小组计划活动Big Room Planning，它让团队和领导共同构建每个人可以交付的共享、可实现的发布计划。由现在开始，每个团队的工作与战略变化将会保持一致，Scrum团队可以“查看”以了解他们正在建模背后依据的基本原理，以及他们的工作如何推动公司战略的实施。但是，我们还需要具备另外一个条件。

培养企业的敏捷文化

一个敏捷企业必须深谙只有将战略、能力及文化结合起来，才能实现真正的机构转变。文化产生于人们的互动方式，因此我们寻求能够促进不断学习和改进的互动，而回顾和良好的绩效指标能派上用场。

最后，我们不应只是“做敏捷”，更应真正“变敏捷”（being Agile）。我们已具备所有解决重大问题所需的一切条件：包括出色的团队执行、按价值划分的优先等级、从战略到执行的连接，以及满足我们协调、沟通和改进文化需要的平台。我们应专注于为客户创优增值，而非只是创建过程。我们已经弥补组织中的缺口，现在我们可以积极引导我们的公司响应市场变化，真正成为一个敏捷企业。endprint