HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

敏捷转型中管理层的认同和支持

  • 2014-02-11
  • 本文字数:3099 字

    阅读完需:约 10 分钟

敏捷转型是一种涉及管理层的组织级变革。我们常说管理层的认同对于敏捷是否能取得成功很关键,缺少管理层的支持,敏捷转型就可能会遇到巨大障碍。公司中管理层支持敏捷有很多不同的方法。

Arijit Sarbagna 在《规范的 Scrum( prescriptive Scrum )》一文中讨论了在敏捷转型过程中管理层的认同和支持的重要性:

假设我们正在以敏捷方式开发项目,最初采纳敏捷不是自上而下的,而是徒劳的“自下而上”。在这种情况下中,很可能我们就会错失了“管理层认同”这个关键因素。缺乏管理层的支持,打造自组织团队的良好意图很可能会走进死胡同。作为 ScrumMaster 或者敏捷教练,我们需要花费大部分的精力来说服管理层(或者客户),而不是实际上的指导团队。

根据 Arijit 的观点,对经理而言支持自组织团队非常困难:

(……)管理团队遭遇决策的困境,在团队成为“自组织团队”过程中应该留有多少回旋余地。这很搞笑方,我们不得不跟管理层解释敏捷是如何工作的,为了使敏捷有效,管理层应该相信敏捷。有时我们必须要提醒管理层,如果我们不信赖员工,即使瀑布式开发也不会成功。信任是成功的支柱,围绕着信任我们补充了工程实践。

Arijit 建议经理不应该强制实施 Scrum:

但是,如果我们正在处于规范化 Scrum 困境的话,比如很可能管理层会指导团队,敏捷应该怎么做(或不应该怎么做)——这些人可能从未实施过敏捷而只有理论知识——那么这只会让事情变得更糟,或者变成“失败的故事” 。

相反,Arijit 建议“宣扬和鼓励理解敏捷的人,从而拥抱实践”。

Zvonimir Križ写过一篇文章《亲爱的经理,我们已经敏捷了( dear management, we’re already agile )》,文中质疑缺少管理层的支持是否是采纳敏捷的真正障碍。这个问题可以理解为,当关注于实践而不是敏捷原则的时候,实施敏捷的唯一方法就是自上而下:

从诸如 Scrum 之类的实践直接开始敏捷可能使人们相信,敏捷“旅程”需要深层的组织变革。当然组织变革需要管理层的支持。另一个更有趣的原因是瀑布式开发本身。为了更加精确,瀑布式开发需要大量的前期规划(upfront planning)。这也是我们大脑中的一种思维惯性,为了成功,所有事情——包括敏捷转型——都应该详细规划。此外,管理层需要如此大量的前期规划和重大决策。

Arijit 建议敏捷转型还可以采用自下而上的方法:

有时候人们忘记了自下而上的敏捷转型是合理的。

每个人应该都知道采用敏捷原则不需要依赖管理层。(……)你可以现在就开始。不需要任何理由!

我们曾采访过 Jeff Sutherland ,他在《敏捷做了对的事,但方向却错误( agile done right and agile gone wrong )》一文中提到了领导力和团队。Jeff 在 Google Plus 上分享了这次采访,他提到管理层可以采取如下做法来支持敏捷:

这和管理层的认同无关。而是与敏捷管理层如何敏捷、领导以及展示变化相关。在某些大型公司内,会有由高级管理层组成的 Scrum 团队。他们不会赋予团队执行 Scrum 的权利,而是自己也在执行 Scrum,并且希望团队和他们一样执行 Scrum。

在敏捷转型过程中,中层管理者该如何支持呢?Em Campbell-Pretty 写了一篇文章描述这个问题《对敏捷教练与中层管理者沟通的建议( advice for agile coaches on “dealing with” middle management )》。文中说明了为什么管理层的认同如此重要:

