敏捷创造了一个新词汇,叫“自组织团队”。我个人是自组织团队的忠实粉丝。它在很多时候运行良好,尤其是在那些人们于公共生活中展现高度责任和义务标准的文化中,这是因为人们把这些高标准同样带进了办公室,完美地匹配了“自组织”团队。让每个雇员都工作于自组织的模式中,是所有公司的梦想。但是就像所有人类各不相同一样,不是每个人都适合“自组织”的团队。比如,不是每个医生都能成为外科医生、牙医或者整形医生,但是每个医生仍然都对社会有用。相似地,不可能期待每个人都能以“自组织的风格”工作。然而,同样是这些(不适合自组织定义的)个人,假如以不同方式处理,仍然可以成为很棒的贡献者。这里就是项目经理角色变得特别有帮助的地方,他可以通过多多少少(依赖于个体情况)的监管,让团队成员做出非常好的的工作。敏捷使用“教练/促进者”一词来代表这种角色。另一方面,这一角色在人们稍稍偏离自组织状态时也工作良好。在如下3种情况中,教练/促进者或许必须延展其工作范围。
1.人们过度偏离自组织状态(比如非常无组织、非常不专注、情绪化等等)。
2.人们的软技巧与业务需求不相匹配(比如,不能做到积极主动,害怕讲话,沟通不良,时间管理差等等)。这些软技巧的缺乏,不可能让真实的潜力转化为绩效。
3.人们得了企业病(比如诽谤中伤,嫉贤妒能,自吹自擂,知识垄断,阿谀奉承等等)。技术上讲,假如有强力的管理者(而非教练)以持续的监督来控制他们,在影响到团队互动之前就扼杀这些苗头,仍然可能使这些人有所产出。
我在此的意思是,我们应当对所有专业人员具备高度的包容。但是处理和发挥一个个体的长处,方法因人而异,没有适用于每个人的通行法则。组织在这一点上应当反省。所有国家都有很好的技术人员,他们可以是好的贡献者,但也许不能自组织。这就是教练/促进者会转为更像一个项目经理的地方。这些人也许会犯错,也许需要引导和监管,也许缺乏软技巧,如此等等。在教练/促进者的有限范围内,让这些类型的人员与敏捷相适应来完成工作,会成为一个噩梦。我对各种各样的人充满尊重,也坚信这些人可以成为好的贡献者,但是你需要延展教练的职责范围,给与其某种权力来强硬地表明“什么该做,什么不该做”。这里项目经理的角色就变得有帮助。下表展示了一些觉得需要项目经理的其他领域。
情境编号 | 事实 | 敏捷如何有用 | 敏捷帮不上忙的地方 (而管理者可以!) | 备注 |
1 | 人无完人 | 举行每日进度会议,让他们保持专注,让产品负责人保持需求与业务相一致。 | 1.专注点是否在正确方向上? 2.产品负责人是否每个冲刺都改变目标? 3.责任是否真正分担?如果每人都觉得别人更有经验、懂得更多,所以更要负责,该怎么办? 4.人们是否以敏捷之名掩盖自己能力的不足? 5.团队是否做到真正自组织? 6.人们是寻找外部原因作为借口,还是真正有所改善? 7.团队中是否有某人正抢占所有功劳,而损害了团队动力? 8.是否有人垄断了知识,不与团队分享? | 具备横向思维的管理者可以想出创新的办法来管理不完美之处。 教练可以用合适方式提出如何做事,但如果人们不遵循又如何?比如,要是团队在演示后不听取产品负责人的反馈呢?这是可接受的,还是必须强制听取? |
2 | 控制改变 | 敏捷在每个冲刺开始时欢迎新的需求,而Scrum Master在冲刺中防止范围蠕变。 | 1.Scrum Master是否正确履行职责? 2.测试人员是否按时做了工作? 3.人们的软技巧和承诺是否正在改变? 4.客户是否突然开始不信任敏捷? 5.客户是否突然开始期待不切实际的事情? | 敏捷以需求优先级来照管改变,但只是一部分。 产品负责人可以发挥影响力,在冲刺进行中增加故事,可团队不知道如何应对? 任何方法都无法应对无形的改变。 |
3 | 沟通不适当 | 敏捷用站会提供了每日沟通的机会,也用回顾会议创造了大家畅所欲言的平台。 | 1.团队是否真正提出障碍? 2.团队是否积极主动地沟通所有事项? 3.受众是否完全理解了沟通内容? 4.我们的沟通中是否有语言或文化的隔阂? 5.分布式的沟通是否成了瓶颈?用户体验是否良好? 6.是否所有email都得到回复,并达到预期、质量良好? | 公司沟通是与懂得写程序非常不同的课题,也是很困难的课题。 管理学研究解释了沟通的艺术性。 任何流程都不能处理软技巧。 |
4 | 流程不完美 | 敏捷在软件开发中有效。 | 每个方法论都有其局限,最终是人来使项目成功。 | 差的敏捷不如没有敏捷。 |
5 | 流程实施不恰当 | 敏捷是一个实施依赖于人的流程。 | 1.人们是否遵循流程? 2.流程可否改善? 3.流程的哪些子集适合我的项目? 4.例外在哪里,何时偏离流程没有关系? | 一个简单例子——在敏捷中,团队是否进行大量的结对编程? 非常好的实践何时真的成为我项目的非常好的实践? |