几周前我参加了公司内部的一个讨论,主题是:高效的 Scrum Master 该具备哪些技能?大家都根据自己的经验积极发表看法。但是很奇怪,我感觉大家在逐渐偏离着主题。我更情愿相信大家的讨论是针对“称职的 Scrum Master”而非“高效的 Scrum Master”。因为在我看来,这两者之间是有着本质上区别的。
这次讨论让我回想起 2011 年初的一次经历。当时我加入了一个新项目,该项目已经持续运行 6 个月左右,有 4 个 Scrum 团队。该项目外包给了另一家公司,所以团队成员基本是外部人员,Scrum Master 最初也是由一名外部同事担任。在进入项目后不久,我就发现一个奇怪的现象。我们的组员甚至其他组的同事经常会有些不断重复的抱怨。最常听到的有:Scrum 不过是一个时髦的名字而已!我们会工作地更有效率,如果没有那些烦人的表格和会议!这不是 Scrum,不要叫我们 Scrum 团队!
坦白地说,我不喜欢待在一个士气低下、缺少责任感的团队里面。我明白,因为是外包项目,团队的设置比较复杂,而且组员之间的信任感还不够强,所以在这样的团队中矛盾是会相对比较多一些。但是因为大家经常挂在嘴边的是对开发模式的抱怨,所以我打算找出为什么大家如此不喜欢 Scrum 的原因。在相处两个月之后,经过细心的观察,我大致得出了结论:尽管管理层有一定的责任,但是我更愿意归结为团队自身出了问题 – 不是沟通不畅,也不是日程太紧,而是开展 Scrum 的时候出了问题。这个项目的团队的是比较新的,而且有些成员也是刚开始接触 Scrum 开发模式。然而对于刚开始采用 Scrum 模式的团队来说,这些因素都很常见,况且我们组还有一个称职的 Scrum Master。
我说的“称职的 Scrum Master”是具备这样条件的:他 / 她理解对于 Scrum Master 哪些能做哪些不能做;他 / 她知道怎么使用相关工具产生相关工件并利用相关产出分析问题;他 / 她明白怎么开每日例会、计划会议、评审会议以及回顾会议,等等。
坦率地说,在接触 Scrum 的这 5 年中,我遇到过不少“称职的”Scrum Master。他们严格地根据标准的 Scrum 模式(比如源自一些入门级的介绍性的培训或者 Scrum Primer 等类似指南的描述)来确保团队实施 Scrum,并帮助成员习惯这一开发模式。这对于在团队刚开始采用 Scrum 的初始阶段是非常重要的。因为大家需要这样来逐渐巩固对 Scrum 模式的理解。然而一旦过了那个初始阶段,新鲜感褪去后,团队很快就会遇到一层天花板:很难真正利用 Scrum 的先进之处并看到相应成效。
那么,到底我们的团队在开展 Scrum 的时候具体出了什么问题?让我继续说说去年加入的那个团队。当时我的感觉就是我们确实遇到那个天花板了。整个团队似乎还停留在适应 Scrum 的那个阶段:按照标准的模式按部就班。我们的团队当时采用 Scrum 完全是因为管理层的要求。因此在习惯了这种新鲜的工作方法后,团队必然要期待更多的好处。按大家对 Scrum 的了解,那会:提高软件的质量,提升团队的生产力,形成更自由的自组织团队,等等。然而那个时候,大家没有看到期待的结果。 因此在等待那些好处的同时,对 Scrum 的信任和耐心在逐渐流失;随之而来的是日渐增多的怀疑和抱怨。可以这样描述我当时加入团队时候的情景:团队的信念 <50%, 怀疑 >50% (信念 + 怀疑 =100%)。由于大家看不见回报,因此失去了信心,团队像是被卡在某个地方很难进退了。
为什么团队会被卡住了无法冲破那层天花板?因为,大家只是在“用 Scrum”(Doing Scrum)。Scrum Master 努力做的称职;团队努力的按照按标准模式在做。但是在我看来,做的好还不够,做的高效才是真正的目标。对于 Scrum Master 来说,称职只是第一步。如果真想利用 Scrum 来给团队带来明显的好处、改善,那么成长为一名高效的 Scrum Master 则是你应该内化的责任和义务。高效的 Scrum Master 除了能让团队平稳地运行,还需要帮助团队进一步的深挖以形成内在的责任感,并且找到在 Scrum 框架下最适合团队自己的工作方法。停留在表面上、仅仅按标准模式行事,不能成为我们的目标。我们需要更进一步;我们需要将注意力放在团队本身。
那么,到底怎样才算是一名称职的 Scrum Master,怎样才能变得高效呢?下面列出一些我对称职的 Scrum Master 的认识:
- 严格地知道 Scrum 是什么,不是什么;
- 严格地知道 Scrum Master 该干什么,不该干什么;
- 具备强烈的责任感和自尊心;
- 具备良好的团队工作技能。
一句话:称职的 Scrum Master 应该是一个具备基本 Scrum 知识的“好人”。
然而想成为一名高效的 Scrum Master,你还需要具备以下一些特质:
- 高度的决心和毅力
- 这是成功的关键性因素。因为,对于推动队员思维模式的转变是非常困难的,更不用提整个组织的转变了,特别是在看到组织内部有失败案例的时候;
- 你必须有足够的耐心来帮助团队一步一步地转变,因为要想看到积极的趋势是会花很多时间和精力的。在出现“信任危机”的时候(非常可能出现),你必须要有足够的耐心来说服他人、影响他人;
- 既要理解标准化的 Scrum 模式,又要根据自己组织的固有特点来实际地运用它
- 这是成功的决定性因素。因为没有任何两家公司是相同的;
- 这也要求你要比较温和的推进转变。记住:欲速则不达;
- Scrum Master 需要制定一个比较长远的推进计划,然后步步为营,直到团队自己找到基于 Scrum 框架和思维模式的最佳工作方法;
- 准备好挑战他人并接受他人的挑战
- 向管理层寻求帮助固然有用,但通常比较困难。因此在适当的时候记得去挑战你的老板。很多成功的变革通常是由下至上发起的,不要一味地依赖老板的指示;
- 若在实施过程中受到外界的挑战和动摇,一定要对自己、对团队、对组织有坚定的信心。如果外界的动摇具有 10 分的摧毁力,那么你自己的动摇则具有 100 分;
- 持续改进自我的愿望
- 这点不仅适用于团队成员,更是适用于 Scrum Master 自身。因为通过自我的持续改进,你才能有效的影响团队成员,让大家积极的凝聚在一起,直到找到最高效的工作方法这一终极目标。
当然,除了上面列出的这些,或许你还可以写出更多的条款。但是,所有的这些归根结底化成一句话:把自己融进 Scrum 里面,而非单纯的使用 Scrum,同时让 Scrum 的思维模式渗透团队的方方面面(being Scrum instead of simply doing Scrum)。坦白的说,让我们的思维模式发生这样的转变需要比较长的时间。但这是值得的,因为只有这样才能成为一名高效的 Scrum Master。
关于作者
高鸿 目前在诺基亚西门子通信工作,2007 年开始接触敏捷开发,2009 年获得 CSM 认证。是敏捷及 Scrum 的提倡和实践者,并于 2012 年 2 月获得 CSP 认证。相比具体的工具和实践,高鸿更关注软件开发及项目管理过程中软技能的应用及思维模式的转变带来的协同效应。他的微博: @Elton 鸿
给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论