当我刚开始担任Scrum Master时,最让我害怕的就是如何将那些崇高的理想转化为实际的脚踏实地的行为。虽然“Scrum是经验主义”这句话听起来不错,但我不知道我的团队应该是什么样子,我应该如何表现来支持这一点,以及我可以如何灵活地使用 Scrum框架。
我曾为许多类似的问题而苦恼。偶尔跳过每日站会可以吗?作为Scrum Master,我是否应该始终领导Scrum活动?如何领导?我与利益相关者的关系应该如何?尤其是当他们要求我向团队传达他们的批评意见时?
在这篇文章中,我们收集了五个实用见解,我认为每个Scrum Master新手都应该了解这些见解,这些见解的灵感来自于我多年来所犯的错误。如果有的话,我希望我在开始时就意识到了这些。
如果你是一名新Scrum Master,你可能会觉得压力很大,需要解决团队遇到的任何问题。例如,我会立即解决在每日站会期间提出的任何问题或障碍。我还花了很多脑力,试图想出让更多利益相关者参与进来的方法,如何完成更多的完成增量,以及如何改进我们的部署流程——然后向团队介绍我的解决方案。
尽管我做这一切都是出于好意,但简单的事实是我不知道还能如何解决这个问题。我对我的团队的印象是,他们不愿意花时间在这些问题上,而且因为我不想进一步打扰他们,所以我试图自己解决障碍。有一段时间,这对我来说就像是进步。团队对此也很满意。
幸运的是,我很快意识到这是行不通的。我的第一个预感是,当我的团队越来越多地将障碍委托给我时,我感觉解决这些障碍的效率非常低。例如,我的团队要求我代表他们参加“Scrum of Scrums”,或者与产品负责人交谈以更改Sprint的范围。然后有一台笔记本电脑突然死机了,开发人员让我换一台新的。我的第二个预感是,在我休假期间,各种基本问题都在董事会上停留了数周,等待我回来。
简而言之,这就是为什么你应该“把它带给团队”。当你有疑问时,当面对如何做某事的问题时,当面对障碍时:问问你的团队——包括你自己——他们应该如何处理这个问题,然后一起努力去真正做到这一点。当你分享你的不带偏见的观察结果时,效果会更好(例如“我注意到,在我休假期间,产品负责人积累了很多问题,但这些问题都没有得到解答。”或“我注意到利益相关者在Sprint评审期间很少有话要说”)。
当你有条不紊地这样做时,其他人也会开始这样做。你现在不仅可以从整个团队的经验和见解中受益,还可以练习宝贵的解决问题的技能,而这些技能是持续改进的驱动力。
作为新Scrum Master,你要么有机会组建一个新的Scrum团队,要么加入一个现有的团队。我多次学到的一个惨痛教训是,你真的应该尽早召集你的团队来重启团队,回答三个核心问题:
1.这个团队的目的是什么?它所创造的产品是什么?
2.谁是这个团队的成员?它的利益相关者是谁?
3.作为一个团队,我们需要遵循哪些最低限度的规则来管理我们工作的复杂性,同时为我们的利益相关者提供价值?
“我多次学到的一个惨痛教训是,你应该尽早召集团队,回答三个核心问题,从而重启团队。”
如何回答这三个问题取决于你。我总是喜欢把它变成一个为期1到2天的团队研讨会,其中包括团队建设和制定共同愿景,即如果我们齐心协力,它会变成什么样子。无论你做什么,都要尽可能争取至少一天的一部分时间来做这件事。如果你觉得还不够,而且通常确实如此,你可以稍后安排后续活动。
毫无疑问,我在Scrum方面犯的最大错误是,我花了很长时间才意识到利益相关者应该推动Scrum团队开展的所有工作。将所有精力都集中在团队上,而将外部世界留给产品负责人,这种做法非常诱人。这是个错误。
在改善团队工作方式方面,利益相关者是你的天然盟友。如果你因为不必要的官僚主义而无法在每个Sprint发布完成增量,那么这对利益相关者和团队的伤害一样大。
如果你的产品负责人缺乏决策权,并且因此导致一切进展缓慢,他们也会蒙受损失。如果你的团队交付了质量存疑的产品质量,那么了解利益相关者的反馈将为有关质量控制和完成定义的重要对话打开大门。
我应该指出,利益相关者指的是所有实际参与你产品的人。这些人会为你的产品投入大量金钱、时间或两者兼而有之。如果你交付了一款出色的产品,他们会很高兴。
如果你交付了劣质产品或什么都没有交付,他们就会失去这笔投资。这个定义不包括那些可能对你的产品有意见,但如果你的产品没有交付,他们个人不会有任何损失的人。
因此,在你的第一个Sprint中,请与您的产品负责人和团队合作,确定利益相关者的位置以及如何立即让他们参与进来。
即使这非常困难,一旦实际的利益相关者开始出现在你的 Sprint评审中,并且一旦团队开始听取他们的反馈,Scrum框架中的所有内容就会开始有意义。这就是这条建议如此重要的原因。
“因此,在你的第一个Sprint中,请与你的产品负责人和你的团队合作,确定利益相关者在哪里以及如何让他们参与进来。”
在担任Scrum Master期间,你将面临许多棘手的挑战;这些问题非常棘手,没有单一的解决方案能够脱颖而出。例如,当出现严重问题时,你应如何鼓励团队的自主性,同时又能介入?当管理层要求你报告团队进展并评估团队成员时,你应如何响应?
其他时候,事后你会发现自己一直在做的事情并不是一个好主意,但为时已晚。例如,许多Scrum Master最初都遵循故事点估算,并根据团队在每个Sprint中交付的点数进行比较,直到他们发现,当你将故事点用于此目的时,它们会导致各种问题。
值得庆幸的是,你并不孤单。对于所有刚入行的Scrum Master 或任何专业人士来说,我们最好的建议之一就是向其他Scrum Master寻求帮助。有许多社区可以促进这一点,比如我们自己的优普丰敏捷社区,加入我们的优普丰大广场群,和领域内的小伙伴们一起探讨。
Scrum框架对团队和组织的潜在影响很容易让人兴奋。为了展示领导力,新晋Scrum Master(以及经验丰富的 Scrum Master)有时会对其团队和组织来说行动过快。我有时确实会这样,这让与我共事的人非常恼火。
因为在这种兴奋中,很容易将人们现在的工作方式视为“传统”或“过时”,当人们看不到你所看到的东西时,你会感到沮丧。带着这种傲慢和对已有事物的漠视,你很容易产生自己的抵触情绪。
解决这个问题的办法是保持谦虚。你需要花时间深入了解Scrum框架是什么以及其元素如何协同工作。哎呀,我当Scrum Master已经十几年了,但我仍然在发现以前从未完全意识到的细微差别。
谦逊也意味着善良。善待你团队现在的工作方式,即使它看起来还不是Scrum。善待那些还没有看到你所看到的潜力的人。当你不知道如何在某种情况下扮演Scrum Master的角色时,善待自己。
“坚定地将自己视为团队的一员,不要将自己置于团队之上”
这就引出了Scrum Master的第二个难题:透明度。当你不断寻找方法让团队和组织知道哪些工作做得好,哪些工作做得不好时,你就能为团队和组织做出最大的贡献。一个简单的方法是分享一个不带任何评判的观察结果,然后提出一个开放式问题。
例如:“我发现我们在 Sprint 的大部分时间里都在各自处理自己的项目,我想知道这对我们有什么好处,以及我们作为一个团队可能会因此而失去什么?”或者:“我发现我们的Sprint评审很少有利益相关者参加,我想知道这对我们的合作意味着什么”。
你还可以与团队合作跟踪有用的指标(如周期时间、错误数量和团队士气),并一起检查它们。
通过将谦逊和善良与这种彻底的透明度相结合,你可以创建一个安全的环境,让你的Scrum团队(包括你)可以不断提高其实证工作的能力。
“通过将谦逊、善良与彻底的透明度相结合,你可以创建一个安全的环境,让你的Scrum团队(包括你)可以不断提高其实证工作的能力。”
在撰写这篇文章并征求其他Scrum Master的意见时,我注意到大多数建议与我们通常与职业成功相关的因素无关;你拥有的证书、你接受的培训量,甚至你拥有的年限。虽然掌握Scrum确实需要数年时间,但这也意味着每个Scrum Master都应该能够应用它们——无论他们的经验如何。
这就引出了我最后的要点。作为一名Scrum Master,很容易完全停滞不前,整天如履薄冰,担心自己做错了,或者缺乏别人眼中的才能。但就像你不可能一下子就打造出完美的产品一样,与团队一起循序渐进地学习Scrum也是很自然的。
作为一个团队,你会犯错误,有时前进一步就会后退两步。如果你们作为一个团队一起工作,最终你会成功的!