Scrum敏捷实践集

Scrum_TP1

ScrumMaster如何规避微观管理问题?

在许多组织的敏捷转型过程中,一些由传统强势项目经理或团队Leader转职而来的Scrum Master仍然在延续以往的管理习惯,存在微观管理现象,阻碍了团队的成长。

一 微观管理及其危害

微观管理(Micromanagement)一般是指:在对员工的工作管理中,管理者过度关注和控制工作细节的管理风格和管理行为。

客观地说,关注细节并非坏事。但是一旦过于关注和控制细节,就会带来种种问题:

Read more

Scrum_tp2

3种策略教你如何在Sprint中偿还技术债

作者: Mike Cohn

译者:李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

链接:https://www.mountaingoatsoftware.com/blog/three-strategies-for-fitting-refactoring-into-your-sprints

 

团队常常很难将重构或其他技术清理工作纳入到其sprint中。首先,要说服产品负责人相信技术债务应该偿还而不能任由其累积,这就会是一个挑战。然而,即使产品负责人已经同意了,由于面临其他干扰、中断和变更,许多团队仍然很难将重构纳入Sprint中。

在本文中,我阐述了为重构腾出时间三种常用方式。对于每种方式,我将描述其优缺点。

Read more

Scrum_tp

Scrum Master如何使用强有力的问题来引导团队

今天,我想分享的话题是:作为敏捷教练,Scrum Master如何使用强有力的问题来引导。

一. 使用强有力的问题来引导团队

教练不会给人们答案,而是会引导人们自己找到解决方案。

那么如何引导呢?

Charles Kettering指出,“只要清楚地陈述出问题,就已经把问题解决了一半”。

Dorothy Leeds在其著作《提问的七种力量(The 7 Powers of Questions)》中进一步地总结了人际沟通中提问的七种力量,分别是:

  1. 提问能要求回答
  2. 提问能激发思考
  3. 提问能给我们带来有价值的信息
  4. 提问能让您掌控局面
  5. 提问能让人们打开思维
  6. 提问能引发高质量的聆听
  7. 提问能使人们说服自己

作为敏捷教练,强有力的问题,是Scrum Master在日常工作中最有用的手段之一。

二. Scrum Master要转换角色

当我们还是一名开发人员时,我们往往习惯于亲自动手解决问题。当我们还是一名传统的团队管理者时,我们往往习惯于发号施令。

当我们成为Scrum Master时,如果我们仍然是采用直接给出问题解决方案,或者通过发号施令的方式来管理团队,那么团队就会习惯于服从我们的指令,而无法成长为一个具备自组织能力的敏捷团队。

因此,为了培养团队的自组织能力,当团队面临问题时,我们不能仅仅是直接给出问题的解决方案,而是要引导团队自己找到问题的解决方案。

三. Scrum Master应用强有力问题的三种常见场景

作为敏捷教练,Scrum Master有三种常见的提问场景:

  1. 当团队忽视了某种问题或风险时,通过提问引起团队关注。
  2. 当团队存在认知偏差时,通过提问让潜在假设浮出水面。
  3. 当团队在工作中存在思维盲区和方法局限时,通过提问挖掘更深层次的问题、开拓思路、引发创新方案。

四. 在不同场景下的提问方式

1. 当团队忽视了某种问题或风险时,通过提问引起团队关注。

这种情况下,我往往会采用类似于“我注意到。。。。。。,这会不会。。。。。。?我们该怎么办”的句式来提问。

例如:在某个迭代过程中,有一位团队成员突然有事请了两天假,而团队还没有意识到这会不会影响到迭代目标的实现时。我会在每日站会结束前问整个团队:“我注意到大刘请了两天假,这会不会影响到我们迭代目标的达成呢?我们该怎么办?”

2. 当团队存在认知偏差时,通过提问让潜在假设浮出水面。

由于存在错误的潜在假设而导致出现认知偏差,往往是出现协作冲突的根因。这种情况下,要让潜在假设浮出水面,我往往会采用类似于“对于。。。。。。,你怎么看?”、“对于。。。。。。,你认为会怎么样?”的句式来提问。

例如:在一开始的迭代计划会议上,团队成员不愿意对迭代目标做出承诺。我会私底下单独找团队成员问:“如果迭代目标没有全部都实现,你觉得会对团队有什么不良影响?”

3. 当团队在工作中存在思维盲区和方法局限时,通过提问挖掘更深层次的问题、开拓思路、引发创新方案。

这种情况下,需要帮助团队成员改变思维定势,我往往会采用类似于“为什么。。。。。。?”的句式来引导大家继续深挖问题,采用“大家觉得除此之外,还有没有什么其他可能的方案?”的句式来开拓方案,如果团队确实想不出更好的方案,我会介绍自己的一些经验做法,然后问大家“有没有可能。。。。。。?”,以此来引导团队考虑新的方案。

五. 您怎么看

您在教练团队时碰到过哪些提问场景?您通常会提出什么强有力的问题?
欢迎在评论区留下您的经验。

 

作者:李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训

