在上一篇文章《什么是Scrum–敏捷框架Scrum系列(1)》中,有这样一段文字:
一种改变组织架构的破坏性框架
Scrum的交付周期很短。要在这很短的周期内对需求作出反馈,对个人、团队、组织提出了很大的挑战。如果组织架构无法适应这种开发模式,我们不应修改Scrum来掩盖这些问题,而应鼓励调整组织架构来解决这些限制。否则,很难从Scrum框架收益,甚至不如运行Scrum之前。
有网友私下问我:开发团队进行敏捷开发,还需要调整组织架构?这成本太高了吧。我回答:是的,需要调整组织架构,否则,很难从Scrum框架受益,很有可能会在敏捷框架和组织架构的矛盾之中左右为难,因而付出更高的成本。
组织架构与Scrum框架矛盾的例子
1. 某团队采用敏捷开发框架,但是产品经理随意变更需求(如图1)。
图1 微博上某大V抱怨随意变更需求
在这个案例里,产品经理随意变更需求,无论是产品经理不懂还是不愿遵循Scrum,其本质原因都是组织架构的问题导致的。产品经理对需求有绝对的生杀大权,可以要求临时变需求。在提出变更需求之后,团队无法拒绝;在提出紧急上线(意味着当前交付周期不是固定的)之后,团队必须紧急上线。在这个组织架构里,产品经理处于绝对优势地位。
在Scrum开发框架里,产品负责人(Scrum开发框架里没有产品经理)有权限决定需求的优先级,无权要求开发团队改变交付周期(即迭代周期,一旦确定下来就固定不变),如果想临时变更需求,需要和敏捷教练(Scrum Master)沟通,在敏捷教练评估并认为可以变更需求之后,才可以变更。
在Scrum中,产品负责人与敏捷教练、团队开发人员处于平等的地位,这需要组织架构给予支持。如果地位不平等,即使大家都懂Scrum如何运行,仍旧很难推进。
2. 某业务人员向开发部门主管抱怨:“既然你们是敏捷开发,为什么我提一个很简单的需求,你们总是说要下个月才能完成?”于是,开发部门主管对团队说:”我们软件开发还不够敏捷,现在是4周一个迭代,以后要争取做到1周一个迭代。“
这是我听到过的真实案例。在这个Scrum团队有敏捷教练,有产品负责人。产品负责人的需求来自各个业务部门。业务部门的需求提出人不懂Scrum,开发部门的主管也不懂Scrum。
业务部门对Scrum的各种误解,导致对开发部门的不信任,进而向开发的部门主管投诉,开发部门的主管为了顺应业务部门的需求,转而要求团队改变迭代周期。开发团队不得不陷入各种解释的焦油坑中,越陷越深。
我们知道,Scrum团队中的每个人应该完全理解Scrum框架怎样运行,而Scrum外部的任何人都不应该阻碍团队的正常运行。若要保证这点,除了自上而下进行Scrum培训之外,更重要的,需要组织架构支持这种运行方式,否则所有对Scrum的诉求都只是一个美好的愿望而已。
组织架构与Scrum的矛盾
最近两年接触的环境和以前大不相同,感觉有些企业文化和Scrum相冲突的地方很多。很多时候,技术部门的主管听说了Scrum, 对Scrum一知半解,觉得很有用,就让下属去推行。一方面,他的某些行为会成为Scrum推行的阻碍;另一方面,某些主管对下属是发号施令型的,而不是服务型的。在这种氛围下,建立起自我管理、相互信任的团队,难度实在太高。
组织结构应如何调整
应该如何调整组织架构呢?恐怕没有千篇一律的答案,得先分析当前组织架构与Scrum的要求之间的差距,再考虑具体的方案吧。
很多年前,当我在就职于某企业的时候,经历过推行Scrum的整个过程,这种做法很有借鉴意义。
公司在中国的研发中心有多个BU(业务单元,可以理解成业务部门)。我所在的BU开发的产品全球市场占有率第一,在全球是300多人的研发团队。当时,整个BU决定推行Scrum。
鉴于整个研发团队的规模比较大,我们采用了Scaled Agile Framework(SAFe)作为开发框架。对部门进行重组,以期与SAFe框架相匹配。整个BU负责人下分成若干Division(部门),部门主管担任SPO(Strategy Product Owner,战略产品负责人);每个部门下辖4 ~ 6个团队,团队主管担任TPO(Tactical Prodcut Owner,战术产品负责人);每个团队7~9人,与Scrum要求的团队人数吻合。
在进行部门重组的同时,自上而下对团队所有成员进行SAFe基础培训,对于敏捷教练和产品负责人,除了基础培训之外,Scrum中的个角色还应参加对应的培训。在团队所有成员学习了Scrum知识后,开始实施。我们采取4周(中国国庆节、欧美圣诞节等特殊节日5周)一个迭代,所有团队遵循相同的迭代周期,在前几个迭代周期里,每个团队都有一位讲师指导Scrum的运行,直到大家都掌握了Scrum的运行机制。
在当时,大家觉得问题很多。现在回过头来看,其实已经做了非常好了。
最后,复述一遍:在推行Scrum之前,如果你的组织架构与Scrum的要求相差甚远,先调整组织架构吧。
何止要调整组织架构,一个上班要打卡的公公司不管怎么调整,肯定做不好Scrum。