敏捷教练去哪了？
两年多前，美国总部的老板带着几位同事来上海出差，向我们介绍其中一位：「这位是塔拉，刚升的经理，之前是我们的敏捷教练。」
一年前，这位塔拉离职了。
几个月前，我问老板：「我在犹豫，是不是招一位敏捷教练进来，帮助团队持续地改进？」
老板毫不犹豫地回我：「公司在几年前定下的方向是，这些事情需要由 Leader 负责。」
不久前，一位认识的敏捷教练，加入了一个新公司，成为了 PMO 的一员。
我突然意识到，短短几年间，我认识的敏捷教练，真的越来越少了。
我对于敏捷教练的记忆
2006 年或者更早一些，Scrum 开始在中国零星发展；
很快， CSM 认证开始红火，很多公司开始有了 Scrum Master 职位，负责渐成燎原之势的「敏捷转型」。此情形持续了至少 10 年。
起步稍早的一些心思活络的 Scrum Master 们，很早就改称自己为 Agile Coach。
原因是大多数 Scrum，都会结合 Kanban （ScrumBan 就是结合的一个名词产物，现在也听不到这个词了），以及自动化测试、极限编程的实践。 把自己称为 Scrum Master 显得太局限了。
后来《持续交付》把 CI 扩展成了 CI/CD；Docker 和 微服务相互促进；云时代渐渐来临；终于，在敏捷陷入疲态时，DevOps 异军突起，成了新一代的 Buzzword。
很多人已经没办法对 DevOps 进行定义了，因为它已经包含一切。
原因很简单，DevOps 本身聚焦于软件研发的「最后一英里」，所以自然而然以拉动的方式，对所有上游的活动提出了要求。
它本身又是以技术实践起家的，跟火热的 Docker、云原生、k8s 等等结合在一起，成为了 Scrum、Less、SAFe 等其它 Buzzword 所不具备的「优势」。
至此，敏捷教练中，一个很清晰的派别分类已经呈现出来了：技术派和非技术派。
技术派中，除了 DevOps 中的 Ops 外，还有一个一直都很「小众」的极限编程派，尤其以 TDD 和「重构」作为信仰，像一股小小的清流，在繁杂的红尘中不为人瞩目地流着。
非技术派呢，最初的眼光停留在团队身上的 Scrum Master 们，也许是为了开好会议，开始学习「引导」，或者结合了涂鸦，进一步有了「视觉引导」。
又有少数人，开始走上了 Coach 的路。有关注于组织变革的「组织教练」，有关注于人的「高管教练」，更多的是关注于团队各种教练。终于，敏捷教练的「教练」二字，似乎有了更加名副其实的意义。
就跟 XP 作为技术派的小众清流一样，非技术派中也一直有个小众的清流，就是「Kanban」，这个「精益」里的一个小实践，在软件的世界里变成了一个独立的方法论。
「精益」和「敏捷」双峰并立，潜心修道者，都会化繁为简溯源于此；而商业派，则会端出琳琅满目的敏捷大餐，互助互惠的同时收割一茬韭菜。
纷纷扰扰中，似乎从 2020 年开始，当这个行业需要新的 Buzzword 时，「业务敏捷」这个容易让人诟病或误解的词昙花一现之后，「数字化转型」正式登上舞台。
敏捷教练的困境
十几年前和今天没有太多差别，敏捷社区仍然火热，甚至更加火热。
我从来没有做过全职的 Scrum Master 或者敏捷教练，但我一直都在这个社区，「敏捷」也一直是我一个重要的标签。
这让我更像一个旁观者，看着身边的敏捷教练，经历着不同的敏捷团队，我看到敏捷教练面临的困境也仍然在重复，并且更加凸显。
迎合一场运动 vs. 持续改进
有点好奇，为何这个社区从当初的「敏捷转型」到现在的「数字化转型」，一直没法抛弃「转型」这两个字。
很多人慢慢意识到了，「转型」是个陷阱，它暗示了一场一次性的运动，而公司或者团队需要的是持续的改进。
但是很多的敏捷教练，还是落入了这个陷阱。当初 CSM 证书的火热，让一个完全没有相关经验的人，经过两三天的培训，就成为团队的敏捷教练。
现在的证书只多不少，运动一场接着一场，这个陷阱越来越大。
不切实际的通才
十年前出现过一张图，Scrum Master 的技能或者角色，具体记不清了，但里面罗列了从 Facilitation 到 Mentor 等将近 10 个技能。
似乎在把敏捷教练塑造成一个通才。
讽刺的是，很多敏捷教练是本质工作做的不是很优秀的开发或者测试，在企业的「敏捷转型」运动中，在上了几天的培训之后，来担任的（否则他们也不会转），为什么期望他们转到这个新的职位上，就能成为优秀的通才呢？
不知为什么负责？
Scrum 的创始人显然也意识到了，Scrum Master 在现实中成为了会议组织者。
所以他们在最新的 2020 版 Scrum Guide 中，首次提出了「Scrum Masters are true leaders 」这个宣言。（可是，团队里的 leaders 不应该也是 true leaders 吗？）
这也是很多敏捷教练的困境：他们不知道为什么负责。当团队为交付业务价值负责时，为什么敏捷教练置身于外，只负责把会议引导好？
有种说法是：敏捷教练的目标是把自己做没。不管这个目标听着多么感人，事实是，它显然不是团队其他人的目标。
敏捷教练一边说「上下同欲者胜」，一边又把自己置于特殊的位置：我负责让你们同欲，可我跟你们不同欲。
伪自组织
部分是因为敏捷教练的目标的错位，自组织成为敏捷团队最大的迷思。
如同代码的可维护性越来越差，团队也只会越来越沉沦。这叫熵增定律。
自组织有一个很大的前提，就是企业有清晰的战略目标，并且团队能把它分解成团队的战略目标，而且这是个持续不断的过程。
单单这一项，就过滤掉绝大多数的团队了，谈何自组织呢？
最好的自组织团队也许是小型的创业团队，而他们偏偏不会有「敏捷转型」这个运动，也不会有敏捷教练这个角色。
擅长什么 vs. 公司需要什么
大部分的敏捷教练，也只是一线员工，却肩负着「管理」责任。
而所有的一线员工，或者初升为管理者的人，都容易有两个非常严重的问题：
- 仍然保留 operational thinking，而缺乏战略思维（strategic thinking）。
- 只做自己擅长的事，而不是公司需要自己做的事。
公司需要自己做的事，不是领导交代的事，而是居于战略思维思考并分解出来的需要自己做的事情。
敏捷教练热衷于跟社区链接，不断扩展自己擅长的领域，让自己本来擅长的事情变得更加擅长。
而回到公司，回到团队，虽然热热闹闹，可是常常无法带来持久的成效。
因为团队需要的，和他们擅长的，经常不是一件事。
无法识别瓶颈
团队需要的事情，往往是动态的。
除了来自于战略目标的拆解，还来自于对团队瓶颈的识别和预判。
而很多情况下，团队的瓶颈往往来自于技术领域。这让很多不懂技术的敏捷教练只能隔靴搔痒，并且还毫无意识。
我自己作为程序员出身的管理者，经常看到代码或者设计上的瓶颈时，都有一个问题：我恰好懂，所以能看到问题并提供帮助，那不懂技术的管理者或者敏捷教练呢？他们如何洞察此类问题？
这个问题至今没有答案，这个困境，也仍然在敏捷教练身上上演。
敏捷教练的出路
这个副标题容易引起误会，所以声明一下，这篇文章并非试图指点江山，它的出发点，其实是对我自己和一位同事的思考。
我思考的很俗也很危机感：随着年纪渐长，我作为技术出身的管理者，我的价值和出路在哪？
而我那位做敏捷教练的同事，他作为非技术出身的管理者，价值和出路又在哪？
持续识别团队的需要
如果我对自己或那位同事只有一个建议，我的建议会是：持续地识别团队的需要。
说些最近的故事。
前几天，我给美国的老板和业务团队老大们发了一封邮件，说了下对产品下一步规划的想法。并且建议开一个会来讨论，并决定下一步。
我习惯于在开会前把我的想法发给老板预览一下，目的是他可以提前了解，才能在会议上知道如何支持我。
他的回复是：希望这个会他可以不参会。
他同时在另一个邮件讨论另一件事时也明确说：「这个会我不参加，你们跟 John （就是我）讨论就行。」
是他不管我了吗？当然不是。他的一个需要是：需要我作为上海团队的负责人，能够独立自主地搞定事情，包括跟业务人员协调并且做出决定。
背后的背景，除了他对我的信任，还有他在美国，他的团队遍布几个州，他需要每个分部的人能独立做出正确的战略决定，否则他的团队无法再壮大以支持业务的战略需要，这个战略需要是，这个业务线需要在几年内成为公司最大的业务线。
这是我对「他或者这个公司对我的需求」的识别。这个识别是居于公司战略需要的。
回到战术上，这个团队需要快速地成长，要在变大之前变强。员工的招聘和员工的培训，团队的协作，都成了迫切的需求。
话说回来，老板对我的信任，是建立在我过去两三年里，持续不断地识别他或公司对我的战略需求，并持续地做符合这些战略需求的事情之上的。
而在这过程中，我总得挣扎地放弃去做我擅长的事情。
持续的领导力
作为管理者，如果有一个需求不需要识别就永远存在，那就是持续的领导力。
领导力就是跟熵增搏斗的那个力量。
失败的敏捷团队都是类似的：缺乏领导力。外部的教练进来一阵风走了，除了一些实践，什么也没留下。内部的教练热衷于实践，也不知领导力为何物。
领导力需要什么呢？需要视野和战略思维，持续地识别团队的需要。
而有一个需要是不需要识别就永远存在的，就是持续的领导力。
完美！（对不起我晚饭没吃饱，只能拗成这样了。）
识别团队需要的一个最重要部分是：识别团队瓶颈。
而团队的瓶颈往往不在技术上，就在业务上。所以管理者：你只能兼任技术 Lead 和 业务 Lead，你没办法只做一个。
为什么要有出路？
今天听到电视中一个人说：感觉生活没有出路。我就想：为什么要有出路？要出去哪里？
每天吃饭，睡觉，跑步，思考，读书，写点东西希望它有助于人，这就够了，不一定要去哪里。
有人让吃饱了饭，就得有所付出。以此致敬袁老。
