【本文翻译自Mike Cohn的博客】
很多组织都声称自己是敏捷的，这里有一个快速的方法来验证他们的说法是否正确。
评估组织是否敏捷是很困难的。一个组织可能在某些方面是敏捷的，但在另一些方面却是非常僵化的。即使一个组织在敏捷的某些方面很优秀，但是在另一些方面可能就做得很艰难。
因此，对于组织是否敏捷，没有简单、完美的答案。敏捷存在于一个连续体（continuum）上（译者注：牛津词典对“continuum”的解释是“相邻两者相似但起首与末尾截然不同的”，译者觉得“Agile exists on a continuum”这句话可以意译为：敏捷不是指某一个特定的状态，而是需要持续不断的改进的。）。有些组织非常敏捷，有些则不那么敏捷，但可能正在尝试改进。
然而，有一个快速的方法来评估一个组织是否至少是适度敏捷的并试图变得更好将是有帮助的。例如，求职者可能想在承诺加入某个组织之前了解该组织是否敏捷。
为了在类似的情况下提供帮助，我想确定一组非常小的问题，这些问题将揭示组织(公司或团队)究竟有多敏捷。
我决定将自己限制在三个问题上。“三”的选择是随意的。但我故意想要一个足够小的数字，这样就能方便求职者在面试时问他们的面试官。
评估敏捷团队的功能
问题1：您的团队多久完成一次产品集成?
对于第一个问题，我想了解团队是否具有跨功能和结构化的方式，使得他们能够经常完成所有的工作。我首先想到的是询问产品实际向客户发布(release)的频率。但是，这个问题的答案实际上提供的信息较少，因为它很大程度上取决于客户想要一个新版本的频率。例如，当我使用的任何SaaS产品添加新功能时，我都喜欢(假设它们是我想要的功能，而不只是膨胀)。亚马逊——我相信，它是我大部分可自由支配支出的接收者——每天可以多次更新其网站，我很高兴。然而，对于手机制造商来说，情况就不一样了：如果我买了一部新iPhone，苹果公司在我从苹果商店开车回家的路上发布两款新手机，这时我会很沮丧。因此，产品实际发布的频率可能不能告诉我关于组织的敏捷性的太多信息。我更感兴趣的是它们完全集成(integrate)的频率。这告诉我，如果客户希望，组织可以多久发布一次。
衡量领导层对敏捷的承诺
问题2：如果出现危机或问题使最后期限或计划的里程碑无法实现，领导层如何应对？
衡量组织对敏捷有多信任的最好指标之一是发生危机时如何响应。
如果由于某种原因，一个团队不能达到之前商定的里程碑，那么组织的反应就是，“我们没有时间做敏捷的事情;我们必须在最后期限前完成?或者，员工是否意识到危机是更充分拥抱敏捷的时候?
如果某个团队由于某种原因未能达到先前商定的里程碑，组织的反应是“我们没有时间来使用这种敏捷的东西，我们必须在最后期限前完成”， 还是员工意识到危机是更充分拥抱敏捷的契机？
询问组织如何应对这样的危机，就可以发现敏捷是一种根深蒂固的信念，还是仅仅是领导层想要尝试的新花样。
发现隐藏的敏捷功能障碍
问题3：谈谈你们最好的SM或PO。
询问对方认为谁是最好的SM或PO，可以反映出公司里的人对敏捷的看法。
当我询问一个优秀的SM时，我寻找的是危险信号。例如，组织中的SM是否分散在太多的团队中？关于SM是否需要全职还存在争议，但一位经理告诉我，他们最好的SM是和20个团队一起工作。
另一个危险信号是得知有过度指令型的SM。或者，尽管宣称使用Scrum，组织还是决定保留项目经理（project manager）头衔，而不是“把他们都重新命名为Scrum Master”。
就像关于优秀SM的回答一样，当有人在描述优秀的PO时，也有需要注意的危险信号。
有一次，当我要求了解更多有关组织中出色PO的信息时，我被告知有人能够在“不影响她实际工作”的情况下承担起PO的角色。这真的是一个危险信号。
同样，我希望听到PO在整个迭代过程中与团队合作，而不仅仅是在计划和评审会议上。如果PO没有这样做，这可能是另一个危险信号。
三个问题还不够，但它们是一个开始
仅仅三个问题可能无法知道一个组织有多敏捷。如果有时间进行更彻底的采访，您可以对组织的敏捷性建立一个更完整、更细致的观点。
但我认为，这三个问题至少为观点提供了坚实的基础。您可以使用它们来帮助确定在该组织中工作是否能满足您对敏捷的期望。在与客户初次接触之前，我就已经使用过它们，所以我知道当我到达的时候会发生什么。
你有什么问题？
你觉得我的这三个问题怎么样？您的组织将如何回答这些问题？如果你只能问某人三个问题来评估组织的敏捷性，你会问什么？请在下面的评论中分享你的想法。
网友评论