写点什么

如何把 Scrum 推销给管理层?

2010 年 10 月 14 日

hspace=5你刚上了 2 天的 CSM 课程,满脑子的新想法,想要去付诸实践。最近这段时间,你的公司在交付和质量方面都存在问题,好像进行改变已是万事俱备,只欠东风了。于是你走进老板的办公室向他推销 Scrum,但他对此并不感兴趣。你该怎么办呢?这正是近来在 Scrum Master 邮件组里讨论的一个问题。

Rafael Fuchs 所遇到的就是这个问题,他想引入敏捷开发但得不到管理层的支持。于是他和他的团队打了擦边球。他们没说要变成敏捷开发,而是称自己仅仅做些小小的改变。每当管理层问起时,他们就会说:“这些新鲜玩意是用来改进我们的工作的。”但他们绝不会说这和敏捷有关。几个月后,他们揭开面纱,摊牌说这就是敏捷开发,并且指出现在一切进行得有多顺利。Rafael 认为,有些管理层是抵触改变的。在这种情况下,他认为最好先行动起来,等你有了结果以后通过结果来谈改变。

Steve Ropa 则提醒道,有些不愿意尝试敏捷开发的管理者所带来的问题要大得多,他们可能破坏那些像 Rafael 一样的人所做的尝试

Roy Morien 建议,如果管理者不负责日常活动,那么就直接采用敏捷开发吧。“你只要改变你的开发方式,并且经常地、定期地给他们展示结果,这样可行吗?我肯定他们会对你策略改变有些惊喜和好奇,但我的经验证明‘用户’始终看重的是及早的、经常性的交付”。

Alan Dayley 提醒我们,大多管理者不怎么关心方法论的问题。他们更关心交付价值以及无发布事故。他建议把问题从怎样引入 Scrum 转换为怎样解决管理者当前面临的问题。

与 Alan 不约而同, Brian Lawlor 发现他的秘密王牌也是去询问管理者,问他们是否想要更频繁地看到项目交付,例如每个月。他通过展示每个月更好的 ROI 获得了管理层的信任。

笔者认为:

管理者不可能轻视改变。他们想要高质量的软件,并且能够定期发布。这是业界常见的一个问题。我的真言是:推销敏捷开发?不要推销!而是去倾听。你的经理也有需要解决的问题和烦心事,问题是它们是什么?你不能告诉位高权重的人(或者就那件事而言有决定权的人)你想要什么,而应该发现他们需要什么。通常这会归结到“更高的质量”,“更快上市”。如果你运气好,他们两个都想要。我们不一定要惊天动地改进方法学,相反,进行一些小的变化也能帮助把刚刚说到的两者中的某项做得更好。在此,我们不是在寻求解决全部问题,而是需要小小的胜利。你和你的团队需要展示的是,通过一两个星期的学习,你们能让事情更好一点。你每一次这样的努力,都会为下一次多赢得一点信任和自由空间。最终你将获得大展拳脚的机会来完成更彻底的转变。 关键是:询问你的经理他们关心什么?聆听他们的需要。专注于交付他们所重视的。最终将体现出你的价值。

Don MacIntvre 推荐了一篇 Mike Cohn 的博文:你如何从这里出发实现敏捷?迭代进行。Mike 认为,想要实现敏捷,你应该建立一个需要改进/ 改变的待办事项列表,迭代进行。同时有效地运用Scrum 实施这一切。

查看英文原文 Selling Scrum to Your Manager?

2010 年 10 月 14 日 02:32942
用户头像

