黄灵 | 敏捷团队的激励手段

题图:Volleyball team by KeithJJ@Pixabay

编辑:冷锋

敏捷团队的激励手段

作者: 黄灵

企业级精益敏捷实施专家

米么金服精益敏捷管理总监

敏捷团队与传统团队的最大区别莫过于其自组织、自管理形式。

既然是自组织自管理,在跟PO共同定下迭代目标以后,如何实现迭代目标就该是团队自己的事。

就这一问题,我在敏捷培训和咨询过程中,无数次被问到:

  • 既然是团队自己决定怎么做,他们在估算的时候就可以放水,如何解决呢?
  • 这种环境必然会造成一部分团队成员消极工作,本来可以完成5个任务的,他只领取3个任务,怎么办?
  • 由于自组织团队的工作执行方式是让团队成员自我认领任务,能力强的多做,能力弱的少做,而敏捷专家们又建议对敏捷团队进行整体的绩效评估,如何避免因吃大锅饭带来的不公正呢?

以上问题表面看好像是关于对团队的信任、以及如何解决绩效评估的问题。

其实,不管是哪一个问题,究其原因,都是关于如何激励自组织团队的困惑在起作用。

大家都知道,激励分两种形式,外部激励和内部激励。

管理学教授Douglas McGregor 创建了X, Y理论。

X理论认为,人们通常都倾向于不工作,金钱刺激、管理控制手段以及胡萝卜加大棒理论,都是让人们工作的最佳方式。

这种理论认为,只有在一定量的外部激励下人们才能以最佳的工作态度开展工作。而这些外部激励形式不外是工资、绩效加薪、绩效奖金等金钱形式的激励。

但是大家同时也知道,马斯洛需求理论认为,人的需求是分层次的。当人们的需求已经不再是解决温饱和生存问题,而是更关注安全感,或是更高层次的情感、归属和自我实现的时候,这种以金钱为主的外部激励形式就不一定凑效了。

同样,Y理论认为,人们愿意承担心理和生理上的责任,即人们是否要好好工作是取决于其内部激励的。

而对于敏捷团队这样的知识工作者团队来说,内部激励的效果则要优于外部激励。

由于马斯洛需求理论决定了每个人的需求层次是不同的,甚至是同一个人在不同的时间的需求层次也会不同。要想对团队成员的激励手段凑效,必须要明白激励对象处在什么层次,或者找到合适的激励平衡点。

Jurgen Appelo 在他的《管理3.0——培养和提升敏捷领导力》一书中,根据自我决定论和Steven Reiss 的十六个基本需求理论归纳出团队成员的十大需求(《管理3.0》P81):

1. 让团队成员感到有能力胜任自己的工作,分配给他的工作有调整且在其能力范围内。

2. 努力让团队成员感受到自己是受管理者和组织认可的。及时表扬他们所取得的成就。(必须是发自内心的)

3. 确保满足团队成员的好奇心。就算是那些很单调的事情,也要提供一些新东西给团队成员研究。

4. 让团队有机会满足集体荣誉感。必须让团队自行制定规则,这样,每个人都会乐意遵守。

5. 给业务注入一些理想主义。不能只是为了赚钱,更要为了美好的世界作出团队的贡献。

6. 培养团队的独立性(自主性)。在各司其职的情况下,允许团队成员与众不同。

7. 确保维护一定的秩序。在有章可循的情况下,人们可以更好地工作。

8. 确保人们对周边发生的事情有一定的处理权或影响力。倾听他们的想法,采纳他们的意见。

9. 给团队成员创造良好的社交环境。

10. 让团队成员感到自己在组织中的地位,而不要让他们觉得自己处于金字塔的最低端。

Jurgen还提出了激励和负激励的概念,并创建了激励损益表评估法。有时候,要想激励一个人,你需要扫除那些无法让人积极工作的障碍,即负激励。

因此,激励团队成员(或者负激励)的方式有很多,为了判断这些激励手段是否有效,可以采用激励损益表来帮助我们。

上图是Jurgen创建的他自己的激励损益表(见《管理3.0》一书P83图5.2)。该损益表结果为正值,所以,Jurgen受到的正激励大于负激励。

激励损益表可以很好地评估每个团队成员是否得到很好的激励,并帮助找出把那些负激励,为调整激励方式提供了很好的依据。

当然,除了内部激励,有时候我们也需要外部激励,尽管很多专家都认为绩效加薪、奖励津贴和奖金有很大的破坏作用。

但是,在敏捷自组织团队中,一定不能采用绩效排名的方式进行外部激励。正如戴明所说,业务中80%的问题都是系统造成的,这是管理的责任,对员工进行绩效排名的方式会摧毁他们的自尊。

那么,到底该如何在敏捷团队实施外部激励呢?

可以借用心理学的一些正向行为强化手段。比如,采用积分兑换制、团队自行制定分配规则等方法,但所有这些规则和制度制定及执行过程,都应做到公开透明,在团队认可的前提下执行效果方能有保障。

来源:中生代技术

原文链接

时间: 2024-10-03 18:40:11

黄灵 | 敏捷团队的激励手段的相关文章

传统团队如何转变为敏捷团队?

