InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

Scrum团队的个人奖励机制

作者 Shane Hastie 译者 金毅 发布于 2010年1月19日

领域
架构 & 设计,
过程 & 实践
主题
软件工匠 ,
敏捷 ,
协作
标签
Scrum

最近在LinkedIn“敏捷联盟”(Agile Alliance)邮件组中,Reeju Srivastava提问道:“我们应该在Scrum团队中进行个人表彰奖励吗?”讨论由此展开。

这个问题引发了激烈的辩论,正反两方各执一词。

这里我们概括了一些讨论中所提到的观点,供大家参考:

正方:

Virgil Mocanu认为:

共产主义者曾经尝试过合作农场这一概念。在那个框架下,假设所有人的表现都是一样的。不用多说,这种概念行不通。

当伙计们争辩说一个竞争性的奖励机制不好的时候,他们的出发点往往是比较极端的,他们会认为争强好胜就是胜者通吃的零和游戏。但现实生活中却往往不是这样的。

大部分的团队中,团队动态类似于一个纳什均衡(就像电影《美丽心灵》描述的那样)。所有的“参与者”内心都有一个共同的目标,他们想要超过别人,但决不采取一种降低团队整体积极性或者偏离大方向的方式。

去奖励纳什均衡里的个体“参与者”也不是什么错事。事实上,如果没有奖励,那么也就没参与者了。

商学院里教的是,人们在职业生涯中主要会被三种因素所激励:
- 个人成长
- 金钱
- 认同

如果奖励机制不能通过这些途径足够地激励个人,那么就等着处理员工流失的问题吧。这种问题短期可能不会发生,但着眼中长期那是必然会的。

虽然很多社会都曾尝试去长时间地束缚人们,但没有一个能成功。不变的是,这样的社会秩序总是失败的,原因要么是人们彻底地反抗,要么是人们干脆移居/出逃到附近能够提供合适奖励机制的社会去了。

毋庸置疑,过多的竞争会使一个团队不稳定。这也就是为什么几乎没有团队能容忍自负而喜怒无常的人。但是没有了竞争,风险也就随之而来:
- 成员为了更多的奖励机会而离开
- 无法激励较弱的成员去提高突出
- 较强的成员消极而不愿突出
- 整个团队停滞不前,也不想进一步提高技能

何团队都可以承受一定程度的竞争以及一定程度的奖励缺乏。两个极端之间总有一个相对稳定的“中间地带”。我相信那就是对纳什均衡很好的一种诠释。但是“中间地带”之外却是处处危机呀。

Sean Capes的看法是:

就像多次提到的那样,我相信一个团队选择去赞赏超出一般水平的杰出个人是很正当的事情。如果团队对最终交付集体负责,我提倡也由团队来决定他们的奖励激励流程。敏捷方法的原则虽然是鼓励协作,可我不认为这就表示完全排除个人因素。毕竟我们都有自己的抱负和职业发展,即使再紧密的合作环境里也一样。我相信我们需要识别个人利益来创造团队合力,比如基于手上的需求,根据特定成员的经验和才能赋予其设计而非编码的角色。

反方:

Kevin E. Schlabach认为:

为什么凌驾于团队之上去评估某个人是值得的?你希望到达的目的是什么呢?你为什么想这么做呢?

Archit Jauhari觉得:

Scrum团队能够良好运作是因为团队中的每个人都联系紧密。个人表彰可能会破坏这种精细的关系,而使团队成员之间产生隔阂。

Jay Conne则提到:

如果你想有个“胶冻”团队(译者注:《Peopleware》中提到的概念。是指一群紧密结合在一起的人,其整体大于部分的总和),那么绝对不能这么做。

我能想到的唯一例外就是团队主动要求这样做。

但这会引起利益冲突。

于是问题就来了,我们又该怎么样来公平地奖励专家和新手,还有这两个级别之间的所有人?我能想到的唯一的方法就是制订一个机制,以此来客观公正地决定技能等级。

任何可能导致团队信任逐渐削弱的行为都是很糟糕的决定。

Daniel Liljeberg也不赞同:

简单地说...不。
既然Scrum团队作为一个整体来对他们的承诺和工作负责,那么实施个人奖励的可能性就表示你的团队出问题了。没有集体决定,个人又怎么可能突出呢?

如果一切正常,那么团队中的某些人要么在做他本不该做的事情,要么是集体的决定要求他做有问题的事情。两者都不是需要个人奖励的理由。

当然,当人们工作努力的时候,去称赞一下总是很好的。但我会用另外的方式去处理。

Kevin Schlabach对于这个话题曾经写过一篇博文


你的团队是不是也在使用个人奖励机制呢?这种机制到底是提升了还是降低了团队的表现呢?

查看英文原文Individual Rewards on a Scrum Team

译者 金毅 多年来服务于欧美软件外包行业从事管理工作,对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。

审时而定 发表人 Jun Ran 发表于
奖励机制要看重对团队的贡献 发表人 jiang jianbo 发表于
  1. 返回顶部

    审时而定

    发表人 Jun Ran

    即使不在Scrum团队中,个人奖励也是个大问题,想想那个兔王发萝卜的故事吧,关键在于如何运用,什么时候用。

    我认为既然Scrum团队是自我管理的,那么可以由团队自己决定这个问题,团队自己发展出来的奖惩机制应该是可以把负面影响降到最低的。

  2. 返回顶部

    奖励机制要看重对团队的贡献

    发表人 jiang jianbo

    个人奖励机制当然需要存在,但是应该通过交付物的实物进行分级和评估。对于结对的工作,则积分平分。一个能力高的人,肯定会有更多的机会去帮助别人,所以也肯定会在评估中和其他人拉开差距。即使存在博弈,也不会是负面博弈。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。