如何重拾对 "自组织 "团队的管理控制权？

你给了那个篮板手一个奇怪的眼神，然后说 “再见Felicia"，然后第二天你就召集全队开会，问他们这到底是怎么一回事。

如果真的发生了这样的事，我会马上炒掉那个白痴篮板手。这个传球手很危险，不专业，不适合他的工作。真正 "炒掉你的主教练 "的方法是辞职：他基本上只是向全队提出了辞职。

我不明白你为什么要担心。他们都是你的下属，没有权力开除你。

更重要的是，你要搞清楚到底是怎么回事。scrum master本人可能需要视情况而定，

在你的老板（或CIO）对你说同样的话之前，趁现在还来得及，趁早做。

虽然我曾与一些团队合作过，他们也采取了同样的做法，但听起来并不像在处理这件事时那么谨慎。我想分享一下我所看到的情况，看看是否能给你带来帮助。

首先，Scrum确实鼓励自组织团队。关于自组织团队，Scrum指南中特别提到的是：

他们是自组织的。没有人（即使是Scrum大师也没有）告诉开发团队如何将产品积压（Product Backlog）转化为潜在的可释放功能的增量；

这句话，以及其他很多关于跨职能和广泛的问责制的内容，都是为了鼓励团队成员问自己，问自己如何很好地完成了什么请求，以满足他们的要求。绝对值得花时间去阅读一下Scrum指南–它很短。

至于管理者，如果你发现你过去的工作一直在分配任务和跟踪工作项目，Scrum确实要求你退一步，从这一点上看，你的工作是要退一步。坦白说，如果Scrum大师在第一次回顾之前很久没有和你谈这个问题，那可能是他的失误。不过一个残酷的现实是，很多习惯了经理为他们安排任务的团队，并没有做好充分的准备，直接跳槽到这种方法。如果你觉得你的团队正处于这种情况，我建议你和Scrum大师谈谈这个问题。有很多技巧可以让这个过渡更容易。特别是，我会看看David Marquet的《领导力的阶梯》（Ladder of Leadership of Ladder），也许还可以看看他的书Turn the Ship Around。你会发现，在这两本书中，没有一个经理人被解雇。

最后，让我们来看看，如果你在过去成功地管理过的人，为什么你要做这个过渡。简而言之，就是帮助他们学会管理自己，你会获得更大的成功。关于这个问题的研究和数据太多，甚至很难知道从哪里开始–但我想说的是，这是一个很好证明的事实，所有的人都有潜在的自我组织能力，在一个团队中，比如说，十个、十一个人（包括你的）的大脑总是比一个人解决问题更有效，如果解决方案出了问题，另十个人在一旁等着把责任推给你，这是个很好的证明。我总是会告诫一个团队不要直接 “开除 "一个。即使你像你的问题中所说的那样令人望而生畏，你管理着面前的每一项任务，我也曾与很多这样的管理者共事过，他们仍然是团队的惊人资产。在这些自我组织的团队中，你把所有的时间都花在指挥团队的行动上，转而确保他们的成功之路是清晰的，而且总能得到更好的结果，团队能提供更多的成果，而经理人也有创造摇滚明星的声誉。

• 在scrum的背景下。产品主说的是什么？这不是scrum主的职能，要求更多（或更少）的资源，这不是scrum主的职能。这是产品负责人需要与利益相关者保持一致的事情

• 在scrum的背景下。回顾是关于过程和团队和项目的回顾（不是关于 “我对老板的感觉如何"）。如果你是团队的一员，你应该被邀请参加。如果你不是团队的一员，回顾会应该只涉及到你在项目中的角色。

• scrum大师告诉直线经理该怎么做至少和直线经理直接参与到scrum中一样荒谬

所以scrum大师显然是越位了。

如何进行：

• 你在一对一的会议中与团队进行交谈，问他们发生了什么事。你解释清楚，scrum master是不是线职能，他不_集结团队。同时问他们觉得你应该不参与日常事务的地方

