如何恰当地教授c级管理层关于Scrum的知识
嗨Scrum.org社区,2022世界杯国家队排名
我已经阅读了几个线程，并获得了许多有用的见解，以帮助我们部门采用Scrum。作为一个部门(研发)，在过去的几个月里，我们已经掌握了从瀑布式开发到敏捷开发的许多概念和必要的思维转变。我一直在履行Scrum Master的职责，现在我需要扩展到更高的管理层，以便教育他们这种方法是如何工作的。我的经理(也就是PO)在向c级高管解释Scrum时感到了一些阻力。他们的主要抱怨是用“为什么每个人都不忙”或“这家伙什么都不做”的老派观点来看待我们的部门。
虽然我清楚地知道“确保每个人都很忙”本身就是一种障碍，但我如何最好地在基础方面教育高层管理人员，让他们理解为什么这种心态在Scrum中不再有效?毕竟，我认为他们的目标应该是看到我们部门的产品发挥作用，而不是确保所有团队成员都有事可做。
如果我遗漏了任何必要的细节，我提前道歉。就问我。
谢谢你的帮助!
我最喜欢的一句格言是“看接力棒，而不是跑者”。重点应该放在正在做的工作和正在取得的进展上，而不是放在是否每个人都过早地优化了生产力。
在购买个人使用的软件时，你会问自己“这个产品对我来说有价值吗?”还是会问“我想知道每个从事这个产品的人是不是一直都很忙?”
如果团队以客户和企业都能接受的速度交付高质量的工作，那么与其他员工相比，一些员工的忙碌程度有什么不同呢?我们是“信任”(Scrum的5个价值观之一)团队能够自我管理团队内部的工作和任何效率低下的努力，还是更喜欢以命令/控制的方式对它们进行微观管理?
希望这能让您了解如何与c级管理人员一起解决这个问题。
我同意@Ian关于你的经理是产品负责人的观点。我通常看到和提倡的是，产品负责人是完全专注于产品的人，没有其他责任。Scrum Master只关注团队在向涉众交付一致价值方面的生产力和效率。我也很喜欢@Timothy提到的指挥棒。这是一个很好的类比。
在执行层，重点是确保你没有浪费钱，这样公司就能保持盈利。在以前，这意味着你不花钱请人坐着不干活。这被认为是确保你从顾客那里得到的钱不会被浪费的最好方法。然而，它没有考虑到一些忙碌的人在做客户不想要或不会使用的事情。发行新游戏才是最重要的。在当今的敏捷世界中，重点是在客户需要时根据他们的请求交付他们想要的东西。
你可能想看看循证管理(EBM)材料在这个网站上。我还建议你的领导也阅读它。这将有助于建立一个关于如何评估正确事物的共同理解水平。
嘿，约翰，我在这个位置上呆过很多次了，x在做什么?他还能做更多吗?在这个sprint中我们没有任何前端工作，y只是坐在那里吗?高级管理人员有时习惯落入微观层面微调效率的陷阱。有个词可以形容!
我更倾向于应对这种情况，让高级管理人员关注重要的指标，比如你说的为客户创造的价值。考虑一下，就你的特定产品而言，你如何将这些指标具体化，也许是呼叫中心的电话更少，bug更少，停机时间更短，向客户表达感谢的想法更多，客户满意度更高，甚至是一些定性的东西，如客户信心。
我认为这是你从瀑布式转向敏捷的过程中所期望的，所以请将其视为一个过程而不是一个事件。快乐走:)
