\

本文要点

\\

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

\\

教条主义的危险

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

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

\\

  • 在Shu阶段,团队成员学习他们将要使用的框架。这时候适合并需要一种约定俗成的方法。\\t
  • 在Ha阶段,团队已经习惯了框架,开始变得敏捷。他们正在内化精益敏捷的价值和原则,并有意识地采用真正符合精益敏捷价值和原则的方法“打破原则”或者处理灰色地带。\\t
  • 在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\u0026amp;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

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

  1. 爱客专业服务团队是企业转型SaaS的关键

    SaaS热潮下,越来越多的软件公司想"分羹一杯",但从传统到SaaS模式的道路总是充满着羁绊.就此,巅峰网专家给出了他们的观点:爱客ikcrmcom从公司的实际出发,充分发挥公司的 ...

  2. 平安7年精益敏捷转型之路

    导读:平安作为互联网金融的领跑者,目前有超过40个APP,传统业务全面互联网化.能够成功转型与敏捷密不可分,平安科技更是整个集团敏捷转型的领头羊. 2011年,敏捷开发试点项目大获成功之后,平安科技驶 ...

  3. 华为精益敏捷专家:DevOps转型中的那些坑

    陈军–原腾讯高级项目经理.华为精益敏捷专家 DevOps是现在非常流行的一个词,很多人都在提DevOps,在往那个方向去转,但转的时候坑特别多. 现实是很理想的,大家都觉得做了DevOps之后就会非常 ...

  4. 精益敏捷企业的七大核心能力和实施路线图

    本文转自:Scrum中文网 前言 之前我们介绍了Scrum@Scale 和 LeSS (需要了解的朋友可以在我们公众号往期文章中查找),今天我们再来聊一聊最近被广泛讨论的另外一个大规模敏捷框架SAFe ...

  5. 敏捷之旅2013 北京站-精益敏捷交响曲 12.21

       还在敏捷的迷途中徘徊吗?    还在精益的道路上困惑吗?    还为拓展工程实践苦恼吗?    年关将至,在这收获的季节敏捷之旅2013北京站强势来袭,邀请到多位具有丰富实践经验的大师级人物为大 ...

  6. 05精益敏捷项目管理——超越Scrum

    00.我们不是不知道它会给我们带来麻烦,只是没想到麻烦会有这么多.--威尔.罗杰斯 01.知识点: a.Scrum是一个强大.特意设计的轻量级框架,器特性就是将软件开发中在制品的数量限制在团队层级,使 ...

  7. 敏捷与数字化转型银行_使敏捷人超越数字化

    敏捷与数字化转型银行 2017年红帽文化调查发现,数字化转型正在改变着内部和外部的业务. 大多数受访者(91%)同意,技术发展正在改变其行业中的组织为成功而必须运作的方式. 这将需要仔细研究它们的工作 ...

  8. 何勉:第一性原理和精益敏捷的规模化实施

    摘要: 什么是第一性原理?第一性原理如何指导我们的精益敏捷开发?阿里资深解决方案架构师.畅销书<精益产品开发:原则.方法与实施>作者何勉,结合实践案例,详述第一性原理和精益敏捷的规模化实施 ...

  9. 业务驱动的精益敏捷实施实践

    我们为什么要提升研发效能 随着5G.人工智能.IOT等新技术的迅猛发展,企业的业务都将构架在软件和互联网之上.软件交付能力成为企业的核心竞争力,随着市场竞争的加剧,企业对研发效能的期望越来越高. 然而 ...

最新文章

  1. python 线性回归_用Python实现线性回归算法
  2. 每个人眼中都有一个哈姆雷特
  3. Hp linux tar 解压,tar命令的用法(百度)(HP_UX)
  4. spring之Environment
  5. C# .net 下拉框显示提示内容-【ComboBox】
  6. linux体验服务器,体验Ubuntu做服务器
  7. 【数学与算法】步长一维搜索、梯度下降法、最速下降法、牛顿法
  8. leetcode 284. Peeking Iterator | 284. 顶端迭代器(给 iterator 添加 peek 方法)
  9. 一个列表中按钮的不同样式
  10. 新手推荐,前端性能优化小整理,效率加倍
  11. java处理获取到的Elasticsearch数据
  12. 自适应滤波——线性预测(LPC)
  13. 光环PMP 项目范围管理 、项目进度管理、项目成本管理、项目质量管理
  14. IDEA设置光标所在行背景色
  15. C语言程序设计第四次作业-选择结构(2)
  16. 【P4】解决本地文件修改与库文件间的冲突问题
  17. 基于Python统计红楼梦中人物信息
  18. Java和Javax
  19. 选择IDC机房的心得
  20. 用Python快速将ppt制作成配音视频课件的方法

热门文章

  1. 0x00a1bdb3 指令引用的 0x00000001 内存。该内存不能为 read。
  2. ubuntu各种实用的软件
  3. 23.文件特殊权限之SUID权限、SGID权限、Sticky BIT权限和ACL权限
  4. swing小区安全管理系统
  5. 【SSL】2128可可摘苹果
  6. 使用高德地图服务获取全部行政区划与各个省市的地理坐标
  7. 计算机之父 匈牙利“唯一的天才” 冯·诺依曼
  8. Flowable初始化失败 Table ‘xxxx‘ already exist
  9. [css] 你是怎么选择resetting和normalizing的?为什么?
  10. 线性代数:零空间维度等于自由变量个数的原因