佛系敏捷--寻找Scrum底层动力

本文主要是介绍佛系敏捷--寻找Scrum底层动力，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

转自本人运营的公众号“ 携程技术中心PMO”（ID：cso_pmo）

Trip.com Group 携程集团

Key：Trip.com,携程,携程PMO,携程技术,敏捷开发,PMO,PMI,PMP,Scrum,Agile

作者简介

Franz，一个既不Certified，也不Agile，更非Coach的Agile Coach。

Scrum在中国变得很流行，而和“流行”相对的是并没有多少人认为完整的跑Scrum是可行的。有趣的是按照《Scrum Guide》，只实施部分的Scrum不是 Scrum。那我们跑的到底是啥，该怎么做？

《Scrum Guide》仅仅一页纸，为什么就是做不到？所幸在几位教练老师的帮助下重构了底层信念，得以从另外一个视角看Scrum。这里基于其中一种框架来阐述一些观点。

每个人都是OK的

Scrum的基本团队设计就是PO、SM、Dev-Team平等。由于缺少类似于“三权分立”的历史背景，这个结构在我们的工作环境下很难被理解。

有次某个团队出现了严重的危机，几乎所有的项目管理行为都终止了，团队处于极度混乱状态。为了恢复混乱，某个领导提出：为什么组织形式搞那么繁琐，就按传统的“项目经理负责制”不就好了吗？虽然大家也清楚任命的那个“项目经理”（也是PO）既缺乏担任项目经理的经验，也缺少项目经理所必须的项目管理知识和沟通能力。但也宁愿相信把责任都丢在他身上，他就很快能承担起一切。

让一个人负责并独裁团队是我们一直以来的习惯：如果发现管理不流畅时就企图获得（或者帮助某人获得）更大的权利。然而只要组织系统的基本逻辑和集体潜意识没有被改变，更大的权力并不能解决无穷无尽的扯皮和对抗。这样的管理模式也有其他的副作用，“帕金森定律”就是其一。

负责人为了让下属更能接受他的管理，他（或者他的领导）会去找能力比他弱的下属。而这些下属如果还有下属的话，则会找更弱的人以便于管理他们。很快组织就变得庞大并且充满各类嗷嗷待哺的弱鸡了。这些弱鸡缺乏来自上级的指导，今后又不得不继续寻找低价值的工作来填满基础业务熟练后空出来的工作时间，这样流程也变得臃肿了。

为了避免出现这种可怕的场景，我鼓励想退出权力圈的SM在没有领导正式或非正式意见的情况下主动进一步，分掉这个“项目经理”的管理权。而当发现SM无意识地存在话语权过大的趋势时，又提示她应该退一步，维持好与PO的平衡。这个过程就像是教一场舞蹈，观察双方的舞步来示意谁应该前进一步，谁应该后退一步。

逐渐让大家意识到 “多头管理”其实并没有什么可以担心的，并且更多（没有职务头衔的）人可以短时间的接管团队管理权。这样的“多头管理”逐渐会让管理者接受更优秀的人才进团队，通过集体共创来关注于更好的做事、做产品，共同成长，而不总担心自己会失去权力。而他们，将逐渐走向支持团队其他成员的“Servant-Leader”。

对于“Servant-Leader”，中外在2000年前都有很好的探索。一个是《马太福音》（Mathew 20:26-28）：“Whoever wants to becomegreat among you must be your servant, and whoever wants to be first must beyour slave.”另外就是《道德经》有类似的说法：“欲上民，必以言下之；欲先民，必以身后之”。而后，不管是《管理3.0》一书，还是Mike Cohn提议：“敏捷软件开发中的微观管理要交由团队来做”，以及其他各种管理著作，类似的观点数不胜数。但是！任何理论上的忽悠与洗脑都是没用的。只有通过实例和体验，让陷入“微操狂热”的管理者真的建立起“People are OK”这个信念，他才会放手团队去尝试和发展自组织。

每个行为背后都有正面的动机

这个信念是上一个的延续，如果不遵从这条可能会陷入过程控制理论泥潭。有段时间总有人抱怨：“总有人乱删文件/乱改文件夹/乱合分支……”，并且建议增加权限控制。“权限控制”这样的蠢事我也干过几年，结果就是在IT管理系统中设置这样那样的权限规则，很快规则就变得越来越复杂。再然后就衍生出奇奇怪怪的管理流程，更复杂的管理流程。再后活动检查单、宣贯培训、过程审计都出现了。

