可悲的现实是,尽管意图很好,但大多数敏捷转换都失败了。失败是指它们被取消,撤销或未能达到预期的结果。

显而易见,敏捷转换成功与敏捷项目成功不同。敏捷的成功率往往比传统方法高得多,并且有很多数据点可以证明这一点。不幸的是,关于敏捷转型成功的可用数据很少。

我的确发现,参加我的培训班的大多数学员都属于尝试过某种转型的组织。他们中的大多数人报告说成功有限,而且在许多情况下完全颠覆了敏捷计划。

敏捷转型是主要的变革计划,代表着风险。根据我对各种转换的观察,让我们探究这些敏捷转换失败的一些原因。

#1 –敏捷转换因时间过长而失败

我认为敏捷转换失败的主要原因是它们需要很长时间。作为人类,在过去的五到十年中,我们对事物的期望发生了巨大变化。

今天,我们立即期待着一切。亚马逊现在将在两个小时或更短的时间内将几乎所有东西(包括食品杂货)运送到我家。我们已经适应了近乎即时的满足,而我们正在失去延缓满足的能力。

在组织中,高管人员的短期任期以及对短期结果的近视关注加剧了想要即时结果的挑战。首席信息官的平均任期约为四年。无需花费很多时间进行深刻而持久的改变,例如转变为敏捷。高管们发现,他们需要扎扎实实地工作并快速交付成果。大多数人没有耐心或时间来进行敏捷转换。

组织中真正的敏捷转型绝非快速。对于所有组织而言,变革都需要时间。大多数人认为这需要三到五年的时间。对于大多数高管而言,这是遥不可及的。

一旦将重点转移到另一个闪亮的对象上,或者敏捷冠军离开了组织,这些开始的变革很可能会在中期停止。

#2 –敏捷转型仅限于流程变更

许多人将敏捷视为运行项目的另一种方法。他们将其视为工具包中的另一工具,与传统的项目管理实践(如《项目管理知识体系指南》(PMBOK®指南)中所述的方法一样)。

以金融科技巨头ING为例。它在2011年对敏捷开发流程进行了巨额投资,然后进一步投资DevOps。

多年后,它认识到它没有得到好处,因为它没有从根本上改变组织结构以及与内部业务客户的关系。它只是简单地将敏捷添加到现有组织上。

#3 –缺乏行政领导

敏捷转型失败的另一个常见原因是缺乏领导支持。当在部门,项目或团队级别进行自下而上的努力时,通常会发生这种情况。

最初,敏捷对于该部门或业务部门可能做得很好,因此领导者同意“敏捷”,然后坐下来等待。也就是说,他们容忍敏捷的工作方式。

自下而上的方法使我想起了一堆在客厅里建帐篷堡垒的孩子。他们玩得很开心,他们相信父母会让他们永远留下来。当父母想把客厅放回原定的样子时,他们有些震惊。

像父母一样,管理者和领导者可能会容忍不同的事情,但是只能忍受这么长时间。一旦遇到麻烦(根据Satir变更流程模型,就会有问题,请参见下图),他们将更改当前sprint的优先级,要求团队成员从事特殊项目,要求制定MS项目进度表或采取其他措施破坏敏捷转型。

#4缺乏敏捷理解

前两项的根本原因可能是缺乏对敏捷含义的确切理解。

尽管敏捷软件开发已经存在了将近20年(Scrum和其他前辈甚至更长),但有些人并没有花时间真正地理解它。

我一直都这样。当我拜访新客户时,他们总是告诉我,所有领导者都在公司工作,他们理解敏捷。

问题是,他们真的不明白!当然,有些人确实做到了,但是大多数人只是读到它,或者经历了一点都不敏捷的“敏捷”版本。

在可能的情况下,我会鼓励他们在告诉团队他们需要采用敏捷之前,了解敏捷的实际含义。

我经常不得不说服他们,对敏捷培训进行投资以建立一套通用的术语和理解是一个好主意。

#5 –复制他人而不是尝试和思考

大多数敏捷转换并不是凭空开始的。在大多数情况下,组织外部的人员会引入一套在其先前公司工作过的特定实践。

或者他们是教练,他们告诉组织最适合他们的。或者组织中的某人在Capital One或ING上阅读了有关转型的文章,或观看了Spotify视频;他们以此为蓝本进行转型。

敏捷最简单的形式就是思考,进行小型实验并不断改进。这是建立学习的力量。这与复制另一个组织所做的工作并将其实现为“货神教徒”无关。

这就是我坚持要我的客户发展自己的内部教练和冠军以帮助带领他们转型的原因之一。正是组织内的那些人可以帮助从内到外推动变革。像我这样的外部教练可以帮助启动变革,但是最接近工作的人需要拥有它,其中包括就转型做出明智的决定。

您对敏捷转型有何经验?希望本文对您以及敏捷转换失败的原因有所帮助。在我的相关文章“敏捷领导者如何在3个步骤中创建业务敏捷性”中,我们探讨了其他组织为取得成功所做的事情。

我非常想听听您关于敏捷转换的经验。如果您之前曾经参与过转型,或者目前正在参与转型,您学到了什么?我的观察是否高于目标?