你刚上了 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?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论