• CSPO+A-CSPO直通车
  • 敏捷领导力(CAL E+O / ALJ)认证培训
  • Five_reasons_three
  • Hardware-agile-practice-20231012
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • CSM A-CSM一站式培训
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • ShineScrum捷行出版书籍
【规模化敏捷系列 4】精益快速启动--系统的改变

上期我们为大家讲述了精益快速启动-从团队到企业,我们可否自下而上地规模化敏捷方法?本期【规模化敏捷系列 4】与大家分享精益快速启动--规模化敏捷需要做系统的改变。对规模化敏捷感兴趣的小伙伴,持续关注我们哦。




规模化敏捷系列文章

1、大规模敏捷LeSS认证课Certified LeSS Practitioner

2、Scrum@Scale认证国内首次开课 | 上海 10月26-27日

3、精益快速启动--自下而上地规模化敏捷方法



 规模化敏捷需要做系统的改变 

规模化敏捷要求系统地改变组织结构和流程,从而改变人的思维模式和组织文化。


我年少的时候非常擅长打羽毛球,我和我的朋友每天晚上会打几个小时的羽毛球,然后再一起出去玩。这是一段有趣又让人怀念的时光。 后来我们几个想尝试一下新的运动,我选了网球。我希望能很快学会打网球,但是发现特别难。我发现我打羽毛球的好手法限制了打网球。很久以后我才发现打羽毛球的手法和技术跟打网球是不一样的(见图4:打羽毛球和打网球要求具备不同的工具和技术)。这两项运动从表面上看起来差别不大,但是却有着完全不同的手法,不同的运动器材(网球区别于羽毛球,球拍的形状和重量也不同),不同大小的运动场地。所以从打羽毛球转到打网球不是一个小转变,需要去了解这两项运动的区别从而做思维和结构性的调整来适应这两项运动。


图4.打羽毛球和打网球要求具备不同的工具和技术


显而易见,如果不做这些改变,从一项运动转而投入到另一项运动都会遭受挫折,无论你是多优秀的选手。这些道理是不是很明显?然而,如今很多组织也面临类似的问题。用传统的管理方法来管理敏捷团队效果适得其反,有些时候甚至毁掉了整个组织的敏捷性,虽然这是无心之过。


这里根据真实的案例来举几个例子。假设有个ACME集团,很多年前,有几个开发人员采用极限编程(XP)方法。因为他们对于开发高质量的代码很感兴趣,所以采用了极限编程,但是却缺少广泛的支持。由于没有广泛的理解和支持,很快这个团队就瓦解了。其中几个开发人员因为非常灰心而离开了ACME。而其他人则坚持偷偷地采用极限编程方法。最后大家对于极限编程的理解就只有结对编程了。


几年后,一个ACME的经理听说了Scrum,这个先进的敏捷管理方法,并且参加了Scrum Master的认证培训。她充满激情的回到公司,开始在她的团队实施Scrum,团队的士气大涨,并开始提升团队交付项目和产品的动力,业务客户非常满意,并且到处宣扬Scrum和敏捷带来好处。


自此之后,Scrum的应用像病毒一样传播到越来越多的团队,部门总监开始意识到Scrum团队比传统使用瀑布式管理的团队有更好的产出成果,Scrum团队的客户更加满意。他结合了多个敏捷团队,并担任了敏捷捍卫者的角色。在他的领导下,更多的团队开始使用Scrum,很多团队还把Scrum与极限编程实践,如重构,测试驱动开发和持续集成等方法相结合。原先的极限编程开发人员受到了很大的鼓励也不再偷偷摸摸的了,而是公开的进行他们的实践。产品质量得到了巨大的提升,基于自动化的构建和测试周期,客户反映交付更快质量更高了。在持续一年之后,这个部门由于其敏捷性和对不断变化的业务和组织需求的快速响应而闻名。


由于这是一种自下而上的对敏捷方法的应用,而传统的管理体系凌驾于敏捷团队之上,不可避免地,诸多问题也相应的产生。


问题开始于组织机构的重组,把那个成为敏捷捍卫者的部门总监划分到另外的分支。新的部门总监虽然很想支持敏捷,但对敏捷方法以及潜在的精益原则没有全面的理解。由于缺乏理解敏捷和精益的管理层的有效支持,敏捷实践开始瓦解。组织机构的重组演化成了构建在敏捷团队之上的传统组织架构的发展。所以,现在敏捷团队就面临了许多由于组织架构和敏捷方法不协调而导致的问题


组织架构和敏捷方法没有对齐的表现

  1.  敏捷方法要求小团队,(Scrum要求5-9人),而实际操作中团队平均人数达到25人。

  2. 敏捷方法要求具有全方位专业技能的团队,但是实际操作中把测试人员从一个正式集成的团队里拎出来到一个单独的测试团队隔离。

  3. 敏捷方法要求团队成员80%以上的精力集中在单个项目上,而现在团队成员却要同时参与2到3个项目

  4. 敏捷方法要求锁定一个迭代内的所有需求范围,但是一些没有经过培训的产品负责人却在不断地添加新需求。

  5. 敏捷方法要求团队成员选择自己的任务并且对任务负责,但是新来的项目经理却自行给每个成员分配任务

  6. 敏捷要求每日站会上成员陈诉自己的工作和遇到的问题,但是现在这样的会议却被用来给项目经理汇报工作进度。



你意识到这些问题了吗? 遗憾的是,这些问题都是那些中高层管理人员没有十分了解敏捷的组织中的典型问题。不了解敏捷方法的管理人员使用传统方法来推动敏捷,在敏捷团队之上构建传统组织架构,最终导致组织在敏捷实施中倒退。


最终我们的组织会演变成如图6:传统的瀑布管理凌驾于敏捷团队。


图6:传统的瀑布管理凌驾于敏捷团队


很不幸,这种覆盖模式在文化和组织之间引入了自我增强的循环。因为组织架构会驱动文化,这样传统架构会使得敏捷团队又倒退到了瀑布模式。

为了阻止倒退到瀑布式管理,我们必须加强和放大敏捷性,并超越团队层面接下来的章节会更加详细地介绍。


未完待续...


本文作者Sanjiv桑吉夫,由ShineScrum捷行主导翻译


审校: 张宁宁, 马凯, Jim Wang

编辑:刘康