关于大规模敏捷，我们踩过的那些坑
著名的外科医生和作家 Maxwell Maltz 曾经说过。"仔细观察会发现，大多数'危机情况'都是让你要么前进，要么原地不动的机会"。我可以根据我自己的个人经验告诉大家，确实是这样的。
众所周知，在 2008 年金融市场崩溃之后，金融服务部门在 2009 年至 2016 年期间经历了一系列的监管。但可能不为人知的是，在此期间，一些监管措施在银行机构内相互竞争时间、注意力和资源。我在与一个 IT 团队合作担任顾问时，亲眼目睹了这些事情。
对我当时的客户公司来说，这完全是一个危机情况，我将称这个客户为 "X 银行"。在短短三个月内，监管的最后期限迫在眉睫，很多工作仍未完成。这个最后期限是不可动摇的，而且对X 银行来说，风险是最大的：他们的声誉取决于是否遵守这些新法规（更不用说对不遵守规定的罚款了）。为了完成未完成的工作，X 银行启动了应急管理程序。
一个由十个人组成的 "行动小组 "走到了一起，我是这个小组的一员。我们的任务是整合各个孤立的团队的工作，试图建立一个监管报告解决方案，并在银行业务中推广该解决方案。这个团队是由 X银行的员工、顾问和供应商代表组成的。团队成员有明显不同的背景和资历，这被证明是有益的（下文将详细介绍）。
那时，人们简单地称这为 "危机管理"。但在协作努力下，我们确实达到了最意想不到的结果，即成功完成了任务！我们处理这种情况经验，在企业级敏捷性和扩展变化方面给我上了最重要的一课。这也是我第一次体验到真正的 Gemba。
Gemba (现场) n. - 一个日语术语，意思是 "实际的地方"。在精益方法论中，Gemba 指的是创造价值的地方。这可能是工厂的车间，餐厅的厨房，或者办公室。
今天，扩展敏捷的框架无疑要进化得多，多年来我也有过其他的经历。但我一直在反思 X 银行这个案例，因为它一直是一段无可匹敌的学习经历。以下是我从中得到的收获。
1.当你需要做出彻底的改变时，紧迫感很重要
在 X 银行，当时的情况需要一种紧迫感，这让我们在事情发展过程中都很紧张，但最终证明是有帮助的。不幸的是，在非紧急情况下推动重大变革时，人们往往忽视了紧迫感的重要性。我经常和一些沮丧的客户打交道，他们一直在运行多年的敏捷转型项目，却没有实质性的成果。他们应该创造一种可以像野火一样传播的紧迫感，而不是仅仅依靠可能需要数年才能实现的渐进式变化。
紧迫感可以来自外部或内部的力量，但外部的力量更强大。比如说。
市场变化--就 X 银行而言，是监管的最后期限。
COVID-19（或其他长期的全球事件）--正如我们目前所看到的，公司希望比以往更加灵活，以便他们能够驾驭不断变化的环境。
破坏性创新--这可以是来自公司内部的，也可以是来自竞争对手。
用精益的说法，所有这些都导致了 kaikaku（或 "kaizen blitz"），这是 kaizen 的一个较不知名的表亲。Kaikaku 是关于彻底的改变。这并不一定意味着 Kaizen（增量和持续改进）不那么重要。但在策划组织变革的背景下，kaikaku 更有效率。它就像被空运到200英里外的目的地，而不是试图步行到达那里。换句话说，一个人为另一个人创造了一条道路。首先是 Kaikaku，然后是 Kaizen。
将事件或其他重新设定的点（例如，异地会议、季度末）纳入到工作节奏中。朝着这些方向前进将有助于引出正确的行为，并使彻底的改变更容易实现。
2.敏捷性需要对运营模式进行全面的改变
许多组织都在使用一些主流的框架，如 SAFe 或 S@S 或 LeSS。但是，在组织的其他部分，任何矛盾或不匹配的操作程序(和/或文化)都可能导致无法有效地扩展敏捷。因此，我们不能仅仅通过使用主流的框架来扩展组织的敏捷性，而不对公司的实际运作方式进行全面的改变。
在 X 银行的案例中，监管合规举措涉及到业务的各个方面。这意味着必须对整个价值链进行分析。团队中的专家追踪了每一种产品和服务，以绘制出每一个价值流。这种可视化是找到所有我们必须改变流程以满足新法规的地方的关键。因此，我们组织了拥有不同背景人员的团队，开始整合和测试更新的流程步骤。这在很短的时间内形成了组织的敏捷性。
敏捷性要求对运营原则进行整体变革，通过调整团队、流程和治理来优化价值流。
3.精益预算有很大的不同
在过去，企业按年度将预算与 "成本中心 "挂钩。但我们今天知道，将预算与价值流挂钩，更有利于创造敏捷性。尽管如此，绝大多数企业仍在使用传统的预算和会计方法，这对敏捷性增加了很大的限制。
在 X 银行，业务发起人在危机期间将预算所有权暂时移交给执行组织，从而有可能根据计划→执行→检查→行动（PDCA）原则反复调整资金。有趣的是，在如何使用资金方面没有任何限制——我们只是对资金的使用有了更大的责任。
无可否认，X 银行确实使用了基于成本中心的对账方式，这导致了实施后对成本中心交叉收费的恶梦。但是，这些经验仍然是有效的：高度的开放性和适应性会帮助增强敏捷的交付。
对于大多数 IT 团队来说，预算是实现完全敏捷的一个主要制约因素。按周期为价值流提供资金可以最大限度地减少这种限制。会计实践需要根据价值流的长期转型路线图来调整 Capex 与 Opex 的定义。
4.敏捷实践可以（也应该）扩展到整个供应链
X 银行所做的最好的事情之一是与供应商建立公开对话。以共同的价值观、标准和方法为基础的非正式社区方法建立了融洽的关系，以至于在危机中大家可以相互依赖。
否则，在不影响敏捷实践的情况下与供应商合作，对许多公司来说是一个重大挑战。首先，采购过程是出了名的官僚主义。此外，供应商可以有自己的做法和标准，这可能是明显不同的。他们可能不想每天都进行合作，而只想交付成品。
促进与供应商组织的开放文化和共享价值观，可以在整个供应链中创造无缝的敏捷性。社区意识在创造文化转变方面大有帮助。
5.设计思维与精益方法一起助力有效扩展
在 X 银行计划的时候，扩展敏捷的挑战是众所周知的。但诸如 SAFe、DaD、Scrum@Scale 和 LeSS 等框架还没有完全发展起来。相反，我们的团队采用了用户体验（UX）设计的最佳实践来确定角色和用户旅程。我们的工作受到了 Eric Rees 所倡导的精益创业方法的影响。
主要重点是重新定义 MVP（最小可行产品），以满足审计师在监管期限内的要求。范围以同心圆的形式体现出来，内部圆表示待办事项的核心部分。缩放方法基于经典的构建→测量→学习反馈循环，这很快让我们进入了一个可以自信地加速努力的阶段。
客户体验和设计思维是新的热点（有充分的理由！）。当设计思维与精益方法结合使用时，扩大变革的规模变得更加有效。
6.“吃自家的狗粮”（软件公司使用自己生产的产品）真的有用
作为构建→测量→学习的一部分，X 银行的交付团队涉及关键的内部小组，主要是审计员。内部审计团队提供了重要的反馈，并帮助改进用户旅程。他们的参与也鼓励了各个业务领域更快地采用该产品。如果你想知道，当外部审计师第一次看到他们的时候，他们对工作的质量印象深刻。
即使是最好的团队也会在概念化与实际的用户行为之间挣扎，这导致了技术和功能上的债务。持续的 dogfooding 可以帮助你避免这种情况。
7.纵向切分的团队可以在整个过程中起到引领作用
敏捷从最早期就强调跨职能的团队。但是，我从 X 银行项目中学到的最重要的东西之一是纵向和横向划分团队的重要性。也就是说，不仅要有了解其工作职能所有细微差别的专家，还要有能帮助驾驭各种组织细微差别的团队高级领导人。
组织在其转型过程中，当他们的传统结构成为扩展的瓶颈时，就会达到一个点。垂直切分的跨职能团队可以加速扩展。