写点什么

爱立信的敏捷转型

2018 年 9 月 26 日

本文要点:

  • 想变成什么样,领导就要先以身作则,这是变化开始之处。
  • 敏捷转型是思维的改变:你看世界的方式和你的想法。
  • 思维的改变需要组织中的人做系统的改变,由敏捷教练推动,由改变人们交互、讨论方式的过程和结果做支撑。
  • 你做出的任何改变都会有副作用。为保持转型在正轨上,你需要用组织系统回顾来解决可能产生的影响和副作用。
  • 文化通过叙述转型,要想改变文化,你需要关注它。

应用复杂的系统思维,通过故事叙述培养敏捷思维,可视化人们的交互,这是爱立信推动敏捷转型的一些尝试。由于拥有完全拥抱敏捷的领导团队,拥有敏捷教练组成的独立小组,在领导团队中经常进行回顾,这能保证敏捷转型维持在正轨之上。

爱立信特别项目经理 Hendrik Esser 将会在 Agile Summit Greece 2018 大会上做有关爱立信敏捷转型经验的演说。这次会议将于 9 月 20 – 21 日在希腊雅典举行。

Agile Greece Summit 大会的讲师涵盖开发人员、团队负责人、经理和主管人员,他们都是来自世界各地的顶尖敏捷讲师和参与者。

这次大会的主题是“创建可以改变世界的优秀团队”。InfoQ 将会以总结、文章和问答的形式来报道这次大会。

InfoQ 采访了 Esser,询问了他有关敏捷转型是如何开始的,如何运用复杂的系统思维和实际的故事叙述来推动敏捷转型,在转型过程中什么成功了,什么失败了,帮助转型的实践技术,敏捷是如何影响管理者处理不确定问题的,如何保证敏捷转型在正轨上,以及他对于敏捷教练和主管人员的建议。

InfoQ:你能详细介绍一下为什么需要采用敏捷,以及在爱立信敏捷转型是如何开始的吗?

Hendrik Esser:在二十世纪八十年代和九十年代,我们共同见证了全球化推动的强势增长。为了更好地应对这样的增长,我们需要学会如何让软硬件开发工程师满足全世界客户的需求。那时就没有什么内联网和互联网。所以我们将如何创建产品的知识内容编为文档,打印下来,并把它们发到我们的产品开发场所。那时候这是最先进的技术了!

在二十世纪九十年代末以及 2000 年,我们见证了两件事的发生:使用内联网进行内部通信,这使合作变得简单和快速,因为我们的产品以及遍布了全世界,全球化进程也结束了。我们写下来的过程已经不能应对新知识的传播和接受,以及饱和市场产生的动态性。这里的饱和代表着:全球市场变得“狭窄”,竞争加剧,我们需要再次聚焦到客户的需求上来。

所以在二十一世纪初,我们开始使用极限编程。在很长一段时间中,敏捷并不是一个很好的选择,因为我们不知道如何将敏捷方法运用到我们这样规模的公司中来(当时我是领导班子成员,我们组织大约有 2000 名员工,遍布在全世界七个地方)。然而,在 2008 年我们采用了新的措施来解决当时我们遇到的最大问题,即上市时机、质量以及投资回报率的问题。我们邀请整个组织参与其中。一些人尝试了 Scrum 方法,发现非常有帮助。这就引发了一系列的研讨会,我们讨论如何将敏捷的思想扩展到公司中,最终我们采用了大规模推动敏捷的策略。

InfoQ:在你的演说中你将讨论如何运用复杂的系统思维和实际的讲故事来推动敏捷转型。你可以详细说明一下吗?

Esser:对于我们这样规模的组织来说,敏捷转型是非常成功的。在开始之后大约一年半时间之后,我开始思考为什么我们会成功,为什么我们公司中有一部分会取得更大成功的问题。加入到敏捷联盟的支持敏捷采用计划之后,我在一些研讨会和会议上碰到了 Diana Larsen、Jutta Eckstein 和之后的 Dave Snowden,我了解到公司(或组织)是人组成的复杂动态系统。这就是说,敏捷转型是组织和人的系统的转型,需要相应地应对。这代表着你做的所有变化都会有副作用。所以你需要进行变更实验,准备好接受组织中发生的变化,并相应接纳。

