ScrumMaster窘境之”你只是一面镜子”

csm
Scrum Master 中文CSM认证-18年1月-厦门 (PMI ACP & PMP PDU, CSM)
2018年1月1日
scrumalliance
Scrum行业报告 2017-2018摘要
2018年1月4日
前些日子写过一篇《一面镜子的使命》。在文章里,我倡议ScrumMaster应该把自己看作平整、干净的“平面镜”。看待问题有景深,面对问题要全面。而不要去做带有主观偏见的“哈哈镜”,也不要去做违心奉承的“魔镜”。文章反响不错,有很多人同意这个观点 。我很欣慰,也很感谢大家的支持。但我觉得有个角度还没有覆盖到。所以今天再来补充一下,貌似有点自我迭代的意思。

正如标题上说的,“你只是一面镜子”。而镜子是无法代替行为的。就好比一个人在镜子里发现自己上火了,他可以立刻用厚厚的粉底将其掩盖;他可以决定今晚不吃火锅了;他也可以忽视这个问题,什么都不做。而镜子传递“你上火了”这条信息的使命后,也就没它什么事儿了。

         在敏捷开发对于角色的定义来说,ScrumMaster不负责开发和需求制定。如果ScrumMaster无法得到团队的信任,他对于问题的洞察无法得到团队的支持,那么很多改善就无法落地。(他撸起袖子自己干的情况除外)
来看这么一个场景

某个团队在项目早期做自动化发布策略时承诺,用户测试环境(UAT)和生产环境(PRD)的配置是完全一致的。所以在成功发布UAT之后再发布PRD是一定不会出问题的。

生产环境发布当天,在过往一周多次发布UAT成功的前提下,发布PRD失败了。得利于强大的团队,在几个小时的排查后,最终赶在期限前半小时成功发布PRD。

排查过程中,团队发现的问题如下:

• UAT环境上某个服务的版本,和PRD环境上同服务的版本不一致

• 用来发布UAT环境,和用来发布PRD环境的用户账号权限不一致

事后,ScrumMaster表达了自己看到团队体现出过硬的能力。另外也提出了一个问题:如何能确保之前说的那样,在成功发布UAT之后再发布PRD是一定不会出问题的?因为只有确保这样,团队才有信心在以后进行频繁的发布。

对于这位镜面ScrumMaster所体察到的问题,团队会如何响应呢?
响应一:很快从成功救场的兴奋中冷静下来,开始回顾在排查中发现的问题。一位对于发布全过程很熟悉的DevOps工程师趁热打铁,草拟了一份发布准备项清单。由全队帮他补充。更让人兴奋的是,出于对“UAT和PRD的配置应该是完全一致”的追求,有人提出了取消UAT的设想,并且开始梳理和讨论可行性。

当然还可能有第二种响应:•  这很正常的,在以往的项目中都有类似的情况

•  我们都不是很有经验的DBA,没办法提前预见这些情况的 发生。即便是DBA,也可能无法提前预见的

•  绝对不可以没有UAT!!!

•  问题不是解决了嘛。我们玩的是敏捷,就应该见招拆招

第一种情况里,ScrumMaster的价值通过团队得到体现。团队认可他的存在,正面他观察到的问题。团队作为一个整体在逐步改善。第二种情况里,团队没有重视ScrumMaster观察到的问题,甚至可以说有意在回避。就好像前面提到那个上火的人在镜中看到自己时,感觉镜子会“批判”自己一样,找着各式各样自己上火的理由。更糟糕的情况可能是,有的因为不愿意看照镜子,从而搁置或毁坏无辜的镜子。

到这有人可能会说,Scrum Master是个很考验软技能的角色。对于如何表达来赢得他人认同,并积极引导(Coaching)他人采取行动,这本来就是ScrumMaster的职责。

是的,我认可Coaching技巧的重要性,或许我会在另外一篇文章里分享一二。但在这,我们不能用“想救人就得就救全世界”的道德绑架来偷换概念。有些人不会被改变,或者改变他的成本很高。而ScrumMaster不是孔圣人,不是传教士。他是站在第三人视角反应实际情况的。他只是一面镜子。而镜子不是所有人都能用得出价值的。

YY一下,实在被逼急了,或许可以变身贞子从镜子里爬出来 
作者:尤承亮, CSP

评论关闭了。