对部门内的所有团队实施统一的Scrum方法

Question

在我工作的地方，我们最近使用Scrum切换了敏捷开发。我们经历了典型的成长痛苦，但已经达到了一种目前看来可行的方法(从长远来看，这是否有效，这是另一个问题！)

显然，部门管理层对Scrum的转变感到高兴。但他们已经开始做一些我觉得不对的事了。

管理人员将观察一个团队，看看什么对他们有效，并向整个部门开出处方。比如：

• “已完成”的定义
• 哪一个故事点值可以用来指向故事(例如，从谎言中省略8)。因为1，2，3，5，13等是他们观察到的短跑中唯一使用的序列)
• 告诉团队，他们必须校准他们的故事点值1，以“更新UI标签”，并将其限制在20 的上限。
  • (虽然并不是所有的项目都有客户端，也不是所有的开发人员都有UI经验)

• 告诉团队用100的故事点估计值来表示“我们以后再分故事”
• 告诉团队使用无穷大的故事点估计来表示“这是一部史诗”或“我们需要更多的信息”。

我知道他们在努力提供帮助，但上面提到的不都应该是针对Scrum团队的吗？也就是说，对一个项目中的一组人有效的东西对另一个项目的另一组可能没有意义。

我担心的是，我们正在转向一种非常规定性和僵硬的敏捷方法。我是否有理由这么想，还是我反应过度了？

编辑

只是为了澄清..。我所说的“管理”和“经理”并不是指产品负责人。我指的是Scrum团队之外的任何经理，而是软件部门内部的任何经理。

Answer 1

你当然有理由这么想。事实上，你所说的“强制执行Scrum”是一个响亮的警报警报器。

Scrum首先是关于团队的自我组织；他们可以选择如何完成他们的工作，以及如何组织自己。管理部门只对需要做的工作有发言权。

团队应该组织自己的原因是，他们总是独特的，因为每个团队成员(和他们一起工作的人)的不同性质，以及他们工作的产品的不同。一种对一个团队非常有效的实践，会对另一个团队产生不利的影响。这就是为什么在一定范围内(经常使用沙箱隐喻)，他们必须进行实验，学习并找出对他们最有效的方法。

您需要的是一位非常胜任的Scrum大师(每个团队一人)，他可以指导团队进行这一发现，但同时也可以与管理层一起工作，以获得团队进行该发现的自由。

Answer 2

欢迎来到scrum最可怕的噩梦之一。您已经遇到了scrum未能交付每个人在采用scrum时所想到的优秀内容的原因之一。

不幸的是，scrum与高层管理不兼容，后者倾向于在整个组织和团队中集中和创建管理流程。为了取得成功，高层管理人员必须改变他们的心态，集中精力于团队所需要的东西。他们不应该关注团队是如何运作的。他们应该参与的唯一时间，是如果一个团队没有执行，以找出原因。

我相信你必须和管理层坐下来谈谈他们的需求，以及他们希望团队提供什么。这对所有团队来说都是一个全球性的要求。可以是估计，他们理解，持续时间等。这些事情不应该支配团队的进程。重要的是，要将管理期望与运行scrum的方式分开。每个团队必须找到他们自己的速度和他们自己的方式来推动项目，这将使他们成功，有效率，并交付管理所需的东西。例如，如果您有15个故事点的估计值，那么团队应该能够根据团队的平均速度将这些点计算成人工日(或小时)。但这对球队来说是独一无二的。

Answer 3

作为一家公司，平衡资源应该是一种竞争优势。否则，只需创建一群失去这种杠杆作用的软件公司。一个拥有多个团队和项目的组织必须关注翻转和团队平衡。我不认为对每一个独特的团队组合来说重写一本关于他们将如何使用scrum的书是个好主意。

每当你试图聚合事物来测量某物时，一致性是很重要的，即不要比较苹果和橘子。管理层应该关注这些更高层次的需求，但要确保他们不会过多地参与团队运作的细节。试着运用他们的建议，但是要准备为为什么一个团队可能是例外而辩护。任何个人不喜欢一种特殊的做事方式的人，都需要穿上成人的裤子，处理好这件事。

必须有一定的灵活性，这样你才能完成这项工作。必要时应保持一致性。如果团队成员被改变了，每个人都不应该觉得这是他们工作的第一天。

也许你的球队永远不会改变，但你应该给这个选择一个机会，保持一定的一致性。