• Five_reasons
  • Cal2_20220108
  • Hardware-agile-practice
  • 2020-scrum-guide-banner
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • 敏捷思维 领导力 企业培训 国际Scrum联盟认证
  • 汽车行业敏捷开发课程
  • CSM A-CSM Scrum敏捷实践
  • 敏捷领导力认证培训  CAL认证培训 CST CSP
  • 30天软件开发 敏捷规模化实践 Scrum精髓 敏捷文化
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • Scrum敏捷培训 Scrum敏捷企业内训
  • Scrum敏捷软件开发管理 企业内训 Scrum转型
【Scrum模式语言11】自组织团队(Self-Organizing Team)

译者语:最近在读《Design Thinking for Innovation》, 作者是Walter Brenner 和Falk Uebernickel。其中的理念、方法论和实践总结和自组织团队有很多的地方异曲同工。


借此,很想和大家简短分享,Design Thinking 其中的一个步骤就是(Test/Learn) 试错/学习,重新审视问题,确认是否创新解决了“显而易见的”或者“隐藏的”客户需求。看到这里时,我很兴奋,因为这使得我从另一个视角理解了, 驱动自组织团队通过自我管理,自我决策,共同反思,在“试错的路程”上不断学习,进而找到新的解决方案、不断创新的源泉。


”Design never ends” – “设计无终结“(摘自<<Design Thinking for Innovation>> Walter Brenner 和Falk Uebernickel, 2016版) 。或许这就是,自组织团队/开发团队不断地反思改进、践行“设计无终结”,精益求精的精神所在吧。

原文:


自然界中,鸟类自行组织成队形并不断地调整重组队形。人类社会中,组织建立了信任社区并且在此不断耕耘。研发团队作为一个自治团队在运作。


没有一种安排团队或工作的通用方法,可以适用于所有的场景和工作,并且经久不衰。

 

对于多人参与的工作任务,其需要通过一种有条理的、相互协调的方法,来安排任务及人员协同工作。否则,可能会陷入混乱。不过这种组织可能很复杂。

 

为了达到降低复杂性的目的,组织会将架构和流程标准化。这个标准化过程,或通过采纳最佳实践来实现,或通过延续企业文化发展来实现。

 

最佳实践这种方法, 在特定的情境下发展,以便达到特定的目标。这种方法未必适合指定的组织。在任何复杂任务的执行过程中,超前地预期到哪些共有的基础配置是最佳方案,几乎是不可能的。这时候,我们只需要一个合适的、符合既定目标的起步;从这里开始,跟随“紧急情况”的引导来前行。至此,组织或许会在合适的时间和情况的迫切要求下,发展出它自身的最佳实践架构和流程。这些最佳实践即成为获得确认的实践方法。但是,即便这些实践方法通常会奏效一段时间;随着时间的流逝,它们不会一直持续有效。由于管理方法的提高和科技的进步,商业情况也随之变化。相应地,团队也许会进入新的发展停滞期。


当被领导并被告知需要做什么的时候,员工会感到轻松。这种指导和管控会导致一些后果。当员工为控制型经理工作时,工作动机和一些工作场所要素,例如员工离职率和工作满意度会受损。


此外,执行任务的员工才是那些理解,如何才能把他们的工作做到最优的合适人选。当员工失去对他们的工作的控制时,也会相应失去对改善效率、效果和质量成果等有价值的时机。例如,一位工厂的工人也许会自发的采取行动改进以提高工作效率或者安全性。这种改进可能并不会由经理人发起。因为经理人对具体情况并不了解, 以至于,他不能体会到改进的必要性,更不用说考虑改进了。


研发团队成员通常具备专业技能。利用团队成员各自的强项和差异,来有效率地工作是有益处的。但是,如果团队成员只在他们自身的专业技能领域内工作,任务进度可能会延误,而不是更均衡的分配和展开。

 

因此,研发团队自我管理和组织以便让工作“完成”。研发团队独自负责工作如何开展。

 

研发团队控制日常工作的所有细节。例如,他们开每日站会,并且决定新的工作任务和相关负责人。他们决定工作任务的顺序,并且决定如何组织群集工作:单件持续流。团队决定如何利用研发团队成员的专业技能和相关领域的专长。这个过程可以包括,决定团队内如何搭配配合工作等。


特别值得一提的是,自组织要求团队成熟并自律。一些人在自组织型团队感到不适应。组织的利益相关人,例如产品负责人,或许会想要直接提供帮助,或者Scrum Master认为他们知道谁应该接手相关任务(Scrum Master绝不会指派人员来完成任务或告诉开发人员如何工作)。即便在初期会困难重重,但是,研发团队以外的成员需要让团队通过自组织来学习。

 

取消明确的监督角色的一个危险是,另一个人(在团队中)可能会担任同样的角色。从而通过施展魅力、盛气凌人或者支配对话,来把他的个人意志强加于团队。这种行为会让团队保持与之前一样的驱动力,而没有任何变化。Scrum Master需要明白,这种情况也许会发生,并需要通过行为建模帮助团队提高认知,以便保证每个研发团队成员都能贡献力量。这个互动的过程会帮助团队建立准则。如果这种类型的行为发生(或其他任何会抑制自组织的行为),Scrum Master有责任帮助团队识别并且清除障碍。当然,由小团队和同一地点的团队施行自组织最容易,因为后勤工作相对简单容易。

 

 这个模式是Scrum核心实践的其中一个。它使在一个Sprint中的工作,以最有效的方式得以开展。它有助于提高研发团队的士气(并且也有证据说明提高了绩效)。它使得研发团队有机会进行自查并改进。有了它,研发团队就具有”自我治愈”的能力,即团队能识别错误并有能力去改正。这是敏捷型组织需要掌握的最重要的模式之一。


当业务允许研发团队自我组织的时候,团队获得了自由和相应的责任;这是通向信任社区的大门。一个有如何组建产品的话语权的团队,就会对其自身和其产品有更强的荣誉感。

——译者:Yina Xu

校对:Leo Yan

参考资料:

(1)A Scrum Book:17 Self-Organizing Team