Scrum Master的坏习惯

Scrum现在非常流行dev.process,而且项目经理突然获得新的头衔(Scrum Master).然而,它应该不仅仅是一个新的标题,而是新的习惯和新的范例.你的Scrum主人的坏习惯是什么？

不让scrums走上正轨 - 让他们进入技术讨论和更长时间的会议.

我们Scrum Master最初的一个坏习惯是认为我们会照顾自己的障碍.这是Scrum Master应该做的事情之一,但是她把它留给了我们直到它无法管理.

我们处理的另一件事是Scrum Master认为他们负责驾驭开发人员,直到完成任务.这会给团队带来不良气氛,因为他们应该自我管理.

对我和我们的团队来说,Scrum Master的工作是成为团队的盾牌和助手,阻止障碍并尽其所能帮助加快工作.Ken Schwaber的Scile 敏捷软件开发是Scrum的一个很好的介绍,这是我们团队使用的,我们已经非常成功.还有Scrum的敏捷项目管理,特别是Scrum Master和Product Owner角色.

事无巨细

执行旧式的指挥和控制,而不是促进自我指导的团队

在数字聚焦更多/燃耗/积压不是在人谁弥补球队

不保护团队免受外界干扰

分配工作并询问每日状态报告,而不是让团队学习如何管理自己的工作.

使用超级活动对团队进行微观管理

因为"Scrum说"和"团队必须投票"而压倒了高级开发人员的技术决策.完全取消了高级技术人员的权力.

试图在回顾中从一块石头上挤出血液来解决实际上没有问题的问题.

告诉我这些要点并不重要,但在每次审核时,这些要点都会被检测出来,每2周检查一次.此外,我们的年度奖金基于我们的积分表现.

Scrum是好的,但它可以忽视良好的工程实践和技术过程,这些实践和技术过程已经成为一种魅力.

不断交换进出Sprint的新bug.

scrum master有两种:

由于采用敏捷而改名的项目经理.

独家Scrum大师,只为项目经理(shusa)提供便利和报告.

第二点是在"真正的"敏捷组织中传播和实践.它很贵,但它有一些优点.

也,

预计scrum master将一直与sprint团队一起出现(不是字面意思).如果项目经理这样做,他/她将是微观管理.

Scrum主管的角色不是管理预算,而是根据团队可以做的工作量来预测sprint团队的可预测性.

Scrum主人应该了解团队成员的优点和缺点,并促进Scrum间的最佳实践共享.

所以,我的观点是,如果这些角色混淆,团队可能做得不好.

在流程的推后部分无济于事，例如“这些客户在这次迭代中都需要所有商店，这就是我们必须要做的”。