- Scrum敏捷软件开发
- (美)Mike Cohn
- 3511字
- 2023-08-31 20:45:44
渴望
除了需要变革的意识,还必须渴望变革。我意识到我应该多吃一些蔬菜,但我还没有渴望改变自己的饮食习惯。在我的意识转变为渴望之前,我的饮食习惯还是照旧。Scrum培训师和顾问Michele Sliger讲述了一个公司的故事,其转型就是因缺乏类似的渴望而受阻。培训课程过了几个星期后,Sliger打电话给那家公司,让他们看看人们是如何做事情的:
因为他们公司政治方面的原因,他们认为敏捷对他们真的没用。这是我知道的唯一的一家企业,他们花时间学习敏捷,从一个敏捷顾问而不只是从书本上真实地测试了他们的文化和政治,然后说:“不。”他们是务实?现实?还是他们害怕?悲观?我不知道。但我没有见过其他公司这样说不。也许更应该说不,我确实尊重这个事实,即这些人决定,不管出于什么原因,他们就是没有准备好,而不愿意进行一些半心半意的尝试。
因为公司已经花掉引入外部培训师的费用,所以至少有部分员工已经意识到需要采取不同的做法。但是,通过Sliger的故事,我们可以得出结论,这个公司没有足够的意愿做进一步的投入进行变革。
对于许多人来说,从意识到现有开发过程不再奏效,转变到有强烈的愿望采用一种不同的方式,非常困难。毕竟,我们曾受过教育,要使用一个顺序的方式,不论是在学校,还是多年的经验。另外,尽管我们可能对项目的要素不满意,但我们为得到好老板和优秀团队做了很多努力。Scrum会改变这一切。最后,Scrum也许貌似简单,有时可能只是时机不对而已。
20年前,我的一位朋友建议我阅读约翰·D.麦克唐纳(John D. MacDonald)的特拉维斯·麦基(Travis McGee)的侦探小说。当晚,我就买了一本《穿褐色睡衣的女孩》(The Girl in the Plain Brown Wrapper),然后开始读。我不喜欢这本书,看到一半就不看了。大约一年以后,我看到书架上的这本书,决定再尝试一次。我喜欢看了,然后去买了另外20本特拉维斯·麦基侦探小说。就是心态问题,也许因为我第一次读这本书时心态是不对的。对于团队成员听说Scrum的好处,也是一样的道理。如果对一个人来说,时机不对,你就无法说服他们。好消息是,相同的消息、相同的传递方式,但在不同的时间,常常足以让一个人从有意识转变到渴望变革。
渴望提升工具
提升实施Scrum的渴望,往往比建立变革需求的意识难得多。幸运的是,有许多工具可以用来帮助人们从意识转变到渴望。
告诉人们有更好的方法。建立意识的时候,企业或团队实施Scrum面对的关键问题中,最重要的就是沟通。当我们从建立意识转变到增加渴望的时候,重点沟通Scrum如何有助于问题的解决。结合这两条信息(即目前的做法是不够好的,而Scrum可以提供帮助)会使一些人停下来,变得不接受任何信息。尽管如此,因为许多员工已经意识到需要改变,所以改变消息可以转变为福音。本章开头的Lori Schubring的故事,描述了一个富有感染力的渴望类型。
我相信敏捷可以帮助我们。我把计划放在一起,得到了我们主管的支持,然后变成一个内部的福音传道者。因为我非常相信它,所以任何人都很难忽视它。如果有人质疑这个想法,我会马上回过来质疑他们。我的愿望就是一定要抓住一部分人,虽然其他人稍微有点不太愿意。少数几个关键人物产生兴趣,确实有助于团队其余成员接受Scrum。
创造一种紧迫感。从意识到渴望,其中一个方法就是激发热情。通过创建一种紧迫感,清楚地告知他人“现在的状况不能再这样长久持续下去。”还记得我意识到我需要吃更多的蔬菜吗?假设我的医生明天打电话给我,对我说,如果我不开始吃西兰花、芦笋、菜花等,我将在6个月内死亡。我的反应可能是搞清楚如何才能喜欢上它们。
造势。把时间和精力集中于帮助热衷于Scrum的人,而不是对Scrum意愿低下或持有异议的人。让愿意做的人去做,而不是争论什么该做、什么不该做。我们的目标是营造一个不可阻挡的势头,用每一个成功去带动其他人。当Salesforce.com的Steve Greene和Chris Fry回头看他们公司的成功转型时,他们建议其他团队“关注于少数团队的成功”(2008)。不是过于分散地支持所有团队,力争通过早期的成功使Scrum实施看起来是势在必行的。接下来,其他的人就会渴望成为其中的一员。
让团队“试驾Scrum”。与其让团队对Scrum做抽象的争论,不如让他们快速体验一下Scrum,然后针对具体的内容展开讨论和争论。同意试用Scrum 3个月是一个不错的选择,这可以使团队有足够的机会尝试第一个或两个Sprint,可能还是会觉得这很不舒服。在3个月结束的时候,整个团队进行一次深入的回顾和集体决策,决定是否继续前进。不要决定是否使用Scrum。如果“试驾”后无法决定,并且团队已经划分好,那么另一个选择是继续“试驾”几个月。或者也许是团队决定,我们尚未为某个特定的实践做好准备,所以选择暂时搁置,但还可以继续使用Scrum的其他方面来工作。
统一激励机制(或至少消除不利因素)。在一个企业中,有许多奖励计划,现金奖励或其他方面的奖励,这些可能会和Scrum实施产生冲突。许多组织已有奖励计划,用来奖励对团队或部门有重大贡献的雇员。虽然类似激励计划的出现乍看有益,但违反了我们对Scrum团队成员所期望的“我们是团队”的合作心态。根据测试人员发现的缺陷数量来奖励测试人员的激励计划有着同样的破坏性影响(缺陷被记录在一个缺陷跟踪系统中)。
我曾为一个企业修订了其年度审查的形式,去掉了个人化的标准,比如工作知识、时间管理和处理多任务的能力。取而代之的是以团队为导向的准则,其中包括让别人更好地完成份内工作,为知识的分享做出贡献,愿意跨职位工作,达到团队交付目标和质量目标。
我在另外一家公司了解到,他们的产品负责人和职能经理承诺,如果产品可以按时交付,并且交付约定数量的产品功能,他们将给予团队一项独一无二的非现金奖励。尽管该产品负责人和经理信任团队,相信他们可以继续保持高质量的工作,但我要求团队给出质量指标。我不想他们通过牺牲质量来拿到奖励。他们建议以产品发布后30天内报告的缺陷数量作为衡量依据。他们的目标是比以前类似规模的版本少报两个以上的缺陷。4个月后,按照计划的日期,该团队交付出的功能比计划承诺交付的稍微多一些。在1个月后衡量质量的时候,该团队拿到了他们的奖励——4个星期的Sprint期间,他们自己做产品负责人,可以为所欲为地工作。他们借此机会对已经困扰他们很久的地方做了一些重构。一个测试人员花时间来探索新的测试工具。两个开发人员在应用程序的一个部分增加了一个脚本接口。这种类型的奖励差不多是全赢,避免了现金或类似奖励方式引发的常见问题。
聚焦恐惧的消除。我们的行为往往受我们所恐惧的东西的影响。由于过去不好的经验,产品负责人会担心一个失控的开发团队只造他们自己想要的东西。这导致产品负责人喜欢有详细的前期需求收集阶段,因为这会防止开发团队闭门造车。
另外一方面,管理层也许会担心进度过度延迟。这使得他们喜欢可以早期提供准确交付日期估算的开发过程。管理层总是认为我们不可能按时拿到产品。但正因为这个原因,通过让团队承诺更早的交付和持续给团队施压,他们可以更早拿到产品,可以避免较大的交付延迟。
架构师可能喜欢在前期做详细的系统设计,因为她擅长这个,她害怕如果项目没有设计阶段,就无法在同事面前表现更优秀。与因为恐惧而放弃渴望的人沟通时,要找机会解决为什么他们会有毫无根据的恐惧。
参考
许多恐惧来源于瀑布谬论和敏捷恐惧症,这些将在第6章讨论。许多其他的恐惧也将通过本书的补充内容进行介绍。
帮助人们学会放手。人们不会渴望有一个新的未来,除非他们可以放手过去。每一个转型都可能会有损失及随之而来的痛苦。给他们时间去悲伤,听取和接受他们的损失,而不是争吵。损失是个人的,主观的。你将永远不能说服那些因为悲伤而反应过度的人,告诉他们损失的并不是“那么重要”。所以不要尝试。
不要诋毁过去。在描述转型和向勇敢的、新的敏捷世界转型的过程中,不要漠视或贬低过去。无论现有开发过程至今对企业成功有多大帮助,都值得我们由衷赞赏和尊重。它不是一无是处。William Bridges,Managing Transitions的作者,描述了在过去努力的基础上建立新措施支持的重要性。
许多管理者对未来的热情源于将来比过去好。嘲笑或谈论原来的做事方式,这样做加大了转型的阻力,因为人们知道他们过去做事的方式,这使他们感觉过去的自我价值受到了攻击威胁。(2003,34)
努力让员工参与。在这个阶段尽量多招募同盟者。理想的盟友是一个赢得目标群体中大部分人尊重的舆论领袖。少数舆论领袖具有感染力的热情可以很快传递到企业内的其他人。Benoit Houle, BioWare公司的ScrumMaster,对此有亲身体验。
我非常有幸和其中一个备受其团队成员尊重的高级程序员建立了良好的关系。他担任我们最初试点项目几个Sprint的ScrumMaster。关于这个过程,他十分兴奋,买了许多关于Scrum和极限编程的书。作为ScrumMaster,他做得十分出色,他的热情洋溢在办公室的每个角落。
让怀疑论者也参与进来。问他们在愿意尝试Scrum之前,需要看到、体验或者知道什么,想办法满足他们。
参考
第4章将描述使用改进社区的方式来吸引员工向Scrum转型。