写点什么

不可知敏捷:精益敏捷转型成功的关键

2018 年 8 月 16 日

本文要点

  • 教条的敏捷方法,如严格遵守 Scrum 指南,不是敏捷,而是一种严重的反模式。
  • 内化精益敏捷价值和原则是敏捷转型成功的关键。
  • 组织的复杂性需要一种多框架方法,针对组织独特的文化、目标和问题量身定制。
  • 理论必须以实践为依据。
  • 敏捷是达到目的的手段,而不是目的本身。

教条主义的危险

但是,Scrum 不是我变得敏捷所需要的所有东西?也许是,但不大可能,因为没有哪一个框架是任何复杂的组织精益敏捷转型的答案,尤其是当超出 IT 部门实现整个组织业务敏捷性的时候。

不过,还是有些教条主义者和框架销售人员声称,Scrum 将解决团队层面的所有问题,或者,他们的大规模框架适合组织的扩展需求。虽然能获得收益,但真正的转型收益可以让你的组织绩效比竞争者高出 200 倍,那就需要一种基于务实的不可知敏捷理念的方法,而且要针对团队和整个组织进行真正的定制。

那么,为什么会那样?首先,让我们看下教条的通用方法如何妨碍组织的精益敏捷转型。主要的原因是它没有识别或处理你的组织的独特性。即使在同一个行业中,组织也有自己独特的历史、文化、挑战和目标。

组织完全实现特定的框架是给自己帮倒忙,那只是因为他们被某个教练或框架销售人员说服了,认为在其他地方有效的东西,如 Spotify 模型、Scrum、SAFe、LeSS 或其他后者正在推销的东西,对他们自己也完全适用。

他们花时间真正地了解你们的历史、文化、挑战和目标了吗?雅虎和谷歌都有搜索引擎和信息聚合业务,但他们是两个大相径庭的组织。而且,即使是在同一个组织里,小组和部门可能有完全不同的需求。可能小部件部门应该使用看板,而垫圈部门就需要混合使用 Scrum 和 XP。

其次,教条的通用方法无法实现健康、不受约束的精益敏捷演进,无法同时在团队和组织层面成熟。例如,一个典型的命令控制型企业开始时可能只做好了采用像 SAFe 这样的高度结构化大规模框架的准备;不过,它可能会发展到一个点,此时,一个结构化远不如前者的模型如 Scrum@Scale 或 Spotify 模型会更合适。在这种情况下,组织需要意识到这种更为轻量级的方法,并协助过渡到最适合他们的方法。

此外,教条的、通用方法压制了创新、学习,违背敏捷原则“团队定时总结如何提高效率, 并相应地优化和调整其行为”;教条的方法会限制团队和组织“相应地调整其行为”的能力。可惜,团队的自然演变和成熟可以看作是违反一贯做法或框架指南,会被教条的教练扼杀在萌芽状态,他会强迫团队按照他奉为“圣经”的著作来实施敏捷。坚持认为这才是“SAFe 工厂”,而“我们只能按照一贯做法从事”,其他任何东西都是“Scrum-Butting”,这阻碍了任何发展,极其不利于团队和组织。

教条的以框架为中心的方法还会破坏团队和组织的独立性,为了确保正确地使用了框架,团队和组织会依赖他们的框架教练。任何偏离都会被视为失败,他们会去找框架教练回顾框架,帮助他们回归正轨。这会滋生货物崇拜心态,团队或组织会把遵循框架指南视为敏捷,而很少或不了解框架背后的精益敏捷价值和原则。

损失的还有基本的事实,那就是,精益敏捷是一种理念,而不是一个具体的框架,它主要是关于创建一种赋权文化。敏捷宣言的第一条是“个体和交互胜过过程和工具”,这绝非偶然。

现在,我们已经知道为什么教条的通用方法是精益敏捷转型的反模式,而且根本不是敏捷。接下来,我们将看下不可知敏捷方法能为我们做什么。

我们将通过介绍不可知敏捷原则在促进和加速组织转型及精益敏捷演进方面的重要作用来说明。注意,本文包含我自己对这些原则的解释和评论。原始的原则描述在这里

原则 1:把客户放在第一位,使他们独立

除了要对多框架方法进行裁剪使它最适合客户外,还要把客户放在第一位,授人以渔,使团队和组织不依赖教练。

