自管理，而非放任自流：与 Scrum 开发者相关的常见错误
《Scrum 指南》将 Scrum 团队描述为跨职能且自管理的：他们在内部决定谁做什么、何时做、怎么做。开发者——即每个致力于在每个冲刺中创建可用增量任何方面的人——掌握着工作如何完成。这是 Scrum 最有力的理念之一，也是最常被误读的理念之一。“自管理”被听成了“别去管他们”，而一年的分布式远程工作让人很容易陷入这种误读。下面是由此而来的错误，以及如何避免它们。
把自管理误当作无人管理
自管理关乎对“怎么做”的决定权，而不是结构的缺失。最常见的失败，源于把这两者当成了一回事。
没有共享的完成定义。 自管理团队仍然需要清晰的完成定义。没有它，“完成”对每个开发者的含义都不一样，增量也就不是真正可用的。团队拥有这个定义，但它必须存在并被共享。
默默地认领任务。 当每个开发者都悄悄接走工作却不让它可见时，团队就失去了围绕冲刺目标自组织的能力。自管理依赖于透明——冲刺待办列表必须反映真实情况。
经理来分派任务。 经理、甚至 Scrum Master 来分发任务，会悄悄抽走“自管理”里的那个“自”。由开发者决定谁来做什么；Scrum Master 则辅导他们把这件事做好。
没有人对冲刺目标负责。 “自管理”不等于“没有承诺”。开发者集体地对每个冲刺创建有价值、有用处的增量负责。共担责任并不等于无人负责。
远程工作特有的失败模式
分布式团队也能把自管理做好，但距离会放大几个具体的弱点。请留意这些：
每日 Scrum 之间的偏移。少了走廊里的交谈，团队可能要过好几天才察觉自己已偏离计划。每日 Scrum 是开发者检视冲刺目标进展并据此调整的事件——务必守护它。
看不见的阻碍。卡了两天的开发者，对着屏幕远比在房间里更可能保持沉默。让提出阻碍成为常规且安全的事。
嗓门最大的人获胜。自管理并不是最自信的人说了算。团队需要一种方式，让较为安静的开发者也能塑造计划，尤其是在文字沟通和通话中。
在私下渠道里做出的决定。当选择发生在私聊里时，团队其余成员就无法围绕这些决定自组织。把决定放在所有人都看得见的地方。
良好的自管理究竟是什么样子
一支健康、自管理的开发者团队会主动拉取工作，而不是等着被分派；会把自己的计划和进展对所有人公开；并每天对照冲刺目标调整这个计划。Scrum Master 不指挥工作；他辅导团队走向自管理、清除阻碍，并帮助团队坚守自己的标准。产品负责人通过产品待办列表确定“做什么”和“为什么”；开发者掌握“怎么做”。
如果你的团队陷入困境，请克制通过分派任务来收回控制权的冲动——那只是处理症状，反而加深了病因。相反，应去强化自管理所需的条件：共享的完成定义、可见的冲刺待办列表、真正的冲刺目标，以及一个确实在检视与调整的每日 Scrum。自管理是团队逐步成长出来的能力，而不是第一天就能拨动的开关。
如果你的敏捷团队名义上自管理、实践中却停滞不前，XNM 的项目群与项目交付咨询服务 可以帮助你营造让自管理真正奏效的条件。