• 这个错误,每个ScrumMaster都犯过


    【小编】ScrumMaster要授之以渔,还是授之以鱼?从04年开始接触XP,到08年自己的团队开始提出敏捷的概念,再到10年接受ScrumMaster培训;在刚开始做ScrumMaster的一段时间内,我也一直为团队没有主动性而困扰/烦躁;越是这样,就越是喜欢指手画脚 (Command & Control),结果进入恶性循环。


    以下是译文:

    很多年以前,我开始从一名项目经理转换到ScrumMaster的职业道路上,看上去并不难,对吧?

    但,其实没那么简单!

    就如同我在“你到底是项目经理还是ScrumMaster?”这篇文章里说的,让我放弃指令控制性的管理思维方式,是很难的。我必须要努力改变。

    dailyscrum

    在这个改变过程中,我犯过很多错误,自己也感觉很煎熬,所以对其中的每一次“自我觉悟”都记忆犹新!直到今天,我还是会经常把这些心路历程作为经验分享给那些希望成为ScrumMaster的朋友。当然,我还是遇到了很多名片上印着ScrumMaster职位的人,并没有真正理解 Daily Scrum 的真正用意以及和“项目汇报”有啥区别,虽然这仅仅是Scrum所推行的一个小小实践,但是对于一个敏捷转型中的企业的影响可谓巨大!

    你犯过这个错误没有?

    承认吧!如果你做过ScrumMaster,一定推行过 “Daily Scrum汇报”例会,而且情有独钟!症状如下:

    • 每个开发人员对着ScrumMaster说:我昨天干了这个,今天我干这个,没有问题!
    • 然后,ScrumMaster把白板上的即时贴挪动一下位置,告诉团队:好吧,你们应该这样!
    • … 最后,ScrumMaster问道:那这个任务完了没?或者:啥时候能做完?

    看上去很熟悉吧,很像你自己对不对(或者你的团队里面的某某人)。好吧,那我来告诉你,这种状态(行为)必须立即改变,你的团队必须学会如何自行管理进度,并且能够自己高效,高度协作的完成整个会议;当然,教会他们是你作为一名ScrumMaster的责任。

    Daily Scrum和你想象的并不一样!

    要理解 Daily Scrum 的目的,其实没有那么容易。我这么说是因为我发现要戒除“汇报”的习惯是一件很困难的事情,在任何组织中都是这样;但我建议你还是要像我一样努力一下。

    开始接触 Daily Scrum的时候我也很困惑。15分钟的会议,代替原来的“项目汇报”,原来放在每个周五,现在可以每天进行,很简单。一切看上去都没啥变化,我们用一块白板来跟踪进度,每天早上回答“三个问题”,大家向我(项目经理/ScrumMaster)汇报一下进度。没啥不同嘛!

    但是这种想法从一开始就错了!

    Scrum的真谛

    在一次真正的 Daily Scrum 上,作为ScrumMaster应该做的并不是主持这个会议,而是教会团队如何更好的跟踪进度,完成规划,处理他们自己的问题,和PO更好的协作,并在出现问题的时候适当的处理。

    简单的说,你要做的是授之以渔,教会你的团队如何自行管理,而不是管理他们。

    一旦懂得了这一点,我将自己的行为从一种管理者的姿态放到了协助者的姿态。这一点小小的心态调整,让我的团队有了巨大的变化和改进。当我的团队学会了自我协作后,我就开始慢慢减少参加他们的Daily Scrum,到现在基本上不参加!

    有很多人会把Daily Scrum称为Daily Stand-up,其实我建议还是采用Scrum Guide上所使用的名称。虽然仅仅是名称上的不同,但它会提醒你所做的是Scrum,而不仅仅是stand-up,这是一种思维方式的改变。对于一个组织的敏捷转型,思维方式的转变才是根本。

    如果你是一名ScrumMaster,建议你首先改变自己的姿态,以一名协助者而不是管理者的姿态参与;想清楚,我是来帮助大家的,不是来管理大家的。

    最后

    回想一下你的 Daily scrum是个什么状态?思考一下:如何能让你的团队在你不在场的情况下,仍然可以高效的协作,这个出发点就对了!

    原文作者 Dan Sloan敏捷教练,Scrum.org认证的专业培训师

    dansloan

    原文链接: https://www.linkedin.com/pulse/1-mistake-every-scrum-master-makes-least-once-daniel-sloan


    【小编评语】让自己从一名管理者变成一名协助者不是一件容易的事情,最困难的是我们内心的不安全感:“如果我不管他们,工作做不完怎么办?最后还得我来收拾!”其实有的时候,放手才是解决问题的办法,当然,放手的前提是由你,一名管理者,划定好了轨道;但是在轨道上跑的,是你的员工,而不是你。管理者需要的是让自己的员工能够按照组织的期望工作,做到这一点需要的是形成员工自己的“驱动力”,而不是你“拉动力”。


    请关注微信公众号 devopshub,获取更多关于DevOps研发运维一体化的信息

    qrcode_for_gh_b7c158df1fd1_430

     转自:http://devopshub.cn 

  • 相关阅读:
    申请国家自然科学基金项目的一点体会(周浙昆)
    漫谈影响自然基金申请的因素
    凡是过往,皆为序章—写在2018年国基揭榜之时
    再谈国家基金项目申请中的几个问题
    国家基金申请书中的科学问题与关键问题
    我喜欢这样的国家自然科学基金本子
    Fedora 28 —— install fonts for WPS
    清华11篇撤稿背后:院方早已处理,被曝光才公开结果
    CPU:chip、core 和 processor 的关系
    Fedora 28 —— chm 阅读器
  • 原文地址:https://www.cnblogs.com/ups216/p/4997207.html
Copyright © 2020-2023  润新知