健康的团队演进是指他们经历三个阶段,通常称为 Shu-Ha-Ri。这种演进也可以应用于整个组织。

  • 在 Shu 阶段,团队成员学习他们将要使用的框架。这时候适合并需要一种约定俗成的方法。
  • 在 Ha 阶段,团队已经习惯了框架,开始变得敏捷。他们正在内化精益敏捷的价值和原则,并有意识地采用真正符合精益敏捷价值和原则的方法“打破原则”或者处理灰色地带。
  • 在 Ri 阶段,团队完全独立、自我指导,特定框架的细节变得越来越不重要,因为他们现在运用完全内化的精益敏捷价值和原则来裁剪和混合框架,创建满足其需求、目标、环境和文化的、独有的精益敏捷生态系统。这就是 Scrumban 和 Spotify 模型的由来。团队或组织不再践行 Scrum 或 SAFe,而是践行 OurAgile。

虽然不可知敏捷教练知道需要讲授框架,但他们也知道,单框架方法并不是最好的,他们还知道,精益敏捷价值和原则必须结合框架讲授。此外,他们会特别指出,价值和原则比正在谈论的框架细节要重要得多。从我个人来说,我总是向团队成员和管理人员建议说,解决任何困难的最好方法,在任何情况下的最佳行为,以及任何问题的最佳答案,是最符合精益敏捷价值和原则的那个。

一旦团队熟悉了框架,了解了精益敏捷价值和原则的重要性,不可知敏捷教练就会指导和训练团队和组织内化这些原则和价值。这可以推动他们发展到 Ha 阶段。教练会挑战团队,使他们理性地打破规则或寻找处理灰色地带的方法,确保他们已经运用了决策制定过程中的价值和原则,而不是马虎了事。

最终,不可知敏捷教练会知道,团队真正内化了价值和原则,而他们的决策和方法也符合价值和原则。教练已经教会了他们钓鱼,他可以在夕阳下骑车回家了,因为团队现在已经可以自我指导了。一个好的教练会解雇他自己,一个糟糕的教练会成为永久的存在,让人们对他产生不健康的依赖。

原则 2:尽我所能,用实践经验完善理论

你的教练有实践经验吗?你的培训师?你的 Scrum 管理员?虽然各种框架的书本知识是必要的,但对那些从事培训、促进、辅导或指导的人而言是不够的。实践经验告诉你什么真正有效、哪里有坑、什么有帮助、什么有妨碍、哪里是问题的关键。理论与实践的结合降低了做出不利行为的风险,提升了理解客户与众不同之处的能力,便于针对那个客户制定最佳的方法。

作为一个组织,只有当你的教练、产品经理、Scrum 管理员有着扎实的精益敏捷最佳实践和敏捷实践经验,你才能从他们那里获益。如果按照书本,他们知道什么有效,什么时候那样做,什么时候不那样做,那么当使用的框架不提供现成的答案时该怎么办。

有一个令人担忧的问题,就是团队可能会由一个仅接受了两天培训(CSM、PSM I)、没有经验的人指导;有趣的是,组织从来不会安排一个没有经验的人作为瀑布开发的 PM,但却会安排一个没有经验的人作为 Scrum 管理员。更令人担忧的是,受过四天培训(SPC4)的人就可能会领导一个企业范围的大规模敏捷转型。在许多情况下,取得 Scrum 管理员或 SPC4 认证并不需要有任何实际的精益敏捷经验。这就像在教人开车而自己却没有驾驶经验。只有当培训师有着真实世界的精益敏捷实践,他们才能传授实际的精益敏捷技术实战知识,而不是教条和乐高游戏。

原则 3:根据环境定制敏捷

在“教条主义的危险”部分我们已经讨论过,每个组织都是独一无二的,因此,它应该有一个而且需要有一个精益敏捷方法来应对组织的独特性。这不是说不可知敏捷实践者会容忍敏捷增长缺位或假敏捷,而是说实践者认识到,组织无法以同样的速度发展,不能强迫组织、团队和个人过快变革,对他们造成精神上的创伤。实践者的经验和受到的培训让他们知道何时推进,何时不推进。那种经验还让实践者可以混合精益敏捷技术,定制出符合组织现实情况的方法。

原则 4:了解有妨碍的限制,努力消除

这里的关键是了解组织独特的环境和文化,因为这关乎组织、团队或个人的位置。尊重很重要,因为组织、团队和个人要像往常一样度过每一天,他们已经学习在当前的环境和文化中生存甚或成长,而在这个环境中,浪费及其他的功能障碍已经常态化、内在化。脑科学告诉我们,小变革更可能成功。

