Scrum 指南把 Scrum 团队定义为“自组织和跨职能的”。如何成功地创建一个高效的自组织团队?Scrum 指南上写道,“自组织团队自己抉择如何最好地完成他们的工作,而不受其他外部团队的管理控制。” 最近许多评论员分享了他们的经验和想法,探讨了如何使用自组织的核心原则促成团队自身的自行组建。这些经验还论证了促进作用是成功自组建和保持自组织团队效率的关键因素。
Mike Cohn 是一名 Scrum 正规化的早期贡献者,还是 Scrum 联盟的创始成员之一,他在最近的报告中指出,在自组织团队形成和生存的期间,需要平衡促进作用和自上而下的指导原则。他记述了把促进作用融入团队治理的个人经验,报告中称这么做易于建立工作实践、会议和其他能充分估计影响因素的工作授权,而“太多的规则将会把团队推向绝境”,并使你们远离自组织。Mike 提醒说:
对于每条规则,你都应该考虑是否值得为这条规则冒险。如果答案是否定的,那么你就不要设立这条规则。另外,不管什么时候只要你考虑为团队增加一条规则,就要看看是否有其他可以删除的规则,或者它对工作有哪些限制。
在最近一篇关于自建团队的文章中, Scrum 大师 Rok Prešeren w 分享了他的项目经验,他阐明团队构成是保持自组织团队成功的关键因素。他在文章中说, 下一个被敏捷彻底改变的传统管理范式是团队形成的过程。他还指出自上而下的团队建设通常过于关注个人能力,而不是团队的综合能力。
……管理应从促进团队自建开始切入,因为这么做通常会收获更好的项目成果。不管怎么说,谁更了解如何针对实际的项目工作去完美地组建项目团队呢?
Prešeren 引述了 Craig Larman 和 Ahmad Fahmy 在美国银行美林集团(BAML)全球证券业务技术的经验,他们只开了 3 小时的会议就成功地促使 35 个个人由 5 个专业职能组织重组成了 4 个跨职能的团队。Larman 和 Fahmy 利用逻辑约束在自组织的三个推进周期内迫使个人在舒适区之外组成团队。Craig 和 Ahmad 设立的约束是,团队必须是均衡的、本地协作的、跨职能的和跨组件的。Prešeren 指出促进作用是指导团队组建的必要条件,要避免嵌套的命令和控制结构:
促进者以提问的方式请大家针对约束评估团队构成,以此把大家推出了舒适区,从此之后事情才开始改变。在第二个周期他们开始自我形成团队,但是此时,自然当选的团队领导开始在团队形成中使用自上而下的方法了。这时有必要让促进者介入以预防形成内部自上而下的方式。
《精通软件项目管理:最佳实践、工具和技术》的作者 Thomas Cagley 去年写文章叙述了会在敏捷场景中出现的问题,自顶向下会损害团队构成的稳定性。他指出敏捷是建立在一个基本假设上的,那就是“团队将是稳定的,在 sprint 或者迭代周期内团队成员和工作重心都不会有变化。”他描述了团队成员之间人际关系的重要性,每一次团队发生变化时都会带来团队的化学变化。他说:
如果团队构成违反了这个基础的假设,那么团队成员的任期就会破坏团队的信任度和效率。这就会产生一群职责不清的个人,而不是一个敏捷团队。
Infosys 的 Nitin Mital 最近探讨了创建自组织团队所必需的成功因素。他在文章中说,要创建自组织团队并不断地取得成功需要分三个步骤培养团队能力,指导团队一起享受工作效率,然后不断地辅导和学习。他写道:
……自组织团队不需要“命令和控制”,但它需要教练和指导。
本着同样的精神,Cagley 和 Cohn 也写文章探讨了由教练去促进和引导反馈环的必要性,这有助于团队自我评估和拥抱敏捷。Thomas 分享了一段轶事,有一个已经远离敏捷实践并已经开始分配工作的团队,通过引入了教练和新的反馈机制能让这个团队重新步入正轨。
Mital 提醒我们:
……组建自组织团队是一个不断持续的过程,我们从来都没有到达过终点。无论团队构成何时发生变化,我们都需要重复整个过程。
查看英文原文: How to Self-Assemble and Sustain a Self-Organising Team
感谢吴海星对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论