Scrum之类的框架非常适合解决业务问题，并且公司不断过渡到敏捷以实现目标。但是，如果他们忘记了敏捷只是一种方法论（一种实现目标的手段）而不是目标本身，就会出现问题。
斯科特-邓恩（Scott Dunn）写了一篇很棒的文章，讲述了与管理层突然"变得敏捷"的决策有关的陷阱（和恐惧）。它反映出它是一个简单的实现方式（如更换供应商），而不是一个需要在观念上进行重大改变的框架，这是一种错觉。
"亚马逊正在这样做。"
这些都是很好的指标，表明企业尚未明确定义为什么要使用敏捷，以及"为什么？" 与公司合作过渡到敏捷或教学认证的Scrum课程时，这是我首先要提出的问题之一。
我经常得到诸如以下的答案：
我们想迅速适应变化
我们要不断改进
我们想更定期地交付
从表面上看，这些听起来像是伟大的目标，并且与我们从敏捷方法学中期望的结果一致。
但是，即使你没有明确定义目标，但即使听起来不错的目标也会引起问题和挫败感。
假设我的朋友告诉我他想在未来12个月内再赚10万美元。我可能会鼓励他对这个目标进行压力测试，看看这是否是他真正想要的。
"五个为什么"是一种发现问题的根本原因的公知方法，它也可以很好地发现追求目标的根本动机。
如果我问我的朋友为什么他要这10万美元，他可能会回答说这是为了改善自己的地位，或者他说他想彻底改造自己的房屋。
如果我们再加上一个"为什么"，我们可能会发现更深层次的关于这些事情对他而言重要的内容。然后他可能会说地位对他很重要，以向他的父母证明他的成功。或者，他想进行改造，以便能在一天工作结束时回家会很高兴。
当你继续研究为什么某些重要内容时，你可以开始回顾最初的目标并提出以下疑问：这是正确的目标，并且定义明确吗？
例如，也许我的朋友不需要10万美元就可以向父母证明自己成功了，也许他只需要一些生活指导就可以意识到自己足够好。也许他一天结束以后想要回家所需要的所有东西都是问候他最好的朋友。
经过一番讨论，我的朋友决定他绝对想要的就是现金。
他应该如何实现呢？
他可以抢银行。或通过庞氏风格的加密货币骗局获得资金。
他应该考虑那些选择吗？
好吧，由于我的朋友不是犯罪策划者，所以他很有可能会被抓住并失去自由。他也是一个非常体面的人，所以犯罪的想法可能会让他不高兴。
大概不是。
显然，我们认识到，除了选择正确的目标之外，他还需要想一下如何实现该目标（例如不违反法律）以及不损害对他来说很重要的事情（例如他的自由和价值观）的指南。
我认识一位高级副总裁，他想利用Scrum改善协作。
对于这种敏捷框架而言，这是一个完美的目标。但是，他还认为，只有团队实际合作才能实现协作。结果，他把每个人都搬进了一个狭窄的小房间，并坚持所有的工作和讨论都在那儿进行，整个团队都参与其中。
这不仅不舒服；这也意味着以前在家里工作了几天的一名会员现在每天要往返三小时。
士气和工作质量开始受到影响。当我进来看看为什么敏捷对他们不起作用时，我首先问他为什么要改善协作。
他告诉我，他希望团队成员：
了解其他人在做什么，找出差距，或查看成员在哪里过度工作，以便他们可以互相帮助
自信而迅速地讨论问题的解决方案
以简单明了的方式相互交流
而且我们意识到，这些东西实际上都不需要任何人坐在别人旁边。
副总裁再次审视局势，意识到"协作"并不意味着必须坐一起，而且我们能够重新审视他们为实现实际目标而可能采取的不同方式。
我与一个刚加入团队的Scrum Master一起工作。当她发现他们修改了一些规则时，在她眼中，他们没有正确地执行Scrum。作为Scrum Master，她觉得纠正团队，确保每个人都以正确的方式做Scrum是她的职责。
为此，她仔细研究了规则，强调了团队的错误并建议他们应该怎么做。但是她推得越多，推倒的人就越多，这变成了无休止分歧的有害环境。
我问她为什么强制采用这些工作方式如此重要。她回答：
"因为那是我以前与以前的团队一起工作的方式，所以我们真的很成功。"
我请她描述该团队的情况，并分享她为什么认为他们在一起表现很好。
"我们做到了。即使我们犯了错误，我们也是彼此的啦啦队。我们知道彼此的长处，我们从不担心踩脚，我们真的很乐意进去并尽自己最大的努力。"
当我们退后一步时，我们发现她对规则的严格性造成了紧张、不信任和生产力下降。她的总体目标是成为一支高效能的敏捷团队，但她的短期行动与之直接冲突。
如果你想避免类似的敏捷问题，请参考以下建议：
如果你的组织正在向敏捷过渡，请鼓励经理在可能的情况下对这些目标进行压力测试。保持好奇：找出真正重要的内容。消除歧义性与团队协作所要实现的模糊性，这样你就可以通过自己的方法来发挥创造力，而不是被任意的规则所束缚。
考虑一下你愿意支付的费用，以及你不会受到损害的地方。团队士气重要吗？吸引更少的客户以实现承诺，提供更可靠的服务并建立更多的重复业务是否更好？
我最喜欢的非敏捷书籍之一是Daniel Coyle撰写的《文化守则》。在其中，他研究了使某些团体成功的因素，并向领导者展示了如何建立凝聚力、积极进取的文化。在运动队中，他发现成功通常与团队成员做出的许多无私的传球有关，与个人如何将团队的成功置于个人荣耀之上。
我认为成功的敏捷团队也会发生同样的事情。与我一起工作的一个团队按时交付，但显然设计师天天加班。成员在计划和挑选任务时没有考虑自己的个人能力，而是开始考虑团队能力。他们认为，如果一个人在挣扎，他们会都很难受。开发人员放弃了自己的一些积压项目，花一些时间学习设计并尝试提供帮助。团队在短期内降低了速度，但从长远来看，由于他们拥有更加广泛的技能，他们开始提供更多的东西。如果他们只是专注于在每次迭代中提供尽可能多的功能，那么这种长期的进展可能永远不会发生。
我希望知道你的经历。目标是否明确定义和理解？还是你曾经觉得自己正在遵循以流行语为基础的商业计划？使用Scrum和敏捷解决业务问题或实现目标时，你发现什么效果很好？
所有你的敏捷是怎么样的呢？ 是否有关注到最终目标呢？ 敏捷转型过程中你还有哪些困惑呢？
欢迎留言讨论......
本文首发于 Bob Jiang的博客 ，转载请联系 Bob Jiang