关于分布式团队

scrum关注的是团队级敏捷,所以一般不会涉及到分布式团队(多地点),但less是大规模的团队运作框架自然而然就让人想到了分布式团队的问题,首先,从敏捷的基本价值观上来说肯定还是期望尽量要在同地点办公以达到高效的沟通效率,但组织架构和公司策略决定了分布式团队是不可避免的,加之目前疫情的影响也进一步促进了各种分布式团队的形成,那我们只能从一些角度尽量让分布式团队可以更好的协作:1、避免职能分散 敏捷特别强调跨职能的特性团队,如果您的分布式团队是按照职能划分地域的,那将非常糟糕,比如:产品中心在北京、研发中心在深圳、运维中心在上海,总之,我们期望的是即使出现分布式团队,在同一个地点也应该是一个具备多职能的完整团队,能够独立的交付业务价值。2、组件团队 第二种情况可能比较少见,但是也不免会出现类似的情况,就是一个地点交付产品的某一个或多个组件,但是不能完整交付产品增量,比如前端团队和后端团队在不同的研发中心。既然要组成特性团队,那就一定要具备各个组件的交付能力。3、充分利用工具 即使满足以上两点的要求,分布式团队的协作依然会遇到很多问题,那好的协作工具就非常关键了,比如在疫情期间涌现出的大量远程协作工具将大大的提高团队协作效率。
虽然以上的策略能够解决部分协作问题,但是还是建议不同地点的团队间定期同一个地方短暂聚会、工作,这样短暂的面对面合作对于团队的帮助将是非常巨大的。

04-less框架的团队协作机制_java

关于团队协作

既然less要求scrum master可以同时负责多个团队,那就要求团队应该具有较高的成熟度,所以在协作上应该具备自主性,同时组织应该为团队提供各种利于协作的环境和实践。1、环境支持 首先团队应该在一个开放的环境中工作,这个在各种管理理论中都会强调,团队不应该被环境所限制,应该注重碎片化的沟通方式,不要总是以会议的形式进行沟通,同时要注意培养分散决策的文化,团队成员有权利决定自己能把控的任何事情以期更好地为业务交付服务。2、系统思考 其次要培养团队的系统思考意识,团队完成自己内部工作的同时要关注产品整体的视角,加强跨团队产品协同,而这样的工作内容不是scrum master负责的,也不是团队代表负责的,是团队所有人共同的责任。3、工程实践 团队协作不能只依靠流程和管理约束,还要从工程实践的角度进行思考,比如:团队可以通过分支策略、在线代码评审机制、结对编程、持续集成、测试驱动开发等等实践加强各个角色间的沟通和协同,具体实践的介绍这里就不赘述了,感兴趣的可以看我之前发的文章:极限编程XP是怎样极限的?除了以上的措施我们还可以构建Cop,通过社区的力量提高团队成熟度,促进团队协作和成长!

04-less框架的团队协作机制_java

关于scrum master

前面我们一直说less中scrum master会负责更多的团队,那具体实践上有什么需要注意的或者好的做法呢?1、系统思考 上面我们刚刚说过团队应该具备系统思考能力,那回到scrum master身上也当然是一样的道理,scrum master负责多个团队就要从多个团队视角进行考量,而不同的scrum master之前也应该建立一定的合作机制,互相沟通、学习、借鉴和促进。但是有一点需要注意,scrum master要关注多个团队但并不应该代替团队做跨团队的沟通和交流,这个观点在我之前的文章中也有提到过:敏捷转型10宗罪2、渐进式调整定位

04-less框架的团队协作机制_java_03


scrum master的关注点会随时时间和组织的成熟度而改变,如下图所示,在初期scrum master会重点关注团队和po以及组织架构和机制的建立,接着需要花费大量的时间和经历指导相关角色按照敏捷的方式和思维做事,但是后续当po和团队逐步经历了守破离的阶段后scrum master对两个角色的关注度就会降低,在对相关角色进行指导时是不太会关注组织层面的,但是到了后期随着团队的产出和交付,又会把关注点放到组织的持续优化上,同时越多后期scrum master应该更多的帮助组织引入好的、先进的工程实践和管理思路,确保团队能够持续改进。