总结了24个常见的Scrum陷阱

Scrum 是最流行的敏捷方法…如果算上所有团队“Scrum Butt”.  Doing Scrum really well is much harder and much rarer.  Here is a list of 24 common pitfalls or bad behaviours of Scrum teams:

  1. 过多的准备/计划:Scrum不需要常规的大型前期计划。取而代之的是,团队可以开始使用Sprint评论中的不断反馈并调整计划。在第一个Sprint开始后,甚至可以创建Product Backlog。
  2. 专注于工具:许多组织试图找到一种电子工具来帮助他们管理Scrum流程……甚至还不知道如何做好Scrum!因为最容易上手,所以请使用手动和基于纸张的跟踪来早期使用Scrum。寻找工具通常只是入门的障碍。 (此外,请查看  敏捷 Manifesto says about tools.)
  3. 日常问题解决中的问题:不应使用Daily Scrum 来解决所提出的问题(障碍,障碍)的解决方案。取而代之的是,让会议时间很短,然后只与感兴趣的人进行解决问题的对话。 Scrum Master促进了这次会议的进行,以保持会议的进度。
  4. 分配任务:尽管自组织团队的概念已经存在很长时间了,但是仍然有人认为项目经理或团队负责人应该将任务分配给团队成员。与“接管”并分配任务相比,等待某人加强工作更好。
  5. Sprint重新启动失败:尽管取消Sprint的情况很少见,但是尝试重新启动之前要等待一切都“完美”或“就绪”,这很诱人。球队应该 立即 取消Sprint后重新启动。
  6. Scrum Master作为贡献者:ScrumMaster就像是一名消防员:他们可以闲着-只是看着团队-等待紧急障碍。承担任务往往会分散ScrumMaster的注意力,使其无法帮助团队遵循Scrum规则,大力清除障碍以及保护团队免受干扰。
  7. 产品负责人未显示:产品负责人是团队的正式成员,应出席所有Scrum会议(计划,审查和每日Scrum)。同样,在工作期间也应该有产品负责人。当然,PO也需要与利益相关者合作,并且在此期间可能不在,但是这些讨论应该安排在团队会议时间之外进行。
  8. 伸展目标:团队决定在Sprint中要完成多少工作。没有人应向团队施加压力,使其过度投入。这只会引起不满,不信任并鼓励低质量的工作。就是说,挑战总体项目或产品目标当然会启发团队。
  9. 个人英雄:Scrum团队中的个人不应该过多地加班,或者以任何其他方式尝试成为团队的“英雄”。 Scrum 帮助我们建立 伟大的团队,而不是伟大的团队 (引自Barry Turner)。
  10. 团队组织产品积压:团队没有对用户需求的适当洞察力,而应专注于解决技术问题。产品负责人需要对投资回报率负责,因此出于“技术”原因,应该抵抗团队的压力,以特定的顺序进行操作。
  11. 产品负责人指定解决方案:产品负责人必须让团队有足够的自由提出产品积压中提出的问题的解决方案。 PBI应该没有技术规格,除非它们可以直接与客户或最终用户的要求联系在一起。
  12. 紧急中断:不应在Sprint中允许紧急打扰…相反,如果足够紧急,团队应取消Sprint。否则,应将中断记录在产品待办事项列表上,并推迟到下一个Sprint开始。
  13. 进行假设:团队成员通常不会向产品负责人询问他们正在进行的工作的详细信息。团队成员可以解决问题,但了解约束至关重要。 PO和团队成员之间的反馈应该在Sprint的每一天都在持续进行。
  14. 未完成:这很难防止不时发生,但它可能成为团队过度投入的习惯。确保这样做的团队有效地使用了燃尽图,并且即使没有完成所有工作,也保持着演示。
  15. 演示尚未就绪:有时,团队会忘记准备演示所需的时间:清理团队空间,设置演示环境,准备脚本以及确保准备关键的涉众。这些活动可以是Sprint Backlog中任务的一部分。
  16. 无法交付原型:Scrum团队应该尝试从第一个Sprint开始就生产生产质量的,“可能可交付的”软件。构建原型代码只会延迟编写生产代码的必然需求。同样,也应避免使用线框,详细设计和其他类似工具。
  17. 分布式团队:尽管Scrum并未正式要求将团队成员并置在“作战室”中,但现实情况是,团队成员的任何分布(甚至只是分成单独的小隔间)都会对透明度和沟通产生巨大的负面影响,这反过来又对对生产力和质量产生巨大影响。
  18. 指令ScrumMaster:ScrumMaster需要成为促进者,以支持团队学习自我组织和Scrum规则。 Scrum Master应该  决不  倾向于提出团队成员的工作方式,以及下一步要做的工作。
  19. 改变团队成员:Scrum是创建高性能产品开发团队的框架。如果Scrum团队的成员资格发生变化,它将迫使该团队重新开始“ Forming-Storming-Norming-Performing”序列。如果团队处于“规范”或“表演”状态,则出于任何原因更改团队成员资格都将浪费大量投资。
  20. Scrum 团队中的非Scrum角色:对于组织而言,创建一个Scrum团队而不更改该团队成员的正式头衔和职责是很常见的。例如,作为项目经理的人可能会被赋予产品负责人的职责,而无需正式更改标题。 Scrum 团队应该只有一个ScrumMaster,产品负责人和团队成员。
  21. 放弃质量:Scrum对团队的结果质量有很高的要求:“潜在的可交付软件”。对于团队或组织而言,很容易退回到缺陷跟踪软件的拐杖上,而不是始终保持极高的质量(由于发布功能的压力)。
  22. 截止日期的范围和资源:Scrum基于现实。如果外部利益相关者希望施加最小范围,最后期限并限制团队可用的资源,那么他们必须允许质量下降……这反过来又违背了Scrum的原则。现实是,没有人能预测未来,因此任何这种强加只是幻想。
  23. 施加的“完成”的定义:的概念之间存在混淆 “完成”的定义 和“标准”。经理和其他利益相关者常常错误地将团队的标准强加为“完成”的定义。
  24. Scrum Master不存在:我曾经看到一个组织为ScrumMasters的“团队”创造了空间。他们大部分时间都在那里一起工作! Scrum Master唯一一次应该离开团队的时间是当他/她正在努力消除团队外部的障碍时。否则,ScrumMaster应该在团队的房间里。