其中重要的一个部分就是我们希望公司拥有的“文化”。我们如何传播文化?一个不太好的方式是通过过程和制度来传播文化。确实是一个办法,但并不能很好地传播。它不能深入人心。我们看到很多采用敏捷失败的公司都认为“敏捷是思维”,如果你不能培养这种思维,你就不能成功,会不断陷入变更的过程。一种培养思维的方式是借助有经验的敏捷教练,来引导人们转型。另外一种传播文化的方式是通过叙述,比如说我们讲的故事。那些可能是我们在走廊或咖啡角听到的故事。所以一个好的变更工具,就是宣扬期望的文化的小故事。这些故事不应该是“发生了什么,我们做了什么”的单纯描述,而应该是有关人的故事,让人们可以感同身受。

这是一个故事的例子:一开始有一场关于“当我们觉得准备好的时候,我们才真的准备好了”的辩论。我们用“当乘客错过火车的时候,他会搭乘下一班火车”的故事来说明。我们一直在说这个故事,直到有一天我们的财务总监在会议上说:“是的,但是地铁和通勤火车是有区别的,如果我准备坐地铁,我快要错过地铁的时候,我知道下一班地铁会在 5 分钟内来。但如果我要坐通勤火车,可能下一班要半小时才回来,我只能跑着去上班了!”这个小故事帮助我们了解到,发布频率是非常重要的。

另外一个例子:我们的变更策略需要有大概一年的过渡期,我们会用老方法完成当前运作的项目,随着人们完成这些项目,给他们完整的敏捷训练,让他们将敏捷运用该在新的项目上。在大概过了六个月过渡期之后,一些还在运作老项目的团队表示:“我们在敏捷项目工作的同事看上去更开心!我们能早点开始敏捷训练吗?”这是一个很好的故事,我们重述这个故事来宣传它的内容,并由此让其他员工早点开始敏捷训练。给整个过渡期带来了更多的帮助和动力。

InfoQ:你能举例说明在转型过程中什么成功了,什么失败了,以及你学到了什么吗?

Esser:非常有效果的一个例子是我们如何面对变化的:首先我们需要训练领导团队,之后为想要成为教练的人举办“培训训练者,教导教练”的活动。之后让这些教练成为当地过渡期团队的一员,和经理一起进行训练,教导教练和团队,并讨论每天会发生的所有问题。这里我了解到,转型是从领导层开始的,需要受过良好教育、技术熟练的教练来帮助转型的成功。

一个失败的例子是我们创建跨职能团队,之后我们不会再这么做了。在过去,我们有由技术专家和解决方案架构师组成的技术部门,由软硬件开发人员组成的开发部门,由测试人员组成的测试团队。我们将这些组织合并为一个组织,所有团队都成为跨职能团队。我们看到了其中的巨大好处。但大约实践了一年之后,我们发现创新越来越少,技术优势也有所下降。谁能和客户一起讨论未来的技术发展?之前是由技术团队完成的。现在我们发现,技术人员被开发团队(更关注于短期的)同化了。

所以我们知道,让同一个人用不同时间视角完成平行 / 多任务工作是非常困难的:对跨功能开发团队来说任务是完成功能,他们不可能和客户讨论未来潜在的可能。职能错乱就会导致问题,我们的解决方案是重新组织技术部门,但比我们以前的技术部门小很多,他们专注于动态的和中长期技术研究。这个变化减少了对团队的干扰。对我们来说,总体上还是一个成功的“商业案例”。

InfoQ:你用了什么实际的技术来帮助变更?

Esser:我能想到的一个很好的例子就是我们改变了计划的方式。在敏捷转型的一开始,我的任务是构建一个叫“资产组合管理”的组织,如果你愿意的话,它是非常轻量级的敏捷“项目办公室”。部分原因是需要改变我们计划和预测的方法。我们很早就知道预估不能被(误)认为是“承诺”,而应该是一种不确定和风险的表述,是团队做出的预估。我们引入的方法是提供“不确定范围”,而不是“完全错误”的预测,比如“我们将在 10 月 12 日 10:30 分交付”,我们现在会说“根据目前的了解,我们有望在 8 月到 11 月之间交付”。我们可以在每个 sprint(持续学习)之后重新预测,从团队中收集到新的范围,来规划总体情况,和业务管理人员进行讨论。我的组织负责从团队收集这些范围。

这听起来非常简单,从单一值的预测变成了时间段,但的确改变了人们的思维方式。当只给出一个确定值的时候,人们会将它看作是一个承诺。当你给出的是一个范围的时候,人们就会有问题产生。这种对话让我们对于情况、风险和不确定性有了更深的了解。使用范围可以改变我们交流和思考的方式。