发布了 114 篇内容, 共 24.8 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
  • 敏捷教练的十大技巧

    《敏捷教练》的作者Rachel Davies和Liz Sedley做了一个有趣的演讲,名为“敏捷教练的十大技巧”。可能这个演讲的主题被称之为“敏捷教练常犯的10大错误”也不错。

  • 敏捷是如何使你跑得更快?

    希望能够更快地交付软件,是企业在回答为何采用敏捷软件开发时经常提到的原因之一。那如何使用敏捷,才能更快地交付软件呢?

  • 荷兰铁路在采纳敏捷和精益中的做法

    敏捷和精益遵循近似的哲学思维模式,精益可扩大敏捷,反之亦然。敏捷实践适用于开发复杂产品,而精益实践适用于发现一些可降低流程中浪费的机会。精益有助于以客户的角度查看从开始到交付的结果情况,而敏捷则支持向客户交付最优的价值。

  • 持续改进不能止步于回顾

    如果你希望持续改进,则可以从回顾开始,但不能止步于回顾,还要进行变更管理、文化变革和创新。为了促成组织变革,最重要的事情是培养新的习惯及变革文化。

  • 故事案例(上):新手上路,如何引入变化?

    今天,我会给你介绍一些每个人都可以学得会的实用方法,帮助你更好地引入变化,尽可能地降低你在尝试过程中的碰壁概率。

    2019 年 11 月 26 日

  • 教练 /Coach 如何赢得团队成员的信任?

    一个来自中国的敏捷教练在LinkedIn敏捷教练组中提问说,如何赢得他现在新敏捷团队的信任。他提到现在他的团队成员认为他是一个管理者,不想和他分享太多的信息,因为认为他是检查他们绩效的人。很多人给出了自己的答案,但是不知道这些欧美教练的建议是否适合中国国情!

  • GlobalLogic 自底向上的组织级敏捷转型

    在敏捷东欧2016大会上,来自于GlobalLogic的交付经理Yuriy Koziy主张组织变革应该从团队层面开始,而非始于高层管理者。他召集了一个由志趣相投的工程经理和敏捷教练组成的团队,作为变革促进者从内部转变组织。

  • 采访和书评:实用的大规模敏捷开发方法

    《实用的大规模敏捷开发方法(A Practical Approach to Large-Scale Agile Development)》一书讲的是应用敏捷和精益原则的故事,这个故事发生在惠普Laserjet Futuresmart固件的大规模软件开发项目中。我们采访了该书的两位作者Gary Gruver和Mike Young,内容包括敏捷原则、管理变更、分布式团队之间的协作以及使用敏捷的好处。

  • 园中那颗“烂苹果”

    过去几天,Scrum Development Yahoo讨论小组有个激烈的讨论,如果团队中某人“表现欠佳”,你该怎么办?针对“Rotten apple in Scrum team”这个帖子,回帖多达130多篇,讨论也五花八门,从对该问题的建议,到团队士气以及谁来负责的讨论,再到怎样衡量个人这样的经典争论,以及怎样识别一个团队是否是真正的“团队”,当然还有一些其它的内容。

  • 经理权:如何有效使用经理权?

    有时候,管理者就是要落地经理权,强制聚集力量来交付业务价值。经理权要慎用,用了就一定要见效,才能树立威信,具体方法有……

    2020 年 8 月 24 日

  • 开篇词 | 你为什么需要学管理?

    与其说管理是一个职位,倒不如说管理是一组能力,是每个人职业发展中都绕不开的话题。本专栏会为你阐释管理的方方面面,从而让你心无旁骛地走上管理之路。

    2018 年 8 月 13 日

  • 敏捷反模式的存在及应对方法

    如果置之不理,敏捷反模式会影响到组织、士气和质量。要解决问题,第一步就是要承认痛点的存在。

  • 让 Scrum 之树长青:战胜紧张和恐惧

    团队迅速紧握像Scrum这般简单有效的东西时,与其相关的改变可能引发担忧。采用Scrum时的问题普遍存在,而细微玄妙之处也几无可避免地出现。了解了本文列举的问题,你就可以为之做好准备。如果自己碰到这些问题,感觉不会那么糟——它们本来就很普遍。

  • 诚实——是敏捷的价值观吗?

    在一篇引人深思的博客中,Declan Whelan引用了他从Mishkin Berteig那里了解到的想法:诚实,是敏捷团队之所以成功的一个(不言而喻的)原则。这个想法很简单:如果个人不够坦诚,绝大部分的敏捷实践无法发挥作用。

  • ScrumMaster 项目面谈诀窍

    ScrumMaster或者迭代经理在敏捷团队里面是一个关键角色,而且,对于ScrumMaster,选择与哪个组织合作或者与哪个团队共事是非常重要的——在考虑是否接受一个新项目时,很重要的是创造一个取得成功的环境。本文提供了一些面谈时的建议,可供ScrumMaster考虑是否接受项目或团队时参考。

  • Scrum 看板:是进展,还是矛盾?

    与看板有关的研习班、课程和会议越来越多,有实用精神的敏捷专家们开始研究这种来自精益的方法能为团队带来什么。人们提出的吸引人的好处包括:揭示瓶颈、让团队体验更多的“流畅”状态而变得更为快乐。但是有些思想者们警告说:看板那种不紧不慢的方式,就像是让超人绵软无力的“氪星石”,不能满足Scrum对于去除障碍的迫切需要。

  • 第 89 讲 | 刘俊强:做好一对一沟通的关键要素(下)

    本文将跟大家分享更多实践,包括如何在一对一会议中倾听对方需求并分享你的需求,如何评估会议结果并跟进完成情况等内容。

    2018 年 9 月 18 日

  • 我讨厌说说而已的敏捷

    现在总有人说“敏捷死了”,然后又说“我们是开玩笑的”。他们想表达的意思是,敏捷本身并没有死,是我们的敏捷实践方式出了问题。那么怎么做才是对的?或许真正的敏捷只存在于理论之中?有时候我也会这么说,但现在已经感到厌倦了。

  • 开篇词 | 一个技术总监的管理“自白”

    我发现技术管理最有效的学习方式有两种:一种是在实战中自己反思和总结;另一种是有人结合真实的案例,一对一地给你分享经验。

    2020 年 8 月 24 日

  • 如何物色和培养核心人才?

    本文探讨如何选拔和培养人才,其中重点探讨如何授权。

    2018 年 10 月 2 日

