你的Scrum大师的坏习惯[关闭]

我们的Scrum管理员一开始有一个很大的坏习惯,那就是认为我们会处理好自己的障碍。这是Scrum管理员应该做的事情之一,但她把它留给了我们,直到它变得无法管理为止。

我们处理的另一件事是Scrum管理员认为他们负责在处理任务之前让开发人员退缩。这在团队中造成了糟糕的气氛,因为他们应该自我管理。

对我和我们的团队来说,Scrum Master的工作是成为团队的盾牌和助手,阻止障碍,并尽其所能帮助加快速度。肯·施瓦伯的 带Scrum的敏捷软件开发 是一个很好的Scrum介绍,这是我们的团队使用的,我们已经非常成功。还有 带Scrum的敏捷项目管理 更适合Scrum主角色和产品所有者角色。

不要让Scrum保持在正常的轨道上——让它们进入技术讨论和更长的会议。

1. 微观管理
2. 执行老式的指挥和控制,而不是促进一个自我指导的团队
3. 关注的更多是数量/消耗/积压,而不是 人 谁组成了这个团队
4. 不保护团队不受外界干扰

分配工作并要求提供每日状态报告,而不是让团队学习如何管理自己的工作。

1. 以超活跃的方式对团队进行微观管理
2. 在技术决策上凌驾于高级开发人员之上,因为“Scrum说”和“团队必须投票”。完全剥夺高级技术人员的权力。
3. 在回顾那些实际上并不是问题的问题时,试图从石头中榨取血液。
4. 告诉我这些要点并不重要,但在每一次审查中,这些要点都被剔除了,每两周审查一次。此外,我们的年度奖金基于我们的分数表现。

Scrum是好的,但它可以忽略好的工程实践和技术流程,这些都像是一种魅力。

有两种Scrum大师:

1. 项目经理,其头衔因采用敏捷而改变。
2. 一个专门的Scrum大师,他只促进Scrum并向项目经理(Shusa)报告。

第二点是在“真正的”敏捷组织中宣传和实践。它很贵,但有一些优点。

也,

1. 一个Scrum大师应该一直和Sprint团队在一起(不是字面上的意思)。如果项目经理这样做,他/她将是微观管理。
2. Scrum Masters的作用不是管理预算,而是将可预测性放在Sprint团队周围,以团队可以完成的工作量为标准。
3. Scrum管理员应该了解团队成员的优点和缺点,并促进Scrum之间的最佳实践共享。

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

在冲刺中不断地交换新的bug。

不帮助处理流程的后推部分,例如“这些都是客户在此迭代中想要的所有商店,所以这是我们必须做的”。

不断尝试将实际工作时间与故事点估计值联系起来。

当我参与到一个Scrum中时,Scrum管理员很快养成了让我们自己做事情的习惯,而Scrum又回到了我们正常的开发过程中。

1. 无法在周期内适当地分配任务(通常太多)
2. 与外部客户打交道不好(如果某项任务对于单个周期来说太大,则向团队抱怨,而不是向客户施压)
3. 使每天的清理过程过大——不遵守特定的时间限制(我们更喜欢15分钟的最大值)。

我真的不喜欢当前PMS变成了Scrum大师时,我认为Scrum是一种减少原始(个人)义务的方法,而不把时间花在团队工作上,积极减少压力(计划挫折)。他们只是躺下,开始赞扬自己取得的伟大成绩,而每个人都可以看到,没有他们的存在,团队的表现会更好。

在我看来,我们最好的Scrum管理员都是具有高度责任感的开发人员,或者非PMS。

然后,我再次为严重震动的PMS工作(在世界了解Scrum之前)。我敢肯定,他们今天一定会成为出色的Scrum大师。