管理者作为ScrumMaster

Posted 从LeSS到学习型组织

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了管理者作为ScrumMaster相关的知识,希望对你有一定的参考价值。

摘要


管理者作为SM(ScrumMaster)?你不能这么做!这样做不符合常理 - 指挥控制型的管理者没法象SM那样来带领和辅导团队。然而,作为敏捷变革中的重要方面,自管理就意味着管理者从指挥控制到带领辅导的转变。这篇经验报告将解释一个大规模组织如何在三年间导入敏捷,并聚焦于SM和管理者的角色演变以及他们一起工作的方式。它描述了围绕自组织的变革是如何引入并调整的,然后又是如何通过创建在敏捷带给组织的价值观和原则与付诸实践所需的管理能力之间的一致性来将变革持续的。


上下文


我从2002年到2010年在诺基亚西门子网络(之前是诺基亚网络)的产品开发组织里工作。该组织分布在两个地点,一个是中国的杭州,另一个是芬兰的艾斯堡。


在2005年末,我们开始在各种项目和团队试点Scrum,以在我们项目中取得聚焦和灵活性。我们当时运作多个并行项目,由此导致的多任务使得大家失去焦点。因为团队是围绕组件而非客户交付物来组织的,我们对聚焦客户的意识淡薄。单一职能团队和组件团队的混合结构让我们难以灵活地适应变化。因为所有这些因素,上层管理和团队都有动力尝试不同的开发模式,而Scrum具备的敏捷性和简洁让它成为了自然的选择。我在该组织中带领了其中一个早期Scrum项目。


在2007年,我们的试点取得初步成功之后,我们整个产品组织(超过500人)决定转向敏捷/Scrum的模式。我被选为在新的基于Scrum的组织里带领一个大约100人规模的部门,并加入了该组织的领导团队。这个故事讲的是我们如何一直对SM和直线经理(Line Manager)的角色进行检查并适应,以及他们如何从那时起一起工作和成长。


引入自管理


许多组织没能改变产品管理,因为它通常独立于研发。然而我们的产品组织包含了产品管理,它跟研发汇报给同一个老板。我们引入了PO(Product Owner:产品负责人)的角色,并创建了一个以PO为中心的运行模式。因为传统的项目管理工作已经被分布到Scrum的三个角色(团队、PO和SM),我们去除了大多数的项目经理角色以避免由于角色重叠而带来的紊乱。人事经理则没有感受到变革的威胁,因为人事管理在敏捷组织中依然(如果不是更为的话)关键。得到他们的支持因而相对容易。挑战在于让人事经理理解他们的角色需要经历从指挥控制到带领辅导的深刻变化。


原先的部门结构是基于单一职能和组件团队的,我们将其重新组织为跨职能特性团队。在部门里已有几个直线经理,但是SM是一个新角色。对应我们部门的PO已经选好了。我作为部门经理的第一项任务就是建立团队以使Scrum开发(也就是跨职能特性团队基于迭代来承诺和开发出潜在可交付的产品增量)可以进行,并让SM来带领引导团队和Scrum实施。自管理是Scrum中的一个关键主题。我打算将这一原则融入变革中 - 我们能否通过自管理来重新组织团队和选出SM?


我们先列出所面对的约束条件,并决定我们需要合适大小的、跨职能的和能够交付客户特性的团队。我们为大家安排了自组织的培训,并提供了让大家相互认识的机会。我们的PO也分享了目前的产品待办列表,从中预示了团队所需具备的能力。在计划时有人提出一个顾虑,如果大家没能自组织形成团队该怎么办,我们要等多久来让团队涌现?我们决定对组建团队的过程设定时限并向潜在团队加以了解释。如果团队没能在规定时限内涌现出来,那么管理层会来决定团队的组成。


我们把所有潜在团队成员邀请到一个组建团队的活动中。有大约80人在一个大的会议厅里。白纸架被摆放在房间四周,每处代表了一个团队的存在。我们在大白纸上列出主要标准。度过一段混乱之后,一些人开始在纸架附近聚集,另一些人则加入关于标准的讨论。大家在房间内四处走动。之前有过良好工作关系的一些人作为初始成员开始形成团队的雏形,他们甚至添加了自己的标准用于招募其他成员,有些标准和技术相关,有些则和社交相关。最有意思的经历发生在最后。一些“剩下”的人最终合并形成了最后一个团队。我有些担心他们的未来,然而让人惊讶的是,他们后来成为了最好的团队之一。在乱糟糟的一小时后,10个团队形成了。