—-让团队清楚地知道问题应该向谁解决

—-你去找下一个线上的人（如果是CIO，那就是CIO—-几个月没有经理是不能接受的）。说明情况需要立即解决（通过开除scrum master或者CIO与他有一句话，说他会被开除在目前的路线上），否则会危及项目–在我看来，这听起来像是scrum master不明白自己的职责和界限。对于团队试图 "开除 "他们的经理作为回溯的一部分，专业的回答应该是 "解决你和你老板之间的关系不是我的事，这绝对不是项目付给我们的钱"。

我已经向团队强调了自我组织团队和团队赋权的好处。

好吧，他们当然把_那部分放在心上了。

看来很明显，你现在的情况很情绪化。显然，你的团队对你和他们之间目前的关系有一些重大问题。你没有参加回想会可能是件好事，因为通常情况下，人们之所以会突然愿意说出真正困扰他们的事情，就是因为这个原因。如果他们愿意围绕着一个只合作了几周的Scrum Master来做，那么要么他们已经信任这个人了，要么他们已经很烦了，以至于他们真的不在乎后果。

无论哪种方式；这并不是一个新的问题，在你换了Scrum或者雇佣了一个新的人之后突然出现的。这是一个已经发酵了很长时间而没有被发现的问题。常常有人说，工作敏捷并不会产生新的问题，而是让已经存在的问题变得极为明显。 这很可能就是这样的情况。他的工作是帮助团队朝着自组织的方向发展，当然。但是，这不是正确的方法。首先，他不能真的解雇你，而只是告诉你 “这是团队想要的 "是完全没有建设性的。我不确定他认为这样做的结果会是什么，但这不可能是团队认为的结果。你不能随便把一个不知道有问题的人撤掉。如果不出意外的话，这将会让每个人都害怕，如果他们错过了一次回想，他们可能会突然回到工作岗位上发现自己被开除出团队。这将会造成一种恐惧的氛围，而不是信任。在敏捷工作中，信任和开放的氛围是你_想要的。

所以，既然你的Scrum Master没能在开放的氛围上下功夫（至少在团队外，他似乎已经让人在内部开放了不少），也没有找到建设性的解决方案，那么似乎就应该由你来做。Scrum和敏捷是关于授权人们做自己的事情，在这一点上主张你的权威，很可能会导致整个团队被解雇。团队已经声明，他们已经到了要人走人的地步，所以虽然他们可能已经把人弄错了，但是和他们正面交锋，很可能会以至少有几个人离开而告终。记住关于离开的最重要的规则：最有价值的人将是第一个离开的人）

所以如果你真的想和这个团队一起做Scrum，这个时候你必须接受他们的能力，让他们决定如何工作，并就他们想如何组织团队进行公开讨论。他们不能解雇你，但他们已经很清楚地表明，你现在做的事情对他们来说并不可行。你需要谈谈你未来的角色是什么，他们需要你做什么，你需要从你这里得到什么，以及这一切如何安排。请记住，他们可以决定他们的工作方式，但最终还是需要交付产品；他们将会_根据他们所交付的东西的质量来评判。如果你需要他们做一些组织上的事情，他们也要做这些事情。(话虽如此；和他们一起研究这些事情的形式，并确定这些事情是真正需要的，然后再强制执行)。

确保在那次会议上，你不要从你的权限出发，不要从你的权限出发；整个想法是让每个人都站在同一起跑线上。你们都是同事，都是个人，都有工作要做，都想把工作做好，都要在日常的工作中一起努力。做一个独裁者通常只会让大家互相对立，这样是没有效果的。所以，在这里要尽量做到脆弱，要愿意承认自己做错的事情。你们需要想清楚如何从这里开始做人。

听起来，你们的团队在团队发展的过程中遇到了暴风雨阶段，他们遇到了hard。现在要看团队（至少现在我把你也包括在内）如何去想办法了。请注意，不是所有的球队都能走出这个阶段，我不能保证这种方法就能解决问题。我可以保证不会比退出或解雇所有人更糟糕。

