Answers:
并非不可能。除非你生活在天堂。对于您可以采取的具体步骤，我全力建议您拿起一份《无畏的改变》副本
希望这是有道理的..正如您可能已经猜到我已经来了一段时间:)
听取团队，管理层，利益相关者的意见，并听取线索。他们可能会在敏捷直接解决的许多领域感到痛苦。
坚持建议可以直接减轻那些痛苦。“你无法治愈自己的感觉” –可以这么说。
这需要很长的时间，但建立信任至关重要。有了过去的成功，并获得了您的团队和经理的信任，他们将在需要做出决策时向您求助。
经过多年的挫折，试图让人们改变我们交付软件的方式，我亲眼目睹了这种情况的发生。尽管现在我已经取得了成功，但我离完成还差得远。尚有很多地方需要改进，而我目前通过引入可以直接解决我们所感到的某种痛苦的小变化而取得了最大的成功。
最后，我只想说很同情。我错误地忽略了大部分想法，因为我没有在《 XYZ敏捷书》中读到它们。听取您的团队意见并尝试实施他们的一些建议将大有帮助。
祝好运！
跳过技术层面，我们发现在组织内部找到一个可以购买敏捷方法并提供“测试台”的团队至关重要。我们公司中有很多人不理解敏捷的不同术语，对术语和流程感到困惑，并且普遍感到恐惧。
我的研究小组对尝试使Scrum工作（以及其他几种敏捷类型方法学）非常感兴趣。我们的兴趣使我们能够在公司内部形成测试平台，以尝试各种要素。我们首先做了很多教学，包括与他人的走廊交谈，公司高管的演讲等。我们并没有努力进行，我们接受了教育。然后，我们请求允许与我们的小组一起尝试。
关于如何生动地展示结对编程，测试驱动的开发，Scrum等之类的东西如何可以节省时间的问题，将会有很多答案，但是总的来说，我觉得证明需要来自公司内部。找到一个可以用作测试床的小组，让他们实际进行试验。没有什么比向您的团队证明这一点能够减轻恐惧更好的了。
将它们塞入他们的喉咙，但没有引起他们的注意;）
在过去的六个月左右的时间里，我一直在缓慢地尝试将敏捷原则（主要是Scrum）应用于我的工作场所。我首先介绍了日常站立运动，这使每个人都习惯了一些站立运动，但是效果非常好。由于我们都在一个系统的不同程序上工作，因此很难按照定义来遵循scrum。我的下一步是开始冲刺会议以关注我们的每个发布。我们已经进行了一个月的周期，所以sprint的长度不是问题。我还计划在下一个大型项目中完全遵循Scrum原则。我是该项目团队的两名开发人员之一，他全心全意不断改进。我希望管理层能够看到我正在努力实现的目标。
我认为关键是要慢慢来。担任同一职位多年的人们通常会反对侵入性更改，但是如果您可以逐一偷偷摸摸，他们就不会注意到。首先，也要从小的频繁会议开始。通过使它们简短，管理层不应将其视为浪费时间。
首先提高自己。真。例子是谈论敏捷的有力方法。而且，正如某人已经说过的那样，请避免使用技术定义，而应使用经理和行政人员可以理解的术语。两周后改为冲刺；规划而非Sprint规划或规划游戏；产品经理，而不是产品负责人，依此类推。Michele Sliger 在Waterfall Enterprise中做了一个关于敏捷的精彩演讲。真的是必看的视频。您可能还对另一个有关敏捷采用的视频感兴趣。
在我工作的地方，我了解到Scrum是开始敏捷的好方法，因为管理层很快就知道了。它很简单，并且名字很好。后期，在进行回顾时，您可以建议XP做法作为改进，并且很容易让人接受，至少可以尝试一下。
亲切的问候
我们将其介绍给我们的“维护”任务（错误，影响较小的变更等），历时2周。因此，从事长期项目的开发人员保持原样，但是我们的维护冲刺轮换。因此，每个人都可以使用烧尽图表和扑克估算，而不会破坏主要项目。
然后，随着每个主要项目的结束，我们使用敏捷的2周冲刺开始下一个项目。整个过程花了几个月的时间才让每个人都冲刺，但是这意味着中断更少了，每个人都可以“轻松”地进入流程
人们总是抗拒变化，转向混乱是一个很大的挑战。动机和方向是关键。
第一步是让人们有动力给Scrum一个机会。我发现Ken Schwaber的Google Tech Talk在使人们认识Scrum的好处的同时提供了很好的介绍，它非常有用。从您会接受变更的人开始，不管他们是开发人员还是管理人员，这样您就可以建立动力。在某些时候，必须要有管理者在身边，但是如何处理取决于您的环境。
之后，无论是读书还是进行系列讲座，每个人都需要接受培训。除非人们知道Scrum的工作原理，否则您将无法开始尝试执行该过程。
一旦人们有了动力并且对需要做的事情有了想法，就需要举行第一次计划会议并设置必要的Scrum部分（scrummaster，日常会议等）。
我希望第一次计划会议不会顺利进行，并且将是每个人的学习经历。另外，前几个冲刺将非常艰难，并且可能落后于进度。现在的关键部分是纪律和持久性。不要让日常会议运行得太久，不要让计划会议按时进行，并确保每个人都在正确地扮演自己的角色。
我认为最有抵抗力的人是从事软件开发很长时间的人，或者是因为感到混乱而承认自己以前做错了事的人。这是要克服的棘手障碍，但是我认为通过向他们展示其好处，您可以逐渐说服他们。这只需要时间。以我的经验，产品经理确实很抵制，因为这迫使他们更加清楚自己的要求和要求。但是，一旦他们看到了敏捷过程如何使他们受益，并使他们的生活更轻松，他们就会很快加入。
祝好运！
在考虑引入敏捷开发之前，请先探索哪种方法最适合您的组织/项目。例如，如果您正在查看Scrum，请考虑是否要严格使用Scrum，或者是使用更为宽松的Scrum形式，甚至是另一种方法可能更适合。然后，我的答案是敏捷作为您的敏捷方法。
Scrum非常适合需要创新，鲜为人知且需要实验的项目。它不是执行维护现有产品或处理经常性维护工作之类的最佳选择。幸运的是，scrum是一个松散的框架，您可以使用它的最佳方式。
对于维护工作，看板可能更适合您，或者您可以尝试一些scrum元素来管理sprint和执行诸如日常站立等操作。我称此为“ scrum-but”，“是的，我们在公司中进行scrum，但是……”。很好，不要为此感到难过。
为了在您的组织中引入适当的Scrum，您需要产品所有者和利益相关者的参与。如果您是一家小公司，那么那个人可能是一个人，是老板，而在大公司中，可能是产品经理和部门主管/老板。我建议两种引入Scrum的方法：
1）您可以开始以稍微宽松的形式使用scrum来立即管理现有工作队列。但是也请看一下看板。
2）在某些需要创新，及早反馈以及尚有许多未知之处的新项目上，开始以更严格的形式使用scrum。您可以向老板/产品负责人建议，scrum非常适合这个新项目。
但要记住！这不仅与代码有关，产品所有者具有至关重要的作用，必须理解并履行其职责。举例来说，这意味着不要先编写所有规格，而要从最小的规格开始，快速迭代，获取反馈，学习并反馈等等。尝试与产品经理合作，后者会像您一样热衷于引入Scrum，但从产品所有者的角度来看，理想情况下，他/她应该足够坚强地抵御管理要求并保护冲刺。
从开发和产品管理到引入Scrum都需要团结一致的努力。
在这样的新项目上，请尝试将新团队转移到一个单独的房间，并使用便签纸来可视化各个状态下的工作，例如积压，进行中等。在此阶段，请不要陷入电子工具的泥潭，使事情尽可能简单。当您也开始使用卡计划扑克时，不要感到傻，一旦您的团队加快了速度，您可能不会只说数字就使用它们。
以我的经验，先引入纯形式的Scrum容易，然后简化它以实现更多维护类型的工作队列。反之则更困难。
我最后的评论是要当心Scrum是某种发展的灵丹妙药，事实并非如此。Scrum是用于产品创新的有用且简单的框架，但是可以根据您的业务需要而探索其他结合方法，并且对此不会感到难过。
几年前，我曾是一家大型公司（近20,000名员工）的顾问，该公司正在运行许多大型企业软件项目。我当时在其中之一。一个相当关键的。
我们面临许多问题，开发团队为此承受了很大的压力。问题只是软件行业常见的问题，但是管理层拥有更多的面向基础架构的经验，而很少有面向软件的经验。所以一切都集中在我们身上。我认为向管理层介绍Scrum是一个好主意。
我面对强烈的勉强，所以我暂时放弃了这个主意。但是问题仍然不断加重，因此在团队负责人的赞助者的帮助下，我们最终决定自行决定制作Scrum。
包括我在内的任何人都对Scrum有任何经验。因此，我们通过以下方式发现了该框架...
如今，Scrum通过由认证培训师管理的程序推广到整个企业。我不知道我们的主动性是否是触发因素。就是说，我知道这是一个相当僵化的公司的真正革命。
我认为要将类似的东西引入企业，您必须遵守以下原则：
它必须改变是必要的。如果没有令人信服的理由必须进行更改，那么就没有理由让管理团队冒险。
除非它们是管理问题的一部分，否则我们必须专注于管理问题，更不用说开发人员的问题了。换句话说，您必须为他们而不是您提供解决方案。把自己放在管理层的鞋上。他们有什么担心？
您不应提议立即更改整个组织。您必须提出一个试点项目，由您负责。我建议您提出切合实际的目标，例如大幅提高项目进展的可见性。恕我直言，这是Scrum对软件管理的主要贡献。它使人类的常识得以运作，从而向前发展。
最后，必须确保有经验的人可以控制此介绍。不要只读一两本书。您必须接受培训，我想说，有必要聘请经验丰富的教练。显然，没有它也可以完成，但是会很痛苦:)
如果您遵循原则并提出事实，那么它将起作用。关于事实，您会在《 30天之内的软件》一书中找到许多内容：敏捷经理如何打败对手，取悦客户并让竞争对手陷入尘埃。这是Scrum创作者Ken Schwaber和Jeff Sutherland的最新著作。
在Ken关于这本书的博客文章中，您可以阅读：
杰夫·萨瑟兰（Jeff Sutherland）和我做到了。我们在一起写过书，这是自1995年Scrum首次发行以来我们的第一篇联合著作。是什么促使我们发展起来的？我们经常被问到的问题是：
我们如何将Scrum出售给我们的管理层？
我一直对这个问题感到困惑。您为什么要出售更多的可预测性，生产率，质量，价值，风险控制，满意的客户，敬业的员工，并减少管理人员的浪费？但是，我与杰夫交谈，我们发现哪里有烟，那一定是火。
我们在2011年下半年撰写了这本书。任何经理，从上到下，都可以轻松地阅读本书。
[...]
我们一直都在看。（完整披露：我正在开发项目管理应用程序）。问题在于，敏捷方法论给传统管理的组织带来了内在的张力。通常，高层管理人员希望能够提前计划。他们想要3年计划；他们想要适当估算的项目；他们希望能够预算雇用新人；他们希望能够在合作伙伴/客户方面做出重要的里程碑。
但是随后，研发部门决定它将变得敏捷。在编写代码之前，不再需要提前两个月进行计划。冲刺将变得很短，并且超越冲刺，您将获得积压/路线图中的东西的非常低分辨率的估计。研发部门意识到需求变化太频繁，以至于经典瀑布无法生效，但是产品经理希望对产品在12个月后的外观有清晰，深思熟虑和预算合理的看法。
那么，问题在于调和两者。正如我所说，我们一直在与客户一起发生这种情况。因此，我们的解决方案是统一用于执行冲刺和长期计划的工具。好的，现在这是无耻塞子的一部分，所以请随便带一点盐。我们的独特功能之一是，我们使用可缩放用户界面来管理任务。这意味着深入研究一些用户故事/任务并对其进行详细说明非常容易。（您可以在此处查看外观）。实际上，我们系统中根本没有“项目”的概念。所有任务都包含其他任务，并链接到其他任务（实际上是一个分形）。这会在用户故事，任务，项目，史诗等之间造成模糊的效果。
实际上，我们许多使用敏捷方法的用户所做的就是创建一个伸缩计划，该计划将长期路线图（或积压）与管理短期冲刺（或迭代）合并在一起。经理们仍然可以看到一个不错的，估计好的主要功能路线图，有待添加，而开发人员只需更深入地研究实际的工作任务即可。这样做的一个优点是，它减少了管理人员查看工作计划时发生的“讨价还价”的次数。开发团队没有机会只提供非常粗略的估计（即“ 4-6周！”），而是有机会放大每个有问题的用户故事并将其分解为较小的块。当您这样做时，讨价还价的空间突然减少了。您花了10分钟将5周的用户故事分解成大小约为1天的数据块，突然之间，争论就变成了“不，你可以做得更快。不，我们不能。是的，你可以。” 但是“这是这项工作的结果，包括最初估计未考虑到的所有隐藏工作。您建议我们消除什么？质量保证？测试？培训新人？建立构建环境？”。
只要您使用的工具可以使您在最初起草计划时就尽快对其进行更改，那么该方法就有效。这是人们最近讨厌瀑布的真正原因。大多数系统使完全重做现有计划变得异常困难，人们非常理性地拒绝在此活动上浪费时间。
好的，我觉得这已经成为一种推销手段，所以我现在就停下来。:)