我有想过更进一步来让每个团队选出他们的SM,但是出于以下考虑并没有实施这个想法。首先,直线经理对Scrum不熟悉。要想让变革成功,他们一定需要深入理解Scrum,并知道如何在这个模式下有效地工作。作为SM进行实践可以是一个建立理解并让他们立刻参与进新模式的好办法。其次,大家对好的SM应该是怎样的还没有充分的理解,在这个组织里还几乎没有真正的SM。我对自我选出的SM人选的质量心存疑虑,所以决定还是由我来招募,然后加上直线经理,就形成了一个SM的池子。在团队形成后,SM们向团队展示了自己。团队和SM相互约定由哪个SM来服务哪个团队。


让传统的直线经理做SM的一个风险是直线经理可能会倾向于通过权力而非影响力来工作,而团队可能会让直线经理具有权力这一认知阻碍自管理的形成。我们为此建立了规则 - 直线经理不能作为SM服务于直接汇报给她的团队。


既然所有的直线经理 - 包括我自己 - 都承担了SM的角色,直线经理、SM和PO就一起非常紧密地工作在团队层面和组织层面。这个组大约10人的规模还是可以有效地工作起来。我们通过实践作为SM和向外部教练学习来发展了带领和引导团队的能力。此外,我们还加深了对有待解决的组织障碍和有待建立的组织支持的理解。


挣扎与适应


我们不久就发现直线经理在平衡组织导向的经理角色和团队导向的SM角色之间步履蹒跚。


在计划Scrum转型的过程中,Scrum模式下直线经理的角色是一个热门话题。PO决定做什么,团队决定怎么做,而SM支持和促进。开始时,组织里的一些人不清楚流程应该如何工作, 对变革也持怀疑态度。来自客户的危机和紧急投诉要求我们立即关注,没有什么犯错的空间;组织障碍浮现出来,需要管理上的解决方案。向自组织的转变其实需要更多的管理投入和更多的领导力。直线经理的双重角色既影响了在团队层面往运转良好持续改进的自管理团队的进展,又影响了在组织层面往促进和对齐的组织结构和支持的进展。


我们转向了专职SM,而让直线经理带领组织变革和辅导SM。直线经理开始时作为SM的经历使得他们能够在Scrum组织中承担起更多向外的新角色。直线经理更多参与到移除组织障碍和创建组织演进的愿景和策略上。直线经理也从指挥和控制转向辅导和支持SM。一些新的SM在组织内被招募,另一些从团队中涌现,还有一些则被直线经理识别并发展。


在我们的组织中,直线经理有支持员工发展的职责。一旦更好地理解了SM的角色,有些人就显示出往这个方向发展的兴趣;同时直线经理也在寻找能接替他们承担SM角色的人选。这是一个很好的匹配。然而,考虑到我们社会文化的影响,相比于继续发展成为技术专家,会更倾向于进入管理岗位,我们实际上鼓励大家保持专注于发展技术技能。我们明确指出做SM会有利于学习和发展领导力,但它既不是职位也不是升级。事实上做SM会影响成为技术专家。然后直线经理与那些真心想要服务团队并帮助团队变得伟大,也得到其他团队成员支持的余下人选进行结对。通过推荐书籍并在阅读后分享想法,对他们在所属团队的上下文中进行辅导和指导,让他们引导Scrum会议并给予改进反馈,直线经理帮助他们做好开始的准备。交接是在当包括团队的各方都觉得可以了时才发生的。


当直线经理和SM的角色混合时,我们开始是以一个包括了直线经理和SM的群组来工作的。随着演变成有更多专职SM,这个群组就超过了有效团队工作的合适规模。因此,我们决定将它分成两个组。一个由直线经理组成,关注于指定终点和为成就团队创建环境;另一个由SM组成(直线经理作为可选的成员),关注于SM的能力发展。


我们让直线经理在SM发展组里是可选的。除了保持群组规模小之外,我们考虑直线经理的存在也许会妨碍SM来拥有他们自己的发展。我们明确指出这是他们的平台,直线经理只会在受邀时参加。