还有，一定要和Scrum Master单独谈一谈。我不知道是什么原因导致他用这样的非建设性的第一条信息打开，但他需要努力提高自己的沟通和解决问题的能力。

祝你的 状况。你当然生活在一个有趣的时代；好好利用这个时代，并从中学习到你能学到的东西。

（我在这里也假设Scrum Master不会让整个团队在没有一些严重的潜在问题的情况下造反。如果他能做到，而且他对你的工作垂涎三尺，那他就是一个操纵大师。一旦你到了你认为是这样的地步，你就得赶紧除掉这个人asap。这可能是我考虑利用你作为雇佣他的人的权力，开除他的情况。)

无论他们是否有实际权力解雇你这个经理人，你只是因为你喜欢Scrum，就强制要求改成scrum，是你自己带来了这种情况。你并没有和他们讨论过这个问题。你可能是在你作为经理的权利范围内，但尽管如此，这是一件愚蠢的事情，当然，他们现在也会质疑他们是否愿意为你工作了。

你没看到他们宣称的自强不息和自我组织是他们采取这种行动的基础，这其中的讽刺吗？

你需要在明天上午9:15召开会议，为没有考虑到他们的意见而做出如此重要的决定道歉。然后，你可以征求他们的反馈意见，问他们认为第一次冲刺的过程是如何进行的，有什么地方可以做得不一样。

如果你想在这个团队的流程中引入一个新的工作流程，你可以在较小的范围内进行尝试，把具体的任务作为一个试点项目，选择少数几个愿意开放的团队成员来给它一个公平的评价。

有了授权的员工，说服、包容和鼓励比强制执行要好。

换个角度：你有没有想过他们只是在嘲笑Scrum过程及其 “自组织 "方面的问题？坦率地说，我无法想象他们是认真的，在读你的帖子的时候，他们是认真的，而且还笑得很开心。软件开发人员（我就是其中之一）往往是相当愤世嫉俗的人，他们的幽默感很干瘪，不是每个人都喜欢或者说不是每个人都认可的。我相信他们只是在告诉你他们不喜欢Scrum而已。

正如@Sascha正确地观察到的，这看起来一点也不像Scrum：

• 一个Scrum团队没有经理，他们对产品负责人负责。产品负责人代表股东对团队的利益，在冲刺开始时安排好冲刺的交付品，在冲刺结束时接受结果，并在这期间澄清团队的要求。他本质上是团队和公司之间的代理， –如果你是Scrum团队的一员，你会参加回顾会。如果你不是Scrum团队的一员，那么会议应该只限于你在Scrum模式中对团队的作用。

所以，问题是。你在这幅图中的位置是什么？你在Scrum模型中的角色是什么？ **既然是你的想法，那么在提出Scrum之前，你肯定研究过Scrum，也想过这个问题，不是吗？可以说，如果一个经理在转到Scrum的时候，如果他们没有被视为团队的一员，那么对他们来说，最无缝的过渡是产品负责人*，你会继续做同样的事情–但现在团队要集体向你负责，而不是每个成员单独向你负责，而且你不再对他们进行微观管理，除非他们特别要求（可以说后一种情况对双方都是好事）。

*我怎么才能化解这种局面，重新建立起我作为他们经理人的权威，同时又能坚持敏捷的自我组织和团队授权的原则呢？ *

从什么时候开始，你是这个团队的经理人了？我不认为一个团队会因为仅仅因为1个话题的分歧而反叛直接经理。这个问题可能比敏捷方法更严重。

这对一个经理来说是很关键的事情，你需要解决，这应该是你接下来几周的头等大事。