在脸书上分享
Facebook
分享到Twitter
Twitter
在linkedin上分享
LinkedIn

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

最近的帖子

文化,技能和能力//如何成为数据驱动型组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析,以改善数据驱动型决策创新:通过假设测试和学习来测试假设数据平台:获得新见解

Read More »

数据平台//如何成为更具数据驱动力的组织

这是我们关于“如何成为一个由数据驱动的更多组织”系列文章中的第四篇,我们将专注于数据平台。在这一点上,大多数人开始深入研究Data Lakes vs Data Warehouse的技术方面,但是我们想让我们回到一个更高的水平,并要求

Read More »

创新//如何成为更具数据驱动力的组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析以改善以数据为依据的决策制定创新:通过假设检验和学习来检验假设数据平台:获得新

Read More »

搜索博客

敏捷 Management Made Easy!

All About 敏捷

凯利·沃特斯(Kelly Waters)

“’Agile’ is one of the biggest buzzwords of the last decade. 敏捷 methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

凯利·沃特斯

敏捷 101 is available to purchase. GAME ON!

敏捷 101

艾玛·霍普金森火花

“尽管有很多方法可以根据您拥有的团队和想要的学习成果来改变游戏,但是游戏的基本流程是所有人共有的。”
艾玛·霍普金森火花

我们为什么制作游戏?

怎么玩游戏?

联系我们

如果您想与101 Ways的团队之一联系,请填写以下表格或给我们发送电子邮件: contact-us@101ways.com.