和开发团队一起工作时,中层管理的认同非常关键。对于敏捷转型工作,中层管理者可以是良好的动力也可以是克星。如果团队认识到管理层不支持敏捷,那么在试验和冒失败风险的时候他们还会觉得安全吗?我曾见过有些组织尝试敏捷转型,而管理层仍然是传统思维。对于团队而言,这将是毁灭性的问题,如果团队相信敏捷的价值观如透明性,那么他们就会因为暴露事实而受到管理层的谴责。

针对如何解决来自中层管理者的阻力,Em Campbell-Pretty 给出了如下建议:

有些管理者慢慢发现敏捷对他们有威胁。实施敏捷很可能意味着改变,没有人喜欢改变。在这种情况下,或许可以考虑一下 Dennis Stevens 和 Mike Cottmeyer 的建议(Agile 2013 大会上的“不要谈论敏捷”),而不是迫使顽固的经理实施敏捷。相反,我们应该关注于业务目标,以及如何帮助管理层达到他们的目标或减轻他们的痛苦。

通常组织里的中层管理者也同样处于困境。根据 Em 的文章,敏捷教练应该负起责任,寻找方法和中层管理者一起工作并支持他们的工作:

中层管理者其实并不容易,实质上他们就像“三明治里的肉”,处于组织的高级管理者和普通业务人员之间。中层管理者的责任大于权利的情况司空见惯。这可能非常令人沮丧,并且让我怀疑命令与控制管理风格的盛行,是否是大型的官僚组织里中层管理者丧失权利的直接后果。中层管理者的注意力从组织繁文缛节的沮丧转移到改善员工的生活上,对于管理者和团队都是一种回报。不要忘记,中层管理者和其他人一样,倾向于能为我带来什么好处(WIFM——what’s in to for me)。中层管理者必须明白敏捷会如何帮助他们获得成功。

Mike McLaughlin 写了一篇题为《耐心的敏捷教练( the agile coach on patience )》的文章,文中他谈论了敏捷转型对于中层管理者的影响:

许多中层管理者在放手控制权上似乎都有一段困难时期。他们觉得还是需要插手。微观管理了许多年,可能有数十年,要想打破这些实践很困难。即使在团队授权的重要性方面中层管理接受过很多培训,但是在脑海里,他们仍然不确信团队是否可以完成工作,因此还是继续执行微观管理。

对中层管理者和团队而言,采取自组织也很困难:

(中层管理者)有效地阻止了团队发展成自管理、自组织的团队。结果就是,团队继续按照中层管理者的指导行事,或者得到授权才会做事。我把这个现象叫做中层管理者陷阱(Middle Manager Trap)。中层管理者继续制定决策,并一直质疑为什么敏捷团队不能自己负责任。这是一个恶性循环。

Mike 建议中层管理者可以展现对团队的信赖,并留给团队转变为自组织团队的时间,从而支持敏捷转型。

能够实现 180 度大转变(leap of faith)、信任、委派、耐心,实际上是一种对于他人的投资。对于一个新成立的敏捷团队来说,可能要花一段时间才能获得良好的投资回报(ROI——Return On Invest)。过了这段时间后,团队或个人可能还是比较纠结。偶尔的小错误是可以接受的。因为我们需要长远地考虑。

Brian Erwin 给领导敏捷转型的高管们写了一封公开信《致引领敏捷转型的管理层的公开信( an open letter to executives leading agile transformations )》。他建议管理层应该相信员工都很诚实,且能够努力工作,他还建议管理层可以通过环境来支持敏捷转型,从而帮助员工完成工作:

管理层需要打造一种组织环境,在这个环境下对于员工来说采纳敏捷的阻力最小,而不仅仅是采用和强制实施一些如 Scrum、极限编程或看板等敏捷方法。

Brian 的公开信里还包含了一套帮助高管打造环境的行动计划。其中一些建议如下:

