敏捷Pods vs Scrum团队

嘿,彼得,

查看下面的链接。它很好地说明了敏捷Pod是什么。在比较两者时，有一些关键的区别，但它们都非常相似。他们都很小(少于10人)，他们都在如何处理他们所选择的工作方面进行自我组织，他们都有3个角色。

区别是:

• pod是由外部人员根据需求来设计的，以满足需求。Scrum团队从头开始自我组织。
• pod根据需求和技能集根据需要更改。Scrum团队是跨职能的、长期存在的。
• Pod有一个Pod Leader，核心团队和兼职专家。Scrum团队有产品负责人、Scrum管理员和开发团队

有更多的相似点和不同点，但我会让你们自己做一些研究。

https://www.agileconnection.com/article/using-agile-pods-realize-potential-your-team

你们公司知道为什么选择豆荚吗?

公司是否在不妨碍团队自组织能力的前提下提供了足够的指导?

谢谢你的信息和链接，柯蒂斯。我将通读一遍

西蒙-这是我们的首席数字官和一家咨询公司想要使用的。除了“让我们采用敏捷”，没有给出其他理由。我要去见一个Pod leader，看看他们在做什么。会议结束后我会发布更多信息。谢谢!

我知道你可能没有这样做的权力，但敏捷Pods的概念对我来说似乎并不强大。没有被授权的团队成员的敏捷注定会失败，最终可能会浪费数百万美元。

我以前不熟悉敏捷Pods的概念，但是根据提供的链接(谢谢柯蒂斯)，这似乎不是一个明智的做法。

除非我的理解不正确，否则它促进了一种传统的“即插即用”方法资源,在那里豆荚是根据个人技能和工作要求临时组建的。这种策略不能促进稳定的团队、知识转移或交叉培训，并且会强化围绕专业化的单点故障。

嗨,彼得,

我读了你们的数字主管根据咨询公司的建议说的

＂让我们走向敏捷＂

我不得不写下来，因为这让我发笑。就像矮胖子的尖叫"让我们坐在墙上，因为我被要求这样做"．

但所有笑话拉到一边,从Scrum master Scrum master,敏捷豆荚(对我来说)看起来不像一个好主意,因为它似乎有点乱,消除自我组织由于一些成员被核心成员和其他人被兼职成员(这可能导致不可预见的障碍),然后Pod领袖似乎像一个Scrum master(但不完全),但必须优先考虑工作与业务管理团队(所以是豆荚领导人像Scrum管理员或者产品所有者)

然而，现在已经一个月了，我想知道你对你的问题有什么看法?如果你还在写最初问题的时候，我会和建议你跳槽的顾问谈谈，研究敏捷Pods，以及它们与Scrum的比较。然而，如果这些都不可能，我确实在Curtis Slough提供的链接中读到了一些关于Pods的信息:

＂最初的几周可能会让你充满力量，同时也会让你很累。当我们的团队有责任计划出完整的发布周期、需求、设计和交付时间表时，参与所有这些讨论为所有团队成员带来了曝光和更广阔的视角。虽然计划、分类和优先级对大多数团队成员来说都是新的，但一旦我们掌握了窍门，它实际上会让我们感到充满活力＂

所以，如果你又挣扎了一个月，那就坚持下去，但让别人知道，如果你没有挣扎，那就给自己点赞。

我不同意“敏捷Pods”这个概念本身。我看不出Pods结构有什么价值。为什么会有人需要敏捷Pods呢?如果我们彻底理解了scrum团队的概念，并且完全理解了scrum框架(最好也理解了nexus框架)，那么就完全不需要“敏捷Pod”这样的东西了。

在我看来，整个敏捷Pod的想法是根据你的方便来调整敏捷方法，从中创造出一些花哨的术语，比如“Pod Leader”，最终做传统的管理。这只是一种功能障碍。

“让我们变得敏捷”不应该意味着“我们做别人做的事情”。每个组织和每个产品都是不同的。我们需要仔细分析在我们的场景中什么最有效。如果某件事在一个组织里行得通，那么它在另一个组织里不一定也行得通。有很多公司试图采用spotify的模式，但都以失败告终。为什么?因为，他们从来没有理解它背后的概念。他们只是开始使用花哨的术语，重组团队，盲目地遵循模式，而没有改变他们的文化和心态。