敏捷微观管理--真的吗？
让你的Scrum发挥作用#27
Scrum有很多失败的可能性。事实上，鉴于Scrum是一个具有合理而简短的 "手册 "的框架，这种效果不应该让人感到惊讶。例如，Scrum指南明确指出了Scrum团队层面自我管理的重要性。然而，许多使用Scrum的混乱尝试的普遍原因来自于我所说的敏捷微观管理，一种对敏捷原则的伪承诺，只是在从利益相关者或经理的角度看来有利的时候被推翻。
加入我，在不到两分钟的时间里深入了解自我管理的Scrum团队的重要性。
根据Scrum指南，Scrum团队和自我管理的目的
根据Scrum指南，Scrum团队是自我管理的。
"Scrum的基本单位是一个由人组成的小团队，即Scrum团队。Scrum团队由一名Scrum主管、一名产品负责人和开发人员组成。在一个Scrum团队中，没有子团队或等级制度。它是一个由专业人员组成的有凝聚力的单位，每次都集中在一个目标上，即产品目标。
Scrum团队是跨职能的，这意味着成员拥有所有必要的技能来创造每个Sprint的价值。他们也是自我管理的，意味着他们在内部决定谁做什么，什么时候做，以及如何做"。
除了这些对Scrum团队性质的直接提及外，在整个Scrum指南中还有很多对Scrum首要原则之一--自我管理的提及：
- 第4页：当相关人员没有得到授权或自我管理时，适应就变得更加困难。
- 第5页：在一个Scrum团队中，没有子团队或等级制度。
- 第5页：他们也是自我管理的，这意味着他们在内部决定谁做什么，什么时候做，以及如何做。
- 第5页：他们被组织结构化并被授权管理自己的工作。
- 第6页：Scrum Master以多种方式为Scrum团队服务，包括指导团队成员进行自我管理和跨职能的工作。
- 第8页：[Sprint Planning: How will the chosen work get done?] 如何完成，完全由开发者决定。没有人告诉他们如何把产品Backlog项目变成价值增量。
- 第9页：开发人员可以选择他们想要的任何结构和技术，只要他们的每日Scrum专注于朝向Sprint目标的进展，并为第二天的工作产生一个可操作的计划。这就创造了焦点并提高了自我管理能力。
请允许我指出一个明显的问题：自组织并不意味着没有管理。为什么一个Scrum团队要承担，例如，支付角色的责任？这是否有助于为客户创造价值？可能不太可能。因此，作为一个自我组织的团队并不意味着没有管理本身。然而，它确实意味着没有必要进行类似于1926年通用汽车公司装配厂的微观管理。
敏捷微观管理的原因
根据我的经验，由于中层管理人员对变革的抵制，敏捷变成了微观管理。尽管有更多的知识，将一个组织改变成一个拥抱实验和失败的学习型组织并不符合所有人的最佳利益。此外，自我组织、授权的团队往往与中层管理人员执行个人议程的动力相冲突，自我保护就是其中之一。我观察到，组织从敏捷原则--比如Scrum强调团队的自我管理--回归到敏捷的微观管理，只是口头上遵守原来的原则，有三个主要原因。
- 认为失去了控制：经理们被训练成他们部门所有问题的最佳人选，他们发现很难接受团队现在是自我管理的，并负责自己想出解决方案。如果他们的下属不再需要他们，他们岂不是迟早会被淘汰？
- 遇到严重的问题：管理层在关键问题出现的那一刻就放弃了自我组织，组成 "工作队"，而不是支持现有的Scrum团队来解决问题。
- 分配任务：管理者直接给开发者分配具体的任务，从而绕过了产品负责人，忽略了开发者的自组织特权。或者，经理把一个开发人员从团队中调走，让他从事这样的任务。
后果：假装遵守敏捷原则的行为寿命很短，因为Scrum团队中的许多从业者很快就会发现这一点。失去信任可能是毁灭性的，因为信任是一切的开始。没有信任就没有透明，没有透明就没有检查，没有检查就没有适应。这使我们回到了我们开始的地方。水落石出式的规划，掩盖了一个猜测可能成功的希望，并为发起人提供了事业上的推动。同时，实践者试图置身于不可避免的指责游戏之外，在月末领取他们的工资支票。"你假装我们是敏捷的，而我们假装关心结果"。
解决方案：接受这样的事实：在一个复杂的环境中，不再有专家可以解决他们面临的任何问题。因此，管理风格需要调整，从告诉人们什么时候做什么，如何做，到鼓励集体学习，探索选择，并确定团队合作产生的解决方案。管理层的任务是创造一个环境，让每个人都参与进来，在一个心理安全的地方让每个人都有发言权，从而实现这一目标。对于管理层来说，现在是放弃泰勒主义而采用仆人式领导的时候了。
结论
从保守的中层管理者的角度来看，有很多理由说明坚持指挥和控制的管理方式看起来对个人有利。因此，有一种诱惑，那就是采用任何敏捷的过渡方式来满足他们当地的最佳要求和个人的职业规划，从而形成敏捷的微观管理。这最终违背了在组织层面赋予自组织团队权力的初衷。
问题不在于这些人试图通过对敏捷原则的伪承诺来克服对其个人议程的挑战，而只是在看起来有利的时候推翻它们。相反，问题在于，支持敏捷转型的变革者几乎没有为这一事件做好准备。毕竟，《敏捷软件开发宣言》的四个价值不是常识吗？那么，谁会拒绝它们呢？
