合理的决定
您知道，有时我认为与敏捷或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
发表评论