ScrumMaster的十大错误

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

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!

敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。