所有这些,不可知敏捷实践者都了解,制定他们的方法来消除限制,适当了解何时正面处理,何时像溪水流过岩石一样绕过。他们可以回答“对他们有什么好处”的问题,可以要求他们“你帮我我帮你”。他们务实、不可知的心态可以帮助他们避免教条主义的“禁言”方法,那会妨碍任何转型。

原则 5:分享、学习、提高

这是个人、团队和组织成长的关键。不可知敏捷实践者将努力创造一种环境、理念和支持流程,促成分享、学习和提高。团队及多团队回顾、正式和非正式培训、协会、骇客日、展示和讲述以及其他任何方式的学习和分享,这些学习活动将会持续。这种知识的创造和分享可以促进和推动组织的精益敏捷转型。

不可知敏捷实践者不会因为另一名教练或实践者更有经验或技巧而觉得受到威胁,相反,他们争取让那个人成为自己的导师。敏捷实践者知道,不管多么有技巧和经验,他们都可以从遇到的人那里学到一些东西,而不管那个人的“职位如何”。通过学习和增长知识,他们提升了自己对于组织或客户的价值。

不可知敏捷实践者从来不会把自己说成是大师,因为这样做会妨碍知识的分享,既影响了团队及团队成员的成长,也影响了实践者自己的成长。

原则 6:尊重框架及其实践者

不可知敏捷尊重所有的框架、准则和实践者,因为那些框架为我们提供了推动团队和组织转型所需要的工具,并创建赋权文化。

需要说明的是,mono 框架实践者对其他框架必须有一个开放、务实的态度,并且愿意和其他框架的实践者共事,形成多学科团队,唯一的目标是做对客户最有利的事,尊重客户的演进阶段。不可知敏捷实践者会和 mono 框架实践者对话,从而帮助他们对在多框架环境中工作持更加开放的态度。通过使每一个人都转变到一种更为务实的相互尊重的态度,组织可以使每个人都关注其转型,而不是加入到框架战争中去。

原则 7:知所不知,寻求帮助

不可知敏捷实践者非常谦逊,他们知道自己不知道什么,什么时候去向其他教练和实践者寻求帮助和建议,什么时候站到一边,让其他更有经验的教练或实践者介入,如果那最符合客户的利益。不可知敏捷实践者还知道,什么时候需要引入框架专家,就像家庭医生知道什么时候把病人委托给专科医师。

原则 8:不误导,不曲解

从各方面说,不可知敏捷实践者具备诚实、正直的行为,总是为他们接触的客户、团队和个人的最大利益着想。如果他们诚实地高估了自己的能力,漏掉了一个选项,或者犯了一个诚实的错误,那么他们承认错误,承担责任,并设法弥补。作为诚实正直的一部分,当他们觉得自己无意于真正的敏捷时,他们不会为了满足某个外部需求或者高层指令而假装成一个敏捷工厂。为了建立信任,获得必要的支持,实现成功转型,诚实和正直都非常重要。

原则 9:记住,敏捷不是最终目标

敏捷是达成目标的一种方式,可能还有其他的方式可以达成相同的目标,而且就客户成长和总体健康而言更具可行性。不可知敏捷实践者会评估组织的文化、目标和问题,从而确定是否其他的方法或准则更合适。例如,在以恐惧为基础或极端保守的组织文化中,如果不首先解决深层次的心理学和社会学问题,精益敏捷方法将注定失败。在这种情况下,在开始精益敏捷转型之前,组织最好是开启组织变革,引入组织行为专家。

最终,终极目标应该总是最有利于客户的东西,即使那意味着把他们交到其他专家的手中然后离开。

原则 10:要承认,教条主义非敏捷

在本文的第一部分,我已经提到,为什么教条主义不是敏捷,它违背了敏捷宣言的条文和精神。

需要补充的是,不要对务实和不可知论那么教条,以鄙视的态度看待 mono 框架的教条主义者。不可知敏捷实践者接受人们的当前状态,他们自己真得认为自己是敏捷的。因此,要让任何人都得到属于他们的尊重,参与到以敏捷宣言为共同点、富有建设性且相互尊重的对话中。

原则 11:要知道,敏捷不止敏捷那么简单

这条和原则 9 有关。如果有正当理由,那么有许多领域是不可知敏捷实践者可以而且应该利用的。这包括精益、设计思维、管理 2.0&3.0、组织行为、心理学,等等。一个全面的、最适合客户的多模式方法是最重要的。

原则 12:奉献社区,就像社区给予我一样

不可知敏捷实践者知道,社区多年来一直在给予他们知识和支持。他们心存感激,他们通过写作、发帖、指导以及按需提供支持来回馈社区。他们腾出时间给同行和那些希望踏上敏捷之旅的人。这对客户是有好处的,因为实践者在回馈的过程中也增长了自己的知识,此外,敏捷社区的整体知识水平也有提升。

