制造软件而非战争 | 组织中敏捷与瀑布相遇

你正在以某种身份领导敏捷软件交付团队——可能是Scrum Master、产品负责人或经理。你的团队一直努力与敏捷宣言保持一致,并且你为他们定期构建和发布软件的能力感到自豪,敏捷 vs 瀑布
内容来源:敏捷进化之旅、优普丰数字化转型业务敏捷创新 
作者:Erkan Kadir
翻译:Lance Zhang

前言介绍

你正在以某种身份领导敏捷软件交付团队——可能是Scrum Master、产品负责人或经理。你的团队一直努力与敏捷宣言保持一致,并且你为他们定期构建和发布软件的能力感到自豪。你深信,由于你的团队有能力比以前更快地学习和适应快速变化的市场环境,你的业务会变得越来越好。不幸的是,随着敏捷与公司现状之间的差异越来越明显,你的工作也变得越来越具有挑战性。你的团队越敏捷,你就越容易与组织的其他部分产生摩擦。
例如,当产品团队要求你对年度路线图做出承诺时,你会非常抗拒,因为你看重响应变化而不是遵循计划。销售团队对你的团队快速转换的做法很不满意,因为他们是遵循年度路线图来完成交易。架构师感到被排斥,因为你相信最好的架构涌现于自组织的团队。干系人对于不断变化的里程碑感到沮丧。高管们认为你的团队无法达成承诺,并要求你提供更大的可预测性。
你意识到你正在跨越两个非常不同的世界的边缘,为了适应,你开始以稍微不同的方式来对待两个不同的世界。针对不同的受众,你的用词会发生变化——对工程师们,你会用“故事点”和“探针”,而对业务团队,你会用“T恤大小”和“项目交付日期”。你在团队中使用敏捷原则,然后将团队的估算作为基础,向业务团队做出长期的承诺。当项目计划需要变更时,告诉业务团队你无法实现那些承诺,这会使一个痛苦的对话。你的团队运作在一套完全不同于其他人的价值观、语言和期望之下,误解、消极攻击行为和全面战争比比皆是。
如果这听起来很熟悉,那么你可能正处于战争地带——每个组织中敏捷与瀑布相遇的地方。如果不加以控制,战争区域会变得更加激烈,并威胁到你的组织的成功,然而有一些策略可能会有所帮助。

方法上的根本差别

组织中的敏捷和非敏捷部分都怀着良好的意图启动新的计划,并一致同意要在规定的时间范围内达成共同的目标。不幸的是,由于新产品开发的不可预测性,敏捷人员和非敏捷人员都无法找到确保按时交付的方法。由于这两方对于如何应对不可避免的日程变化的方法存在根本性的差异,因此产生了战争地带。
一方面,敏捷人员遵循敏捷宣言所展示的价值观和原则。他们坚信环境和技术是不可预测的,所以他们尽量减少减少计划活动,并允许通过快速实验来产生解决方案。当某个里程碑明显无法达成时,敏捷人员的反应是在约定的日期前,通过推迟价值较低的产品特性,尽可能多地解决潜在的业务问题。敏捷人员随时进行内建质量和集成工作,这使得他们可以在任何时候交付任何他们已经准备好的价值。他们抵制试图通过增加人员来加快速度的尝试,因为他们认为往一个已经延迟了的软件项目中增加人员只会造成更大的延迟。
而在另一方面,我们有那些受传统项目管理原则(典型的瀑布方法)所指导的人。这些人通过控制环境以及尽可能多的变量来降低风险。他们重视能够分析和规划单个最优解决方案的专业能力。他们认为将工作批量化,所有计划的产品特性都在项目最后进行集成和测试,是效率最高的方法。在这种孤注一掷的方法中,放弃一些特性以便回到正轨上通常是不可取的。因此,瀑布实践者会将精力集中于通过向项目中添加人员以达到加速的目的,或推迟项目交付日期。

每个组织都必须在战争地带中航行

Version One最新的敏捷状态报告显示,全球97%的软件公司采用敏捷方法,其中84%的公司仍处于或低于“仍在成熟”的水平。换句话说,敏捷和瀑布的混合是一种常态,我们可以期望在世界上几乎所有的软件公司中找到战争地带。

一个组织实施敏捷的时间长度可以很好地指示出哪里可能出现战争地带。例如,在基层采用敏捷时,几乎可以保证战争地带会很早就出现,因为除了工程部门之外,其他所有的部门都还不知道敏捷。即使在成熟的敏捷组织中,战争也会自然地爆发。例如,当命令和控制型领导被指派与敏捷团队一起工作,敏捷项目的交付是通过PMO来进行管理,或者组织对外销售尚不存在的产品时,战争地带就会出现。

高度一致的组织可能可以成功地将战争地带从他们的环境中完全消除,但他们会发现现在却存在于他们与客户或供应商之间,因为项目被期望在规定的时间范围内完全按照要求进行交付。

我们需要彼此

并没有哪种方法比另一种更好。敏捷方法和瀑布方法都适合解决特定的问题。敏捷实践适合解决具有高度不可预测性的问题,而瀑布则刚好相反。敏捷思维和瀑布方法对组织来说都是必要的,但是常常缺乏对于何时何地采用哪种方法的理解。误解导致对两种方法给组织带来的价值缺乏认知。赢得这场战争并不是非得一方支配另一方——敏捷和瀑布方法都将继续存在。学会如何平衡这两种方法,同时在各自的边界上发展强有力的关系的组织,可以最小化甚至消除战争地带。

制造软件而非战争

这里有一个六步框架,你可以用来重新控制你的战争地带。

1. 评估

在你的组织中,战争地带存在于哪里?——是垂直存在于组织各层级之间,还是水平存在于各部门之间?冲突有多严重?类似Speed Lee的5级冲突框架可以帮助你确定战争地带的严重程度。

2. 集合

将战争双方人们的观点集合起来,以便商谈和平条约。

3. 正常化

让双方知道每个组织都有战争地带,冲突是正常的。他们所经历的冲突是源于他们所拥有的不同技能,对于一个强大的组织来说,这些技能是有价值的且必要的。

4. 教育

你的组织和员工是有韧性的。一旦他们意识到了战争的存在,他们自然会选择一种更巧妙的互动方式。

让大家学习这两种方法的区别。

让双方开诚布公地讨论他们的价值观、信仰和期望。

让人们找到对方的价值所在,以及他们可能更喜欢对方的哪些技能。

展示战争所带来的成本。如果他们能把关注点放在竞争对手身上,而不是放在彼此身上,那他们可以做得有多好?

5. 和平谈判

为双方如何沟通制定一个计划,并将其记录下来,贴在显眼的地方作为提醒。它应该包括:一套双方都会使用的常用词汇。何时及多久传递一次状态信息。他们如何表示对于对方方法的尊重。

一个协商好的关于如何应对不可避免的计划变更时的策略。

6. 固化

利用一些支持的手段,如海报或便利贴,让人们记住他们想要与对方相处的方式。

在你的组织中,瀑布会在什么地方与敏捷相遇?冲突有多严重?对你的业务有什么影响?你又会怎么做呢?

留下评论

您的电子邮箱地址不会被公开。 必填项已用*标注