另一个例子:当组织有问题的时候,我们通常会查看过程,通过改变过程来提升。在动态商业环境和更大的组织里,这可能并不能实现期望的结果变化。因为根据我的经验,过程通常没有什么问题。告诉我问题,我能找到好的过程来解决问题。问题通常发生在人与人之间的交互中。所以,更好的可视化的方法是关注人们的交互,而不是过程。我能想到的一个好的做法是:在白板上画一个小客户。然后问房间里的人:客户在和谁说话?人们将画出下一个人物,然后将客户和那个人连成线。这时候,你就可以接着问:“那这个人在和谁说话?”等等问题。最后,你就能发现谁和谁之间的交流,来满足客户的需求。通常,在大型组织中,这些图会比较复杂,因为我们需要和很多角色对话,获得批准等等。这样,对画的讨论就会变为:我们如何简化,提升流程和敏捷?之后,你就会有不同的想法。

InfoQ:敏捷是如何影响管理者处理不确定问题的?

Esser:我会区分(中层)管理者和主管人员。根据我的经验,主管人员已经面对着许多不确定性、模糊性和动态问题。在大多数情况下,他们之所以能获得领导的职位是因为已经证明了自己具有在这样的情况下处理问题的能力。问题是,不是所有人都有这样的能力,所以有不能适应动态环境的人,有些人甚至不喜欢在动态的环境中工作。其实没有对错之分,只是要看情况。在发生不确定问题的时候,很多主管人员都喜欢和可以执行决策的人一起工作,或者至少给你他们有这种能力的感觉的人。现实生活中经常发生中层管理层尽全力在动态环境中执行决策,解决发生的混乱问题,以此实现确定性。在高层和客户面前,他们希望自己是可靠的、值得信赖的合作伙伴。在这种两难的情况下,为了加强客户和主管人员的信任,他们需要装出很确定很有信心的样子。但是情绪的问题很难解决,因此会造成很大的压力。

如果你采用了敏捷思维,这种压力就会大大降低。不需要再现上面的情况,人们会一起认识到完全的确定性是不存在的。所以,人们不再相互施加压力,而是联合起来解决不确定问题。因此对于主管人员和经理来说最重要的是不要再现上面的情况,而是营造一个可以自由说出不确定问题的环境,之后建设性地讨论如何来应对。有趣的是,这让你变得更加值得信赖,因为你处在了更开放的环境中。这样,你就能分享到更多的视角,做出更好的决定。

InfoQ:你如何保证敏捷转型仍处于正轨之上?

Esser:要保证转型还处在正轨上,这可不是一件容易的事情。有很多因素会影响到你正在试图改变的系统,而且永远不能控制住。在最好的情况下,你可以控制住一些,但即使这样也会有意料之外的副作用。

根据我参与的敏捷转型,我认为有三个重要因素帮助它保持在正轨上。

首先,在组织顶层要有完全拥抱敏捷的领导团队,这样能推动敏捷在整个组织的实施。这些领导要能够讲述敏捷故事和实践,抑制非敏捷因素的影响。我们的领导团队先于组织中的其他人进行了系统的敏捷训练(因此我们的领导团队总是领先于其他人)。

第二个重要因素是由受过良好教育的敏捷教练组成的自组织的、独立的小组,他们负责支持本地组织中的敏捷转型。

第三个重要因素是领导团队的频繁回顾,我们需要分享并分析整个组织中发生的事情。如果事情开始朝着错误的方向发展,这可以帮助我们纠正采取的措施和实验。

InfoQ:你对敏捷教练和主管人员有什么建议?

Esser:我认为大多数敏捷教练都是积极的理想主义者,对于他们教导的团队,他们拥抱服务型领导观念。但我见过一些组织,管理者并不能看到敏捷教练的附加值,因为显而易见的是他们的过程非常简单,他们不能回答经理的一些问题:“你获得了什么?”或是“你有什么附加值?”。所以我给敏捷教练的建议是,不但要成为团队服务的理想主义者,还要提升你努力的结果。一个好的做法是不仅仅面向团队工作,还要面向管理层和更大的组织。(比如培养管理意识的思维模式。)

敏捷是一种思维,在我们的社区里经常会讨论文化变更。我们和周围的领导讨论这个问题,基本上大家都赞同。但是在通常情况下,并没有什么真正的改变。这是因为很难让敏捷变得有形。根据我的经验,更好的方法是将它设计为“我们思维方式的改变”。魔术师在台上表演的戏法对观众来说是不可思议的。通常来说,根据你的思维方式的改变,一些事情也会发生改变,因此你需要改变自己的视角。所以,为了影响人们,特别是领导,我们需要提供新的视角。我通常会使用两种方法:不同的可视化和不同的“语言”,比如说用不同的说法。

