现在，大多数组织都使用敏捷软件交付模型，其首要目标是尽快交付新功能。
我们不妨思考一下这些统计数字：由Digital.ai于2020年5月发布的《第14届年度敏捷方法现状报告》发现，有95%的受访者表示自己的组织有实践敏捷方法，而这样做的首要原因是为了加快软件交付，增强处理不断变化的工作重点的能力并提高生产率。
尽管这些受访者抱有如此宏伟的目标，但是敏捷专家和敏捷实践者纷纷表示，许多组织并没有达到它们所追求的速度，因为它们对实践中的持续性问题视而不见。
Scrum.org的首席执行官Dave West说：“人人都说自己在实践敏捷方法，但很多人其实并没有做到，或者做的不尽如人意。”
那么，组织到底在哪些地方做得不尽人意而自身又没有意识到呢?下面来看看十个常见的自欺行为，这些行为仍然会降低软件的交付速度。
1. 我们之所以敏捷，是因为我们使用各种术语
West发现IT团队采用了敏捷方法的那套话语体系，例如将项目经理称为Scrum主管，将工作组称为部落。诚然，使用合适的术语也许很重要，但这往往只是表面的变革。这些步骤必须得到组织重组的大量工作的支持，从而使已经完成的工作与已经安排的新职位相匹配。
West说：“人们常常做相同的事情，只是称谓不同罢了。他们也许更改了名称，但并没有更改工作要素。而且大多数人为实现这一目标只是做了口头承诺。”
第一资本(Capital One)的技术副总裁Christine Hales对此表示赞同。
Hales说：“这确实是一种文化变革。如果你将其视为一堆流程和工具来使用，那么你就会错过真正可行的解决方案。人们需要以团队的方式进行不同的工作;这就是文化的转变。”
2. 技术人员不需要接受工具和过程变革方面的培训
多年来，德国的金融机构德国中央合作银行(DZ Bank)引入了一系列技术来支持长期的开发运维(DevOps)实践，但总部位于德国法兰克福的开发运维负责人Henning Ehm发现，采用此类工具是漫无目的的。
Ehm说：“我当时在想，‘我在做一些有益他人的事情，我创建技术，然后他们以适当的方式使用技术。’但是却有很多人抵触技术。”
IT领导者往往会认为自己的技术人员会自觉地利用最新的工具并加大使用力度，这种看法并不罕见。但是，正如Ehm所了解的那样，技术人员也需要培训，而且也要从变革管理的策略中受益。
Ehm说：“工程人员喜欢反复钻研，但是要想真正发挥工具的潜力并将其引进流程中，这是艰苦的工作，你必须在变革流程上孜孜以求。如今，我更加关注员工本身，更加关注如何使他们处在一个将技术发挥到极致的场合。”
3. 拖沓的会议
敏捷实践放弃了冗长的正式会议，转而倾向于短暂的集体会议和类似的活动，但是积习难改。例如，Ehm说，他发现，一些本该持续15分钟的Scrum会议却持续了45分钟之久，与会者利用这段时间来解决所有它们所关注的问题和话题。
Ehm说：“会议必须有一个非常具体的目的，但很多人对此并不习惯”。他说，管理者需要让团队知道这样一件事，即在采用敏捷方法并需要管理者强行对时间和话题施加限制时，那就要让他们知道会议真正的运作方式。
Ehm说：“现在，我们在会议上仅讨论一件事。”
4. 只要能自由选择工具和流程就永远能提高速度
尽管现代实践鼓励各个团队选择适合自己的方法，但美国运通全球商务旅行(American Express Global Business Travel)的工程总监Amit R Bhandarkar却认为这种方法存在弊端。
Ehm说，他的团队最终使用了不同的持续集成/持续交付(CI/CD)工具，其中一些工具使用开源的解决方案，而另一些工具则使用由不同供应商提供的产品。“他们以不同的方式实现了相同的结果并且影响了敏捷性;Bhandarkar说：“有些团队表现十分出色，而另一些团队则在苦苦挣扎。”
作为回应，开发团队进行了标准化，转移到一个高度一致的环境中，这个环境能维持高度一致的成功率并减轻了开发人员的维护负担。
Bhandarkar认为这是一个经验教训。“只要有选择，你就必须对自己的方法进行规范;无论这是你想要的特定方法或是冲刺的时间，你都希望保持规范性和一致性，以便每个人都彼此同步”，他这样说道。
5. 我的团队足够灵活
贝恩公司(Bain & Co.)的合伙人兼《正确实施敏捷方法(Doing Agile Right)》的合著者Steve Berez曾经与一家航空公司合作，该航空公司需要工程师为飞行操作创造各种新的功能，同时需要减少客户系统的工作。但是能够进行飞行操作运营的工程师数量有限，这使IT部门对不断变化的业务需求的响应能力大大降低。
Berez说，这是一个十分普遍的问题，他还补充说“工程师不是说取代就取代的。”
Berez说，首席信息官可以通过在业务的不同部分增加对通用技术的使用以及对员工的交叉培训来解决此问题，以便员工可以使用多种技术。
Berez解释说：“这往往意味着使用微服务进行新的开发任务并对那些微服务使用相同的开发语言，即使在不同的功能领域也是如此。”
6. 该规则不适用于我们
与所有方法一样，敏捷框架主张使用一系列最佳实践。
但West发现许多组织并不遵循某些规定的流程，它们认为自己不受这些流程的限制——之后却想知道自己为什么没有获得期望获得的好处。
例如，West已经发现组织从敏捷团队中排除了一个特定的业务组(例如市场营销)，理由是这在他们的公司中是行不通的，因为他们的流程太独特了，而实际上这只是一场没有人愿意为之奋斗的地盘之争。
Berez说：“‘我很特别’是‘我无法解决这个问题的绝妙借口’。”
West还说：“每个人都是独一无二的，但现实并非如此。诚然，每种情况都是独一无二的，而且一个模型并不能适用于所有的情况，但基本原则却都适用。因此，如果你要打破敏捷原则，那么你必须明确说明你为什么要这样做并了解这样做的后果。”
7. 光是流程变革就足够了
技术研究和咨询公司信息服务集团(ISG)的合伙人Prashant Kelker说：“目前，人们过于关注敏捷方法和仪式，以至于忽略了结构。”
Kelker说，企业里的敏捷倡导者还需要考虑如何重组部门和产品，例如确定这些要素是否以客户或流程为中心。
Kelker承认，这是一个很难应对的方面。他说：“一旦你开始谈论结构，你就会专注于自我，职务，员工的职业和职业发展历程”，但他强调结构问题仍需解决。
8. 我们的预算流程不会拖后腿
尽管大多数组织都采用了敏捷方法，但是管理专家说，许多组织没有意识到更新长期预算惯例的必要性。
Berez说：“我们在许多组织中发现了这样的情况，即它们追求新商机的过程花了太长时间。当他们期望的价值不存在时，停下正在开展的工作又花了太长时间。这往往是因为许多组织每年依然为项目提供资金。”
Berez说，最成功的敏捷组织已经发生了转变，即从决定每年资助哪些计划变为实施一个预算流程，该流程随着工作的进展并证明了自身的价值而更为频繁地分配多笔小额资金，这一过程类似于风险投资。而另一些人则使用这样一个流程，在这个流程中，获得授权的产品负责人会使用持续一段时间的资金来交付特定业务成果。
Berez说，这种预算方法“创造了更大的灵活性和敏捷性。”
9. 我的合作伙伴和供应商也不需要敏捷方法
IT领导者通常认为，对自己的团队和内部流程进行变革将使他们能够快速，灵活地按照业务部门和市场的要求交付新功能。
但是，这还不够，Kelker说。他们还必须让合作伙伴参与进来。
Kelker补充说：“如果你与供应商签订的合同只允许瀑布式方法怎么办?如果你的采购方式是计划生成运行(plan-build-run)怎么办?如果你的采购任务不允许使用开发运维怎么办?”
Kelker说，如果企业的IT团队不能让供应商和合作伙伴效仿，那么他们就无法将敏捷方法的收益最大化，直到能让供应商和合作伙伴效仿，他们才能将敏捷方法的收益最大化。他们Kelker指出，与第三方供应商签订的IT合同必须这样起草——确保各方都在使用敏捷方法以快速交付各种新功能并不断做出改进，而且付款方式能够为这一举措提供支持。
10. 我们实施了敏捷方法，所以我们很棒
West曾向一位高管询问该公司的Scrum实践的效用，那时他正在与一家软件公司合作，其目的是扩展其敏捷实践。这位高管不屑一顾，称自己的公司已经采取了这些措施，他认为Scrum的做法(就像公司随着时间的推移采用的其他敏捷原则一样)已经落实到位。尽管他的公司在几次单独的冲刺之后未能交付产品，但他认为这种思路并没有什么不妥。
West说：“他们认为敏捷是可以做到并完成的：这个问题显而易见，但是因为太棘手而没人理会。他们完全忘记了持续改进这一要点。如果你对此视而不见，如果你没有制定继续改进敏捷实践的计划，那么你最终一定会遇到问题。”
