本文是Toptal敏捷扩展系列的第三部分, 设计用于指导项目经理进行团队扩展工作. 一定要读第一部分。”5个敏捷扩展框架的比较:你应该使用哪一个?“第二部分，”敏捷扩展:Scrum大师的安全最佳实践.”

敏捷以某种方式被实践 94%的公司，根据… 第15届敏捷年度报告. 但研究也表明 90%的组织 与企业范围内的敏捷实现斗争. 一般来说，这是 敏捷教练, Scrum master，及其他 项目管理专业人员 领导和组织这些工作. 经常, 他们与抵制变革的团队或部门合作, 在一个难以理解的公司文化中.

在这个圆桌会议中，三位Toptal项目经理讨论了挑战 领导敏捷转型. 因为他们的解决方案符合规模化敏捷框架(安全)，我们也与他们进行了交谈 Leffingwell院长， 安全的创造者. 他们的集体见解说明了 安全从业人员 准备一个清晰的愿景，了解什么是敏捷性，并制定一个领导计划，让不听话的团队加入进来.

与框架的创建者讨论安全问题

安全的, 由规模化敏捷正式确定的框架这一事件仅发生在2014年. 但对于Leffingwell来说，工作从他第一次遇到 敏捷团队 在21世纪初. 作为一名软件开发方法学家，他对 敏捷实践 关于开发团队, 他立即开始探索如何将这种思维方式应用到整个公司. 如果一个敏捷团队可以产生结果，那么一个由敏捷团队组成的团队又能产生什么呢? 如何将敏捷实践用于国内或国际公司的全面转型项目? 正如Leffingwell所说，“我热爱软件开发. 我爱敏捷. 我只是想要 big.”

从那以后的几年里，公司已经认识到 外管局的好处, 包括缩短交货时间, 更高的产品质量, 更高的效率, 更敬业的员工. 截至2021年， 超过三分之一 世界上许多组织都使用安全, 其中最重要的方面是它提供的共享过程和统一语言. 例如, 如果一个团队认为冲刺是两周，而另一个团队认为是30天, 它造成了Leffingwell所说的“巴别塔问题”.如果团队不能就“功能”的含义达成一致，他们就很难讨论要添加什么功能. 他说:“如果你想建立一个大的解决方案，你(需要)人们以一种共同的方式工作。. “在我们的行业中，没有一个术语不是超负荷的，比如‘迭代’、‘冲刺’或‘积压’.如果你想跨团队、跨地区工作，这是没有帮助的.”

敏捷成功案例

让公司里的每个人都采用统一的方式来谈论和做工作是一项艰巨的任务，即使在迫切需要改变的情况下也是如此. 在成熟的公司，这可能更难. Leffingwell解释道:“你看到的是世界上最大的公司，它们赚了很多钱，做得非常好，而且很有竞争力——他们必须改变. 对他们来说，问题是他们为什么要?这里介绍的Toptal项目经理在他们自己的扩展活动中都遇到过这样的问题, 并且每个人都找到了自己使用安全进行敏捷转换的方法.

展示价值

Alvaro Villena, 在圣地亚哥担任Toptal项目经理, 智利, 最近完成了一个开发跨业务平台的投资组合的安全转换. “我过渡的第一个里程碑是领导一个 价值流工作坊他说。. 简单来说, 价值流研讨会是确定从概念到交付以及所有步骤的整个业务流程的启动会议, 用户, 系统, 以及中间的痛点.

让整个企业的代表参加研讨会，帮助维莱纳了解了公司文化，以及他的障碍是什么. “在我们实施研讨会之前, 有一种结构，一个企业有自己的团队, 另一家公司有自己的团队, 下一个业务是他们的团队——三个人互不交谈.”

Villena发现，尽管所有的团队都有相似的痛点, 在解决方案上没有合作. 例如, 尽管投资组合中的每个业务都有产品, 只有一家公司开发了追踪系统. 他们没有理由不能都使用它，除非没有人分享这些知识. 有一次研讨会让他们开始说话, 知识开始在团队之间流动, 企业, 产品负责人. “这样的对话对这个项目来说真的非常有影响力. 这是一个很好的起点，”维莱纳说. 当DevOps, 设计, 产品都知道其他团队在做什么, 他们看到公司里有他们可以使用的解决方案. “他们开始问，‘我怎么能得到那个?’这时你就应该介入并说，‘按照这个流程来.’”

“在知道原因之前，没有人想要改变. 所以你要从为什么开始，给他们一个更好的未来.”Leffingwell院长, 安全的创造者

Leffingwell知道团队有时会抵抗. “没有人想要改变，直到他们知道为什么，”他告诉Toptal. 所以你要从为什么开始，给他们一个更好的未来.“让团队了解他们的效率可以提高多少，是变革领导的有力工具.

即使每个人都热情地参与进来，你也应该预料到起步会遇到困难. 习惯了传统的瀑布式开发和大型发布的团队, 例如, 可能很难转移到更迭代的和 敏捷开发过程即使他们看到了其中的价值. “我们做的第一个项目增量对团队来说是一场灾难，”Villena说. “And we knew it would be; we told the client to expect that the first three months may be difficult.“为了弥补这一点, 他在第一个程序增量(PI)结束时构建了一个为期一周的一次性迭代，团队可以在其中评估他们的进度. 他组织了一个sprint，专门用于流程改进和评估，这将超出通常的范围 检查和适应. 他发现应用程序很有用 敏捷的思维 不仅是产品，还有业务转型, 花点时间退后一步, 看看什么有用，什么没用, 并进行相应调整.