我对主管人员的建议是:不要把转型委派给别人就完了。你需要成为你想要的改变的一部分。如之前所说,一个重要的领导方向是创造安全的环境,在其中人们可以说出自己想说的,不用担心有什么消极结果。你希望人们分析他们的不确定和他们的想法。但是要实现比较困难:你需要了解敏捷,让它深入自己的内心,帮助你建设性地解决动态的、不确定的和惊讶的问题。这是非常有意义的实践,但是你需要经常反省自己,反省你的想法和行为,尽管在第一次尝试的时候心里不太舒坦(这不是经理期望要做的事情!),但是你需要拥有接受挑战的能力,改变你的思维和行为。一个好的教练会帮助你完成这一改变。

然后是一个非常实际的事情:在你的领导团队中实施组织系统回顾,多花些时间在这件事情上。在转型的一开始,我们超过 50% 的领导会议是在进行组织系统回顾。

这都是非常重要的,我们作为领导要了解如何应对组织中出现的各种问题。举个例子,有些事情很难平衡:给人们机会犯错,从中可以吸取教训,但是这个度要掌握好。制定一个共鸣板,了解每个人是如何实现平衡的,这非常有帮助。

另外一个例子是我之前提到过的创新问题。我们在一次回顾中发现了一个问题,然后开始讨论如何解决它,之后我们就决定重新建立了小科技部门。

有关受访者

Hendrik Esser 是爱立信的特别项目经理。他拥有超过 20 年的产品开发领导经历,领导的团队从小(20 人团队)到大(超过 7000 人组织)。他是爱立信企业转型的推动者之一,担任敏捷联盟的支持敏捷采用计划的志愿项目主管,经常在国际会议和公司活动中担任讲师。

查看英文原文 Agile Transformation at Ericsson

感谢冬雨对本文的审校。

2018 年 9 月 26 日 18:315742
用户头像

发布了 217 篇内容, 共 52.4 次阅读, 收获喜欢 70 次。

关注

评论

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

XSKY新一代分布式文件系统XGFS揭秘——元数据服务

XSKY融合存储

极客公园张鹏对话百度CTO王海峰,揭秘中国AI的今昔与前路

脑极体

一.操作系统概述

Winter

操作系统

等级三整理之深信服

Lane

赋能云端管理 激发智能边缘 英特尔发布超能云终端解决方案

最新动态

MySQL5.7应当注意的参数

Simon

MySQL 参数

Kubernetes config多集群管理工具

雪雷

k8s kubecm k8s多集群管理 kubeconfig

Gitlab CI进阶之共享CI库

雪雷

DevOps gitlab CI/CD gitlab ci

K8s可视化监控之-Weave Scope

雪雷

k8s k8s可视化 k8s监控

小小的代码分支模型如何撬动研发过程管理

陈晨

Java 生成解析二维码

喜瑞斯

Java单例模式一文通

喵叔

Gitlab CI之单元测试和代码扫描

雪雷

单元测试 CI/CD gitlab ci 代码扫描

微服务链路追踪之Jaeger

雪雷

全链路监控 Jaeger

Kubernetes-学习必备(awesome-kubernetes-notes)

雪雷

学习 k8s入门 k8s文档 k8s知识

必看的数据库使用规范

Simon

MySQL 技术规范

如何优雅的备份账号相关信息

Simon

MySQL

支付宝蜻蜓刷脸支付

诸葛小猿

支付宝 蜻蜓 刷脸支付

区块链加未来3至5年可以预见 上链将成为常态

CECBC区块链专委会

区块链 金融 数字时代

K8s事件监控之kube-eventer

雪雷

k8s事件告警 k8s资源监控 k8s管理

搜狗联合清华天工研究院推出ChoreoNet模型:让数字人随着音乐翩翩起舞

脑极体

GitOps工具Argo CD实战

雪雷

DevOps CI/CD gitops argo cd

Dynamodb 常见命令操作

麦迪文

数据库 AWS Data dynamodb

曾经每个手机上都有的游戏,作为前端如今你也能开发出来了,附教程

web前端程序猿

html5 前端 前端训练 前端教程 web前端

大数据技术思想入门(一):分布式存储特点

抖码算法

Java 大数据 hadoop 分布式

三分钟搞懂依赖注入

喵叔

Git 常用命令总结

迷羊

git

构建统一监管制度 加快数据要素立法修法

CECBC区块链专委会

区块链 金融 区块链数字经济

使用null条件运算符调用事件处理程序

喵叔

Go: 使用pprof收集样本数据

陈思敏捷

go golang pprof

mPaas-RPC拦截器各种场景下的使用指南

阿里云金融线TAM SRE专家服务团队

RPC

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

爱立信的敏捷转型-InfoQ