小结

通过设计处理组织独特文化、目标和问题的方法,精益敏捷的不可知方法会加速组织的精益敏捷转型。而且,专注于精益敏捷价值和原则而不是具体的框架,不可知方法可以协助组织、团队和个人发展和内化精益敏捷思维。使用务实的、以客户为中心的方法,强调“融入敏捷而不是做敏捷”,可以避免规定性的、以框架为中心的教条主义方法。

要了解更多有关不可知敏捷方法的信息,请联系作者或者访问网站

关于作者

Tim Guay  精通精益敏捷最佳实践,作为实践者、培训师和教练,取得了公认的业绩。他在帮助组织引入敏捷和精益、提供敏捷和精益培训与指导以及引入 DevOps 最佳实践方面有着丰富的经验。自 2002 年开始,他一直在各种组织中担任实践者、敏捷培训师和教练,从创业公司到财富 50 强的企业。Tim 在大会上发表演讲,开发课程,发表有关各种精益敏捷主题的文章。作为不可知敏捷宣言的早期签署者,他在 ICAgile 的 DevOps 跟踪认证委员会任职。你可以给他发邮件( timothyguay@yahoo.com ),也可以随时在 LinkedIn 上和他联系,那上面有他的许多 Pulse 文章和大会幻灯片。

查看英文原文: Agnostic Agile: The Key to a Successful Lean Agile Transformation

2018 年 8 月 16 日 18:085029
用户头像

发布了 1008 篇内容, 共 320.1 次阅读, 收获喜欢 289 次。

关注

评论 1 条评论

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

新增原创标签相关改动

yinhaixiang

测试 个人 aa bb

求求你,别再用wait和notify了!

王磊

Java

FORSAGE智能合约矩阵系统软件APP开发

开發I852946OIIO

系统开发

区块链发展前景广阔,要紧跟时代步伐

13828808769

区块链发展 时代发展

学习笔记4

Qx

Python进阶——什么是描述符?

Kaito

Python

ISP芯片:如何让数字之眼“看清”真实世界?

脑极体

数据类型· 第1篇《元组和列表的性能分析、命名元组》

清菡

测试开发

ReactNative | 项目复盘,涉及环境、RN版本升级、安全等方案

梁龙先森

前端 混合应用开发 React Native

领域驱动设计(DDD)实践之路(四):领域驱动在微服务设计中的应用

vivo互联网技术

架构 领域驱动设计 DDD 领域驱动设计DDD

甲方日常 67

句子

工作 随笔杂谈 日常

跨越“数字鸿沟”,日本老年智能化服务的解法

脑极体

《逻辑和计算机设计基础》第五版(英文原版)PDF免费下载

计算机与AI

计算机基础 计算机组成原理

Java虚拟机科普系列—元空间Metaspace的内存结构

Java老k

Java JVM Java虚拟机 metaspace

【架构师训练营 1 期】第十二周作业

诺乐

浅谈产品与项目之间的爱恨情仇

Week_12 作业

golangboy

极客大学架构师训练营

生产环境全链路压测建设历程之九 淘宝网全链路压测的原理

数列科技杨德华

记一次神奇的MySQL死锁

废材姑娘

spring MySQ

Spring Boot 过滤器

噜噜猫

Spring Boot

访问者模式及其在Java Parser中的应用

maijun

我国一项物联网安全测试技术成为国际标准;Windows 10将支持安卓应用

京东科技开发者

如何搭积木式的快速开发H5页面?

徐小夕

Java 前端 前端工程 React 数据可视化

架构师训练营第四周总结

Geek_xq

金融科技 | 建设中台能力,助力开放生态

xcbeyond

金融科技 中台战略 中台架构

还在手写Operator?是时候使用Kubebuilder了

Java架构师迁哥

以理性不断的崇敬 - 对DDD之后复杂业务软件系统设计的思考

Winfield

领域驱动设计 DDD 架构设计

Sentinel 是如何做限流的

vivo互联网技术

高可用 限流 底层

新增原创标签相关改动

yinhaixiang

aa bb cc

【架构师训练营 1 期】第十二周学习总结

诺乐

时序数据库DolphinDB和TimescaleDB 性能对比测试报告

DolphinDB

大数据处理 分布式系统 时序数据库 DolphinDB 数据库开发

低代码的认知误区与落地实践

低代码的认知误区与落地实践

不可知敏捷:精益敏捷转型成功的关键-InfoQ