过程控制理论还有一个从犯就是度量分析，虽然戴明博士一再强调个人不能改变整个系统、不要对人进行排序，等等。但是还有诸多人无视现代过程控制学派已经趋向于度量（更自动化的）系统，当然也无视戴明博士把PDCA改为PDSA背后的意义。这样人就不会成长、可以把人看作系统中一个固化的零件予以度量。

管理支持团队在这个趋势下越来越发现人手不够用，而项目团队也被管理支持团队的行动折腾到半死。但是，效果呢？几乎没有……在团队考评时问大家，这样的工作干了几年了，到底有什么价值，几乎没人可以说明白。

要改变这些，我用了一个提问：

“谁的工作职责是乱删文件/乱改文件夹/乱合分支？”

对方立即被这个问题问到了：“没有吧……”

或许有的人还不能接受，会回答：“但有时候……团队里还是有坏人，需要一些处罚措施的。”

这时候只要这样问他：“你说的这个‘坏人’是谁，或许我可以跟他去了解下。”

对方可能就想明白了，其实团队里没有‘坏人’，他只是在那个当下不小心做错了或者不知道游戏规则而已，他的根本动机就是把项目做好。只要更好的沟通、磨合，一切都会好起来的，无需那么多繁琐的管理措施。

每个人内在拥有成功所需的一切资源/人会做出当前最好的选择

对于指导团队 “如何敏捷”这方面我一直很佛系，不定义流程规则，也不手把手教如何去做，反正一切都是自然发展的结果。就拿“写用户故事”来说，发现大家用户故事写的像以前的需求文档，或者没有“so that”部分，也没什么兴趣告诉他这样不对，因为这么做没有效果。

要让一件事情做的像点期望中的样子，传统的做法当然是“规范+考核+处罚”啦。从脑科学来讲，这是触动人的“本能脑”。当人 “不遵从领导要求”时，就用强力的命令和处罚去给他制造恐惧。然而，在复杂性的社会或者项目中，这样的做法根本没用。我们不能一会告诉他“你应该这样做，不然我就……”，过一阵子又告诉他“你应该那样做，不然我就……”。在新的命令下达时，只有施加更强力的刺激制造恐惧，才能让他重新听命起来。但是很快这个员工就没有方向，或者只会唯唯诺诺了（如果他还有知觉，那他会选择走人）。

举个例子：我很久没有开车了，原因就是有次我开车的时候，父亲坐在副驾驶席上。我方向盘稍微往左偏了一点，他在旁边大喊：“那边有柱子，你没看到吗？”我吓了一跳，赶紧往右打了一点，他又在大叫：“右边有车子！”所以我的内心活动变成：“你说往左就往左，你说往右就往右，方向盘交给你指挥了，我只管踩油门。”然后没过一分钟，旁边声音又喊起来了：“你没看到前面有车子吗，这样会撞上去的！”我赶紧刹车，很快又听到一个吼叫的声音：“干嘛停在路上？后面的车会撞上来的！”

发现即使彻底交出身体的控制权也没法让他满意后，我的选择很简单：“我再也不开车了！”虽然父亲平时是很和善的人，但他之后再如何鼓动我开车也没有用了。只要有一次这样的经历，我就一直对自己开车缺乏兴趣。如果把大吼大叫以及各种严厉的措施放在工作中，情况也会这样，员工很快变得“顺从”，再然后这些“顺从的员工”也没法令人满意了。他们变成没有灵魂和大脑的奴隶，管理行为从命令升级到吼叫，再到鞭子，最后变成刀子。

所以，对于用户故事没有写“so that”，我就这样问：“我很好奇啊，你的用户故事没有so that，是基于什么考虑呢？” “要把故事讲得更生动点，还有哪些方法呢？”

他会做出那个当下最好的选择：改进写法或者是在进度压力太大时暂缓；也会自己去寻找改进的方法，也就是使他“成功”的资源。而我就只需要等待奇妙的化学反应产生了……

结果也不错，他从自己的平凡中走出来，成为了引领改变故事写法的“英雄”。只要能接受改变没有期望的那么快以及过程有点失控，一切都很好。

说到不快，其实也不算慢。我们可以回忆下，学生时代老师教的课程是不是大部分考试完后就还给老师了？工作经历中，请来的管理顾问定的方案措施是不是很有道理，然后顾问一走没有保持外部强压，团队很快就该咋样就咋样，丢开那些方案反弹了？

只有人内在的改变才是持续的，慢就是快。