Mark Balabanian 是 Accunote 公司新任命的 COO,他问了这样一个问题,管理者能为 Scrum 团队做出什么贡献?根据以前他和 Scrum 团队的接触,他认为 Scrum 只是一个工具,保护开发人员免受管理层的干扰,强迫管理层从开发人员的角度与开发人员打交道。为了提升对 Scrum 的理解,他阅读了 Ken Schwaber 和 Mike Beedle 合著的《敏捷软件开发──使用Scrum 过程》一书。然而书中并未详细介绍管理层的角色,所以Mark 很是疑惑他应该怎么做。
Cory Foy 建议管理层需要做两件关键的事情:愿景以及公司层面的支持(比如扫除障碍)。对前者,Cory 建议效仿丰田的首席工程师(在《丰田产品开发体系》中有详细介绍)。在 Cory 看来,首席工程师应该有“愿景和战略,并有足够的胆识和能力把它转换成日常的概念”,也能够在所有的产品和项目中推行一个共同的目标和愿景。他见过一个模型就是这样做的,这就是流程 / 目标模型:
其概念是这样的,根据市场差异以及紧要程度对所有特性进行排列。其关键是不应有什么东西位于坐标的右上象限──这通常是指你在布告栏上贴的东西。从公司高层的角度来看,需要有人确保组织在正确的时间忙正确的事儿,并且能够交付正确的价值。
Peter Stevens 对 Cory 的观点进行了总结,提出了针对管理层的 3 个要点,然后他还自己加了一条:
- 给整个公司或者部门提供未来的发展愿景、现在的工作重点以及工作流程
- 创建高效的生产环境,清除遇到的障碍
- 创建追求卓越的文化──扩展开来包括:诚实、开放、勇气、信任以及财政责任
- 有自知之明(我认为这与诚实有关)
有些顶级管理者是受人尊敬的长者,在各自领域有着丰富的经验以及深刻的理解。我想这就是丰田为什么会设置首席工程师。而其他一些人通常庸碌无能,甚至颐指气使,不但不能解决问题,反而使问题更加糟糕。
John Galvin 给了一些建议:
- 敏捷不仅仅是开发的问题,而要应用到整个组织。如果开发团队敏捷了,但是产品管理部门没有,那么他们会拖开发团队的后腿。
- 敏捷需要公司文化做出很大的转变,这既包括开放也包括诚实。对需要投入的工作量不能小视。
- 每个部门都会受到影响,HR 需要新的方式进行绩效考核,职业规划等等。
最后,在文章《 The Manager’s Role in Agile 》中,Lyssa Adkins 和 Michael 提出可以这样检查敏捷的管理者:
- 你是否积极推进公司变革来支持敏捷的价值观,并着手打造一个价值交付至上的文化?
- 你是否在组织层面消除了敏捷团队的障碍?与管理者相比,他们是否认为你不像经理,而更像一个教练和领导者?
- 你是否能够在团队之间有效分配资源,使得团队拥有最大的交付价值的能力,而不是在努力争取对资源本身的使用?
- 你的绩效管理系统能否引导团队发挥最大功效,并能公正评价个人以及团队的贡献?
- 你是否采用度量的方式帮助团队提高工作成果,并帮助高级领导者做出决定以提高价值交付程度?
- 你的组织做项目组合决策时,是否基于价值而不是局限于已有的计划以及预算?
- 你是否帮助内部合作伙伴建立精益流程,以与敏捷团队保持同步,而不是忍受伙伴们拖慢开发速度呢?
- 是否鼓励供应商使用敏捷方式工作?外包对你的敏捷团队有所帮助还是净拖后腿呢?
除此之外,不知道你有没有好的建议给 Mark 呢?
InfoQ 上已有的相关内容:敏捷组织中经理的职责是什么?, Mary Poppendieck on The Role of Leadership in Software Development , Managers in Scrum 以及 Collaborative Leadership and Collaborative Management 。
评论