0%

大规模Scrum,More-with-LeSS

蹭大牛的书《大规模Scrum》扫扫盲,没接触过组织变革管理,很多观点觉得挺新奇,也很有道理。虽然对组织设计这件事,“知道”跟“做到”的距离都不止十万八千里,就当头脑风暴了,见识下“完美”是什么吧。顺带学会了一个新词“经验性过程控制empirical process control”。

为什么有些事情很难做,正是因为没有简单的规则可以套用,我们一直挂在嘴边的“最佳实践”,承载了多少不切实际的厚望呀。

####2.1.2 试验、指南、规则、原则
前两本LeSS书强调的是:在产品开发中没有最佳实践,而只有在特定环境中最适合的实践。

实践是在环境中形成的;毫无顾虑地宣称这些实践是“最佳的''会让它们与动机和环境脱节,继而变成纯粹的仪式性活动。推广所谓的最佳实践会扼杀学习、提问、参与和持续改进的文化,因为人们会想为什么要挑战最好的东西呢?

下面这段翻译腔严重,好在不是文学作品,意会不难,还是照原文抄录。
乍一看,这三个原则说得不就是“先试点再推广”么,仔细想想,其实很多事都是按这个套路的。
“采用”是看了前三章最想吐槽的一个词,我猜是adaptation,译成“适应”或“实施”应该更好理解吧。

####3.1.2 指南:三个采用原则

这些原则对于组织的LeSS采用至关重要:

  • 深而窄优于宽而浅
  • 自上而下与自下而上
  • 使用志愿服务

#####1. 深而窄优于宽而浅
在一个产品组中采用LeSS比在许多产品组中采用LeSS效果更好。

不良的LeSS采用具有危害性。缺乏深刻的理解会破坏作为经验性过程控制和持续改进的关键因素:透明和反馈回路。我们甚至看到LeSS被滥用作一种非凡的微观管理工具。故而,在微观管理式LeSS采用成为既定基准之后,那就真的很难再做改变,因为重新学习已知的东西是很困难的。

因此,只需将LeSS采用的工作集中在一个产品组上,为其提供所有必要的支持,并确保其确实能正常工作。这样做可以最大限度地降低风险,如果遇到大问题,它就会触发一个具有针对性的学习机会。成功的时候,它则会激起正面的“传言”,这是进一步实施采用的重要营养素。

#####2. 自上而下与自下而上
我们经常被问到一个问题,方法的采用最好是自上而下还是自下而上。这是一种错误的二分法。只做任何一种,则可能招致失败,需要两者都做。

纯粹的自上而下一一经理驱动的“你应该做LeSS”式的采用会引起阻力,并使组织面临失败。命令团队去管理自己是一个矛盾体。Less采用需要深刻的理解,它不是来自指令,而是来自讨论。只有通过理解、选择和个人安全感,人们才能承担起反思和改进的额外责任。缺乏这些因素所造成的不良局面会因“我们 - 他们",即经理与员工之间的关系而被放大和加剧。在这种情况下,强迫Less进入组织会助长受害者行为,并进一步降低管理层和员工关系的融洽度。人们会说:“我们别无选择,我们的经理说我们必须做Less!”他们会秘密地或许是不知不觉地、舒适地,或者至少是熟悉地躺在受害者的位置上休息。

纯粹的自下而上一一这种Less采用是不可持续的。一开始,这种方式创造出一股令人愉快的能量,这些能量其实来自于那些想做正确的事情的人。这带来了思想开放、学习加速和理解加深的景象。真的很棒!然后呢,这些精力充沛的人以精力充沛的方式撞上了组织的壁垒。砰!在没有来自高层的支持的情况下去改变组织结构和政策,热心的人逐渐失去了原有的精力,对眼前的障碍和僵化感到沮丧。许多人最终放弃了希望,或者因为希望破灭而感到痛苦。这也让我们感到难过。

自上而下和自下而上一一成功的Less采用既需要人们做正确事情的精力,也需要那些有组织权力的人的支持。管理者的心态必须是支持,而不是控制。他们需要确保适当的支持结构及时到位,使基层的能量蓬勃发展,不断扩大。

我们经常听到希望得到管理者支持的心声。但要小心自己希望的究竟是什么!

  • 没有管理层支持往往会导致受害者行为。“没有经理的支持,我们什么都做不了。"
  • 有了管理层支持则可能导致更糟糕的情况。“我们必须做Less,因为我们的经理是这么说的。"这种不动脑筋的服从会破坏Less的采用。

需要什么样的管理层支持?
所需要的管理层支持,来自于那些有组织权力并能在团队中进行结构变革的人,通常是产品组的负责人。这种支持必须是……真正的支持。

真正的支持始于自我教育。产品团队中的所有经理都需要花些时间学习Less,对自己进行自我Less教育。这包括参加几天的入门培训和读几本相关的图书。除了教育之外,管理人员还需要就以下方面与团队进行明确的沟通,并采取明确的行动:(1)Less采用的意图;(2)结构变革的承诺;(3)提供教育和辅导。

不需要什么样的管理层支持?
监督多个产品开发的高级经理,他们的支持往往适得其反。为什么这么说呢?他们会忽略实际问题——因为他们没有充分参与实际开发。他们的支持通常就是做出一些“优化”和“协调”的决定,这些决定从他们高级职位的角度来看似乎很有意义,但实际上很少能为真正创造价值的现场(gemba)带来真正的好处。结果是,为了应对这些用心良苦的决定,团队处理实际问题的精力被不断消耗。

团队也不需要获得这些管理人员在管理方面的支持,因为管理人员们还没有深入了解Less及其产生的影响。我们经常被要求在一个小时的演讲中概述一个为期3天的深度培训,因为这些经理“太忙"了,他们没有时间参加为期3天的课程。到目前为止,我们还无法将需要3天时间来理解的内容压缩为1小时的演讲。好吧,是我们不对。

#####3. 使用志愿服务
如何组建新团队?谁会加人社区?这些问题,以及更多的问题该如何回答呢?

使用志愿者!真正的志愿服务是一种激起人们身心参与的强大方式。如果它没有得到充分利用,则可能是因为管理人员觉得他们会失去控制。但是对于那些自愿的团队来说,志愿服务就是力量的象征。

志愿服务始于教育。假设只是要求志愿者做一个混合结对试验,这可能不会得到很多
人的支持,即便有人回应,这些人在最好的情况下也是感到困惑的。但是如果首先解释混合
结对是一种使用频繁结对和交换的方式来增加学习结对编程技术的机会,那么效果就会不
同,就会有越来越多且越来越优秀的志愿者加人。因此,首先提供足够的教育和讨论,让其他人了解他们做志愿服务的目的。