你刚上了 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?
评论