敏捷试点团队初见成效,却为何离自组织却越来越远?

1 评论 3103 浏览 9 收藏 12 分钟

但凡谈起敏捷团队,我们总是会想到“自组织”这个概念。实施敏捷的团队,产品交付质量与效率都有大幅提升,但这样的团队就一定是“自组织”化的团队吗?

敏捷试点团队初见成效

先分享一个案例:某公司决定启动新项目,并尝试采用Scrum的流程来进行开发。

其中的Scrum Master职位由比较资深,且对敏捷开发有不错认知的原项目经理担任。

在推行了一段敏捷开发,经过几个Sprint之后,试点团队取得了初步的成功。产品交付效率和质量都有了大幅提升,团队成员对敏捷也有了比较高的认可,该项目最终的交付产品达成了预期目标。

公司管理层及团队成员都非常欣喜,有鉴于此,想要进一步扩大试点团队的规模及覆盖面,但是在该项目临近尾声的时候,却也冒出了一些不太好的苗头:

1. 每日站会,计划会议,验收会议,回顾会议等各种会议,如果Scrum Master不召集就不会召开。

一些团队成员由于前一天加班较晚,结果第二天发生了晚到的情况,当天的站会因为人员不齐就不了了之了。

这其中最明显的就是回顾会议,它已经变得越来越索然寡味,了无生趣,大家觉得各方面已经不错,没什么亟需迭代完善的。

随着项目的持续推进和深入,回顾会议的价值却在不断被弱化,没人觉得有何大碍,更没人站出来指出隐患。

加之担任Scrum Master的是项目经理,一旦他临时参与一些其他重要会议,与此发生时间冲突的敏捷各项会议,因团队内部无人张罗组织,自然也就不能按时召开。

2. 团队经常受到紧急需求困扰,导致迭代计划与交付难以展开。

很多时候,高管强行安排新需求,打断团队之前的开发节奏,经常能听到领导说这样的话:

这个新需求,已经答应客户了,所以需要紧急处理,要求一周后交付,其他的先暂停一下。

团队成员也从刚开始的抱怨,变成了习以为常,迭代计划和交付拖期时有时无的在发生,大家也都觉得很正常,没什么大惊小怪的,毕竟人家是高管,自己说再多也是白搭。

3. 团队中开发与测试位于不同的楼层,平时沟通都是用社交聊天软件,缺乏应有交流。

受制于社交聊天软件,开发与测试的同事线下面对面沟通的机会较为缺乏,充其量就是在每日各项敏捷会议时有些互动,但毕竟时间有限,项目同步性或多或少已经受到一些影响。

以上这些不太好的苗头,在很多敏捷团队都屡有发生,但是因为对最终的产品交付尚未造成比较大的影响,也就没人觉得要上纲上线,指责Scrum Master,或是团队其他成员的不是了。

可是究竟是出了什么问题,才会导致出现这些隐患呢?

我们的团队怎么了

乍一看,该公司的试点团队在敏捷推行方面已经初具成效,可是为什么仍然会冒出那些看起来不好的苗头?其症结就在于:团队的“自组织”出了问题,才造成虽然试点团队取得了初步成功,却离团队“自组织”越来越远。

为什么这么说呢?我们来看一篇堪称敏捷思想鼻祖的文章《The New New Product Development Game 》中是如何定义“自组织”的呢?

一个群体具备三个条件时拥有自组织能力:自治、自我超越、正向交互。在我们对多个新产品开发团队的研究中,都发现他们具备这三个条件。

而在案例中,领导直接命令,注重审核,是根据命令让团队执行的他组织下形成的习惯,这其实已经犯了团队“自治”的大忌。

在《The New New Product Development Game》中写到:

团队自治要求总部的参与仅限于在开端提供指导、金钱和道德支持。在日常的基准上,高层管理者很少介入,团队可以自由地设定自己的方向。

在某种程度上,高层管理者充当风险资本家。或者正如一位高管所说:“我们打开钱包,但保持闭上嘴巴。”

案例中,团队成员从起初的抱怨到习以为常,也是因为此前一直处于他组织的状态下,接受指令,按部就班的执行,从而形成了固有的行为和思维习惯。