你的N+1、N+2都请假几个月了？ 可能影响了你的团队造反。公司的财务状况如何？ 如果财务状况不好，员工可能会认为你的工作做得不好，没有你可以做得更好）。(把这个话题告诉大家是非常重要的，因为他们都知道，如果影响到日常的工作，那么这个话题是非常重要的)。-找出真正的问题（只是这个敏捷方法，还是你之前和团队有什么问题？-当你知道真正的问题后，你需要调查：谁是对的，是你还是你的员工？-确定谁是这个叛逆的领导者（总有一个员工比其他人更藐视权威）。如果你认为他越轨了，你需要采取纪律处分。

我不知道 “经理 "在你们公司里是什么意思，但一般来说，我认为它是指帮助团队需求和提高团队绩效的人。现在：

我是敏捷的忠实拥护者，所以我请了一个scrum大师，说我们将遵循scrum。而不是先巩固团队，关于你的想法。我认为每个团队都有权利批评你的想法，并在你的想法上打洞，如果你的想法不坚定，你应该可以放弃它。**你是他们的经理，不是他们的老板*，这是两份非常有特色的工作!

“守则更像是你所说的 "准则"，而不是真正的规则。” - Barabossa队长

在我听来，你的处境很窘迫，你试图坚持一些不合理的理想。

我已经向队员们强调了自我组织团队和团队授权的好处。

向你的孩子们解释一下，自我组织和授权并不意味着他们可以为所欲为。如果你的团队决定去偷一些自动武器，去抢银行，你并不因为他们被授权了，就有义务去执行。那是你的经理人的职责。开除总是来自于上层，而不是来自于下层。当然，他们可以跳级，和你的老板一起把你撤职，但由于你的老板和你的老板的老板显然都在休假，没有在他们不在的时候把人到位，所以没有什么等级制度可言。你还有几个月的时间。

我跟scrum大师说过，我想跟团队里的人谈一谈这个问题，但他很坚定的说，我在的时候他们觉得 “被吓到了"，不想跟我讨论这个问题。

好吧，那对他们来说太可惜了。无论如何，还是要和他们谈谈。自我授权可能会让你有能力做自己的决定，但它并不能让你从责任中解脱出来，不辜负这些决定。如果我有一个这样的团队，和他们谈话是我考虑的最好的级反应。

有人可能会说："哦，但是SCRUM大师应该是解决像这样的障碍。一切都应该通过他来解决。” 好吧，那就难办了。他把这一点搞砸了，当他去找你说你被开除了，却没有以足够礼貌的方式让你接受。一个SCRUM大师应该有比这更高的人际交往能力。

那你怎么说？

首先，你要弄清楚他们是否真的决定 “开除 "你。你一个人的话，我确实认为这种情况下，团队应该可以直接说出自己的说法。

其次，考虑一下 "开除 "是什么意思。你宣称自己是一个手握重权的主教练，但他们却要你走人。他们不是写工资单的人，所以解雇你的决定并不是 "哦，他们没有发挥自己的作用 "这种决定。那是 "这个人在积极阻碍 "的决定。这里有什么东西真的不对劲。在你做任何有意义的决定之前，你需要需要它为你加起来。作为一个在互联网上匿名的人，我不能说是你还是他们或者是SCRUM大师，但是在这种情况下，something_真的是真的真的真的有问题，你最好在和他们谈完的时候就知道是什么。做一个管理者。想办法解决这个问题。找到一个让你能够做你的工作，而他们做他们的工作的方法。

现在，如果他们的回答让你有了足够的封闭性，让你尊重他们的自我授权，现在你要向团队展示一下，当你这样 "解雇 "领导时，会发生什么。说："好吧，我就不做你的经理了。我就不再充当你的经理人了。你不能实际开除我，因为那不是你的立场，但如果你想玩这个游戏，我们可以玩。我曾经是你的经理人 帮助你远离公司政治和向上级领导汇报的压力 现在，我是你的上层管理者，你不再有这种绝缘体了。现在，既然我不能把自己从这个位置上撤下来，那我就干脆从高处开始转发任务。” 解释一下，团队投票了，不代表你对上层管理人员没有义务，你就没有义务去履行，而且还会继续履行。"

那就去找人帮忙吧。"