Scrum_tp

您知道敏捷中是如何尽早识别风险的吗

作者: Mike Cohn

翻译:李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训

原文链接:https://www.mountaingoatsoftware.com/blog/use-a-pre-mortem-to-identify-project-risks-before-they-occur

 

“任何可能出错的事情,都将出错。”我们都听过墨菲定律的含义。我们很多人都曾经讲述过墨菲定律,但是很少会有人表现得对此而担心。

为可能出现的问题做好准备的一个有用技巧是进行“预分析(pre-mortem)”。这是一个在项目或版本开始时召开的会议,干系人在会议中识别所有可能影响成功交付的问题。

Read more

Scrum_TUP

2020年Mike Cohn的十大流行博文

如同过去几年一样,在新一年开始时,我会列出了我前一年分享的最受欢迎博客文章。以下是根据每天的页面浏览数量和评论数量选出的2020年最受欢迎10篇博文,从第10篇开始,一直到最受欢迎的那篇。

10. 在风险发生前,使用事前分析来识别项目风险

我们都熟知回顾会议或事后分析的好处。这篇文章描述了一个强有力的事前分析过程。 Read more

u=389611283361,1817667073&fm=26&gp=0

不能将软件组织的绩效目标分解到职能

在上一篇文章《软件研发绩效管理的第一性原理》中,我阐述了软件绩效管理的三大目标和原则,大家可以用来评估和改进自己的绩效管理体系。

本文中,我将讨论软件组织中绩效管理的责任主体。

一. 组织通过价值流来实现绩效

要进行组织的绩效管理,首先要理解组织是如何实现绩效产出的,这就必须了解价值流的概念。

什么是价值流? Read more

Scrum_tp

软件研发绩效管理的第一性原理

我的上一篇文章《软件研发管理中需要破除的三大绩效管理理念》发表后,得到了不少小伙伴的赞同,大家希望能进一步给出一些问题解决方案。比如:有一位ID为“飘游乱码”的小伙伴留言:“问题有了,有建议的解决方案没?谢谢!”

由于绩效管理是个比较大的话题,我会持续选择一些主题来进行讨论。在本文中,我想先讨论一下自己对软件研发绩效管理的第一性原理理解。

一 在很多组织中,软件绩效管理“三观不正”

我自己亲自在很多家公司工作过,也接触过很多公司,亲眼目睹了许多软件研发绩效管理的“三观不正”现象。特别是以下两种现象:

#1 绩效管理,完全以考核人为目的

在某些公司,绩效管理完全围绕着绩效考核来进行。每年/半年/季度,这些公司的管理者都要对员工设置绩效目标,并在周期结束时进行绩效考核。

然而,在软件研发中,个人绩效目标很难预先设置和合理设置;所以,在绩效考核时,管理者往往也并不是真得完全基于绩效目标来进行考核,而是要对自己认为表现好的员工,挖空心思去加分,而对于自己不满意的员工,则挖空心思去减分。

于是,绩效管理,就变得完全以考核员工为目的——依赖绩效考核这个手段,把人区分出三六九等,给与分别对待——对于管理者认为表现好的人,升职、加薪和多发奖金,而对于管理者认为表现不好的人,则是将其淘汰的机会。

这样做,保证了管理者的权威,同时也让组织变得“官文化”流行。

#2 崇拜“神器”

很多公司都很崇拜绩效管理“神器”。

曾经非常流行KPI,所有的岗位都要有KPI——彷佛没有KPI的公司就是游击队,绩效管理完全围绕着KPI来进行。后来,出现了一篇非常著名的抨击KPI的文章,名字我就不说了,大家可以自行百度一下。于是乎,一夜之间,“神器”变成了“过街老鼠”。

一个神器破灭了,怎么办?没关系,还会出现新的“神器”!你看,新的“神器”不是又出现了——OKR。

于是无数的公司又捧起了OKR这个“神器”——所有的岗位和工作都要制定OKR目标。还有许多知名人士在发文著作,O该怎么定义,KRs该怎么定义,OKR该怎么跟……彷佛企业只要参透了这个秘密,彷佛企业只需要推行了OKR,就能够立马打通任督二脉,从此飞上了天。

然而,不可避免的是,有人质疑:“OKR与KPI到底有什么区别?难道传统的KPI就没有目标和关键成果物吗?难道传统的KPI就不进行目标和关键成果物的跟踪吗?”——“这个问题说不清楚,别讨论这个问题,你只要相信OKR就行了,总之OKR就是好!”……

当然,我并不反对企业合理运用KPI和OKR这两种工具,但是我反对企业无脑地、不加思索地、盲目地崇拜“神器”。一味地依赖和滥用工具,只会导致官僚主义和效率低下。

二 解决软件研发绩效管理问题,要回归第一性原理 

“刻舟求剑”的故事大家都学过:战国时,楚国有个人坐船渡江。船到江心,楚人把随身的宝剑掉进了江中。为了把宝剑找回来,他马上掏出一把小刀,在船舷上刻上个记号,并且对大家说:“这是宝剑落水的地方,所以我要刻上一个记号。”船靠岸后,那楚人立即在船上刻有记号的地方下水,去捞取掉落的宝剑。结果当然是捞不到。