在组织里开始展现你所期望的行为。造势最有效的方法之一就是先改变你自己和你的行为。实际上你不能强迫别人改变,但你可以鼓舞他们改变。(……)

不要在团队级别强制实施一种方法。不要强迫团队实施 Scrum 或其他方法框架,要把敏捷落地(……),通过移除组织障碍来提供和展现你个人的支持与承诺,还有你的立场。(……)

投桃报李。(……)如果你打造了一个环境,鼓舞员工奉献一切,视公司如家,并且通过投资员工展现出他们的价值的话,那么你的组织会有更大的可能性长期赢得市场。

原文英文链接: Management Buy-in and Support in Agile Adoption


感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-02-11 09:251799

评论

发布
暂无评论
发现更多内容

专科毕业,Android不好找工作的同学,你的问题在这里,android源码设计模式解析与实战

android 程序员 移动开发

为了KPI,对APK进行极限优化!,2021年Android春招面试经历

android 程序员 移动开发

毕业总结

Geek_35a345

产品级Flutter开源项目FunAndroid,Provider MVVM的最佳实践

android 程序员 移动开发

不明白四大组件底层的通信机制是怎样的?写给Android应用工程师的Binder原理剖析!

android 程序员 移动开发

互联网寒冬即将过去,Jetpack将是燃起来的第一把火,我先收藏为敬

android 程序员 移动开发

从 0 到 1,带你解剖 MVP 的神秘之处,并自己动手实现 MVP !

android 程序员 移动开发

今日头条屏幕适配方案终极版正式发布!,移动应用开发平台

android 程序员 移动开发

不愧是鹅厂,连面试算法题都是这样恐怖至极,已顺利OC,附赠课程+题库

android 程序员 移动开发

专科毕业三年,从外包公司到今日头条offer,我想把面试心得分享给你

android 程序员 移动开发

为什么不能使用 Application Context 显示 Dialog?,安卓kotlin

android 程序员 移动开发

互联网大厂“围城”,android界面开发

android 程序员 移动开发

五千字长文,深度解密:那些BAT大厂的Android面试官到底在想些什么

android 程序员 移动开发

中奖了!中奖了!,android组件化通信

android 程序员 移动开发

为什么不能使用 Application Context 显示 Dialog?(1)

android 程序员 移动开发

为了弄懂Flutter的状态管理, 我用10种方法改造了counter app

android 程序员 移动开发

毕业设计

Geek_35a345

人工智能的下一站:精细化生活场景的智能时代,靠着这份900多页的PDF面试整理

android 程序员 移动开发

今日头条APK瘦身之路,android组件化开发框架对比

android 程序员 移动开发

不愧是阿里技术官,Android-Framework的精髓全写在这本“限量笔记

android 程序员 移动开发

不懂源码、NDK,架构设计,2021最新Android笔经

android 程序员 移动开发

不要再焦虑了:BATJ大牛给程序员的价值百万的职业规划(18-35岁(1)

android 程序员 移动开发

不要再焦虑了:BATJ大牛给程序员的价值百万的职业规划(18-35岁

android 程序员 移动开发

【得物技术】主子订单模型

得物技术

互联网 模型 电商 订单系统 订单

为了这一次字节跳动Android面试机会,我准备了158天,一个疏忽让我前功尽弃

android 程序员 移动开发

为什么经常看到35岁程序员,转行之后工资呈断崖式下跌?

android 程序员 移动开发

二本学历,五年抄代码经验,疫情期被裁,真牛皮

android 程序员 移动开发

携程商旅订单系统架构优化实践

GavinYe

架构 中台 后端 OTA 订单系统

为您的应用配置 Play Feature Delivery,flutter视频教程仿京东

android 程序员 移动开发

今年40岁了,忽然接到公司裁员通知,接下来的路我该怎么办

android 程序员 移动开发

浮感

feitian

敏捷转型中管理层的认同和支持_技术管理_Ben Linders_InfoQ精选文章