兵变不是小事。你的整个团队就这么把你一票否决了。别小看它。找你上面的人帮忙。也许你可以给你的老板打电话请假。也许你可以和你的首席信息官谈谈。有人需要知道你的公司有一个大的人际关系问题，而且你正在解决这个问题。

我建议的解决方案是，通过选择领导（即CIO）会想要的东西来要求领导（即CIO），精心打造你作为 “承担要求的经理人 "的形象，这是在打造一些自我实现的过程中，与这种自我实现的过程中，精心打造的。他们可能会认为自己想做什么就做什么，但你还是有义务让他们成为一个成功的团队，如果你非要从远处做，就从近处做。找出你的甩手掌柜的做法让人望而生畏，并确保你永远不要这样做。

最终的目标是让他们意识到你是站在他们这一边的。如果他们是真正的自我授权，那么他们需要意识到你是团队中有益的一部分。只有当他们成功了，他们才会意识到这一点。如果他们被不可能的事情所淹没 死线和无望的繁文缛节，他们永远不会看到。

只要确保所有的加起来就可以了。2+2=4. 一个 "甩手掌柜 "被新来的SCRUM总管 "开除 "了，因为太吓人了，而两层管理人员却在放假？从这里看，有些地方不对劲。你更贴近实际情况。找出不符合的地方，再去解决。

要么：a)他们是对的，你的存在是失败的。他们还是不能开除你）或者b）scrum master想要你的工作。

我觉得你最好的办法就是去上一个为期2天的scrum master课程，把你的scrum master弄走。然后你可能会在年底的时候因为做了两份工作而获得奖金。

在scrum团队中，没有管理人的角色。真正的问题是，为什么你一开始就认为自己是团队成员。如果你不参与功能交付，你在这个团队中就没有地位–所以团队所做的事情是正确的。

如果他们认为你是一个障碍，那就找出原因–很可能的情况是你在干涉，而解决的办法是你退出，让他们做他们的工作。想出一个与scrum目标一致的有用的答案，然后向团队强调你打算做那份工作，而不是干涉他们的工作。

所以我不明白为什么你不能把这看成是积极的事情？我的理解是，一个自我管理团队的目标是不需要经理人的。

你需要做的是看清楚这带来的机会。你基本上有了一个可以自我管理的超级团队，现在你就可以做到以下几点：

–你可以更容易让团队对公司的承诺负责。如果他们不能完成公司的目标，那么他们根本就不能自我管理 —你能够在团队中增长技能。所以现在你可以把更多的精力放在团队的人员方面。职业成长、赋能之类的事情。 –意识到团队+scrum master在公司的层级、预算和绩效考核过程中，仍然要对你负责。所以他们不可能越过你的头顶。

所以现在就当做是成功了。多想一想你如何加强团队的机会。**也要意识到，在这种自我管理方式失败的情况下，你需要在那里为这种自我管理方式的失败做准备。

老子说：

邪恶的领导者是被人们所鄙视的人，

好的领导者是被人们所推崇的人， 当一个伟大的领导者领导，人们会说："我们自己做的"。

当人们几乎不知道他的存在时，领导者是最好的，

当他的工作完成了，他的目标实现了，

他们会说：我们自己做的。

但是当你做了，你就做了，必要的时候你就踢鼻子，你是对他们的工作负责的人，毕竟–人们确实会因为你的推荐而被开除，开除你应该的，而且是及时的。

我不知道为什么任何开发者会开除一个不妨碍他们工作的人，他们基本上都是在那里为他们解决问题，保护他们不被客户甚至偶尔的上级所左右，照顾到设备的可用性，文档的可用性，不断地催促他们成为更好的程序员和更好的人，让他们能够专注于代码。

你还是他们的上级–如果你需要的话，你仍然可以开除他们，你没有被这个职位开除。你只是被认为无用或不利于开发工作，他们宁愿没有你也要玩。

要么是这样，要么是团队文化出现了一些严重的病态。