发现更多内容

食堂就餐卡系统设计

饶军

架构师如何做架构总结

Karl

ARTS-WEEK2

一周思进

ARTS 打卡计划

食堂就餐卡管理系统

孙志平

ARTS(2020-06-01/2020-06-07)

天行者

ARTS 打卡计划

图解Java垃圾回收算法及详细过程!

攀岩飞鱼

Java JVM 虚拟机 垃圾回收机制

极客时间-架构师培训-1期作业

Damon

程序员的晚餐 | 6 月 7 日 豆腐年糕

清远

美食

ARTS打卡 week 2

猫吃小怪兽

ARTS 打卡计划

HBase 常用 Shell 命令手册

Rayjun

Java HBase

架构师训练营第一周作业

小树林

食堂就餐卡系统设计

刘志刚

ARTS打卡Week 03

teoking

ios LeetCode

dnsmasq-域名访问及解析缓存

一周思进

SpringBoot基本特性以及自动化配置-SPI机制

攀岩飞鱼

Java 微服务 Spring Boot SpringCloud

架构方法学习总结

飞雪

Element-UI实战系列:Tree组件的几种使用场景

brave heart

vue.js 前端 Elemen

LeetCode 769. Max Chunks To Make Sorted

liu_liu

LeetCode

程序员陪娃系列——数学启蒙趣事

孙苏勇

程序员人生 陪伴

SpringBatch系列之并发并行能力

稻草鸟人

Spring Boot SpringBatch 批量

架构师训练营第一周学习总结

刘志刚

食堂就餐卡系统设计

飞雪

第一周UML作业

吴建中

极客时间 - 架构师训练营 - week1 - 作业2

jjn0703

极客大学架构师训练营

每周学习总结-架构师培训一期

Damon

食堂就餐卡系统架构设计

Karl

愚蠢写作术(3):如何把读者带入迷宫深处

史方远

学习 读书笔记 个人成长 写作

SpringBoot整合Quartz实现任务定时

北漂码农有话说

SpringBoot 2

面试了 6 轮 Google中国 之后,还是挂了

石头

面试 谷歌Google Java 面试 经验分享 面经

软件建模与设计文档

大雄

UML

架构师训练营第一周作业

芒夏

极客大学架构师训练营

NLP领域的2020年大事记及2021展望

NLP领域的2020年大事记及2021展望

如何把Scrum推销给管理层?-InfoQ