虽然“刻舟求剑”只是一个寓言故事,然而只会僵化地执行某些方法论的人却比比皆是。

要解决软件研发绩效管理问题,绝不是依赖于某一两种方法论或者工具,而是要回归第一性原理,也就是要搞清楚研发绩效管理的核心目标和有效性原理,这样才能建立起正确的“三观”。

三 软件研发绩效管理的第一性原理分析

我个人认为,软件研发绩效管理有三大目标和原则:

  1. 尽可能地促进组织交付更多的价值
  2. 尽可能地促进端到端协作
  3. 尽可能地激发员工的内驱力和促进员工成长

下面,我对这三大目标和原则做一个详细讲解。

#1 尽可能地促进组织交付更多的价值

进行组织绩效管理,首先必须先搞清楚什么是组织绩效,以及如何衡量组织的绩效产出。

彼得·德鲁克在《21世纪的管理挑战》中谈到:“任何组织的绩效都只能在外部反映出来。……管理的责任是通过协调组织的资源,以在组织外取得成效。”——这段话为组织绩效管理指明了方向。

我们必须明白,组织绩效就是其向外交付的价值;组织的绩效只能通过其向外交付的价值量来衡量。对于任何组织,无论这是一个企业,还是一个大学或者机构,都是如此。

软件研发组织的绩效,也只能通过其交付的价值量来衡量。尽可能地交付更多的价值,就是整个软件研发组织的绩效目标。

所以,软件研发绩效管理的首要目标和原则只能是:尽可能地促进组织交付更多的价值。

那么具体如何衡量一个软件组织的绩效?

可以从以下三个方面来衡量软件组织的绩效:

  • 价值的生产和交付周期:即从需求提出到得到满足的端到端时间,也就是通常所说的“前置时间”。
  • 价值交付量:即一段时间内交付了多少价值,这里的价值通常表现为能满足客户需要的功能特性和实现的业务价值。敏捷开发中,往往使用“交付的故事点数”来衡量。
  • 交付质量:即交付的成果物满足内外部客户的程度。通过可以用“缺陷数”、“故障数”、“技术债”之类的指标来衡量。应当注意的是,我们不仅要关注外部质量,还要关注内部质量,否则就会导致未来价值交付量和交付质量的降低。

#2 尽可能地促进端到端协作

在软件研发组织中,要交付更多的价值,不是通过某个人的单打独斗或者个人英雄主义来实现的,而是通过整个端到端价值交付过程中的所有人员通力协作来实现的。

所以,软件研发绩效管理的第二大目标和原则是:尽可能地促进端到端协作。

那么该如何衡量端到端的协作呢?

可以通过度量价值流的流动效率来实现,具体做法如下:

 

假设:如上图所示,从需求提出到发布上线一共经历了6个步骤,每个步骤上有两个两个时间数据:“工作时间”和“停留时间”。我们可以把6个步骤的“工作时间”和“停留时间”加起来,就可以分别得到“总工作时间”和“总停留时间”(即“前置时间”),然后利用“总工作时间”/“总停留时间”,即可得到“流动效率”。图上的“总工作时间”是6小时,而“总停留时间”是7周(可通过“8小时”和“5天/周”,换算为280小时),这样可以计算出“流动效率”约为2.1%。

#3 尽可能地激发员工的内驱力和促进员工成长

许多企业为了解决协作问题,制定了复杂的工作流程,建立了精细的项目管理系统,希望能够通过流程和工具来解决人际协作问题。但这些做法,结果却往往只会适得其反——让过程变得沉重而低效,以及让员工变得官僚。

那么如何才能解决协作问题呢?《敏捷软件宣言》中给出了答案:个体和交互胜于流程和工具。

在软件研发组织中,要解决协作问题,应当依赖于每个人的主动性和能力。如果每个人都有足够的能力,并且积极主动地为他人补位,那么协作就不会是问题。反之,如果每个人都等让着流程和系统来协调,那么就会浪费无数的时间。而流程和工具定义得再完善,也无法弥补个人的主动性和能力上的缺陷。

所以,软件研发绩效管理的第三大目标和原则是:尽可能地激发员工的内驱力和促进员工成长。

四 运用三大目标和原则,评估您所在组织的绩效管理

个人认为以上这三大目标和原则,就是软件研发绩效管理的第一性原理。

如果能够将这三点做好,绩效管理必能成为组织发展的一大助力。反之,如果您的组织违反了这三点,必然会在某种程度上成为组织价值交付的障碍。

您能运用这三大目标和原则,去评估当前您所在组织的绩效管理,并找出问题和改进点。

五 您怎么看

您觉得软件研发绩效管理有哪些关键目标和原则?在您的组织中,采用的绩效管理办法,符合本文提出的三大目标和原则吗?还是说,您的组织中,有更为优越的指导思想?

欢迎在评论区留下您的观点。

 

本文作者:

李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练