合理的决定
您知道,有时我认为与敏捷或Scrum的新手共享有关Spotify模型的任何内容都可能弊大于利。
我的一个朋友转发了一个 文章 上周对我问,并询问了有关共享内容的意见。这篇文章是由Spotify产品经理撰写的,他曾尝试组建一个敏捷团队,并删除了他们用来观察会发生什么情况的敏捷实践。那 ’是的,他们退出是为了促进Scrum框架中概述的所有事件。
这些结果验证了我认为应该在Scrum团队中发生的事情。随着时间的推移,通过遵循框架,Scrum团队的成员将在协作,计划和价值交付方面变得更好。我的理论是,随着他们成为更好的沟通者和合作者,只要他们继续遵循Scrum的价值观,团队对Scrum框架的依赖就会改变。
应对背景不足
这个结果听起来可能吸引许多人。我听到的一些陈述包括:
- “相信团队,他们会解决的。”
- “我们不知道Scrum太臭了。”
- “我们应该转到软件开发的Spotify模型。”
我关注的是上下文之一。也许最好将其表述为“缺乏背景”。所缺少的是团队在引入变更时所处的背景。
Spotify成立于2006年4月,在他们的旅程的早期就采用了Scrum。但是,随着团队数量的增长,他们遇到了一些扩展问题。他们带来了 亨里克·克尼伯格,他通过吸收Scrum的经验并添加其他敏捷实践和框架中的实践来发展Spotify模型,从而帮助Spotify拥抱了敏捷思想。本质上,Spotify超越了Scrum,以实现更高的敏捷度。即使在今天,Spotify模型甚至在Spotify中仍未完全使用。
我喜欢Spotify模型。许多概念(部落,行会,小队等)都很吸引人。但是,在翻译中迷失的是敏捷是一种思维定势。不仅是一种实践或工具,而且是一种不同的思维和工作方式。如果不采用敏捷思维方式,Spotify模型及其相关实践将不会比包括Waterfall或Scrum在内的任何其他实践更好。 Spotify模型是在整个组织中扩展敏捷性的几种方法之一。
敏捷+ Scrum行动
以下是Spotify的敏捷工程和产品管理YouTube视频的链接:
让我知道你的想法。想谈谈吗?
感谢您的光临。
克里斯
让我们连接。 Instagram的 | 脸书 | 领英 | 推特 | www.beLithe.com