在分布式离岸环境中从事产品开发的传统大型软件产品组织很难遵循 Scrum 中的敏捷精神，原因如下：
他们的产品开发不是迭代的。产品工程团队经过多轮迭代系统工程，提前正式确定给定版本的产品需求、产品架构和设计。可能会发生这种变化，但不会大规模。
产品工程团队现在让离岸团队根据创建的规范构建此产品。这些大型离岸团队不能在迭代和经验模式上工作，因为这在这里没有保证。
然而，产品经理可能希望通过在短期迭代中请求增量交付来定期了解离岸团队的产品开发。
如果这些离岸团队可以在定义的正式流程（非经验性）、经理管理的环境（非授权）和使用增量开发方法（非迭代和自适应）中遵循 Scrum 的变体，那对他们将非常有用。
在这种情况下实施的真正 Scrum 方法可能看起来很虚伪。但是，如果我们可以给他们一个正式的 Scrum 变体，用于传统的瀑布式场景，他们可能会利用它来为每个人带来好处。
我试图在我的博客scrumtales.blogspot.com上更详细地描述这种情况。
我们可以这样做吗？
简短的回答绝对是 YES。
虽然 Scrum 是一种由某些仪式和流程组成的方法论，但它们的常见实现就是这样 - 一个实现。对于每个过程，退后一步，寻找更高抽象级别的解决方案，这不存在您遇到的问题 - 主要是距离。例如 - 托管。虽然常见的解释是让所有正在协作以“完成”用户故事的人进入一个具体的房间，但这不一定是唯一的房间。聊天室会做这项工作吗？虚拟现实房间会更适合您吗？VOIP 解决方案也可以工作。
每月一两次会议（冲刺计划和回顾）可以在这样的虚拟环境中举行，而不会对偶尔在正常下班时间工作的人造成太大压力。
如果时区和互联网带宽难以逾越，也许可以将频繁的在线会议脱机。日常会议可以通过使用 wiki 来完成。或电子邮件。
有无数用于仪式的在线工具，例如计划扑克 ( PlanningPoker.com )，有些是商业的，有些是免费的：VersionOne、AxoSoft OnTime等等。
无论物理距离如何，Scrum 的其余部分都可以完成——编写用户故事、估计和故事点没有基于位置的限制。
希望这会有所帮助，阿萨夫。
用于传统瀑布场景的 Scrum 正式变体
这被称为“Scrummerfall”。这里有几个链接可以帮助您开始解决您可以在您的组织中释放的痛苦：
http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.asp x http://blogs.msdn.com/nickmalik/archive/2007/06/04/waterscrum-vs-scrummerfall。 aspx
根据我在您的问题中读到的内容，我的简短回答是否定的。
我不得不说，除非你的分布式离岸团队愿意采用增量开发，否则这根本不是一个有用的练习。如果没有增量交付，正在为这个远程团队嘲笑 Scrum 流程的其余部分的产品经理将在 sprint 审查中寻找进展，并且团队将无法展示他们作为一部分完成的事情之外的任何内容他们的瀑布过程。因此，对于第一部分，设计已经完成，随后实施工作完成，最后系统和集成测试正在工作。当然，产品经理将无法要求对原始计划进行一些更改，此时团队可以做出响应并仍然满足他们正在推动的其他承诺和里程碑。为什么？因为他们要等到项目后期才能提供功能。
增量开发是关键。一旦他们有了这些，并且产品经理正在接受有时间限制的审查会议，那么您就可以开始远离做出承诺的经理，让团队成员收到反馈并直接做出承诺。
一旦您进行了增量开发，另一件要尝试的事情是使用离岸团队经理作为产品负责人代理的想法。它允许您的产品经理与项目中的所有团队协商依赖关系，并将其传达给代理。然后代理可以以权威的方式与他们的本地团队进行交互，并且仍然代表产品经理的目标和优先级。这也有助于解决分布式团队在无法直接访问产品负责人时所面临的问题。拥有本地代理有助于解决团队可能对功能提出的问题，而无需等待世界另一端的人在一天后做出回应。
您可能想看看 ThoughtWorks (Martin Fowler)在进行敏捷离岸开发方面的经验。我想说的是，让敏捷适应离岸开发（或者你的离岸开发适应敏捷）当然是可能的，但这可能是一个很大的变化。您可能还想查看Fearless Change - 了解将新想法引入组织的模式。听起来你面临的最大困难是对变革的抵制，而不是关于敏捷实施的技术问题。