曾在许多软件工程师眼中闪耀光彩的敏捷方法已经黯然失色。甚至,人们一遇到某些障碍就可能对敏捷冷嘲热讽。在这篇文章中,我们来回顾一下可能成为团队在敏捷道路上绊脚石的 5 种障碍,顺序不分先后:


  1. 单一领导
  2. 团队凝聚力差
  3. 缺乏冗余
  4. 学习文化不足
  5. 团队自主性低

1、单一领导

换句话说就是只有一个人铺路,其他人只会跟随

原因


  • 对团队有直接管理权的人无视敏捷的关键原则——团队自我管理(或至少是自组织)
  • 一种错误的观念:认为团队遵循敏捷流程(例如 sprint backlog 和 sprint review)的同时不改变原有的组织结构,也能让敏捷行之有效

最有可能出现这种情况的环境


  1. 传统行业中的组织,例如印刷出版公司
  2. 存在“经理”的传统权力分层结构
  3. 组织不像科技公司那样深度接触敏捷理念和实践

如何打破这个障碍

鼓励所有人参与分布式权力结构,例如:


  • 创建和维护一个共享的心智模型,例如团队章程、愿景声明
  • 共同决定组织需要做什么事情,以及如何做到它们
  • 跟踪进度以确保生产力,提供所需的输出

成功打破障碍、实现敏捷后,可以看到这样的成果……

大家会共聚一堂,共同就团队实现或超越其 SLO 的具体方式创建相应的协议,达成共识。

2、团队凝聚力差

换句话说:团队没有形成一个有凝聚力的组织,而是各自为战

原因


  • 个体将自己的目标置于团队需求之上
  • 不同团队成员就团队该如何完成工作的问题存在冲突
  • 团队中的工程师没有发自内心产生的团队合作动机

最有可能出现这种情况的环境


  • 团队中的许多成员是在不同时间加入进来的,没有和其他人“打成一片”
  • 牛仔开发者文化,每个人都优先在为自己考虑

如何打破这个障碍


  • 让每个人都负起团队合作的责任,例如为团队 OKR 做出贡献
  • 鼓励团队成员以建设性的方式评论彼此的工作
  • 每日 scrum 或站会之外再举办一些定期社交聚会

成功打破障碍、实现敏捷后,可以看到这样的成果……

整个团队会作为一个整体 SLO 目标,获得整体奖励,而并不会过分强调个体表现。在团队内部,成员之间依旧可以排定荣誉级别,但外在的奖励(来自上级和外部)总是属于团队整体的。

3、缺乏冗余

换句话说:团队人手不足时没有后备力量

原因


  • 每个人都被要求留在自己的车道上,或者他们自己就更愿意这么做
  • 成员职责被细分到非常具体的级别

最有可能出现这种情况的环境

其实很多时候都会有这种情况发生,没有特别突出的场景

如何打破这个障碍


  • 举办交叉培训课程,向更有经验的队友学习
  • 实施相邻角色的工作轮换(例如,每个团队成员应将 10%的工作时间花在非核心活动上)
  • 在日常 scrum 中促进相关角色之间的交流,鼓励他们互相帮助
  • 重复的角色(即 2 个或更多具有相同职责的成员)安排也是可行的,但这里也有风险,因为在没有设置常规任务边界时人们很容易干扰相同岗位的同事的工作

成功打破障碍、实现敏捷后,可以看到这样的成果……

一名混沌工程师突然离开了公司,剩下的成员平稳接手工作。他们有一些混沌实践的经验,并主动向其他团队寻求帮助。他们在下一个 sprint 中调整了工作负载,以将认知负荷保持在合理的水平上。

4、薄弱的学习文化

换句话说:不要重新发明轮子,只把工作做好就行了

原因


  • 每个人都急着把事情做完,然后赶快回家
  • 除了 sprint 结束时的强制性要求之外,敏捷流程中没有任何学习环节

最有可能出现这种情况的环境


  • 有的团队习惯了雇佣“专家”,这些专家认为自己已经了解世界的运转方式,并没有持续学习和改进的动力和欲望
  • 领导层认为 AAR 和事后分析并不重要

如何打破这个障碍


  • 分享在受人尊敬的公司中失败的故事来吓唬团队
  • 建议在突发事件后增加深度学习课程
  • 使用微学习工具,可在对认知负荷影响最小的前提下分享改进想法

成功打破障碍、实现敏捷后,可以看到这样的成果……

每个团队成员都在努力寻找和分享关于如何改进事件分析任务的想法。当团队聚在一起讨论事件时,这是很有用的。

5、团队自治度低下

换句话说:团队没有独立充分发挥实力的空间

原因


  • 其他团队使用更大的政治影响力来让本团队成员分心
  • 外部利益相关者(如 2 级经理)会干预团队任务的完成方式

最有可能出现这种情况的环境


  • 资源有限,高度政治化的公司
  • 组织有着希望保持控制权的老派管理层

如何打破这个障碍


  • 努力提高团队的知名度,例如“这项<工作>就是你们需要我们的原因所在”
  • Scrum Master 把外部人员的要求都转给产品负责人,不去打扰团队成员
  • 为外部人员设置在办公时间举行的预约会议(因为他们想要开会)

成功打破障碍、实现敏捷后,可以看到这样的成果……

团队专注于目标 MTTR 上,不会浪费时间去开一个个解释说明会议,或被其他官僚作风影响

再加一个障碍:敏捷不会增加价值

换句话说:你的工作实际上并不需要敏捷

原因

高管喜欢跟风,想要效仿 Atlassian/Spotify/x 等敏捷组织的成功经历——“他们的市值比我们高很多,所以我们应该学习他们才对,”或许某家银行的经理会这么说。

最有可能出现这种情况的环境


  • 你所在的空间中实现价值所需的输入是已知且明确的
  • 一切工作都可以按照操作手册完成
  • 工作要么简单,要么步骤多,但并不算复杂。例如根据蓝图组装发动机的工厂(步骤多)与设计发动机的工厂(复杂)是不一样的,

如何打破这个障碍


  • 改为实施精益实践——这些实践更适合在更常规的流程中实现卓越运营
  • 取出看板以更好地跟踪工作

- END -


敏捷道路上的五大障碍_团队合作