大多数组织会聘请敏捷教练进行整个组织的敏捷转型。这么做,是希望在教练完成工作后,组织能变得高效并健康。但是,如果这种转型只从团队级别上开始,很难 实现转型,也就无法提升可持续的、端对端的交付过程。
敏捷教练分享了他们对组织转型过程中所犯错误的看法。 Dave Nicolette 把这类问题归结为两种元失效模式(meta failure modes)。
一种是 **“敏捷社区问题”——过分注重团队的单独性、软件和测试的准则,过分关注于帮助团队提高。大多数教练被聘请来帮助团队,而不是把重点放在组织上。另一种元问题是“不是我们的错”**。
我观察到一个普遍的趋势,那就是管理层喜欢把灭火剂直接往他们过程中冒出“烟雾”的地方倾倒,而不是先去找出火焰的位置。由于传统组织的特点(除了别的以外)是互相推卸责任以及信息隐藏,任何交付过程中的问题会在下游分流,而且在此过程中,所有指定时间点的度量报告都会经过“美化”处理。在交付过程结束前,记分卡看起来总是很漂亮的。
Dave 提到,团队可能并不是启动改善过程的最佳地点。应该允许教练们自己去做调查,找出组织转型过程中最薄弱的环节,他们应该着手解决那些问题。
Rob Myers 提出了一份陷阱清单,在转型过程的初期就可以识别出来。Rob 建议把“尽早培养领导团队”作为最关键的前期工作。
根据Rob 的说法,在整个转型过程开始前,管理层应该先接受敏捷培训,以便他们了解敏捷团队会如何工作,并理解“仆人式领导力”及“自组织团队”背后的真正思想。 Jean Tabaka 也把这看作是严重的转型失败。她认为:
那种宣布“我们将采用敏捷”,但又不提供丰富的资源、承诺,不乐意修改成功标准的管理人员,只会削弱团队的士气。成功地采用敏捷与发起者从始至终的热情参与有着紧密关系。
Rob 进一步为转向敏捷的组织提出以下建议:
- 让教练提供培训——不要马上就要求商品化,让教练采用其久经考验的方法。
- 让教练与团队交互——团队总会有一些最后期限。这不应该妨碍教练。
- 不要微观管理工作量——时间不等于生产力,尤其涉及需要创造力和思考的工作时。(软件开发跟敏捷教练一样,需要二者兼备。)
- 没有丰富的反馈就不要定义过程——许多组织会因为听说过或阅读过一本书就去定义一套流程。这未必最适合他们的实际情况。
因此,组织有很多东西需要铭记在心。但是,有时候敏捷教练也会犯错。 Lyssa Adkins 给出了一份有趣的清单,7 种性格的教练会在转型过程中产生问题。她的清单中,以下类型的敏捷教练会导致转型失败。
- 间谍型——只花少量时间观察团队,只参加回顾会议。
- 海鸥型——突然参加一些会议,然后又走了。
- 固执己见型——固守自己的意见,导致团队失去讨论的兴趣。
- 行政型——成为一个不必要的中间人,做会议后勤和其他行政工作。
- 中心型——扮演起团队成员间进行沟通的中心。
- 蝴蝶型——适应不同的团队,但不够专注。
- 专家型——非常喜欢面向细节,但却抓不住大局。
因此,组织和教练都迫切需要谨慎从事。关键在于要超越试点团队,把组织作为一个整体看待。就像 Dave 总结的:
我们应该停止把团队从救援直升机上迫降到机能异常的海洋中,不要因为在一些会议室 _ 兼 _ 团队室的墙上粘帖了一些故事卡,就预期会发生重大的、持续的组织变革。呆子,那不会发生的。
评论