几周前我参加了公司内部的一个讨论,主题是:高效的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 Master应该是一个具备基本Scrum知识的“好人”。
然而想成为一名高效的Scrum Master,你还需要具备以下一些特质:
当然,除了上面列出的这些,或许你还可以写出更多的条款。但是,所有的这些归根结底化成一句话:把自己融进Scrum里面,而非单纯的使用Scrum,同时让Scrum的思维模式渗透团队的方方面面(being Scrum instead of simply doing Scrum)。坦白的说,让我们的思维模式发生这样的转变需要比较长的时间。但这是值得的,因为只有这样才能成为一名高效的Scrum Master。
高鸿 目前在诺基亚西门子通信工作,2007年开始接触敏捷开发,2009年获得CSM认证。是敏捷及Scrum的提倡和实践者,并于2012年2月获得CSP认证。相比具体的工具和实践,高鸿更关注软件开发及项目管理过程中软技能的应用及思维模式的转变带来的协同效应。他的微博:@Elton鸿