有组织认为敏捷或scrum可以是解决它们所拥有的所有问题的解决方案。高级管理层决定，他们的整个组织必须变得敏捷。意识到他们要求所有现有的（瀑布）流程将被敏捷过程所取代。即使他们成功地（通常不是这种情况），它们通常不会从敏捷中获得预期的业务效益。更换流程并不是’T组织敏捷。
团队拥有他们的过程
敏捷团队是 自组织。他们能够规划和跟踪他们需要做的工作。团队成员是 专业人士 谁知道如何完成工作以及如何提高他们的工作方式 回顾。一个敏捷的团队没有’当对他们施加过程时，就喜欢它。它反映了无效的命令和控制风格。
在对团队的施加过程中，管理人员应该在团队定义和改善自己流程的条件下工作。管理者可以做的一些事情是：
经理应该支持团队提高他们的工作方式，例如：
- 允许专业人士花时间进行改进。
- 使团队能够 自我评估他们是多么敏捷.
- 安排 敏捷教练和指导 for teams.
- 培训和刺激专业人士在提供和接收反馈时。
- 向团队询问 追溯 并支持他们进行改进行动。
- 训练回顾性促进者 获得更多价值的敏捷回顾.
- 安排机会 团队互相学习.
- 奖励团队和专业人士提高他们的工作方式。
部署敏捷过程框架
在您的过程中拍摄敏捷视图仍然对您的组织有价值。讨论敏捷价值观和原则有助于专业人士探索并达成他们希望如何共同努力，并更好地向客户提供有价值的产品。
像Scrum，XP，Crystal和Evo这样的敏捷框架是基于敏捷宣言的值和原则的表示。我认为它们与框架和模型类似于TQM， CMMI., 人民cmm 和 倾斜：他们很有价值“tools”在理解他们的专业人士手中 根据人们的上下文和需求部署它们。简单地完成那些有意义的事情，而不是框架告诉他们做的事情。重点放在需要的重新级别，而不是模型本身。
大学教师’T杀死你的团队与敏捷的银子弹
有些组织认为敏捷是一个银弹来解决所有问题。它们通过敏捷框架替换流程，并要求每个人都有这样的工作。如果这很容易，那么现在，所有组织都应该变得敏捷，因为敏捷框架有超过10年。
当经理发展真正是敏捷的真实看法，它可以帮助很多，并且在开始敏捷之旅时，他们可以期待离开它。太常见的是，敏捷可以解决所有问题，是一种易于做的事情，即团队或工程部门可以自己做（这是自我组织的），并且只是通过敏捷替代现有流程的问题（有关此示例，请查看 你可以使用scrum master吗？ by bob marshall）。只有雇用人们并假设这将解决所有问题，请不要出错。请注意，作为管理者，您还需要及时放置敏捷成功。
变得敏捷需要时间。它开始了解值和原则。并使用它来部署敏捷模型和框架，以便它可以帮助您的团队完成工作，并在他们所做的事情中变得更好。变得敏捷是艰苦的工作，但是当你开始获得奖励时（这可以很快）你知道为什么它值得这样做。
（这篇帖子于2014年3月28日发布，2014年4月16日扩展了来自Bob Marshall的博客文章的灵感）。
- 33分享
怜悯，但真实。就在今天，我听到了一个关于管理的另一个故事想要去敏捷，然后否认他们的团队的指导，即使他们与培训他们的scrum-masters的人一起要求它。
谢谢Angelo分享这个。
如果组织想要从敏捷获得福利，他们必须从团队和团队中的专业人士认真地工作。如果你希望他们能够以一种好方法可以完成工作，请倾听他们所说的并以最好的方式支持它们。
在我以前的公司（一个小型创业公司），我们开始没有任何流程。基本上，我们只是与我们最好的知识一起攻击代码。一旦公司开始成长，我们就知道必须变得更加纪律。毕竟，我们已经为大型客户提供了大型客户，并建立了一个相当复杂的软件，我们已经经历了对我们软件质量造成的临时心态的痛苦。
我们的首席执行官足够聪明地建议改变激进的变化。他给了每个团队成员一份SCRUM书的副本（这个是准确的 http://www.amazon.com/Agile-Software-Development-Scrum-Series/dp/0130676349）。我认为这本特定的书被选中，因为它的数量少，那里可能有更好的东西。我们同意阅读该书并遵循所提供的指导方针。然而，无论我们感觉到，我们也都保持自由。我们几乎骑了这本书。它使它变得更好。
It’如果团队已经在某种方式做事历史悠久的历史上，那么可能更难以制作那种开关。我们没有’T有很多工作历史，所以它可能不适用于你的团队。当然，它没有解决我们的所有问题，但它已经使用框架来讨论和基准我们的想法。
I’现在搬到了沿着这些思想启动另一家公司，帮助软件开发团队变得更加富有成效。 Ben Linders，以及其他对主题感兴趣的人，我们’d喜欢听到你的想法。
感谢您分享萨米的体验。
您能否告诉我们CEO如何在分发书后支持组织的变化？他如何支持团队和专业人士更加敏捷？
这也向我看，团队没有’T有人在首席执行官施加对他们的感觉。那里有特定事情，首席执行官做了这让人感受到这种方式？
我认为关键是要使过渡，让它感觉就像是一个共同的决定，没有一个人强加。尽管他们在组织图表中占据了位置，但您需要听到每个人。从打开的问题开始“我们应该如何生成软件”而不是封闭的人“你有scrum吗？”.
让团队决定。如果你有一个很好的团队，他们将最终得到乐趣。 isn.’在敏捷原则的核心中，团队毕竟是信任和自我组织的吗？
交出一本书或由信任的第三方写的指导方针可以节省大量的时间，因为每个人都忙于他们的任务无论如何。只需确保内容易于摘要（不是太多页面）。与每个人参与并记下建议的重点会面。明确决定不是“written in stone”但是，相反，可以在基于经验的时间内随着时间的推移而改进的迭代过程。
有机会就在那里’在团队随着新过程中获得速度，并不是那么许多改变。
但是，你需要坚持不懈。你需要有一个理解所涉及的职责的PO。您需要携带参与会议的人（计划，评论等）。让他们安排在日历中。很多人喜欢例行，更少的人喜欢不确定性和惊喜。
谢谢Sami，提供更多信息，即在Scrum介绍以及影响过渡的方式，非常有用！
嗨本，我同意。
I’已经看到这么多次，客户端，以及代理方面，在哪里管理跪在敏捷的祭坛上，而不是真正向它付出致敬，如果你看到我的意思。有点像偶像崇拜，伸展宗教方法论 -
事实上，我认为，敏捷文化和敏捷项目交付之间存在差异，而前者在许多组织中是可行的，后者更棘手（如果你愿意，请： http://www.thedigitalbusinessanalyst.co.uk/2014/03/does-digital-enterprise-have-to-be-agile.html)
m
马塞尔，感谢您对如何（不）变得敏捷的看法！
我同意，敏捷文化和敏捷项目交付之间存在差异，但它们是alos相关的。现在有许多做法，现在称为敏捷（大多数人在那里长期被创造出来）。在敏捷文化和敏捷心态完成时，这些做法更有效。
例如。如果您想做有效的敏捷项目交付，那么客户合作非常重要。与透明度和开放相同，以确保所有涉及的都知道状态是什么，并且能够采取最佳决策。
马塞尔，你同意这个吗？
绝对地。
我认为这一切都归结为敏捷原则的接受程度。我非常喜欢DSDM atern如何定义它们： http://www.dsdm.org/content/4-atern-principles
甚至更好，他们甚至有一个调查问卷来评估敏捷准备情况： http://www.dsdm.org/content/appendix-b-project-approach-questionnaire-paq
在实践中，往往是我们做所有这些评估，然后继续忽略它们 -
感谢分享DSDM敏捷原则！
你知道我的吗？ 清单敏捷自我评估工具和清单？它真的可以帮助想要的组织 变得更加敏捷和精益.
I’m在博客上工作“制作行动棒将根据评估，回顾率，根本原因分析等解决基于评估，回顾率，根本原因分析等的有效方法。直到那么在那里’s my bog on 揭示更好的方法来完成处理改进 对于想要完成事物的人。