创造小胜利

在采用安全的过程中，为意想不到的障碍做好准备是很重要的. 几年前，Toptal项目经理 Miroslav Anicin 当时，在塞尔维亚的贝尔格莱德，一家电信公司正在向外管局转型. 公司把所有的软件开发都外包出去了. 组建一个非现场团队并不是一项特别繁重的任务——所涉及的问题主要是后勤方面的. 但这一努力给公司本身的转型带来了无法预料的挑战. “我一直在寻找我们需要的能力 释放的火车他说。. “我要选择的所有人都来自营销部门, 从法律, 从产品, 完全缺乏敏捷思维，甚至没有任何敏捷经验.”

很明显，管理层没有处理敏捷团队的经验. 分布式决策要求管理者 放弃一些控制权如果领导层没有敏捷框架的经验，他们可能会回避这一事实. 为了解决这个问题, 阿尼辛必须从下到上和从上到下进行训练, 指导领导者及其团队.

这种向更分散决策的转变需要“改变从命令和控制的工作方式”, 通过仆人式的领导风格, 这种学习文化和敏捷文化，以及容忍错误的能力,Leffingwell说.

Anicin开始了一个循序渐进的过程 敏捷项目 在单个团队中执行, 而不是在安全框架内——这样每个团队就可以获得一些实际的经验. 这些项目必须是不必要的，并且足够小，这样在第一次尝试中出现问题时不会对公司造成伤害，但又足够有用，可以向团队展示使用这种方法可以完成什么. 例如，营销团队创建了一个 内部营销活动在此期间，Anicin教授了他们Scrum的基础知识. 类似于Villena的工作室, 这些较小的项目展示了敏捷的实际价值, 因此，团队成员和领导可以在全面转换之前看到短版本和持续改进的好处.

满足团队的需求

当 Imane马, Toptal在巴黎的项目经理, 领导了一个大型的转型, 跨国金融机构, 她进入了一个混乱的环境，在那里，每个团队都有扎实的工作，但却没有共同的公司愿景. “每个团队都有自己的优先事项. 每个产品经理都希望自己的产品先交付.”

外管局对这个问题的解决方案可以在 加权最短作业优先 (WSJF)模型. WSJF提供了一个标准，用于确定工作的优先级，以便何时决定下一个任务应该是什么, 第一步不涉及对重要性排序的争论. 在基于流的 敏捷系统, 你不需要担心一次交付所有的东西，因为, 正如Leffingwell所说, “最重要的是接下来做什么工作. 这个问题比什么是最有价值的工作更容易回答.“安全提供了一种解决团队之间依赖关系的方法——排序任务对实现这一结果至关重要.

Marouane解决依赖关系的路径变得不确定:“在两次冲刺之后, 在第一次检查和适应之前, 我们注意到一些团队没有遵循我们的PI计划.“没有遵循PI计划中定义的依赖关系, 所以一个团队的工作无法开始，因为另一个团队的贡献还没有准备好.

“因为这是第一次迭代, 这些团队还不习惯这种工作, 我们决定增加一个额外的仪式——每周开会讨论依赖关系的进展,Marouane说. “每个团队都有一个人来更新他们的贡献进展.“这边走, 如果A队说他们无法交付, 团队B可以提前知道并制定相应的计划, 而不是等待那些不会在sprint开始时实现的贡献.

Leffingwell在对外管局进行此类调整时告诫大家要谨慎:“外管局是一个责任体系. 你可以适应它，但你必须非常小心.“尽管框架旨在具有适应性，但如果不重新评估，变化往往会被消化. 的 必要的安全 存在配置以确保任何更改都符合基本标准.

Marouane的额外仪式在第二部PI中再次出现, 到了第三年，它已经被淘汰了. 团队没有什么要报告的，因为他们已经沟通过了. 额外的一点灵活性使Marouane能够让团队回到更传统的流程轨道上. 她发现，转型本身需要敏捷思维，才能最大限度地发挥金融机构团队的作用. 而且重要的是, 她所做的改变, 通过对持续改进的承诺, 最终服务于作为必要的安全基础的精益-敏捷原则. 她的解决方案为公司提供了它所缺乏的统一愿景，并允许团队朝着相同的优先级共同努力.

适应未来

任何大规模运行的框架都将面临挑战. 活动的部分和相互竞争的利益是巨大的. 但回报同样巨大, 一个执行良好的过渡将为团队提供他们朝着共同目标工作所需的工具. 在如此大规模的实施中，您所面临的障碍将是不可预测的, 敏捷思维帮助了Villena, Anicin, 和Marouane适应意想不到的挑战. 毕竟, 这就是持续交付的目的:用工具赋予您的过程以适应不可预见的情况.

规模化敏捷也适应于 新技术 和不断发展 行业标准，在必要时引入新的工具和功能. 每个人都需要保持敏捷，为意外做好准备. “我们没有水晶球，”Leffingwell说. “我们只要跑得快，努力领导，努力跟随，尽可能快地写作.”