如今,Scrum 是相当流行的 dev.process 并且经常项目经理突然获得新头衔(Scrum Master)。然而,它不应该只是一个新的标题,而是新的习惯和新的范式。你的 Scrum master 有哪些坏习惯?
12 回答
不让 Scrums 保持正轨——让他们陷入技术讨论和更长的会议。
分配工作并要求提供每日状态报告,而不是让团队学习如何管理自己的工作。
我们的 Scrum Master 最初的一个大坏习惯是认为我们会解决自己的障碍。这是 Scrum Master 应该做的事情之一,但她把它留给了我们,直到它变得无法管理。
我们处理的另一件事是 Scrum Master 认为他们负责骑在开发人员的背上,直到任务得到处理。这在团队中造成了一种糟糕的气氛,因为他们应该是自我管理的。
对我和我们的团队来说,Scrum Master 的工作是成为团队的盾牌和助手,阻止障碍并尽其所能帮助加快进度。Ken Schwaber 的《使用 Scrum 进行敏捷软件开发》是对 Scrum的极好介绍,这是我们团队使用的,而且我们在这方面取得了相当大的成功。还有带有 Scrum 的敏捷项目管理,它更适合 Scrum Master 和 Product Owner 角色。
- 微观管理
- 行使旧式指挥和控制,而不是促进自我指导的团队
- 更多地关注数字/燃尽/积压,而不是组成团队的人
- 没有保护团队免受外界干扰
- 以高度活跃的方式对团队进行微观管理
- 在技术决策上压倒高级开发人员,因为“Scrum 说”和“团队必须投票”。完全剥夺了高级技术人员的权力。
- 试图在实际上不是问题的回顾会上从石头上挤出血液。
- 告诉我要点并不重要,但在每次审查时,都会对要点进行剖析,每 2 周在审查时分析一次。此外,我们的年度奖金基于我们的积分表现。
Scrum 很好,但它可以无视多年来像魅力一样发挥作用的良好工程实践和技术流程。
不断地在 Sprint 内外交换新的错误。
有两种 Scrum Master:
- 因采用敏捷而改变头衔的项目经理。
- 一个专属的 Scrum master,他只为 Scrum 提供便利,并向项目经理 (shusa) 汇报。
第二点是在“真正的”敏捷组织中宣扬和实践的。它很贵,但它有一些优点。
还,
- 预计 Scrum Master 将始终与 sprint 团队在一起(不是字面意思)。如果项目经理这样做,他/她将是微观管理。
- Scrum master 的角色不是管理预算,而是在团队可以做的工作量方面为 sprint 团队提供可预测性。
- Scrum master 应该了解团队成员的优势和劣势,并促进 Scrum 间的最佳实践分享。
所以,我的观点是,如果这些角色混淆了,团队可能不会做得很好。
对流程的推回部分没有帮助,例如“这些都是客户在这个迭代中想要的所有商店,所以这就是我们必须做的”。
不断尝试将实际工作时间与故事点估计值联系起来。
当我参与 Scrum 时,Scrum 主管很快养成了让我们做自己的事情的习惯,而 Scrum 又回到了我们正常的开发程序中。
- 无法在周期内适当地分配任务(通常太多)
- 与外部客户打交道不好(如果某项任务对于单个周期来说太大了,向团队抱怨而不是推回客户)
- 让每日 Scrums 成为一个过大的过程——不遵守一定的时间限制(我们更喜欢最多 15 分钟)。
我真的不喜欢当前 PM 成为 Scrum Master 时认为 Scrum 是一种减少他们最初(个人)义务的方法,而不是将时间投入到团队合作和积极减压(计划挫折)上。他们只是躺下并开始称赞自己取得的出色成绩,而每个人都可以看到,如果没有他们的存在,团队会表现得更好。
在我看来,我们最好的 Scrum master 是具有强烈责任感的开发人员,或者是非 PM。
话又说回来,我(在全世界都知道 Scrum 之前)为那些严重震撼的 PM 工作过。我敢肯定,他们今天会成为伟大的 Scrum 大师。