ScrumMaster的十大错误

敏捷进入中国有18年了，现在各个行业都在说敏捷，每个ScrumMaster都在说scrum。本身这是个好事，可是出现了很多“敏捷大仙”。用各种预定义的流程、工具、文档替代了敏捷，这已经背离了敏捷的精髓，敏捷的本质。

注明：BoB在工作中也碰到了很多敏捷的误区，与作者深有同感。

1. 因为敏捷而敏捷

其实大家并不关心敏捷，而是关心敏捷背后的那个“快”。（我有一篇文章专门描述，敏捷不是快）。除去“快”，敏捷更应该关注目标及个人成长。

ScrumMaster的口头挂着“敏捷、Scrum、看板”，经常会说敏捷要求我们做这个，敏捷要求我们做那个，blah,blah…… 这个不是答案，敏捷也不仅是项目管理工具或流程。敏捷更多是一种心态的改变。

敏捷应该帮助企业和个人实现目标（即价值）。

团队成员不想开每日站会，讨厌计划会，回顾会。为什么？因为团队认为敏捷是另一套流程，我已经996了，还要加这么多会议，不如去写代码。

在敏捷转型的过程中，“拒谈敏捷”，认真思考如下问题：

• 你的目标是什么？

• 为了达到目标，你需要什么？

• 达到目标的阻力是什么？

• 你怎么知道达到目标了？

敏捷里面有非常多的实践了，比如Scrum的5个会议，看板，用户故事，等等。但是用每个实践之前，尝试回答上面的问题，并且和团队一起来回答。

2. 管理心态

ScrumMaster不用管人，而是帮助改进系统，提升公司和个人价值以及移除障碍。ScrumMaster并不是角色，也不是头衔。 作为ScrumMaster，是与团队在一起帮助团队完成工作。提供团队的需要，解决团队的问题。

良好的ScrumMaster观察团队工作，使之透明并识别改进机会。

3. 推敏捷

不要向团队推敏捷，推工程实践。而是让团队主动用敏捷方法。 参考我之前的文章，推还是拉敏捷

让团队决定他们要如何解决问题。团队需要时间成长。

4. 4W1H（Who, What, When, WHere, How）

ScrumMaster主动的什么也不做。表面上什么也不做。产品开发是客户、产品负责人及团队的工作。作为ScrumMaster是帮助团队成长，改进系统。

下面这些对于ScrumMaster很常见：

• 分配任务

• 编写用户故事

• 提前规划迭代列表

• 估算

• 更新任务板

• 认为对所有问题负责

• 选择配置scrum工具

• 决定什么是团队的障碍

• 计算团队成员的能力（容量）

认真思考一下，作为ScrumMaster你有没有做过类似的事情。如果做过，请认真反思。

5. 定义团队协议及DoD

ScrumMaster和团队一起共同制定团队协议、DoD，而不是代替团队，一个人制定好。询问团队他们想要什么样子的协议，DoD。 这是团队的事情，作为ScrumMaster，是帮助团队制定协议和DoD。 让团队理解协议和DoD的好处，并制定出来。

6. 定义需求或任务

ScrumMaster是帮助产品负责人和团队的，但产品负责人和团队要做他们自己的工作。

产品负责人不准备产品路线图，不提前准备需求，不去和干系人或真实客户探讨，不梳理产品列表。 作为ScrumMaster，需要帮助产品负责人认识到这些问题，并提供相应的工具，辅助产品负责人。

7. 定义优先级及计划

不要成为产品负责人的代理，永远不要。 产品列表的优先级（顺序）是产品负责人的职责，ScrumMaster可以帮助产品负责人认识到：

• 如何排序

• 排序的参考因素

• 什么时间排序

• 什么时间准备好产品列表

产品负责人是产品列表的唯一负责人。（参见Scrum指南）

8. 定义度量指标

让团队自我定义目标和障碍，帮助团队认识到如何改进以及度量改进。 作为ScrumMaster，不应该代替团队制定指标。

团队来决定，如何衡量他们的进步（改进效果）

9. 没有足够的勇气

作为服务型领导、保护团队，保持冷静！ Scrum转型过程中，会涌现出很多未知的问题，ScrumMaster是团队第一沟通的成员。 但作为ScrumMaster，不要成为团队的瓶颈。

作为ScrumMaster，需要有足够的勇气，让团队尝试、失败，最重要的是从中进行学习。

10. 缺失系统思考

闭环思维，客户思维，端到端的思考方式。和其他ScrumMaster交流，建立社区，改进流程。

以终为始，一直考虑的是客户价值。

寻找系统问题。和管理层以及其他ScrumMaster一起，梳理价值流（信息流）。度量改进。

make everything transparent! 准备迎接挑战！ KAIZEN!