我们实施了Scrum伙伴,将一位直线经理和一位SM结对,来支持组织内的辅导和指导工作。对于新的SM,我们也将他与有经验的SM结对,考虑到他们可以从实际工作的SM身上学到更多,而有经验的SM也能通过实践来提升自己的辅导和指导能力。


持续


分成两个独立群组的一个缺点是SM参与到组织层面的机会由此变少了。在我们组织里一个好的SM不仅要关注团队、PO和他们的交互,还要关注组织。为了SM的成长,我们需要他们来理解组织。除了可以将直线经理的辅导延伸到团队上下文之外,我们创建了基于组织任务的工作组,不只是用来解决问题,还希望SM能从中得到成长。另一个缺点是直线经理相比于SM来说跟团队离得远了,从而减弱了他们对团队面临问题的理解。


尽管我们把直线经理定位成组织导向,而把SM定位成团队导向,我们发现在一些SM和直线经理身上这条边界有时挺模糊。从在他们之间形成一致性以持续变革的角度来看这其实合乎情理。


后来我们的组织和我们的部门都扩大了规模。我们也相应增加了新的直线经理。除了遵循通常的管理比例(一个直线经理对2-3个团队),选择新的直线经理也提供了为变革创造可持续性的机会。那些已经在团队和组织上下文中都展现了领导力的SM成为了很好的候选人来源。


当被选作直线经理时,他们继续作为SM服务于直接汇报给他们的其中一个团队。这为管理团队补充了来自团队的有用洞察。看起来我们好象回到了我们的起点,也就是直线经理又成了SM。然而两者之间有重要的区别。在Scrum转型开始时,我们聚焦于在整个组织实施变革,包括创建愿景、沟通交流来获得认同、移除障碍等等。在这个时候,焦点在于持续变革,并确保它作为一部分融入进组织。实现这个目的最好的方式是通过人,特别是那些有影响力的人。随着优秀的SM被提升为直线经理,在Scrum组织背后的价值观和原则与实践它们的管理能力之间就形成了更多的一致性。当团队在自管理上更具经验后,原先在平衡直线经理和SM两个角色上的挑战也就没那么大了。


随着SM的人数增加,学习导向的SM团队已经发展成实践社区,也就是SM社区。很多人一起完成任务已经变得低效,因此我们进一步把焦点转向通过交换想法、分享经验、开放观点和提供洞察来帮助大家成长为好的SM。基于调整后的新目的,我们把SM社区从我们部门扩展到整个组织。我们建立了邮件组和定期聚会来支持社区。我们还做了一些安排来培育它。一些SM和直线经理作为榜样来展示如何在社区里表现得当;我们分发好的书籍并鼓励读后分享和小组学习;我们介绍内部社区连接上外部的Scrum中国社区;等等。随着时间的推移,大家养成了学习的习惯,从而进入到自我成长的阶段。那正是可持续性的来源。SM和直线经理个人的持续改进带来团队和组织的持续改进。而且当他们开始贡献到更大范围中,就形成了正向的增强回路。


总结


我们的初衷是想要更多灵活性和更好聚焦,为此我们创建了客户导向的产品待办列表和团队,以便我们作为一个组织能够每个迭代都开发出潜在可交付的产品增量。在这个上下文中我们实验了如何带领自管理团队,并有如下发现。


成功的变革既需要愿景又需要脚踏实地。尽管最终通过自管理会降低管理投入,我们不应该低估引入变革时的管理投入。尽管从长远看我们希望能够涌现出SM,我们最好不要一开始就自己选出SM;等等。


要想可持续,就需要在拥有服务型领导力的组织管理和自管理团队之间具备一致性。虽然常识说在以指挥控制方式工作的管理者和以带领辅导方式工作的SM之间存在冲突,并建议分离这两个角色,当考虑可持续时这样想却是有问题的。没有改变组织的管理层,自管理团队更多只是偶现。当管理者改变后,原先的冲突也就消失了。


最后,可持续性来自于人的改变。没有大多数人在自身层面的持续改进,就不可能有团队和组织层面的持续改进。

以上是关于管理者作为ScrumMaster的主要内容,如果未能解决你的问题,请参考以下文章

关于ScrumMaster

优秀的 Scrum Master 应当是仆人式的领导

Scrum管理

Scrum master之如何提高晨会效率

SCRUM之Sprint燃尽图实例分析一

Scrum