肯特·麦克唐纳（Kent McDonald）
这是一系列文章的一部分，在这些文章中，我看了一些常见问题并提供了自己的看法。 答案全是我自己的。 因此，尽管我的回答不一定反映敏捷联盟的政策或立场，但我将指向AgileAlliance.org上的一些相关资源，这些资源可以支持我的观点或提供不同的观点。
我们现在是否可以将敏捷思想和相关框架公平地应用于所有业务，软件开发，如果可以的话，可以达到什么程度？
简短的答案是肯定的。
这是更深入的答案：
有很多人在探索如何使敏捷软件开发中体现的思想超越软件开发和IT领域。 这些探索大多属于“业务敏捷性”标签。
这些探索倾向于采取以下两种形式之一：
- 组织其他部门的人员如何需要采用敏捷思维方式才能进行软件开发工作，进而使整个组织变得更加有效
- 组织的其他部门如何采用敏捷框架（即Scrum）和实践（如定时迭代，独立陈述，回顾）
敏捷联盟启动了业务敏捷性网络研讨会系列，以与社区分享其中的一些探索，并在Agile2017和Agile2018上举办了有关敏捷公司的会议。
向组织传播思想
我建议采用第一种形式，以帮助组织其他部门的人员采用敏捷思维方式。 自从团队开始以敏捷的方式工作以来，这是很有必要的，这早在2001年的《敏捷宣言》的作者的思想中就得到了暗示。
但是，尽管宣言提供了一些具体的想法，但有一个更深层次的主题可以驱动许多（但不是全部）联盟成员。 在为期两天的会议结束时，鲍勃·马丁开玩笑说他将发表“糊状”声明。 但是尽管充满幽默感，但很少有人不同意鲍勃的观点-我们所有人都有幸与一群拥有一套兼容价值观，一套基于信任和相互尊重的价值观以及基于以下观念的组织模式的人一起工作：人员，协作，并建立我们要在其中工作的组织社区的类型。 从根本上讲，我相信敏捷方法论者真的是在“糊涂”的东西上—通过在一种环境中操作来向客户提供优质产品，而这种环境不仅仅涉及“人是我们最重要的资产”，而且实际上是在“行事”，就好像人们是最重要的，就失去了“资产”这个词。 因此，归根到底，人们对敏捷方法论的兴趣急剧上升，有时甚至遭到了强烈批评，这与价值观和文化的糊涂有关。
以上摘录中体现的思想当然可以在软件外部应用。 我知道我希望与我合作的任何组织都能表现出这些行为。 因此，我认为在组织外部传播敏捷思想是一件好事。
将敏捷思维方式传播到组织其余部分的关键位置之一是，决定您正在处理的内容以及未处理的内容。 在产品开发中，这就是产品管理的领域。 在IT中，这是项目组合管理的领域。
向组织传播框架和实践
如果您想要一个真正的跨职能团队，那么与与产品开发工作相关的所有人共享实践和框架是完全有意义的。 您想确保团队中的每个人都理解并同意您在共同工作时遵循的约定。 这就是您团队的方法论。 您将介绍框架和实践，以帮助所有人学习如何彼此合作。
您将希望使每个人都能快速掌握用于协作的实践，例如日常站立和回顾。 您可能希望确保团队中的每个人都了解诸如测试驱动开发，结对编程或连续部署之类的技术实践，至少要解释这些实践如何影响您的涉众和用户。
可能没有用的是将敏捷软件开发框架和实践介绍给与软件开发没有直接关系的组织部分，除非您可以在他们的上下文中应用这些实践。
例如，如果您有人员在客户支持中工作，那么他们的工作性质就不适合每两周进行计划。 为此，他们的工作变得频繁而随意。 但是，跟踪当前在信息辐射器上的工作并定期花一些时间来确定改进机会可能会有所帮助。
最终取决于上下文
归根结底，当您希望将敏捷扩展到软件之外时，您需要了解自己的环境。
如果您的组织在需要处理不确定性并且需要能够快速学习和适应以提高效率的情况下运作，那么将敏捷扩展到软件之外是有意义的。
当您需要在组织的其他部门进行更改以使您的软件开发工作更有效时，将敏捷扩展到软件之外就很有意义。
如果您这样做的唯一原因是因为您认为自己已经解决了该软件问题，并且认为会计部门将开始日常工作，那将是一件很整洁的事情，那么将敏捷扩展到软件之外可能没有任何意义。