我在这里可以看到两种观点：

—你曾是矩阵式组织中开发团队的线经理，现在你仍然是线经理。你的工作可能发生了一些变化，但本质上是一样的–你根据公司的预算/人力资源流程，为PO提供开发人员的工时，你负责招聘（如果需要的话，你负责解雇），你与团队合作安排休假，等等。就像所有的事情一样，scrum如果走到极端，可能会造成伤害，_某某人应该注意，比如说，除非有非常好的理由，否则技术堆栈要保持兼容。在这样的组织中，这就是直线管理的工作。 - 你是开发团队的***成员，你对技术决策、架构等有直接的投入。在这种情况下，我会建议你搞砸了，因为你在这第一个冲刺阶段没有足够的参与，因为他们没有看到你将如何为团队贡献你的技术。在下一个冲刺阶段，和团队一起工作。

我是一个开发团队的经理

我是敏捷的忠实拥护者

很好！我是一个开发团队的经理。如果你说的 “敏捷 "指的是 "Scrum"（否则为什么要请一个Scrum大师，否则………..），那么一切都很好

他们历来遵循的是一种非常瀑布式的方法论，并且一直抵制变革。他们已经改变了自己的方式；他们已经放下了抵触情绪（你没有告诉我们他们抵触的是什么，之前…）。他们已经了解了Scrum团队中的角色。

正如你肯定知道的那样，在Scrum团队中，经理的责任非常渺茫，你既不是Scrum大师，也不是产品负责人，也不是Stakeholders之一，更不是Scrum团队本身的一部分。我记得我在一个为期3天的研讨会上拿到Scrum Master证书的时候；"经理 "的角色甚至不在图表上。

如果你的公司使用的是典型的矩阵式结构，即纵向的直线管理与横向的项目相关（或产品相关）管理（即直线经理<>项目/产品经理），那么一切似乎都在按计划进行。你仍然会有管理责任，也就是说，管理团队日常生产性工作之外的一切。

让我重复一下你的关键句子：

我是敏捷的巨大拥护者

现在是一个很好的时机，拥抱这一点，学习管理Scrum团队的意义。现在你的责任也发生了变化。你要做的是常规的事情（入职新成员，处理工资，帮助团队能够工作（为他们提供硬件/软硬件等，以及良好的工作环境），也许还可以与其他Scrum经理合作）。事实上，你的公司似乎对组织单位的认可并没有改变。你的团队成员仍然需要和你讨论，只是不需要讨论他们的工作。

根据你之前的日常工作（向单个开发人员发放工作包），你可能会想看看你可以做的其他事情。比如说，你可以对你的团队为哪个项目工作有发言权，或者如果某个产品负责人在某方面变得很讨厌，你的工作就是安抚他。你可以负责管理客户的合同（销售等）。你将是你的团队的合作伙伴和挡箭牌，以防事态升级。你的工作是管理。管理和开发软件不一样；而给个人分配任务只是其中的一小部分。

说实话，我会说你很幸运。乘风破浪。让他们去做他们的事情。避免把他们的新Scrum管理走了；Scrum正是为了让团队自给自足，能够在没有外部不断的微观管理的情况下执行。Scrum的很多部分是为了屏蔽一个团队不需要的管理而做的。

你的工作现在可能会很轻松。如果一切按计划进行，他们会处理很多你之前必须要做的事情。从现在开始大家可能都会很高兴，特别是如果他们之前不喜欢你的微观管理的话

团队已经集体同意 "开除 "我这个经理

显然，我假设既然你引用了 "开除 "这个词，他们并没有从字面上给HR发邮件把你排除在工资表之外，而是告诉你，他们想把Scrum活到它的全部（和意图）。很明显，我是在假设他们其实并不想在你们公司的组织结构图上划线。即使是一个纯粹的Scrum团队，也仍然需要在公司的某个地方扎根，也就是说，成为线上管理的一部分，那就是你。你只是不再参与到日常的工作中去了。