判断一个组织是否敏捷是一件困难的事。一个组织可能有些方面很敏捷，但另一些地方非常僵化。而即使组织在敏捷的某些方面做得很好，另一些方面也可能存在困难。
所以，对于一个组织是否真的敏捷，我们并没有一个简单而完美的答案。敏捷存在于持续变化之中。有些组织非常敏捷，另一些可能还未达到，但也在努力改进。
然而，如果有一个方法能快速评估组织是否具有适度的敏捷性，且在尝试往好的方向发展，那将很有帮助。例如，求职者也许会想在入职之前了解该组织是否敏捷。
为了帮助解决类似的问题，我希望能识别很小的一组问题，来揭示组织（公司或团队）究竟有多敏捷。
我决定把问题数量限制在3个。3这个数字是随意选的，但我有意想要一个足够小的数字，这样假设有人在面试的过程中，就可以用这些问题进行提问。
1. 评估敏捷团队的功能性
问题1：你的团队多久对产品进行一次完全集成？
通过这第一个问题，我想了解的是团队是否是跨职能的，且组织的方式能允许他们频繁的将工作一路“完成”。我一开始想到的问题是，产品被真正交付给客户的频率如何，但这个问题的答案实际上信息量并不大，因为它很大程度上取决于客户究竟希望多久得到一次新产品的发布。
例如，我喜欢我所使用的SaaS产品上新功能（假设这些功能都是我需要的而不是过度的）。亚马逊 —— 我大部分可自由支配支出的接收对象 —— 可以每天更新多次他们的网站，我很乐意。然而，对于手机制造厂商来说，情况就不同了。假如我买了一部新iPhone，要是Apple在我从苹果商店开车回家的路上发布了两款新手机，那我一定是崩溃的。
所以一个产品发布的周期并不能充分反映组织的敏捷性。我更感兴趣的是他们对产品进行完全集成的频率。这说明了如果客户需要，组织能够多久向客户发布一次产品。
2. 衡量领导层对敏捷的承诺
问题2：当出现危机或问题，使得截止日期或计划中的里程碑不可能达成时，你们如何应对？
能最好的反映出组织对敏捷的信念程度的指标之一，就是当出现危机时会如何应对。
如果因为某些原因，一个约定好的里程碑无法达成，组织中的反应是：“我们没空玩这些敏捷的东西，我们还有个截止日期要赶。” 还是大家能够意识到，危机反而是更好的充分拥抱敏捷的机会？
询问组织如何应对这样的危机，能够揭示敏捷是真正深入的信念，或仅仅是领导层们想试试看的东西。
3. 揭露隐藏的敏捷功能障碍
问题3：和我谈谈你最好的 Scrum Master 或 Product Owner
打听人们心目中认为最好的Scrum Master 或 Product Owner，可以看出公司里的人对敏捷真正的看法。
当向人们问起优秀的Scrum Master时，我在寻找危险信号。例如，Scrum Master是否横跨太多团队工作？关于Scrum Master是否需要全职，还有一些讨论的空间。但一位管理者曾告诉我，他们最好的Scrum Master同时与20个团队共同工作。
另一个危险信号是听到一个过分指令型或规范型的Scrum Master。或是虽然声称采用Scrum，组织却决定让项目经理保留头衔，而不是“直接把他们都改名叫Scrum Master”。
和Scrum Master一样，当有人描述优秀的Product Owner时，也有一些危险信号需要注意。
曾经当我想要多了解一下组织中优秀的Product Owner时，竟然得到了：某人可以承担Product Owner的角色，同时又“不影响她真正的工作”，这样的答案。这毫无疑问也是一个危险信号。
同样的，我希望听到的时，一位Product Owner能够在整个迭代中与团队工作在一起，而不是仅仅在计划会和评审会的时候出现。如果不是这样，那又是一个危险的信号。
4. 三个问题远远不够 但这是开始
仅仅从这三个问题中了解一个组织是否真的敏捷也许是不可能的。如果有时间进行更全面的访谈，你可以对组织的敏捷性建立一个更完整和细致的理解。
但我认为以上三点至少为你的观点提供了坚实的基础。你可以用它们来判断，在这样的组织中工作，是否能满足你对敏捷的期望。我在与客户初次接触前就曾用过这些问题，来帮助我了解到达客户现场时我应该有怎样的期待。
5. 你会问什么样的问题？
对于我的这三个问题，你有什么看法？你的组织会如何回答这些问题？
如果你只能通过三个问题来了解组织的敏捷性，你会问些什么？
请在评论区留下你的观点。
6. Scrum中文网翻译组寄语
判断组织是否敏捷的第四个标志是，团队中的Developers 是否能与Stakeholders 直接建立联系。
我们在工作中往往对PO产生比较多的依赖，很多时候指望PO去跟Stakeholder沟通，如果来不及沟通，就是PO的锅。同时PO也会觉得不需要研发人员直接跟Stakeholder沟通，因为这个工作是自己的，属地意识很强。那么现实中这样就会出现很多依赖PO导致的延迟或者不清晰，如果PO突然休假两周，大家想一想这是不是会成为一个灾难事件呢。
Scrum团队是一个整体，荣辱与共，在足够透明性的团队里，我们其实不太分彼此你我。在得到PO授权的前提下，研发人员是可以直接跟Stakeholder去沟通工作挖掘需求的，但是PO始终还是有决定权。
我们看到如果团队已经自管理的形成默契了，这往往也是团队成熟的标志之一。
原文地址：
https://www.mountaingoatsoftware.com/blog/three-questions-to-determine-if-an-organization-is-agile
注：部分图片来源于网络
关于作者 & 译者
【作者】Mike Cohn
Mike是敏捷联盟及Scrum联盟创始人之一，是帮助企业适应和改进敏捷过程及技术，以建立极致高效团队的专家。著有《用户故事与敏捷方法》，《敏捷估算与规划》，《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。
【译者】Scrum中文网翻译组
Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。
Scrum中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