问题 问:传统的团队如何转化为敏捷团队(步骤,要点,注意事项等)? 问:如果使用敏捷开发,在公司组织架构上有没有什么建议? 分析 在谈到何为敏捷团队之前,先看看传统团队的问题,不要把团队转化完了,问题还存在:换言之,解决问题是目标,转化团队是手段. 1.各部门打架严重 来自于分工中的灰色地带 / 各自目标和绩效的不一致. 典型的是开发/测试团队,扩展而言,还包括市场/销售团队. 后两者也很关键,很多时候开发和测试团队和谐了,联合起来和销售团队打架,公司的整体效率仍然上不去. 不过,如果没有在市场

员工激励手段1+1组合出击

激励主要靠金钱吗?--保罗·维尔德先生告诉我们他关于激励的一些想法. 多年以前,我的一个上级告诉我,你付出的薪酬的多少将会决定员工的士气和干劲.对于员工激励,他有自己的一套哲学--对于他来说,"一切都跟钱有关". 现在由我亲自掌管客服部,我的观点已经大有不同.对我来说,有效的员工激励手段应该是奖赏.认可和实时反馈的组合. 是的,奖赏是关于金钱的,但并不只是包括现金;认可则是关于让员工知道他们做得不错并感受到自身的价值;而实时的反馈则为员工及团队提供了及时的信息,让他们知道自己的表现如何

敏捷团队的组织与管理--- MPD软件工作坊培训感想(下)

注:由麦思博(MSUP)主办的2013年亚太软件研发团队管理峰会(以下简称MPD大会)分别于6月15及6月22日在北京.上海举办,葡萄城的部分程序员参加了上海的会议,本文是参会的一些感受和心得. 今年的大会延续往届模式,以产品创新.团队管理.架构设计.开发管理.测试管理等五个维度作为五个分会场的主题.对于今年来在软件研发中百谈不厌的敏捷开发的问题,大会从团队管理.开发管理等多个角度为与会者全面剖析敏捷开发中所涉及的种种问题,不单单聚焦于敏捷开发本身,更将视线拓展到管理整个敏捷开发团队上. 讲师都

如何在大型开发组织的敏捷团队中实施CMMI

近年来,敏捷开发方法能够更好地适应现代软件开发,逐渐发展成为一种主流开发方法,也正在改变着软件开发过程.然而,敏捷开发方法常常被认为同CMMI过程无法共存,因为CMMI被看做是以规格化方法控制软件开发过程. 2008年,Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad 和 Sandra Shrum出版了<CMMI和敏捷方法:为何不彼此相容>一书,为那些既想保持项目过程可控又想体验敏捷开发灵活性的开发组织开启了一扇窗口.CMMI过程管

怎么才能保证你的敏捷团队不会被指标毁掉

我认为敏捷社区要改变评测敏捷团队是否成功的方法.我们收集指标以及从这些指标中获取信息的方法实际上妨碍了我们做出能用的软件,而这才是最重要的东西. 强推个体指标有时会导致过于关注其他人,影响团队的协作.这会歪曲我们要评测的内容,摧毁我们的真实意图. 在我看来主要有两个问题: 观察者效应: 观察者效应是指对一个流程进行观测可能会影响它的输出.比如告诉一个团队你会密切关注他们的速度,该团队可能会为了加快速度而过度估算他们的工作内容.这在处理 故事点 时尤其危险,因为根本就没有依据可以判断估算是否有效.

敏捷时代的建模:敏捷团队的扩张除了代码还需要什么?

敏捷方法已经成为了当前软件开发的主流模式,可工作的代码(以及自动化测试)被认为是团队最重要的产出. 那么是否不再需要建模了呢?UML真的已死?我并不这么认为. 在本文中,我将探索在敏捷时代,建模方法依然适用并且扮演关键角色的所在.尤其在开发规模扩张到多个团队后,对整个系统的"Big Picture"达成共识将变得非常关键. 敏捷中的"设计"在哪里 虽然代码表现了事实,但它并没有表现事实的全部 – Grady Booch 在开篇部分,我将描述一个使用Scrum的敏捷团

如何打造敏捷团队 这是一场思想观念上的变革

ShineScrum公司创始人及国际Scrum联盟认证培训师(CST)--Jim Wang王军,10月15日受邀参加2016杭州云栖大会云效专场分论坛,现场为大家带来<How To Make Your Organization Agile?>演讲,为大家揭示敏捷领导力背后可以遵循的原则.云效专场分论坛以"用技术驱动企业提效"为主题,邀请业内多位技术大咖进行专题分享,共同演绎技术魅力!     敏捷,目前是互联网开发领域经常被谈及的热词,在Jim看来,敏捷是一场自上而下的变革

敏捷团队管理:把握介入团队的程度

转载请注明出处:http://blog.csdn.net/horkychen 来源 Check In, Don't Check Up (照看而不是介入!) 我从来不是微观管理者(micro-manager),特别是应用agile和Scrum之后.初入职场时,要不是太忙于和别人搅和在一起处理问题,我很可能就会成为一个微观管理者.但是当尽量避免同大家一起检讨细节问题时,仍要认真地照看(check-in)他们.我是从这篇文章(细小的成功多么重要)得到启示的.   介入(check-up) & 照顾(c

敏捷团队中的QA由来

QA,全称为Quality Analyst,即质量分析师(有些称为Quality Assurance,即质量保证师).为什么它总跟质量扯在一块?感觉这个角色明明做的都是测试的事情,为什么不直接叫做tester那?敏捷项目中的QA日常都做什么事情那?可能一大推问题都会冒出来.别急,跟着我这篇文章来一步步的回答这些问题. 假设现在有一个保险公司,他想找一个软件公司做一个在线卖保险的系统.那么这个系统从开始到完成至少需要三个角色. Business owner -> developer -> end