• Scrum@scale-2
  • Shine-scrum-02
  • Arne
  • Jim-banner
  • Cams2
  • Cal
  • Inner-training
  • Growth-process
  • Jens-heart-of-scrum
Scrum反模式
因为Scrum很容易理解,所以初学者可能会使用其中一些实践并机械重复的去实施,但实际上他们并没有理解吃透Scrum原则。

软件领域中使用的反模式术语大多数最初都是吸引人的,易于实施的解决方案。但事实上,远远没有解决实际问题,最终反而导致更大的问题。

正如Scrum指南中所说的Scrum是一个框架,在这个框架内,人们可以处理复杂的适应性问题,同时高效地创造并交付最高价值的产品。Scrum是:
• 轻量级的
• 容易理解的
• 难以精通的

在不到一个小时的时间里,你可以向他人说出Scrum的所有要素。


因为很容易理解,初学者会轻松地使用甚至误用框架。他们可能从整体上使用一些实践,并以机械的方式重复它们,而不理解它们背后的原理。不做任何适应性改变,不挑战自我,这样,能期望提高工作效率吗?

我们需要牢记,Scrum不会一夜之间化腐朽为神奇。人们要适应于新的工作模式,尤其是需要时间适应文化转型。 要有耐心,不要过早的急于表现,从敏捷教练的角度开始应用它,挑战自己,改变你的工作方式并理解原则。

现在我来谈谈最常见的“反模式”,希望能给你带来一些想法。这可以帮助你检视你自己和你的团队。在敏捷团队评估中,我观察到了一些这样的情况,这些公司正在努力找出为什么他们已经开始应用Scrum了却还是没有改进的原因。


• 团队等待分配任务或要求PO(产品负责人)分配任务,从而破坏其自组织性和决策能力的发展。


• ScrumMaster中的“Master”部分被视为技术或领域专业知识,因此,这个职位通常被团队中最有经验的软件开发人员担任。 这对团队的发展产生负面影响。


• PO(产品负责人)和团队仅在 Sprint计划和回顾会议时见面。 这通常意味着产品负责人在sprint期间没有花时间与团队和客户在一起,因此决策和学习过程很慢。


• 在Sprint计划会议上,所有任务都是个人认领,每个人对自己的任务负责,因此他们不作为团队合作,独立工作,在整个sprint过程中不能相互协作。


• 如果他们是按照上面描述的方式工作,那么,每日Scrum(允许协作和作为团队做出日常决策)放弃每日站会也并不奇怪。


• 团队和PO(产品负责人)专注于完成任务而不是交付价值。


• 他们不做回顾,他们实际上并没有挑战自己变得更好。


• 没有Sprint的审查,或者当团队展示了在Sprint中完成了什么,而不是检查交付的价值和sprint目标反馈。


• 会议不尊重“时间盒”原则。


• 随着Sprint的不断推进,Sprint待办事项的变化也越来越大。


• 团队将来自Sprint的用户故事传递给Sprint并针对同一个故事进行多个Sprint,表明存在切割问题或他们不了解迭代和增量工作方式。


• 在Sprint计划中,团队只讨论“什么”部分,而忘记讨论如何拉动项目的开发。


• 由于缺乏待办事项列表优化会议,所以Sprint计划会议时间很长(即超过时间盒)。


• 团队表现以“速度”作为衡量标准。


如果你发现你的团队存在这些反模式, 有方法可以帮助他们恢复,比如结构化教练方法,并向经验丰富的敏捷教练寻求帮助。

本文由ShineScrum捷行翻译、审核

作者:Ebru Yalçınkaya

扫描二维码,阅读英文原文: