Scrum_tp12

灵魂三问,帮你快速判断组织是否真敏捷

判断一个组织是否敏捷是一件困难的事。一个组织可能有些方面很敏捷,但另一些地方非常僵化。而即使组织在敏捷的某些方面做得很好,另一些方面也可能存在困难。

所以,对于一个组织是否真的敏捷,我们并没有一个简单而完美的答案。敏捷存在于持续变化之中。有些组织非常敏捷,另一些可能还未达到,但也在努力改进。

然而,如果有一个方法能快速评估组织是否具有适度的敏捷性,且在尝试往好的方向发展,那将很有帮助。例如,求职者也许会想在入职之前了解该组织是否敏捷。

为了帮助解决类似的问题,我希望能识别很小的一组问题,来揭示组织(公司或团队)究竟有多敏捷。

我决定把问题数量限制在3个。3这个数字是随意选的,但我有意想要一个足够小的数字,这样假设有人在面试的过程中,就可以用这些问题进行提问。

1. 评估敏捷团队的功能性

问题1:你的团队多久对产品进行一次完全集成?

通过这第一个问题,我想了解的是团队是否是跨职能的,且组织的方式能允许他们频繁的将工作一路“完成”。我一开始想到的问题是,产品被真正交付给客户的频率如何,但这个问题的答案实际上信息量并不大,因为它很大程度上取决于客户究竟希望多久得到一次新产品的发布。

例如,我喜欢我所使用的SaaS产品上新功能(假设这些功能都是我需要的而不是过度的)。亚马逊 —— 我大部分可自由支配支出的接收对象 —— 可以每天更新多次他们的网站,我很乐意。然而,对于手机制造厂商来说,情况就不同了。假如我买了一部新iPhone,要是Apple在我从苹果商店开车回家的路上发布了两款新手机,那我一定是崩溃的。

所以一个产品发布的周期并不能充分反映组织的敏捷性。我更感兴趣的是他们对产品进行完全集成的频率。这说明了如果客户需要,组织能够多久向客户发布一次产品。

2. 衡量领导层对敏捷的承诺

问题2:当出现危机或问题,使得截止日期或计划中的里程碑不可能达成时,你们如何应对?

能最好的反映出组织对敏捷的信念程度的指标之一,就是当出现危机时会如何应对。

如果因为某些原因,一个约定好的里程碑无法达成,组织中的反应是:“我们没空玩这些敏捷的东西,我们还有个截止日期要赶。” 还是大家能够意识到,危机反而是更好的充分拥抱敏捷的机会?

询问组织如何应对这样的危机,能够揭示敏捷是真正深入的信念,或仅仅是领导层们想试试看的东西。

微信图片_20220721165545

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中文网是国内领先的敏捷培训及教练咨询机构,作为中国敏捷教练的摇篮,启蒙和培养了数万名敏捷专业人士,帮助数百家知名企业成功转型敏捷。